From: Vasily Averin <vvs@virtuozzo.com>
To: Miklos Szeredi <mszeredi@redhat.com>
Cc: Maxim Patlasov <maximvp@gmail.com>,
LKML <linux-kernel@vger.kernel.org>,
Kirill Tkhai <ktkhai@virtuozzo.com>
Subject: Re: [fuse] 6b2fb79963: WARNING:at_fs/fuse/file.c:#tree_insert[fuse]
Date: Thu, 25 Jun 2020 10:48:03 +0300 [thread overview]
Message-ID: <2733b41a-b4c6-be94-0118-a1a8d6f26eec@virtuozzo.com> (raw)
In-Reply-To: <CAOssrKdTTZEBEfwFm+3dYJ5XB9FsFAeF5g5ydeSo7ZPKkqjJXQ@mail.gmail.com>
On 6/16/20 3:35 PM, Miklos Szeredi wrote:
> On Mon, Jun 15, 2020 at 7:59 AM Vasily Averin <vvs@virtuozzo.com> wrote:
>>
>> On 6/15/20 3:50 AM, kernel test robot wrote:
>>> FYI, we noticed the following commit (built with gcc-9):
>>>
>>> commit: 6b2fb79963fbed7db3ef850926d913518fd5c62f ("fuse: optimize writepages search")
>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
>>
>>> [ 1030.995703] ------------[ cut here ]------------
>>> [ 1030.997563] WARNING: CPU: 1 PID: 17211 at fs/fuse/file.c:1728 tree_insert+0xab/0xc0 [fuse]
>>> [ 1031.021943] RIP: 0010:tree_insert+0xab/0xc0 [fuse]
>>> [ 1031.057802] Call Trace:
>>> [ 1031.060015] fuse_writepages_fill+0x5da/0x6a0 [fuse]
>>> [ 1031.062536] write_cache_pages+0x171/0x470
>>> [ 1031.064933] ? fuse_writepages+0x100/0x100 [fuse]
>>> [ 1031.067419] ? terminate_walk+0xd3/0xf0
>>> [ 1031.069707] ? _cond_resched+0x19/0x30
>>> [ 1031.072140] ? __kmalloc+0x274/0x280
>>> [ 1031.074407] fuse_writepages+0x8a/0x100 [fuse]
>>> [ 1031.076599] do_writepages+0x43/0xe0
>>
>> It is WARN_ON(!wpa->ia.ap.num_pages);
>> however tree_insert() was called from fuse_writepages_fill() with ap->num_pages = 0;
>> In submitted PATCH RFC we have used
>>
>> +static int tree_insert(struct rb_root *root, struct fuse_req *ins_req)
>> ...
>> + pgoff_t idx_to = idx_from + (ins_req->num_pages ?
>> + ins_req->num_pages - 1 : 0);
>>
>> Though committed patch version have
>>
>> +static void tree_insert(struct rb_root *root, struct fuse_writepage_args *wpa)
>> ...
>> + pgoff_t idx_to = idx_from + wpa->ia.ap.num_pages - 1;
>> ...
>> + WARN_ON(!wpa->ia.ap.num_pages);
>>
>> Miklos,
>> do you have any objections if I return to our initial proposal?
>> Am I missed something and it is not allowed now?
>
> No objections, but you need to explain with a comment why that special
> casing of num_pages == 0 is needed. I don't understand it yet.
fuse_writepages_fill() handles few different cases,
in some of them data->wpa should be re-allocated and re-initialized,
another cases requires just add new page into existing wpa and increments num_pages.
In current implementation fuse_writepages_fill() tries to share the code,
by this way for new wpa it calls tree_insert() with num_pages = 0
then switches to common code used non-modified num_pages and increments it at the very end.
I've prepared patch that calls tree_insert() with num_pages = 1,
It have few other minor optimizations therefore I think it is better
than remove incorrect WARN_ON from tree_insert proposed earlier.
During investigations I've noticed few other stranges in neighborhood:
1) fuse_writepages() ignores some errors taken from fuse_writepages_fill()
I believe it is a bug: if .writepages is called with WB_SYNC_ALL
it should either guarantee that all data was successfully saved or return error.
2) fuse_writepages_fill uses following construction:
if (wpa && ap->num_pages &&
(A || B || C)) {
action;
} else if (wpa && ap->num_pages == data->max_pages) {
if (D) {
the same action;
}
}
- ap->num_pages check is always true and can be removed
- "if" and "else if" calls the same action and can be merged.
I'm going to sent separate patches to resolve it.
Thank you,
Vasily Averin
next prev parent reply other threads:[~2020-06-25 7:48 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200615005036.GU12456@shao2-debian>
2020-06-15 5:59 ` Vasily Averin
2020-06-16 12:35 ` Miklos Szeredi
2020-06-18 10:29 ` Kirill Tkhai
2020-06-25 7:48 ` Vasily Averin [this message]
2020-06-25 9:02 ` [PATCH] fuse_writepages_fill() optimization to avoid WARN_ON in tree_insert Vasily Averin
2020-06-27 10:31 ` Sedat Dilek
2020-06-29 21:11 ` Vivek Goyal
2020-07-11 4:01 ` Miklos Szeredi
2020-07-13 8:02 ` Vasily Averin
2020-07-13 16:14 ` Miklos Szeredi
2020-07-14 6:18 ` Vasily Averin
2020-07-14 12:40 ` Sedat Dilek
2020-07-14 12:52 ` Miklos Szeredi
2020-07-14 12:57 ` Sedat Dilek
2020-07-15 7:48 ` Sedat Dilek
2020-06-25 9:30 ` [PATCH] fuse_writepages_fill: simplified "if-else if" constuction Vasily Averin
2020-07-14 12:24 ` Miklos Szeredi
2020-07-14 18:53 ` Vasily Averin
2020-06-25 9:39 ` [PATCH] fuse_writepages ignores errors from fuse_writepages_fill Vasily Averin
2020-07-14 12:44 ` Miklos Szeredi
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=2733b41a-b4c6-be94-0118-a1a8d6f26eec@virtuozzo.com \
--to=vvs@virtuozzo.com \
--cc=ktkhai@virtuozzo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maximvp@gmail.com \
--cc=mszeredi@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®