From: Jan Kara <jack@suse.cz>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: jack@suse.cz, linux-fsdevel@vger.kernel.org,
linux-block@vger.kernel.org, axboe@kernel.dk, tj@kernel.org,
david@fromorbit.com
Subject: Re: [PATCH] bdi: Fix oops in wb_workfn()
Date: Wed, 9 May 2018 11:47:19 +0200 [thread overview]
Message-ID: <20180509094719.sjlw5y4f3cp3tkj7@quack2.suse.cz> (raw)
In-Reply-To: <201805040735.ADG57320.VFOQOJMOLHFStF@I-love.SAKURA.ne.jp>
On Fri 04-05-18 07:35:34, Tetsuo Handa wrote:
> Jan Kara wrote:
> > Make wb_workfn() use wakeup_wb() for requeueing the work which takes all
> > the necessary precautions against racing with bdi unregistration.
>
> Yes, this patch will solve NULL pointer dereference bug. But is it OK to
> leave list_empty(&wb->work_list) == false situation? Who takes over the
> role of making list_empty(&wb->work_list) == true?
That's a good question. The reason is the last running instance of
wb_workfn() cannot leave with the work_list non-empty. Once WB_registered
is cleared we cannot add new entries to work_list. Then we'll queue and
flush last wb_workfn() to clean up the list. The problem with NULL ptr
deref has been triggered not by this last running wb_workfn() but by one
running independently in parallel to wb_shutdown(). So something like:
CPU0 CPU1 CPU2
wb_workfn()
do {
...
} while (!list_empty(&wb->work_list));
wb_queue_work()
if (test_bit(WB_registered, &wb->state)) {
list_add_tail(&work->list, &wb->work_list);
mod_delayed_work(bdi_wq, &wb->dwork, 0);
}
wb_shutdown()
if (!test_and_clear_bit(WB_registered, &wb->state)) {
...
mod_delayed_work(bdi_wq, &wb->dwork, 0);
flush_delayed_work(&wb->dwork);
if (!list_empty(&wb->work_list))
mod_delayed_work(bdi_wq, &wb->dwork, 0); -> queues buggy work
> Just a confirmation, for Fabiano Rosas is facing a problem that "write call
> hangs in kernel space after virtio hot-remove" and is thinking that we might
> need to go the opposite direction
> ( http://lkml.kernel.org/r/f0787b79-1e50-5f55-a400-44f715451777@linux.ibm.com ).
Yes, I'm aware of that report and I think it should be solved
differently than what Fabiano suggests.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2018-05-09 9:47 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-03 16:26 [PATCH] bdi: Fix oops in wb_workfn() Jan Kara
2018-05-03 21:55 ` Dave Chinner
2018-05-03 21:57 ` Jens Axboe
2018-05-09 9:48 ` Jan Kara
2018-05-03 22:35 ` Tetsuo Handa
2018-05-09 9:47 ` Jan Kara [this message]
2018-05-19 14:27 ` Tetsuo Handa
2018-05-21 9:38 ` Jan Kara
2018-05-25 10:15 ` Tetsuo Handa
2018-05-09 10:31 ` Jan Kara
2018-05-09 14:42 ` Jens Axboe
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=20180509094719.sjlw5y4f3cp3tkj7@quack2.suse.cz \
--to=jack@suse.cz \
--cc=axboe@kernel.dk \
--cc=david@fromorbit.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
--cc=tj@kernel.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 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.