lkml.org 
[lkml]   [2004]   [Apr]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: RFC: COW for hugepages
From
Date
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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:02    [W:0.090 / U:0.960 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site