linux-kernel - Re: SLOB lockup (was: Re: [tip:core/locking] lockdep: annotate reclaim context (__GFP

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:	Tue, 17 Mar 2009 02:00:52 +1100
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Matt Mackall <mpm@...enic.com>
Cc:	Ingo Molnar <mingo@...e.hu>, linux-tip-commits@...r.kernel.org,
	Nick Piggin <npiggin@...e.de>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Pekka Enberg <penberg@...helsinki.fi>,
	linux-kernel@...r.kernel.org, hpa@...or.com, mingo@...hat.com,
	tglx@...utronix.de
Subject: Re: SLOB lockup (was: Re: [tip:core/locking] lockdep: annotate reclaim context (__GFP_NOFS), fix SLOB)

On Tuesday 17 March 2009 01:52:09 Matt Mackall wrote:
> On Mon, 2009-03-16 at 21:00 +1100, Nick Piggin wrote:

> > This doesn't work because you have to hold the lock over the test
> > otherwise another thread can concurrently meddle with sp->units.
>
> Ahh, yes, I was glossing over that code because of the misleading
> comment. I was assuming this was the case where the object itself was a
> page, rather than object is the only allocation on the page.
>
> > For that matter my previous patch was buggy, aside from the obvious
> > that Ingo pointed out, because I unlocked before removing the page
> > from the freelist too.
> >
> > This should be pretty close to correct ;)
>
> Yes. Now the only question that remains is if we want to change a nearly
> negligible performance improvement for a nearly negligible size
> increase.

I'd let you decide that one. I very much doubt it would be noticable on
UP, however it might reduce interrupt hold times there. In case of
several CPUs case, it might give some small scalability improvement of
the lock.


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