Messages in this thread | | | Date | Wed, 11 Dec 2013 17:38:55 +0100 (CET) | From | Thomas Gleixner <> | Subject | Re: process 'stuck' at exit. |
| |
On Wed, 11 Dec 2013, Mel Gorman wrote: > On Tue, Dec 10, 2013 at 11:42:15PM +0100, Thomas Gleixner wrote: > > Now, if that map is RO, i.e. we took the fallback path then the THP > > one will fail as it has write=1 unconditionally. > > > > if (likely(__get_user_pages_fast(address, 1, 1, &page) == 1)) > > > > Not that it really matters but the naming and comments around that > particular __get_user_pages_fast call are a little misleading. The ifdef > CONFIG_TRANSPARENT_HUGEPAGE in futex.c is there because greater care has > to be taken against THP splits, not because it is dealing exclusively with > THP. The PageTail check applies to either hugetlbfs or THPs and similarly > gup_huge_pmd handles both. The whole path should be very rare for THPs > considering that THPs exist on MAP_PRIVATE anonymous mappings and how many > shared futexes exist backed by such mappings? A RO mapping makes that seem > even more strange because what thread is updating the value the caller is > waiting on? It seems more like that was a shared futex on a hugetlbfs-backed > mappings which might explain why the bug was undiscovered for so long.
This is the fshared path. The MAP_PRIVATE path does not do that dance at all.
Thanks,
tglx
| |