Re: [patch 1/5] vmalloc: do not check for freed locks on user maps

From: Thomas Gleixner
Date: Wed Mar 05 2008 - 12:22:45 EST


On Thu, 6 Mar 2008, Nick Piggin wrote:

> On Thursday 06 March 2008 03:03, Thomas Gleixner wrote:
> > User maps do not contain kernel internal objects. No need to check
> > them.
>
> Why not? Depends on your definition of kernel internal... and
> objects ;)
>
> Drivers could create and manage some objects in this vmalloc
> area. They are no longer internal if you map them to userspace,
> but I still don't think you want to vunmap it until those
> object lifetimes are finished.

Well, in case of the locks I have a hard time to figure out how you
use a spinlock/mutex with a user space address. The same applies for
timers or other objects used by kernel subsystems. So when the driver
writer creates an kernel related object in the vmalloc space, he has
to use the kernel mapping which is unmapped separate, right ?

I can see your concern about the infinite stu^H^H^Hcreativity of
driver writers, but I prefer not to go down that road and provide
debug infrastructure for absurdities.

Thanks,
tglx

> > Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
> > Acked-by: Ingo Molnar <mingo@xxxxxxx>
> > ---
> > mm/vmalloc.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > Index: linux-2.6/mm/vmalloc.c
> > ===================================================================
> > --- linux-2.6.orig/mm/vmalloc.c
> > +++ linux-2.6/mm/vmalloc.c
> > @@ -382,7 +382,8 @@ static void __vunmap(const void *addr, i
> > return;
> > }
> >
> > - debug_check_no_locks_freed(addr, area->size);
> > + if (!(area->flags & VM_USERMAP))
> > + debug_check_no_locks_freed(addr, area->size);
> >
> > if (deallocate_pages) {
> > int i;
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/