Re: [RFC] Wine speedup through kernel module

From: David Howells (David.Howells@nexor.co.uk)
Date: Thu Sep 07 2000 - 10:25:29 EST


Andi Kleen <ak@suse.de> wrote:
> But that's not race free on SMP. Two CPUs can set the bit in parallel
> and you'll never notice. You would need at least a protecting spinlock
> between the test bit and set bit (or a cmpxchg on x86)

Are you sure? I understood that the "lock" prefix on a i386 made the
instruction it guarded SMP safe.

If not, I suppose I can use the xchg() macro instead.

Hold on a moment... You said "between the test bit and set bit"... this is a
single CPU instruction! With the lock prefix, there should be no between.

Also, a quote from asm/bitops.h:
- /*
- * These have to be done with inline assembly: that way the bit-setting
- * is guaranteed to be atomic. All bit operations return 0 if the bit
- * was cleared before the operation and != 0 if it was not.
- *
- * bit 0 is the LSB of addr; bit 32 is the LSB of (addr+1).
- */

Doesn't "atomic" mean SMP safe?

What's the point in the lock prefix if it doesn't make things SMP safe (after
all, the unadorned instructions are UP safe...)?

> That also does not help for protecting your objects, it only protects
> the wait queue.

Yes.

I don't see what more needs to be done, at least on the mutex. It is either
available when we come to grab it, and we find this out and grab it in a
single operation, or it isn't, and we wait.

Furthermore, the objects also have atomic_t reference counts like other kernel
modules, so they aren't going to go away whilst in use.

> The processes look it up in a shared name table (shmem). Yes they have
> to negoitate in this case -- it'll only be a win when they usually do not
> share.

And really horrible when they do share. Plus you still have to jump through
all the same synchronisation hoops to control access to the shmem that the
kernel does when governing access to its objects.

> Probably, it is a DoS.

Surely a DoS attack is only possible if there is a limit in force? Namespace
DoS attacks are possible whatever the underlying system, wineserver, 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 unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:30 EST