Messages in this thread | | | Date | Mon, 04 Jun 2012 01:37:33 -0500 | From | Larry Finger <> | Subject | Re: Question about do_mmap changes |
| |
On 06/04/2012 01:26 AM, Al Viro wrote: > On Mon, Jun 04, 2012 at 12:29:45AM -0500, Larry Finger wrote: >> Al, >> >> In commit e3fc629d7bb70848fbf479688a66d4e76dff46ac in 3.5-rc1, you >> change do_mmap() to static, and use do_mmap_pgoff() instaed. The >> VirtualBox kernel module calls do_mmap(), and no longer compiles. I >> fixed the compile problem with the patch > [snip] >> I am not quite sure why do_munmap() is undefined as the symbol is >> exported; however, should do_mmap_pgoff() be exported? > > a) you'd better make very certain that you are holding ->mmap_sem on > current->mm; I couldn't verify that. > > b) as for rtR0MemObjLinuxDoMmap(), I would suggest pulling down_write()/ > up_write() on ->mmap_sem into the function, collapsing them down into > do_mmap() turning it into vm_mmap(). Oh, and probably breaking wrists > to whoever had come up with that function name, but that's a matter of > taste. Some prefer kneecaps. > > c) WTF is MY_DO_MUNMAP() and are you guaranteed that you are doing that to > current->mm and not to something else? If not, you have a big problem; > if yes, convert to vm_munmap(). > > Again, doing mmap/munmap to some random process' mm is a bloody bad idea; > there's a shitload of races in that area.
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?
Thanks,
Larry
| |