linux-kernel - Re: process 'stuck' at exit.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.02.1312111737590.28330@ionos.tec.linutronix.de>
Date:	Wed, 11 Dec 2013 17:38:55 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Mel Gorman <mgorman@...e.de>
cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Dave Jones <davej@...hat.com>, Oleg Nesterov <oleg@...hat.com>,
	Darren Hart <dvhart@...ux.intel.com>,
	Andrea Arcangeli <aarcange@...hat.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/