Re: Thread deficiencies
Date: Tue, 4 Jan 2000 13:43:52 +0000 (GMT)
From: Alan Cox <email@example.com>
You want to put a conditional, a lock contention, an unlock into
every single syscall path ? Thats bad enough. Second point. It
doesnt work. The lock is dropped when you sleep so it doesnt solve
your credential problem at all. Also you've added a pointer
indirection to all the uid tests, and used an extra register in
almost every syscall.
The big kernel lock is already there, so we're not adding anything new.
As far as whether or not it's "good enough" to solve the problem, the
issue only arises if some system call actually does multiple permission
checks, and the change in credentials happens between permission check
#1 and permission check #2. I haven't looked that hard, but are there
really that many cases where a syscall tries to do multiple uid checks?
I'm also not convinced the pointer indirection and the extra register
matters at all. We save all registers in and out of the syscall, and
the extra pointer indirection should be in the noise compared to the
the real work that the system call is doing anyway.
This mailing list is probably not the right one to address the technical
details. The question still remains, though ---- what do we specify?
What we have to do is *not* POSIX.4 compliant. We can try to document
all the ways we fail to meet POSIX.4, and say that application programs
compliant with LSB 1.0 shouldn't (for example) expect wait() on a child
process that was spawned by another thread to work correctly. This is
really ugly, and ISV's might not like to hear it --- but it's the sad