Messages in this thread | | | Date | Thu, 6 Mar 2008 00:31:50 +0100 (CET) | From | Thomas Gleixner <> | Subject | Re: [patch 1/5] vmalloc: do not check for freed locks on user maps |
| |
On Thu, 6 Mar 2008, Nick Piggin wrote:
> On Thursday 06 March 2008 04:20, Thomas Gleixner wrote: > > 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 ? > > This is the kernel mapping. The user mapping is unmapped when > the userspace munmaps.
Ok, my misinterpretation of that flag. Is the user space unmap in the same code path ? If yes, how can it be distinguished from the kernel space unmap ?
Thanks,
tglx
| |