From: Oleg Nesterov <oleg@redhat.com>
To: Jan Kara <jack@suse.cz>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
Dave Chinner <david@fromorbit.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/4] fix the broken lockdep logic in __sb_start_write()
Date: Wed, 22 Jul 2015 23:13:53 +0200 [thread overview]
Message-ID: <20150722211353.GB19636@redhat.com> (raw)
In-Reply-To: <20150721083842.GB6533@quack.suse.cz>
On 07/21, Jan Kara wrote:
>
> On Mon 20-07-15 19:01:03, Oleg Nesterov wrote:
> > 1. wait_event(frozen < level) without rwsem_acquire_read() is just
> > wrong from lockdep perspective. If we are going to deadlock
> > because the caller is buggy, lockdep detect this problem.
> >
> > 2. __sb_start_write() can race with thaw_super() + freeze_super(),
> > and after "goto retry" the 2nd acquire_freeze_lock() is wrong.
> >
> > 3. The "tell lockdep we are doing trylock" hack doesn't look nice.
> >
> > I think this is correct, but this logic should be more explicit.
> > Yes, the recursive read_lock() is fine if we hold the lock on a
> > higher level. But we do not need to fool lockdep. If we can not
> > deadlock in this case then try-lock must not fail and we can use
> > use wait == F throughout this code.
> >
> > Note: as Dave Chinner explains, the "trylock" hack and the fat comment
> > can be probably removed. But this needs a separate change and it will
> > be trivial: just kill __sb_start_write() and rename do_sb_start_write()
> > back to __sb_start_write().
>
> The patch looks good. Did you test this BTW? You can add:
Yes, but "artificially". I just wrote the function which takes/drops
SB_FREEZE_FS twice with and then without SB_FREEZE_WRITE. It worked
as expected, lockdep complained when SB_FREEZE_WRITE wasn't held.
> Reviewed-by: Jan Kara <jack@suse.com>
Thanks!
Oleg.
next prev parent reply other threads:[~2015-07-22 21:13 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-20 17:00 [PATCH 0/4] sb_write: lockdep fixes/cleanups Oleg Nesterov
2015-07-20 17:01 ` [PATCH 1/4] introduce __sb_{acquire,release}_write() helpers Oleg Nesterov
2015-07-21 8:23 ` Jan Kara
2015-07-20 17:01 ` [PATCH 2/4] fix the broken lockdep logic in __sb_start_write() Oleg Nesterov
2015-07-21 8:38 ` Jan Kara
2015-07-22 21:13 ` Oleg Nesterov [this message]
2015-07-20 17:01 ` [PATCH 3/4] move rwsem_release() from sb_wait_write() to freeze_super() Oleg Nesterov
2015-07-21 8:40 ` Jan Kara
2015-07-20 17:01 ` [PATCH 4/4] change thaw_super() to re-acquire s_writers.lock_map Oleg Nesterov
2015-07-21 8:48 ` Jan Kara
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150722211353.GB19636@redhat.com \
--to=oleg@redhat.com \
--cc=dave.hansen@linux.intel.com \
--cc=david@fromorbit.com \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.