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]

Date:	Wed, 16 Dec 2009 10:27:39 -0600 (CST)
From:	Christoph Lameter <cl@...ux-foundation.org>
To:	Andi Kleen <andi@...stfloor.org>
cc:	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 Wed, 16 Dec 2009, Andi Kleen wrote:

> > Do you have alternative recommendation rather than wrapping all accesses by
> > special functions ?
>
> Work out what changes need to be done for ranged mmap locks and do them all
> in one pass.

Locking ranges is already possible through the split ptlock and
could be enhanced through placing locks in the vma structures.

That does nothing solve the basic locking issues of mmap_sem. We need
Kame-sans abstraction layer. A vma based lock or a ptlock still needs to
ensure that the mm struct does not vanish while the lock is held.

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