Andrew Morton wrote:
> I think that's a very good approach. Sure, it's suboptimal when there
> are three or more waiters (and they're the right type and order). But
> that never happens. Nice design idea.
Cheers.
> These numbers are infinity :)
I know, but I think Linus may be happy with the
> You need sterner testing stuff :) I hit the BUG at the end of rwsem_wake()
> in about a second running rwsem-4. Removed the BUG and everything stops
> in D state.
>
> Grab rwsem-4 from
>
> http://www.uow.edu.au/~andrewm/linux/rwsem.tar.gz
>
> It's very simple. But running fully in-k
* less one for the activity decrement we've already done
+*/
+ woken = wake_up_ctx(&sem->wait,65535,-RWSEM_WAITING_FOR_READ);
+ if (woken<=0)
+ goto counter_correction;
+
+ woken *= RWSEM_ACTIVE_BIAS-RWSEM_WAITING_BIAS;
+ woken -= RWSEM_A
>pid,atomic_read(&sem->count));
- return sem;
-
- /* come here if we need to correct the counter for odd SMP-isms */
- counter_correction:
- count = rwsem_atomic_update(-RWSEM_ACTIVE_BIAS,sem);
- rwsemdebug("[%d] corrected(%08x)\n",current->pid,c
Andrea,
How did you generate the 00_rwsem-generic-1 patch? Against what did you diff?
You seem to have removed all the optimised i386 rwsem stuff... Did it not work
for you?
> (the generic rwsemaphores in those kernels is broken, try to use them in
> other archs or x86 and you will notice) and I
Linus Torvalds <[EMAIL PROTECTED]> wrote:
> I think Andrea is right. Although this file seems to be entirely
> old-fashioned and should never be used, right?
I presume you're talking about "include/asm-i386/rwsem-spin.h"... If so,
Andrea is right, there is a bug in it (repeated a number of times)
> About the benchmark you wrote it looks good measure to me, thanks.
As with all benchmarks, take with one pinch of salt and two of Mindcraft:-)
David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
I've attached two slightly different bits of i386 assembly that achieve the
same end, but in slightly different ways. Can some one tell me why Case 1 is
faster than Case 2? Case 1 involves an extra CALL instruction.
* Case 1 has a little wrapper function that saves ECX and EDX before
David S. Miller <[EMAIL PROTECTED]> wrote:
> D.W.Howells writes:
> > This patch (made against linux-2.4.4-pre4) gets rid of some warnings obtained
> > when using the generic rwsem implementation.
>
> Have a look at pre5, this is already fixed.
Not entirely so...
There's also a missing "struct
David Woodhouse <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] said:
> > [BTW, another solution is to truly support opaque "handles" to kernel
> > objects; I believe David Howells is already working on something like
> > this for Wine?
Yes. However, it us
Alon Ziv <[EMAIL PROTECTED]> wrote:
> Obviously... since they're handles, not FDs...
> [BTW, are you using Windows' idea of storing the objects in process space,
> in a page that's inaccessible to the app itself, and passing pointers into
> this page as the handles?]
No... I grab a page in kernel
> Ok I finished now my asm optimized rwsemaphores and I improved a little my
> spinlock based one but without touching the icache usage.
And I can break it. There's a very good reason the I changed __up_write() to
use CMPXCHG instead of SUBL. I found a sequence of operations that locked up
on thi
.h
linux/include/linux/rwsem-spinlock.h
--- linux-rwsem-opt2/include/linux/rwsem-spinlock.h Tue Apr 24 10:51:58 2001
+++ linux/include/linux/rwsem-spinlock.hTue Apr 24 08:40:20 2001
@@ -1,6 +1,8 @@
/* rwsem-spinlock.h: fallback C implementation
*
* Copyright (c) 2001 Dav
> I'd love to hear this sequence. Certainly regression testing never generated
> this sequence yet but yes that doesn't mean anything. Note that your slow
> path is very different than mine.
One of my testcases fell over on it...
> I don't feel the need of any xchg to enforce additional serializ
> I see what you meant here and no, I'm not lucky, I thought about that. gcc x
> 2.95.* seems smart enough to produce (%%eax) that you hardcoded when the
> sem is not a constant (I'm not clobbering another register, if it does it's
> stupid and I consider this a compiler mistake).
It is a compil
> so you reproduced a deadlock with my patch applied, or you are saying
> you discovered that case with one of you testcases?
It was my implementation that triggered it (I haven't tried it with yours),
but the bug occurred because the SUBL happened to make the change outside of
the spinlocked reg
Linus Torvalds <[EMAIL PROTECTED]> wrote:
> - nobody will look up the list because we do have the spinlock at this
> point, so a destroyed list doesn't actually _matter_ to anybody
I suppose that it'll be okay, provided I take care not to access a block for a
task I've just woken up.
> - list_
I had problems with XFree86 4.0 and 4.0.1 locking solidly up under Linux 2.4.x
after about 10mins until I upgraded to XFree86 4.0.2. Now it seems rock solid.
XFree86 3.3.x was always okay.
I've got a Dual-PII machine and an NVidia GeForce.
David
-
To unsubscribe from this list: send the line "un
How this for a laugh:
http://www.microsoft.com/WINDOWS2000/hpc/indstand.asp
David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at ht
I suspect part of the problem with commercial driver support on Linux is that
the Linux driver API (such as it is) is relatively poorly documented and seems
to change almost on a week-by-week basis anyway. I've done my share of chasing
the current kernel revision with drivers that aren't part of
[EMAIL PROTECTED] wrote:
> hey, I hear that wine ( windows emulator ) can port into kernel and make
> it running faster, How can I do it?
> or anyone can make a patch to add wine code into kernel?
> waiting for answer, Thanks
I've been writing one to provide all the Windows kernel objects in
Linus Torvalds <[EMAIL PROTECTED]> wrote:
> Also note that the merging tests were not free, so at least under my set of
> normal load the non-merging code is actually _faster_ than the clever
> optimized merging. That was what clinched it for me: I absolutely hate to
> see complexity that doesn't
read into making this call,
with all other threads SIGSTOP'd until completion (& death) or failure (&
resumption)? (though that's probably better done in userspace)
David Howells
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
/O commands it checks for first, before calling the supplied
service routine.
Other methods that have been mentioned include persuading Linus to reserve a
syscall number specifically for this purpose, and having the module supply a
handler for it.
Cheers,
David Howells
begin 644 wineservmod.tar.bz
ly proving very useful, at least to me... It allows me to use PVCS
(a horrible java-based version control system for windows only) at work whilst
running Linux. It also allows me to run MSDEV without having to reboot.
David Howells
-
To unsubscribe from this list: send the line "unsubscribe
Tigran Aivazian <[EMAIL PROTECTED]> wrote:
> how about the classical standard way of "getting to kernel space", i.e.
> plain system calls? Unless you really need a huge number of new system
> calls,
Just the one... this'll take a parameter specifying the Win32 call to make:
int win32(int f
ject
handles... most of what are called "handles" are really just userspace object
handles issued by userspace DLL's.
However... for instance, the way I'm planning on implementing the registry
through this module is to have a cut down RPC server (using the RPC mechanism
a
Andi Kleen <[EMAIL PROTECTED]> wrote:
> I did not see the lock. Where is it ?
Well, on the bit functions set_bit() and test_and_clear_bit(), the macro
inserts an appopriate locking instruction into the assembly.
On the wait queue, the wait_queue structure includes
> I don't know too much abou
server, kernel
module, or Windows itself.
Of course, when I said "number of processes (not threads) * ~1020" what I
actually meant is "number of interested processed...", since any process not
interested can't actually issue the Win32 calls anyway.
David Howells
-
To unsu
there'll be a
conflict between grab and release, since the actual release is the last thing
done by the ReleaseMutex function, and the actual grab is the first thing done
by the MutexPoll function.
But you are right... It should be guarded anyway. Perhaps what I should do is
to use the owner
Horst von Brand <[EMAIL PROTECTED]> wrote:
> Lost me there. If after releasing the mutex it is free, the release was
> sucessful AFAIAC. If two threads try to do it at the same time, so what?
> Releasing an already free mutex is broken, OK. But two threads owning the
> mutex at the same time is m
[EMAIL PROTECTED] (Linus Torvalds) wrote:
> >I've done an implementation of some of the Win32 "system calls" in a kernel
> >module in an attempt to speed up Wine.
> Hmm.. I have this feeling that it would be much nicer to just implement
> the NT system calls directly.
Yes, perhaps, but as far as
me entries in the syscall table that are
> designated as "dynamically allocatable" would be a nifty trick. If the
> kernel managed these, modules coluld safely grab a few at load time, and
> then declare which indices to use via a /proc file.
My thought exactly, except that y
Passing in a buffer seems cleaner to me.
My point is that read and write have pretty well defined semantics... and I
don't think it'd be a good idea to deviate from them. A side effect of a write
that changed some of the process's memory space would be bad.
Plus, it is entirely p
'm doing it at the moment. However, this incurs a penalty
because of the the number of standard ioctl()'s the system checks for first,
before passing the command to my handler.
What Robert suggested was to use write() to do the deed, which I don't think
is a good idea.
David Howells
-
ently no definitive way to grab an unused syscall, whether a
random one or a pre-determined one.
(2) The syscall table is not exported...
(3) Even if it was... just filling in the syscall slot from a module means
that it is possible for the module to be unloaded whilst the syscall is
You should be able to steal a solution from knfsd. It faces the same problem.
> Of course it takes a small stub that's always in kernel, but so what.
Interesting idea... I'll take a look. Maybe it'll be possible to share
something.
David Howells
-
To unsubscribe from this list: s
Oliver Neukum <[EMAIL PROTECTED]> wrote:
> > (3) Even if it was... just filling in the syscall slot from a module means
> > that it is possible for the module to be unloaded whilst the syscall is in
> > use.
> >
> > David Howells
>
> The follow
/unload issues have already been fixed for
> you.
The thought has occurred... I suppose I need to extend the exec_domain
structure to include a Win32 syscall handler, and I suppose I'll need a stub
to transfer the Linux syscall into the handler.
David Howells
-
To unsubscribe from this lis
Oliver Neukum <[EMAIL PROTECTED]> wrote:
> > How does handle_unload_preparation() get invoked? And does lock_kernel()
>
> Explicitly, or via proc or sysctl.
Alright, let me ask that a different way: If I provide such a function in the
module, _what_ calls it from the m
o "Native API" calls, which are
defined in ntdll.dll. These use "int 0x2e" to obtain access to the kernel, but
are mostly undocumented (typically).
As for Win95/98/ME, I would have thought these would implement the Win32
syscalls directly.
David Howells
-
To unsubscribe from this li
userspace
function, you _can't_ call lock_kernel() from it.
David Howells
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
n32 in the kernel is almost like putting libc in the kernel. You
> can make exceptions for calls that need the greatest performance and/or
> don't translate well.
Also agreed, particularly when GDI calls are considered. Though this also
applies to the Native API.
David Howells
-
To unsu
ail end of this syscall
can fight with the module unload code.
> Or you find a way to hook into task termination.
I'm already doing that... See the release() call on the fd. But this doesn't
stop someone from invoking a syscall at an inappropriate time.
David Howells
-
To unsubscr
g, then, that the stub can't be used by compiled in
(ie non-module) code? Or am I misunderstanding what you mean?
David Howells
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
a generic pluggable syscall
handler, one that is very careful to make sure the syscall can't be entered
whilst the module is being unloaded.
David Howells
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
; but for desktop boxes (for which this wine stuff is) rebooting seems
> appropriate here, too.
It's not all that hard to do... and it does mean you can have demand-loadable
and -unloadable modules. Also I am writing/debugging it at the moment, and so
I like being able to unload and re
> (lcall7) and 0x27 for Solaris/x86 syscalls (lcall 0x27). Pick another
> number, and possibly reassign those two to 1 and 2 respectively because it's
> cleaner like that.
But where do I get the other argument (struct pt_regs *) from? A normal Linux
syscall does not appear to hav
e. Madness *grin*.
You still have to have a static syscall number though...
David Howells
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
check and
guess what... it oopsed! Typical. So I'll have to let you have the code this
evening or tomorrow when I've squashed the bug.
David Howells
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
module in memory?
Because "getting" the struct file from the fd increments the usage count on
the struct file. The VFS automatically maintains the module count pointed to
by the file_operations structure based on the existence of the struct file.
David Howells
-
To unsubscribe from thi
pass a pointer to the file_operations struct, which the stub checks
against before calling the handler.
David howells
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
uld
> be nice to let Linux apps rely on the calls being available.
It doesn't make all that much difference in call latency to be in a module
rather than in the kernel. Plus you can load it when you need it, and so it's
not permanently eating a chunk of non-swappable memory.
Additional
using personalities, but I still need to maintain the refcount on the handle
map fd.
David Howells
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Could you please apply this little patch to export access_process_vm()?
Cheers,
David Howells
=
diff -uNr linux-2.4.0-test8-orig/kernel/ksyms.c linux-2.4.0-test8/kernel/ksyms.c
--- linux-2.4.0-test8-orig/kernel/ksyms.c Fri Sep 15 00:04:36 2000
+++ linux-2.4.0-test8/kernel
[EMAIL PROTECTED] (Linus Torvalds) wrote:
> David Howells <[EMAIL PROTECTED]> wrote:
> >
> >Oliver Neukum <[EMAIL PROTECTED]> wrote:
> >> > (3) Even if it was... just filling in the syscall slot from a module means
> >> > that it is possib
> Dec 8 06:05:29 agate kernel: hdc: packet command error: status=0x51 {
> DriveReady SeekComplete Error }
> Dec 8 06:05:29 agate kernel: hdc: packet command error: error=0x50
> Dec 8 06:05:29 agate kernel: ATAPI device hdc:
> Dec 8 06:05:29 agate kernel: Error: Illegal request -- (Sense key
> here is my first shot for cleaning up the shm handling. It did survive
> some basic testing but is not ready for inclusion.
Can you help me with an SHM related problem?
I'm currently writing a Win32 emulation kernel module to help speed Wine up,
and I'm writing the file mapping support stuff
>> I'm currently writing a Win32 emulation kernel module to help speed Wine up,
^
> fd = shm_open ("xxx",...)
> ptr = mmap (NULL, size, ..., fd, offset);
I am doing this from within kernel space. I'd like to avoid doing the full
open and mmap
> There will be a
>
> struct file *shmem_file_setup(char * name, loff_t size)
>
> which gives you an open sruct file to an unlinked file of size
> size. You can then do
>
> down(¤t->mm->mmap_sem);
> user_addr = (void *) do_mmap (file, addr, size, prot, flags, 0);
> up(¤t->mm->mmap_sem);
>
>
> If you want to change the vma ops table you can replace the f_ops
> table with your own one. SYSV ipc uses this also to be able to catch
> unmaps.
I'd thought of that, but that means I need to concoct an f_ops table of my own
for every f_ops table I might have to override. All I want to do is
istry service, communicating with registry stubs in the
kernel by the simple RPC mechanism.
> I'd rather not have kernel code that is _only_ good for Win32.
> I don't see much reason to have a nasty add-on that can't be
> used by regular Linux programs.
Agreed.
The
ould stick with the current system.
> Doesn't that strike you as being a hack that will cause you
> to need _more_ code in the end?
No.
> You'll end up writing a second VFS layer if I'm not mistaken.
No I won't. I wasn't really thinking in terms of having a
ntation.
> Folks, get real - if you want NT you know where to find it.
Yes - written on the reverse of my cup mat *grin*.
David Howells
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
CreateFile (access & sharing interactions).
> We have fairly different views on how this stuff would hang together
> and, in all likelyhood, mine are based on incorrect assumptions. :)
True... Isn't it nice when you can provide what API's you want rather than
having to make
open() and sys_unlink() functions could be modified to make use of it
if it was stored on the inode. You could then use sys_CreateFileA() to
actually use it fully.
However, it won't work over NFS...
David Howells
as possible interfaces should be Unix-like, and W32 interfaces
> used only when needed.
Or maybe, they'd like both to be available. The two aren't mutually exclusive.
> I understand that Wine has good reasons to use W32 interfaces internally,
> but pushing them to Linux kernel s
nd NT4, hence why they moved the GDI implementation from
CSRSS.EXE into the kernel.
However, I was thinking more along the lines of GDI being implemented in
userspace by the client process, eg: wine.
David Howells
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
to a client's VM.
* Some bug fixes.
It can be downloaded from:
ftp://ftp.infradead.org/pub/people/dwh/wineservmod-2915.tar.bz2
[Thanks to David Woodhouse for this]
David Howells
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
See a pattern here? System calls are not supposed to be modular.
knfsd? But I agree, really. But what is the likelyhood?
> We shouldn't have calls that appear and disappear on a whim.
True... that smacks of MS policy:-)
> Binary compatibility requires that system calls be available
or bitops. I'll re-investigate tonight and see if I can
come back with some benchmarks/code-snippets tomorrow.
David Howells
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
cal X server as an RPC server, handling wine
GDI calls directly *grin*. Then I could hide all the GDI stuff behind syscall
stubs in the same way. This would allow me to implement a lot of the NT Native
API.
David Howells
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
ross a couple of
instances. I don't know whether this ever applies to Win32, though.
David Howells
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
out looking at /proc/12345/fd/ could
be kept, but as /proc/12345/handles instead with a non-fd approach.
David Howells
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
is as fine-grained as possible (which I've tried to do).
David Howells
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
inux-2.4.1-pre10/include/linux/taskornament.h Fri Jan 26 17:16:22 2001
@@ -0,0 +1,129 @@
+/* taskornament.h: task ornaments
+ *
+ * (c) Copyright 2001 David Howells ([EMAIL PROTECTED])
+ */
+
+#ifndef _H_F92CE22E_93FF_11D4_8781_C0005742
+#define _H_F92CE22E_93FF_11D4_8781_C000574
>...
> + spin_lock(&mm->page_table_lock);
> mm->rss++;
> + spin_unlock(&mm->page_table_lock);
>...
Would it not be better to use some sort of atomic add/subtract/clear operation
rather than a spinlock? (Which would also give you fewer atomic memory access
cycles).
David
-
To unsubs
Run the following script (It's been tried on linux-2.2.x and linux-2.4.x):
#!/bin/sh
cd /tmp
mkdir x
cd x
mkdir x y z
strace -etrace=rename,mkdir,rmdir,chmod mv x z
echo -
chmod -w y
strace -etrace=rename,mkdir,rmdir,chmod mv y z
The output:
rename("x", "z/x") = 0
> More to add on the gcc 2.96 problems. After compiling a Linux 2.4.1
> kernel on gcc 2.91, running SCI benchmarks, then compiling on RedHat
> 7.1 (Fischer) with gcc 2.96, the 2.96 build DROPPED 30% in throughput
> from the gcc 2.91 compiled version on the identical SAME 2.4.1
> source tree.
Linus Torvalds <[EMAIL PROTECTED]> wrote:
> Actually, I'd rather leave it in, but speed it up with the saner and
> faster
>
> if (bh->b_size & (correct_size-1)) {
I presume that correct_size will always be a power of 2...
David
-
To unsubscribe from this list: send the line "unsubscribe l
Jesper Juhl <[EMAIL PROTECTED]> wrote:
> kfree() takes a void pointer argument, no need to cast.
vma->vm_start is unsigned long (unless it's changed since last I looked):
struct vm_area_struct {
struct mm_struct * vm_mm;
unsigned long vm_start;
Hugh Dickins <[EMAIL PROTECTED]> wrote:
>
> Remove use of FIRST_USER_PGD_NR from sys_mincore: it's inconsistent (no
> other syscall refers to it), unnecessary (sys_mincore loops over vmas
> further down) and incorrect (misses user addresses in ARM's first pgd).
You should make it use FIRST_USER_
Paul E. McKenney <[EMAIL PROTECTED]> wrote:
> > spin_lock_irqsave(&tsk->sighand->siglock, flags);
> > - old = tsk->signal->session_keyring;
> > - tsk->signal->session_keyring = keyring;
> > + old = rcu_dereference(tsk->signal->session_keyring);
>
> I don't understand why rcu_dereference
that fell through into the done: bit.
Signed-Off-By: David Howells <[EMAIL PROTECTED]>
---
warthog>diffstat -p1 fscache-nullptr-fix-2612rc2mm1.diff
fs/fscache/cookie.c | 49 ++---
1 files changed, 26 insertions(+), 23 deletions(-)
diff -uNr linu
Jani Jaakkola <[EMAIL PROTECTED]> wrote:
> SMP race handling is broken in key_user_lookup() in security/keys/key.c
> (if CONFIG_KEYS is set to 'y').
A patch very much like the one you proposed is already resident in the latest
-rc kernels. Thanks anyway:-)
David
-
To unsubscribe from this list:
- thus breaking against the hard limit imposed by
sys_mount().
Signed-Off-By: David Howells <[EMAIL PROTECTED]>
---
warthog>diffstat -p1 /tmp/linux-2.6.9-nfs4-compat-mount.patch
fs/compat.c | 74
1 files changed, 74 i
Benjamin LaHaise <[EMAIL PROTECTED]> wrote:
> Oh dear, this is going to take a while. In any case, here is such a
> first step in creating such a sequence of patches. Located at
> http://www.kvack.org/~bcrl/patches/mutex-A0/ are the following patches:
> ...
> 10_new_mutex.diff - Replace
Trond Myklebust <[EMAIL PROTECTED]> wrote:
>
> AFAICS You grab the wait_queue_t lock once in down()/__mutex_lock()
> order to try to take the lock (or queue the waiter if that fails), then
> once more in order to pass the mutex on to the next waiter on
> up()/mutex_unlock(). That is more or less
Benjamin LaHaise <[EMAIL PROTECTED]> wrote:
>
> What about the use of atomic operations on frv? Are they more lightweight
> than a semaphore, making for a better fastpath?
What do you mean? Atomic ops don't compare to semaphores.
On FRV atomic ops don't disable interrupts; they reserve one of
The compiler should be now fixed in this respect, for both my stuff that's in
the kernel and Andrea's desired replacement. The problem appears to have been
triggered by having two "input+output" constraints (eg: "+r", "+m"). However,
I can't test this because the head of the CVS trunk doesn't see
> __asm__("and 1 %%esp.%0; ":"=r" (current) : "0" (~8191UL));
This doesn't look right... Where did you get this from.
Taking the one in include/asm-i386/current.h as an example:
| __asm__(
This signifies a piece of inline assembly that the compiler must insert into
it's output code. The __asm
Okay,
"current" is a macro on i386 that expands to "get_current()". This gets the
task_struct for the task currently running on the CPU executing the code.
It does this by masking out the bottom bits of its kernel stack pointer.
For example, assuming that some running process has the following
The bug in gcc 3.0 that stopped the inline asm constraints being interpreted
properly, and thus prevented linux from compiling is now fixed.
David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http:
Ingo Molnar <[EMAIL PROTECTED]> wrote:
> i saw (and like) the ornaments stuff, and TUX could use it too: right now
> TUX has an extra field in task_struct to do exit()-time deregistering of
> processes. Linus suggested to use a more generic mechanizm. I think some
> already existing things, like
> I was running something on my Dell dual p3 box (optiplex gx300). my kernel
> is linux-2.4.3-ac14. I got the following message:
How often did this message occur?
> __rwsem_do_wake(): wait_list unexpectedly empty
> [4191] c5966f60 = { 0001 })
> kenel BUG at rwsem.c:99!
> invalid operand: 00
I have an idea for getting around this problem, but it's only half implemented
at the moment (I use it for implementing a Wine server in the kernel). It
involves having a list things called task ornaments attached to each
process. Each ornament has a table of event notification methods (so it can
Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> The sys_ptrace boilerplate code (everything outside the big switch
> statement for the arch-specific requests) is shared by most
> architectures. This patch moves it to kernel/ptrace.c and leaves the
> arch-specific code as arch_ptrace.
Looks okay f
Andrew Morton <[EMAIL PROTECTED]> wrote:
> > ...kill PG_checked please :) Or at least keep it from spreading.
> >
>
> It already spread - ext3 is using it and I think reiser4. I thought I had
> a patch to rename it to PG_misc1 or somesuch, but no. It's mandate becomes
> "filesystem-specific p
Daniel Phillips <[EMAIL PROTECTED]> wrote:
> > An extra page flag beyond PG_uptodate, PG_lock and PG_writeback is
> > required to make readpage through the cache non-synchronous.
Sorry, I meant to say "filesystem cache": FS-Cache/CacheFS.
> Interesting, have you got a pointer to a full explanati
Hi Andrew,
This patch in 2.6.13-rc5-mm1:
slab-leak-detector-give-longer-traces.patch
Causes the kernel to die with an oops on my test box during boot (see
attached), just about here, I think:
static void inline *
cache_alloc_debugcheck_after(kmem_cache_t *cachep,
801 - 900 of 7895 matches
Mail list logo
