From: Tejun Heo <tj@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jens Axboe <axboe@kernel.dk>,
Kent Overstreet <kent.overstreet@gmail.com>,
linux-block <linux-block@vger.kernel.org>,
NeilBrown <neilb@suse.com>, Arnd Bergmann <arnd@arndb.de>
Subject: Re: [GIT PULL] Block changes for 4.18-rc
Date: Mon, 4 Jun 2018 11:20:17 -0700 [thread overview]
Message-ID: <20180604182017.GA1351649@devbig577.frc2.facebook.com> (raw)
In-Reply-To: <CA+55aFz_iLabbCcCEWY8j5KcKCDsC7074f4EDi8mxB7-FrBHwA@mail.gmail.com>
Hey, Linus.
On Mon, Jun 04, 2018 at 09:24:28AM -0700, Linus Torvalds wrote:
> Tejun, the code in question is mddev_put() in drivers/md/md.c, and it
> basically does
>
> INIT_WORK(&mddev->del_work, mddev_delayed_delete);
> queue_work(md_misc_wq, &mddev->del_work);
>
> inside a spinlock, but then wants to do some stuff *outside* the
> spinlock before that mddev_delayed_delete() thing actually gets
> called.
>
> Is there some way to "half-queue" the work - enough that a
> flush_workqueue() will wait for it, but still guaranteeing that it
> won't actually run until released?
Such interface doesn't exist, yet anyway. Workqueue does have the
concept of delayed queueing to handle max concurrency limits and we
can probably piggyback on that to create an interface which queues and
delays the work item and another interface to undelay it.
That said, it feels like a super-niche feature for a weird use case.
> IOW, what I think that code really wants to do is perhaps something like
>
> /* under &all_mddevs_lock spinlock */
> .. remove from all lists so that it can't be found ..
>
> .. but add it to the md_misc_wq so that people will wait for it ..
>
> INIT_WORK_LOCKED(&mddev->del_work, mddev_delayed_delete);
> queue_work(md_misc_wq, &mddev->del_work);
> ...
>
> spin_unlock(&all_mddevs_lock);
>
> /* mddev is still guaranteed live */
> bioset_exit(&mddev->bio_set);
> bioset_exit(&mddev->sync_set);
>
> /* NOW we can release it */
> if (queued)
> unlock_work(&mddev->del_work);
> else
> kfree(mddev);
> Linus
Looking at the code, the fundamental problem seems to be that it's
weaving different parts of sync and async paths. I don't understand
why it'd punt the destructin of mddev but destroy biosets
synchronously. Can't it do sth like the following?
lock;
if (need to be async) {
/* async destruction path */
INIT_WORK(...);
queue_work(...); /* the work does bioset_exits */
unlock;
return;
}
/* sync destructino path */
do whatever needs to be done under lock;
unlock;
bioset_exit(...);
bioset_exit(...);
kfree(mddev);
Thanks.
--
tejun
next prev parent reply other threads:[~2018-06-04 18:20 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-04 0:42 [GIT PULL] Block changes for 4.18-rc Jens Axboe
2018-06-04 15:51 ` Linus Torvalds
2018-06-04 15:54 ` Jens Axboe
2018-06-04 16:24 ` Linus Torvalds
2018-06-04 18:20 ` Tejun Heo [this message]
2018-06-04 18:22 ` Linus Torvalds
2018-06-04 18:25 ` Jens Axboe
2018-06-04 19:04 ` Kent Overstreet
2018-06-05 0:42 ` Linus Torvalds
2018-06-05 0:44 ` Linus Torvalds
2018-06-05 0:56 ` Kent Overstreet
2018-06-05 1:00 ` Linus Torvalds
2018-06-07 1:45 ` Jens Axboe
2018-06-04 21:16 ` NeilBrown
2018-06-04 21:21 ` Kent Overstreet
2018-06-04 22:52 ` NeilBrown
2018-06-05 0:34 ` Kent Overstreet
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=20180604182017.GA1351649@devbig577.frc2.facebook.com \
--to=tj@kernel.org \
--cc=arnd@arndb.de \
--cc=axboe@kernel.dk \
--cc=kent.overstreet@gmail.com \
--cc=linux-block@vger.kernel.org \
--cc=neilb@suse.com \
--cc=torvalds@linux-foundation.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