linux-kernel - Re: [PATCH 3/3 v6] mm/vmalloc: Cache the vmalloc memory info

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150825103630.26398.qmail@ns.horizon.com>
Date:	25 Aug 2015 06:36:30 -0400
From:	"George Spelvin" <linux@...izon.com>
To:	linux@...izon.com, mingo@...nel.org
Cc:	dave@...1.net, linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	linux@...musvillemoes.dk, peterz@...radead.org, riel@...hat.com,
	rientjes@...gle.com, torvalds@...ux-foundation.org
Subject: Re: [PATCH 3/3 v6] mm/vmalloc: Cache the vmalloc memory info

>> Second, and this is up to you, I'd be inclined to go fully non-blocking
>> and only spin_trylock().  If that fails, just skip the cache update.

> So I'm not sure about this one: we have no guarantee of the order every
> updater reaches the spinlock, and we want the 'freshest' updater to do
> the update. The trylock might cause us to drop the 'freshest' update
> erroneously - so this change would introduce a 'stale data' bug I think.

Er, no it wouldn't.  If someone leaves the cache stale, they'll leave
vmap_info_cache_gen != vmap_info_gen and the next reader to come along
will see the cache is stale and refresh it.

If there's lock contention, there's a risk of more work, because the
callers fall back to calc_vmalloc_info rather than waiting.

But it's not a big risk.  With the blocking code, if two readers
arrive simultaneously and see a stale cache, they'll both call
calc_vmalloc_info() and then line up to update the cache.

The second will get the lock but then *not* update the cache.

With trylock(), the second will just skip the update faster.
Same number of calc_vmalloc_info() calls.

The only inefficient case is if two readers arrive far enough apart that
vmap_info_gen is updated between them, yet close enough together than
the second arrives at the lock while the first is updating the cache.

In that case, the second reader will not update the cache and (assuming
no more changes to vmap_info_gen) some future third reader will have to
duplicate the effort of calling calc_vmalloc_info().

But that's such a tiny window I give preference to my fondness
for non-blocking code.

> I added your Reviewed-by optimistically, saving a v7 submission hopefully ;-)

You did right.  As I said, the non-blocking part is your preference.

I've done so much nasty stuff in interrupt handlers ($DAY_JOB more than
kernel) that I go for the non-blocking algorithm whenever possible.

Reviewed-by: George Spelvin <linux@...izon.com>
--
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/