From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Yang Shi <yang.shi@linux.alibaba.com>
Cc: mgorman@techsingularity.net, adilger.kernel@dilger.ca,
darrick.wong@oracle.com, dchinner@redhat.com,
akpm@linux-foundation.org, linux-ext4@vger.kernel.org,
linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] fs: ext4: use BUG_ON if writepage call comes from direct reclaim
Date: Tue, 3 Jul 2018 19:43:31 -0400 [thread overview]
Message-ID: <20180703234331.GA5104@thunk.org> (raw)
In-Reply-To: <6c305241-d502-b8ea-a187-54c33e4ca692@linux.alibaba.com>
On Tue, Jul 03, 2018 at 10:05:04AM -0700, Yang Shi wrote:
> I'm not sure if it is a good choice to let filesystem handle such vital VM
> regression. IMHO, writing out filesystem page from direct reclaim context is
> a vital VM bug. It means something is definitely wrong in VM. It should
> never happen.
If it does happen, it should happen reliably; this isn't the sort of
thing where some linked list had gotten corrupted. This would be a
structural problem in the VM code.
So presumably, if the WARN_ON triggered, it should be be noticed by VM
developers, and they should fix it.
In general, though, BUG_ON's should be avoided unless there really is
no way to recover.
> It sounds ok to have filesystem throw out warning and handle it, but I'm not
> sure if someone will just ignore the warning, but it should *never* be
> ignored.
If a kernel develper (a VM developer in this case) ignores a warning,
that's just simply professional malpractice. In general WARN_ON's
should only be used as a sign of a kernel bug. So they should never
be ignored.
- Ted
next prev parent reply other threads:[~2018-07-03 23:43 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-03 4:11 [PATCH 1/2] fs: ext4: use BUG_ON if writepage call comes from direct reclaim Yang Shi
2018-07-03 4:11 ` [PATCH 2/2] fs: xfs: " Yang Shi
2018-07-03 4:37 ` Dave Chinner
2018-07-03 17:19 ` Darrick J. Wong
2018-07-03 10:39 ` [PATCH 1/2] fs: ext4: " Theodore Y. Ts'o
2018-07-03 17:05 ` Yang Shi
2018-07-03 23:10 ` Yang Shi
2018-07-03 23:10 ` Yang Shi
2018-07-03 23:43 ` Theodore Y. Ts'o [this message]
2018-07-04 14:03 ` Michal Hocko
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=20180703234331.GA5104@thunk.org \
--to=tytso@mit.edu \
--cc=adilger.kernel@dilger.ca \
--cc=akpm@linux-foundation.org \
--cc=darrick.wong@oracle.com \
--cc=dchinner@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-xfs@vger.kernel.org \
--cc=mgorman@techsingularity.net \
--cc=yang.shi@linux.alibaba.com \
/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.