[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161013165807.GA21138@redhat.com>
Date: Thu, 13 Oct 2016 18:58:08 +0200
From: Oleg Nesterov <oleg@...hat.com>
To: Dave Chinner <david@...morbit.com>
Cc: Jan Kara <jack@...e.cz>, Al Viro <viro@...iv.linux.org.uk>,
Nikolay Borisov <kernel@...p.com>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
fstests@...r.kernel.org
Subject: Re: [PATCH V2 2/2] fs/super.c: don't fool lockdep in
freeze_super() and thaw_super() paths
Dave, I am sorry for delay.
On 10/10, Dave Chinner wrote:
>
> So, it's time to waste more time explaining why lockdep is telling
> us about something that *isn't a bug*.
> [... snip ...]
OK, thanks. I am not surprised although I have to admit I wasn't sure.
> Basically, what we are seeing here is yet another case of "lockdep
> is just smart enough to be really dumb" because we cannot fully
> express or cleanly annotate the contexts in which it is being asked
> to validate.
Yes... perhaps we can add the new lockdep helpers to avoid the false-
positives like this one, but so far it is not clear to me what we can do.
Somehow we need to tell it to to avoid check_prev_add() because we know
that the work function won't take sb_internal, but at the same time we
should complain if it actually does this. Lets ignore this patch for now.
Oleg.
Powered by blists - more mailing lists