[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140113160705.GA7616@redhat.com>
Date: Mon, 13 Jan 2014 17:07:05 +0100
From: Oleg Nesterov <oleg@...hat.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Steven Rostedt <rostedt@...dmis.org>,
Paul McKenney <paulmck@...ux.vnet.ibm.com>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: check && lockdep_no_validate (Was: lockdep: Introduce
wait-type checks)
On 01/12, Peter Zijlstra wrote:
>
> On Thu, Jan 09, 2014 at 06:54:48PM +0100, Oleg Nesterov wrote:
> >
> > --- a/kernel/locking/lockdep.c
> > +++ b/kernel/locking/lockdep.c
> > @@ -1939,7 +1939,8 @@ check_prevs_add(struct task_struct *curr, struct held_lock *next)
> > * Only non-recursive-read entries get new dependencies
> > * added:
> > */
> > - if (hlock->read != 2) {
> > + if (hlock->read != 2 &&
> > + hlock->instance->key != &__lockdep_no_validate__) {
> > if (!check_prev_add(curr, hlock, next,
> > distance, trylock_loop))
> > return 0;
> >
>
> Hmm, you are quite right indeed;
Thanks!
> although I would write it like:
>
> if (hlock->read != 2 && hlock->check == 2)
>
> because the __lockdep_no_validate__ thing forces the ->check value to 1.
Agreed, hlock->check == 2 looks better. But this connects to another
patch I sent which removes hlock->check...
OK, I'll wait for review on that patch, then resend this one with
->check or __lockdep_no_validate__ depending on the result.
Oleg.
--
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/
Powered by blists - more mailing lists