Re: [PATCH] mm: add sys_madvise2 and MADV_NAME to name vmas

[Dave Hansen <dave.hansen@intel.com>]

On 07/10/2013 05:12 PM, Colin Cross wrote:
> I wonder if it
> would be worth trying to make names a struct file?  They would be
> significantly larger than a struct vma_name, but reuse all the
> existing refcounting code.

Not worth it INMHO.

>> Here's one more idea: instead of having a kernel pointer, let's let
>> userspace hand the kernel a userspace address, and the kernel will hang
>> on to it.  Userspace is responsible for keeping it valid, kind of like
>> ARGV[].  When the kernel goes to dump out the /proc/$pid/maps fields, it
>> can do a copy_from_user() to get the string back out.  If this fails, it
>> can just go and treat it like a non-named VMA, or could output
>> "userspace sucks".
>>
>> That way, the kernel isn't dealing with refcounting and allocating
>> strings.  It's got security concerns, just like
>> /proc/$pid/cmdline since it'll let you dig around in another process's
>> address space via /proc.  But, I think they're manageable.
> 
> How do you deal with merging adjacent vmas with the same name?  The
> whole point of the refcounted strings is to allow comparing strings
> for equality by comparing pointers.  You could say that a named vma
> never gets merged, but then you might as well use separate tmpfs
> files, and you end up at least doubling the number of vmas in some
> processes I've seen.

If they have the same userspace pointer target, then they get merged.
Two adjacent vmas with the same name (according to strcmp()) would not
get merged.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>