Re: RFC: COW for hugepages

[Dave Hansen <haveblue@us.ibm.com>]

On Wed, 2004-04-07 at 00:42, David Gibson wrote:
> +	/* XXX are there races with checking cpu_vm_mask? - Anton */
> +	tmp = cpumask_of_cpu(smp_processor_id());
> +	if (cpus_equal(vma->vm_mm->cpu_vm_mask, tmp))
> +		local = 1;
> +
> +	cow = (vma->vm_flags & (VM_SHARED | VM_MAYWRITE)) == VM_MAYWRITE;

You're under the pagetable lock for that mm, so you at least don't have
to worry about preemption.  But, that definitely at least deserves a
comment on why you didn't disable preemption.

Also, for racing with other users of cpu_vm_mask, there aren't any other
users that clear other cpus' bits other than initialization.  

One thing that's I didn't see in this patch is any check of capabilities
or permissions.  What if a privileged user sets up a single page huge
page, then does a setuid() to a lower privilege level?  Is that not a
valid way to get hugetlb pages to an unprivileged user?  That other user
is free to go fork and write to the pages to their heart's content,
consuming as many huge pages as are present in the system.

It looks to me like dup_mmap() drops VM_LOCKED on mlock()'d VMAs at fork
time.  Do we need to do the same for hugetlb pages?  

-- Dave