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@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>