lkml.org 
[lkml]   [1999]   [May]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.051 / U:0.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site