Messages in this thread | | | Date | Sun, 30 May 1999 10:12:36 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: pre-2.3.4.. |
| |
On Sat, 29 May 1999, Chuck Lever wrote: > > > > Chuck, it's unsafe. do_munmap() called from sys_brk() (or from do_mmap() > > for that matter) may lead to ->f_count changes, which is *not* the thing > > you want to do without big lock. > > i don't think it will do this for anonymous maps used by sys_brk().
Not for a nice user no.
A _bad_ user might do something like this:
/* Allocate the anonymous brk */ area = sbrk(largeamount);
/* Tee-hee, we'll mess with the kernels mind */ mmap(file, area, largeamount);
sbrk(-largeamount);
and then the unmap _will_ have a file backing from sys_brk().
Basically, if you want to drop the kernel lock (which is a good idea: it's a rather nasty one to hold there, and in theory we really shouldn't need it in normal use), you have to be more careful about it. Sadly.
(If it was trivial, I would have done it a long time ago. It shouldn't be _hard_, but to do it right really does imply doing the simple mmap by hand instead of being cheezy and calling "do_mmap()").
(The case where do_mmap() unmaps the old area is already protected against: sys_brk() checks that there is no vma overlap, and refuses to create a new mapping on top of an old one. So THAT case is safe, but it's still true that you should never call do_mmap() without holding the kernel lock, simply because as it is right now that would be a rule violation even if you can prove that it "happens to work").
Linus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |