> > Yeap. I noticed the same bug is (was?) in 2.1 recently. Nobody must be
> > doing lots of simultaneous mmap()ing and fork()ing with clones -- yet. ;-)
>
> Wrong. I think this is the other half of the ongoing bughunt for the problems
> with cyclone - along wiht the select one. It may also explain some linuxthread
> bizarreness reported in other apps.
Hmmm.... That just stresses the need for somewhat better bug tracking
(this one was obvious, but I don't recall seeing it reported at all -- I
may just be absent minded). I've had to sit down and write a test suite
(an insufficient, tiny one) to test my mm changes, but haven't tackled the
clone side of things yet. There's also a performance issue with shared
mm's and mmap_sem: it should be possible to make mmap_sem a blocking
read/write lock (where page faults are read locks, everything else is a
write lock). This ought to be trivial to implement, as the page fault
path is already safe on any possible blocking (because of swapping).
Right now only one thread will be handling a page fault at a time, which
might severely hamper performance -- filling in a zero filled page will
block until a previous page-in request from disk completes.
-ben
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu