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.

quoted

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>