From: Dave Chinner <david@fromorbit.com>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: Dave Chinner <dchinner@redhat.com>,
linux-xfs@vger.kernel.org, linux-mm@kvack.org,
Omar Sandoval <osandov@fb.com>
Subject: Re: xfs: circular locking dependency between fs_reclaim and sb_internal [kernel 4.18]
Date: Thu, 21 Jun 2018 09:35:02 +1000 [thread overview]
Message-ID: <20180620233502.GP19934@dastard> (raw)
In-Reply-To: <8fda53b0-9d86-943b-e8b4-fd9d6553f010@i-love.sakura.ne.jp>
On Wed, Jun 20, 2018 at 08:25:51PM +0900, Tetsuo Handa wrote:
> I'm hitting below lockdep warning (essentially same with
> http://lkml.kernel.org/r/1518666178.6070.25.camel@gmail.com ) as of commit
> ba4dbdedd3edc279 ("Merge tag 'jfs-4.18' of git://github.com/kleikamp/linux-shaggy")
> on linux.git . I think that this became visible by commit 93781325da6e07af
> ("lockdep: fix fs_reclaim annotation") which went to 4.18-rc1. What should we do?
Fix the broken lockdep code?
Superblock freeze level accounting is not a lock. By the time a
freeze has got to the state where xfs_trans_alloc() would block,
we've already frozen new data writes and drained all the dirty
pages. Hence if the filesystem is frozen down to the transaction
level, kswapd will never enter this path on the filesystem because
there will be no dirty pages to write back.
So this is a false positive.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2018-06-20 23:35 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-20 11:25 xfs: circular locking dependency between fs_reclaim and sb_internal [kernel 4.18] Tetsuo Handa
2018-06-20 23:35 ` Dave Chinner [this message]
2018-06-21 0:15 ` Dave Chinner
2018-06-21 5:47 ` [PATCH] Makefile: Fix backtrace breakage Tetsuo Handa
2018-06-21 5:56 ` Greg Thelen
2018-06-21 20:48 ` Andi Kleen
2018-06-21 21:30 ` Steven Rostedt
2018-06-21 21:31 ` Steven Rostedt
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=20180620233502.GP19934@dastard \
--to=david@fromorbit.com \
--cc=dchinner@redhat.com \
--cc=linux-mm@kvack.org \
--cc=linux-xfs@vger.kernel.org \
--cc=osandov@fb.com \
--cc=penguin-kernel@i-love.sakura.ne.jp \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).