linux-kernel - Re: [PATCH 1/1] vmalloc: purge_fragmented_blocks: Acquire spinlock before reading vmap

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.00.1112072314140.28419@chino.kir.corp.google.com>
Date:	Wed, 7 Dec 2011 23:18:59 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	Kautuk Consul <consul.kautuk@...il.com>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Joe Perches <joe@...ches.com>,
	Minchan Kim <minchan.kim@...il.com>,
	David Vrabel <david.vrabel@...rix.com>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] vmalloc: purge_fragmented_blocks: Acquire spinlock
 before reading vmap_block

On Thu, 8 Dec 2011, Kautuk Consul wrote:

> > In the original code, if the if-clause fails, the lock is only then taken
> > and the exact same test occurs again while protected.  If the test now
> > fails, the lock is immediately dropped.  A branch here is faster than a
> > contented spinlock.
> 
> But, if there is some concurrent change happening to vb->free and
> vb->dirty, dont you think
> that it will continue and then go to the next vmap_block ?
> 
> If yes, then it will not be put into the purge list.
> 

That's intentional as an optimization, we don't care if 
vb->free + vb->dirty == VMAP_BBMAP_BITS && vb->dirty != VMAP_BBMAP_BITS 
would speculatively be true after we grab vb->lock, we'll have to purge it 
next time instead.  We certainly don't want to grab vb->lock for blocks 
that aren't candidates, so this optimization is a singificant speedup.