linux-kernel - Re: [PATCH v4 07/15] lockdep: Implement crossrelease feature

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: <20170117074935.GJ3326@X58A-UD3R>
Date:   Tue, 17 Jan 2017 16:49:35 +0900
From:   Byungchul Park <byungchul.park@....com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     mingo@...nel.org, tglx@...utronix.de, walken@...gle.com,
        boqun.feng@...il.com, kirill@...temov.name,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        iamjoonsoo.kim@....com, akpm@...ux-foundation.org,
        npiggin@...il.com
Subject: Re: [PATCH v4 07/15] lockdep: Implement crossrelease feature

On Tue, Jan 17, 2017 at 08:12:20AM +0100, Peter Zijlstra wrote:
> On Tue, Jan 17, 2017 at 11:05:42AM +0900, Byungchul Park wrote:
> > On Mon, Jan 16, 2017 at 04:10:01PM +0100, Peter Zijlstra wrote:
> > > On Fri, Dec 09, 2016 at 02:12:03PM +0900, Byungchul Park wrote:
> 
> > > > +
> > > > +	/*
> > > > +	 * Whenever irq happens, these are updated so that we can
> > > > +	 * distinguish each irq context uniquely.
> > > > +	 */
> > > > +	unsigned int		hardirq_id;
> > > > +	unsigned int		softirq_id;
> > > 
> > > An alternative approach would be to 'unwind' or discard all historical
> > > events from a nested context once we exit it.
> > 
> > That's one of what I considered. However, it would make code complex to
> > detect if pend_lock ring buffer was wrapped.
> 
> I'm not sure I see the need for detecting that...
> 
> > > 
> > > After all, all we care about is the history of the release context, once
> > > the context is gone, we don't care.
> > 
> > We must care it and decide if the next plock in the ring buffer might be
> > valid one or not.
> 
> So I was thinking this was an overwriting ring buffer; something like
> so:

OK. I am making code just overwrite ring buffer when overflowing it,
instead of warning the situation.

Thank you very much.

> 
> struct pend_lock plocks[64];
> unsigned int plocks_idx;
> 
> static void plocks_add(..)
> {
> 	unsigned int idx = (plocks_idx++) % 64;
> 
> 	plocks[idx] = ...;
> }
> 
> static void plocks_close_context(int ctx)
> {
> 	for (i = 0; i < 64; i++) {
> 		int idx = (plocks_idx - 1) % 64;
> 		if (plocks[idx].ctx != ctx)
> 			break;
> 
> 		plocks_idx--;
> 	}
> }
> 
> Similarly for the release, it need only look at 64 entries and terminate
> early if the generation number is too old.
> 
> static void plocks_release(unsigned int gen)
> {
> 	for (i = 0; i < 64; i++) {
> 		int idx = (plocks_idx - 1 - i) % 64;
> 		if ((int)(plocks[idx].gen_id - gen) < 0)
> 			break;
> 
> 		/* do release muck */
> 	}
> }