Messages in this thread | | | Date | Fri, 13 Jan 2012 15:39:50 -0800 | From | Andrew Morton <> | Subject | Re: [PATCH] mm: hugetlb: undo change to page mapcount in fault handler |
| |
On Wed, 11 Jan 2012 20:06:30 +0800 Hillf Danton <dhillf@gmail.com> wrote:
> On Thu, Jan 5, 2012 at 7:16 AM, Andrew Morton <akpm@linux-foundation.org> wrote: > > On Fri, 23 Dec 2011 21:00:41 +0800 > > Hillf Danton <dhillf@gmail.com> wrote: > > > >> Page mapcount should be updated only if we are sure that the page ends > >> up in the page table otherwise we would leak if we couldn't COW due to > >> reservations or if idx is out of bounds. > > > > It would be much nicer if we could run vma_needs_reservation() before > > even looking up or allocating the page. > > > > And afaict the interface is set up to do that: you run > > vma_needs_reservation() before allocating the page and then > > vma_commit_reservation() afterwards. > > > > But hugetlb_no_page() and hugetlb_fault() appear to have forgotten to > > run vma_commit_reservation() altogether. __Why isn't this as busted as > > it appears to be? > > Hi Andrew > > IIUC the two operations, vma_{needs, commit}_reservation, are folded in > alloc_huge_page(), need to break the pair?
Looking at it again, it appears that the vma_needs_reservation() calls are used to predict whether a subsequent COW attempt is going to fail.
If that's correct then things aren't as bad as I first thought. However I suspect the code in hugetlb_no_page() is a bit racy: the vma_needs_reservation() call should happen after we've taken page_table_lock. As things stand, another thread could sneak in there and steal the reservation which this thread thought was safe.
What do you think?
| |