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

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

On 07/10/2013 04:23 PM, Colin Cross wrote:
> On Wed, Jul 10, 2013 at 4:08 PM, Dave Hansen <dave.hansen@intel.com> wrote:
>> On 07/03/2013 06:31 PM, Colin Cross wrote:
>>> @@ -289,6 +291,7 @@ struct vm_area_struct {
>>>  #ifdef CONFIG_NUMA
>>>       struct mempolicy *vm_policy;    /* NUMA policy for the VMA */
>>>  #endif
>>> +     struct vma_name *vm_name;
>>>  };
>>
>> You could probably get rid of the extra pointer by unioning this with
>> vm_file.  They should not ever get used together.  We would, however,
>> have to transition away from checking vma->vm_file for "is this vma
>> file-backed"?  We are out of VM_* flag space which is a bummer.
> 
> I considered trying to union with vm_file, but like you said the lack
> of space in vm_flags makes it hard.

I'd rather see 32 more bits "wasted" on new flags than a pointer that is
used very rarely.

> It would also prevent naming file
> backed mappings, which is supported by this patch set.  It's not
> required by my primary use case, but it could be useful to have the
> dynamic linker identify the various elf segments.

That's stretching it a bit. :)

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.

Hey, doing that would even let you reuse vm_file.  >=PAGE_OFFFSET means
it's a file.  <PAGE_OFFSET means it's an anonymous string.  :)

--
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>