[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160330103601.GT3408@twins.programming.kicks-ass.net>
Date: Wed, 30 Mar 2016 12:36:01 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Boqun Feng <boqun.feng@...il.com>
Cc: Ingo Molnar <mingo@...nel.org>,
Alfredo Alvarez Fernandez <alfredoalvarezfernandez@...il.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Sedat Dilek <sedat.dilek@...il.com>,
Theodore Ts'o <tytso@....edu>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [Linux-v4.6-rc1] ext4: WARNING: CPU: 2 PID: 2692 at
kernel/locking/lockdep.c:2017 __lock_acquire+0x180e/0x2260
On Wed, Mar 30, 2016 at 05:59:54PM +0800, Boqun Feng wrote:
> > @@ -3164,6 +3181,7 @@ static int __lock_acquire(struct lockdep_map *lock, unsigned int subclass,
> > hlock->acquire_ip = ip;
> > hlock->instance = lock;
> > hlock->nest_lock = nest_lock;
> > + hlock->irq_context = 2*(!!curr->hardirq_context) + !!curr->softirq_context;
> > hlock->trylock = trylock;
> > hlock->read = read;
> > hlock->check = check;
>
> This is just for cleaning up, right? However ->hardirq_context and
> ->softirq_context only defined when CONFIG_TRACE_IRQFLAGS=y.
Ah, that is the reason it was in a 'funny' place.
The other reason is that we're careful to reduce hardirq_context to 0,1
but don't do so for softirq_context.
> So we should use macro like current_hardirq_context() here? Or
> considering the two helpers introduced in my RFC:
>
> http://lkml.kernel.org/g/1455602265-16490-2-git-send-email-boqun.feng@gmail.com
>
> if you don't think that overkills ;-)
Yeah, that might work, although I would like to keep the !! on both,
makes me worry less.
Powered by blists - more mailing lists