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:	Fri, 18 Dec 2009 18:12:40 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Avi Kivity <avi@...hat.com>
Cc:	Christoph Lameter <cl@...ux-foundation.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Andi Kleen <andi@...stfloor.org>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	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>,
	minchan.kim@...il.com
Subject: Re: [mm][RFC][PATCH 0/11] mm accessor updates.

* Avi Kivity <avi@...hat.com> wrote:

> On 12/18/2009 07:17 AM, Ingo Molnar wrote:
> >
> >>It is not about naming. The accessors hide the locking mechanism for
> >>mmap_sem. Then you can change the locking in a central place.
> >>
> >>The locking may even become configurable later. Maybe an embedded solution
> >>will want the existing scheme but dual quad socket may want a distributed
> >>reference counter to avoid bouncing cachelines on faults.
> >Hiding the locking is pretty much the worst design decision one can make.
> >
> 
> It does allow incremental updates.  For example if we go with range locks, 
> the accessor turns into a range lock of the entire address space; users can 
> be converted one by one to use their true ranges in order of importance.

This has been brought up in favor of say the mmap_sem wrappers in the past 
(but also mentioned for other wrappers), but the supposed advantage never 
materialized.

In reality updating the locking usage is never a big issue - it's almost 
mechanic and the compiler is our friend if we want to change semantics. Hiding 
the true nature and the true dependencies of the code, hiding the type of the 
lock is a bigger issue.

We've been through this many times in the past within the kernel: many times 
when we hid some locking primitive within some clever wrapping scheme the 
quality of locking started to deteriorate. In most of the important cases we 
got rid of the indirection and went with an existing core kernel locking 
primitive which are all well known and have clear semantics and lead to more 
maintainable code.

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