linux-kernel - Re: [PATCH v6 05/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: <20170424093051.imizyhpifqf4t6bc@hirez.programming.kicks-ass.net>
Date:   Mon, 24 Apr 2017 11:30:51 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Byungchul Park <byungchul.park@....com>
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,
        willy@...radead.org, npiggin@...il.com, kernel-team@....com
Subject: Re: [PATCH v6 05/15] lockdep: Implement crossrelease feature

On Mon, Apr 24, 2017 at 12:04:12PM +0900, Byungchul Park wrote:
> On Wed, Apr 19, 2017 at 07:19:54PM +0200, Peter Zijlstra wrote:
> > > +/*
> > > + * For crosslock.
> > > + */
> > > +static int add_xlock(struct held_lock *hlock)
> > > +{
> > > +	struct cross_lock *xlock;
> > > +	unsigned int gen_id;
> > > +
> > > +	if (!graph_lock())
> > > +		return 0;
> > > +
> > > +	xlock = &((struct lockdep_map_cross *)hlock->instance)->xlock;
> > > +
> > > +	gen_id = (unsigned int)atomic_inc_return(&cross_gen_id);
> > > +	xlock->hlock = *hlock;
> > > +	xlock->hlock.gen_id = gen_id;
> > > +	graph_unlock();
> > 
> > What does graph_lock protect here?
> 
> Modifying xlock(not xhlock) instance should be protected with graph_lock.
> Don't you think so?

Ah, right you are. I think I got confused between our xhlock (local)
array and the xlock instance thing. The latter needs protection to
serialize concurrent acquires.

> > > +static int commit_xhlocks(struct cross_lock *xlock)
> > > +{
> > > +	unsigned int cur = current->xhlock_idx;
> > > +	unsigned int i;
> > > +
> > > +	if (!graph_lock())
> > > +		return 0;
> > > +
> > > +	for (i = cur - 1; !xhlock_same(i, cur); i--) {
> > > +		struct hist_lock *xhlock = &xhlock(i);
> > 
> > *blink*, you mean this?
> > 
> > 	for (i = 0; i < MAX_XHLOCKS_NR; i++) {
> > 		struct hist_lock *xhlock = &xhlock(cur - i);
> 
> I will change the loop to this form.
> 
> > Except you seem to skip over the most recent element (@cur), why?
> 
> Currently 'cur' points to the next *free* slot.

Well, there's no such thing has a 'free' slot, its a _ring_ buffer.

But:

+static void add_xhlock(struct held_lock *hlock)
+{
+       unsigned int idx = current->xhlock_idx++;
+       struct hist_lock *xhlock = &xhlock(idx);

Yes, I misread that. Then '0' has the oldest entry, which is slightly
weird. Should we change that?


> > > +
> > > +		if (!xhlock_used(xhlock))
> > > +			break;
> > > +
> > > +		if (before(xhlock->hlock.gen_id, xlock->hlock.gen_id))
> > > +			break;
> > > +
> > > +		if (same_context_xhlock(xhlock) &&
> > > +		    !commit_xhlock(xlock, xhlock))
> > 
> > return with graph_lock held?
> 
> No. When commit_xhlock() returns 0, the lock was already unlocked.

Please add a comment, because I completely missed that. That's at least
2 functions deeper.