linux-kernel - Re: [PATCH 08 of 11] anon-vma-rwsem

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: <20080508220106.GF2964@duo.random>
Date:	Fri, 9 May 2008 00:01:06 +0200
From:	Andrea Arcangeli <andrea@...ranet.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Christoph Lameter <clameter@....com>,
	Andrew Morton <akpm@...ux-foundation.org>, steiner@....com,
	holt@....com, npiggin@...e.de, a.p.zijlstra@...llo.nl,
	kvm-devel@...ts.sourceforge.net, kanojsarcar@...oo.com,
	rdreier@...co.com, swise@...ngridcomputing.com,
	linux-kernel@...r.kernel.org, avi@...ranet.com, linux-mm@...ck.org,
	general@...ts.openfabrics.org, hugh@...itas.com,
	rusty@...tcorp.com.au, aliguori@...ibm.com, chrisw@...hat.com,
	marcelo@...ck.org, dada1@...mosbay.com, paulmck@...ibm.com
Subject: Re: [PATCH 08 of 11] anon-vma-rwsem

On Thu, May 08, 2008 at 09:11:33AM -0700, Linus Torvalds wrote:
> Btw, this is an issue only on 32-bit x86, because on 64-bit one we already 
> have the padding due to the alignment of the 64-bit pointers in the 
> list_head (so there's already empty space there).
> 
> On 32-bit, the alignment of list-head is obviously just 32 bits, so right 
> now the structure is "perfectly packed" and doesn't have any empty space. 
> But that's just because the spinlock is unnecessarily big.
> 
> (Of course, if anybody really uses NR_CPUS >= 256 on 32-bit x86, then the 
> structure really will grow. That's a very odd configuration, though, and 
> not one I feel we really need to care about).

I see two ways to implement it:

1) use #ifdef and make it zero overhead for 64bit only without playing
any non obvious trick.

struct anon_vma {
       spinlock_t lock;
#ifdef CONFIG_MMU_NOTIFIER
       int global_mm_lock:1;
#endif

struct address_space {
       spinlock_t	private_lock;
#ifdef CONFIG_MMU_NOTIFIER
       int global_mm_lock:1;
#endif

2) add a:

#define AS_GLOBAL_MM_LOCK   (__GFP_BITS_SHIFT + 2)	/* global_mm_locked */

and use address_space->flags with bitops

And as Andrew pointed me out by PM, for the anon_vma we can use the
LSB of the list.next/prev because the list can't be browsed when the
lock is taken, so taking the lock and then setting the bit and
clearing the bit before unlocking is safe. The LSB will always read 0
even if it's under list_add modification when the global spinlock isn't
taken. And after taking the anon_vma lock we can switch it the LSB
from 0 to 1 without races and the 1 will be protected by the
global spinlock.

The above solution is zero cost for 32bit too, so I prefer it.

So I now agree with you this is a great idea on how to remove sort()
and vmalloc and especially vfree without increasing the VM footprint.

I'll send an update with this for review very shortly and I hope this
goes in so KVM will be able to swap and do many other things very well
starting in 2.6.26.

Thanks a lot,
Andrea
--
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/