From: Jan Kara <jack@suse.cz>
To: Liu Bo <obuil.liubo@gmail.com>
Cc: willy@infradead.org, dan.j.williams@intel.com,
Fengguang Wu <fengguang.wu@intel.com>, Jan Kara <jack@suse.cz>,
linux-fsdevel@vger.kernel.org, linux-nvdimm@lists.01.org
Subject: Re: a few questions about pagevc_lookup_entries
Date: Thu, 20 Jun 2019 10:36:28 +0200 [thread overview]
Message-ID: <20190620083628.GH13630@quack2.suse.cz> (raw)
In-Reply-To: <CANQeFDCCGED3BR0oTpzQ75gtGpdGCw8FLf+kspBYytw3YteXAw@mail.gmail.com>
[added some relevant lists to CC - this can safe some people debugging by
being able to google this discussion]
On Wed 19-06-19 15:57:38, Liu Bo wrote:
> I found a weird dead loop within invalidate_inode_pages2_range, the
> reason being that pagevec_lookup_entries(index=1) returns an indices
> array which has only one entry storing value 0, and this has led
> invalidate_inode_pages2_range() to a dead loop, something like,
>
> invalidate_inode_pages2_range()
> -> while (pagevec_lookup_entries(index=1, indices))
> -> for (i = 0; i < pagevec_count(&pvec); i++) {
> -> index = indices[0]; // index is set to 0
> -> if (radix_tree_exceptional_entry(page)) {
> -> if (!invalidate_exceptional_entry2()) //
> ->__dax_invalidate_mapping_entry // return 0
> -> // entry marked as PAGECACHE_TAG_DIRTY/TOWRITE
> ret = -EBUSY;
> ->continue;
> } // end of if (radix_tree_exceptional_entry(page))
> -> index++; // index is set to 1
>
> The following debug[1] proved the above analysis, I was wondering if
> this was a corner case that pagevec_lookup_entries() allows or a
> known bug that has been fixed upstream?
>
> ps: the kernel in use is 4.19.30 (LTS).
Hum, the above trace suggests you are using DAX. Are you really? Because the
stacktrace below shows we are working on fuse inode so that shouldn't
really be DAX inode...
Honza
> [1]:
> $git diff
> diff --git a/mm/truncate.c b/mm/truncate.c
> index 71b65aab8077..82bfeeb53135 100644
> --- a/mm/truncate.c
> +++ b/mm/truncate.c
> @@ -692,6 +692,7 @@ int invalidate_inode_pages2_range(struct
> address_space *mapping,
> struct page *page = pvec.pages[i];
>
> /* We rely upon deletion not changing page->index */
> + WARN_ONCE(index > indices[i], "index = %d
> indices[%d]=%d\n", index, i, indices[i]);
> index = indices[i];
> if (index > end)
> break;
>
> [ 129.095383] ------------[ cut here ]------------
> [ 129.096164] index = 1 indices[0]=0
> [ 129.096786] WARNING: CPU: 0 PID: 3022 at mm/truncate.c:695
> invalidate_inode_pages2_range+0x471/0x500
> [ 129.098234] Modules linked in:
> [ 129.098717] CPU: 0 PID: 3022 Comm: doio Not tainted 4.19.30+ #4
> ...
> [ 129.101288] RIP: 0010:invalidate_inode_pages2_range+0x471/0x500
> ...
> [ 129.114162] Call Trace:
> [ 129.114623] ? __schedule+0x2ad/0x860
> [ 129.115214] ? prepare_to_wait_event+0x80/0x140
> [ 129.115903] ? finish_wait+0x3f/0x80
> [ 129.116452] ? request_wait_answer+0x13d/0x210
> [ 129.117128] ? remove_wait_queue+0x60/0x60
> [ 129.117757] ? make_kgid+0x13/0x20
> [ 129.118277] ? fuse_change_attributes_common+0x7d/0x130
> [ 129.119057] ? fuse_change_attributes+0x8d/0x120
> [ 129.119754] fuse_dentry_revalidate+0x2c5/0x300
> [ 129.120456] lookup_fast+0x237/0x2b0
> [ 129.121018] path_openat+0x15f/0x1380
> [ 129.121614] ? generic_update_time+0x6b/0xd0
> [ 129.122316] do_filp_open+0x91/0x100
> [ 129.122876] do_sys_open+0x126/0x210
> [ 129.123453] do_syscall_64+0x55/0x180
> [ 129.124036] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> [ 129.124820] RIP: 0033:0x7fbe0cd75e80
> ...
> [ 129.134574] ---[ end trace c0fc0bbc5aebf0dc ]---
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
next parent reply other threads:[~2019-06-20 8:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CANQeFDCCGED3BR0oTpzQ75gtGpdGCw8FLf+kspBYytw3YteXAw@mail.gmail.com>
2019-06-20 8:36 ` Jan Kara [this message]
2019-06-20 22:03 ` a few questions about pagevc_lookup_entries Liu Bo
2019-06-24 7:25 ` Miklos Szeredi
2019-06-24 10:41 ` Jan Kara
2019-06-24 17:13 ` Liu Bo
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=20190620083628.GH13630@quack2.suse.cz \
--to=jack@suse.cz \
--cc=dan.j.williams@intel.com \
--cc=fengguang.wu@intel.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nvdimm@lists.01.org \
--cc=obuil.liubo@gmail.com \
--cc=willy@infradead.org \
/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).