linux-kernel - Re: [mm][RFC][PATCH 0/11] mm accessor updates.

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: <1261080470.27920.798.camel@laptop>
Date:	Thu, 17 Dec 2009 21:07:50 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Christoph Lameter <cl@...ux-foundation.org>
Cc:	Andi Kleen <andi@...stfloor.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"mingo@...e.hu" <mingo@...e.hu>, minchan.kim@...il.com
Subject: Re: [mm][RFC][PATCH 0/11] mm accessor updates.

On Thu, 2009-12-17 at 13:33 -0600, Christoph Lameter wrote:
> On Thu, 17 Dec 2009, Andi Kleen wrote:
> 
> > > There are a few interesting cases like stack extention and hugetlbfs,
> > > but I think we could start by falling back to mmap_sem locked behaviour
> > > if the speculative thing fails.
> >
> > You mean fall back to mmap_sem if anything sleeps? Maybe. Would need
> > to check how many such points are really there.
> 
> You always need some reference on the mm_struct (mm_read_lock) if you are
> going to sleep to ensure that mm_struct still exists after waking up (page
> fault, page allocation). RCU and other spin locks are not helping there.

Depends what you go to sleep for, the page fault retry patches simply
retook the whole fault and there is no way the mm could have gone away
when userspace isn't executing.

Also pinning a page will pin the vma will pin the mm, and then you can
always take explicit mm_struct refs, but you really want to avoid that
since that's a global cacheline again.



--
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/