Messages in this thread | | | Date | Mon, 4 Jun 2012 07:56:38 +0100 | From | Al Viro <> | Subject | Re: Question about do_mmap changes |
| |
On Mon, Jun 04, 2012 at 01:37:33AM -0500, Larry Finger wrote:
> Oh, shit. I was hoping for an easy conversion of this code to work > with 3.5 so that I could use VB while testing 3.5. Clearly, the > fixes will not be quick. > > As you have likely gathered, I am not a VB developer. Is it OK if I > pass your comments on to the real developers and let them do the > work?
Sure. BTW, if they are doing that munmap() *not* to current->mm, they are in for serious analysis (and very likely - fixing unpleasant races) in earlier versions as well; these races hadn't appeared just now.
Note that aio (another place that used to do such munmap()) had been racy all way back to original merge. Moreover, access of task->mm becomes really interesting when it's another task - note that execve(2) changes the sucker, so you are risking up_write() done to mm->mmap_sem that gets freed under you or up_write() on a _different_ mm_struct ->mmap_sem. And then there's the fact that exit_mm() is done without ->mmap_sem (it's done when no active users should've been left, after all), so munmap() done on it will do nasty things. So will munmap() racing with do_coredump() (again, no ->mmap_sem there - all threads are already not running in userland by that point, so the kernel just goes ahead and assumes that nobody will touch that mm_struct).
Conversion to vm_mmap()/vm_munmap() was done, in a large part, to simplify the analysis and to make damn sure we are doing that to current->mm. There are users of do_munmap() outside of mm/* (ipc/shm.c), but they are also working on current->mm and the code in question is really a misplaced piece of mm/* to start with.
_IF_ this is done not to current->mm, these guys are in for a world of hurt, probably going all way back.
| |