All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.