Question about do_mmap changes

Question about do_mmap changes

[Larry Finger]

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

Index: vboxhost/vboxdrv/r0drv/linux/memobj-r0drv-linux.c
===================================================================
--- vboxhost.orig/vboxdrv/r0drv/linux/memobj-r0drv-linux.c
+++ vboxhost/vboxdrv/r0drv/linux/memobj-r0drv-linux.c
@@ -65,6 +65,13 @@
  # define VBOX_USE_PAE_HACK
  #endif

+/*
+ * 3.5+ kernels no longer have do_mmap(). They need to call
+ * do_mmap_pgoff() instead.
+ */
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(3, 5, 0)
+#define do_mmap do_mmap_pgoff
+#endif

  /*******************************************************************************
  *   Structures and Typedefs

================================

Although the code now compiles OK, the link step results in

WARNING: "do_mmap_pgoff" [/usr/share/virtualbox/src/vboxhost/vboxdrv/vboxdrv.ko] 
undefined!
WARNING: "do_munmap" [/usr/share/virtualbox/src/vboxhost/vboxdrv/vboxdrv.ko] 
undefined!

================================

I am not quite sure why do_munmap() is undefined as the symbol is exported; 
however, should do_mmap_pgoff() be exported?

Thanks,

Larry

Re: Question about do_mmap changes

[Al Viro]

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.

Re: Question about do_mmap changes

[Larry Finger]

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

Re: Question about do_mmap changes

[Al Viro]

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.

Re: Question about do_mmap changes

[Al Viro]

On Mon, Jun 04, 2012 at 07:56:38AM +0100, Al Viro wrote:
> _IF_ this is done not to current->mm, these guys are in for a world of
> hurt, probably going all way back.

	BTW, rtR0MemObjLinuxDoMmap() would really better be done with
pTask == current; it calls do_mmap(), which acts on current->mm and
nowhere in the function does it look at pTask at all.  The caller
has locked pTask->mm->mmap_sem.  And do_mmap() obviously assumes that
current->mm->mmap_sem is held by caller.

	Looking at the callers (both of that an munmap()), it appears
that they get task from
static struct task_struct *rtR0ProcessToLinuxTask(RTR0PROCESS R0Process)
{
    /** @todo fix rtR0ProcessToLinuxTask!! */
    return R0Process == RTR0ProcHandleSelf() ? current : NULL;
}

So it's probably OK, until they follow up on that todo.  BTW, quite a few
callers of that sucker are followed by Assert(pTask != NULL)...

Most of do_munmap() callers are easily converted to vm_munmap(); the only
exception is cleanup after failure in rtR0MemObjNativeMapUser().  May
or may not be convertable to vm_munmap(); depends on whether they really
need ->mmap_sem held over the entire sequence *and* on whether there's
a better solution.  They seem to be trying to shove an array of pages
into VMA they'd just created and lock them there; I might be misreading
and missing details, though - that code is really as pleasant to read
as using warm stale beer to deal with industrial-strength hangover.  The
kind when you end up spitting out a fly or two, if not a cigarette butt...
I'm not up to that right now - it's half past three in the morning here
and I'll have to get up four hours from now ;-/