From: Sasha Levin <sashal@kernel.org>
To: dsterba@suse.cz, linux-kernel@vger.kernel.org,
stable@vger.kernel.org, Omar Sandoval <osandov@fb.com>,
Johannes Thumshirn <jthumshirn@suse.de>,
David Sterba <dsterba@suse.com>,
linux-btrfs@vger.kernel.org
Subject: Re: [PATCH AUTOSEL 5.4 299/350] btrfs: don't prematurely free work in end_workqueue_fn()
Date: Thu, 19 Dec 2019 18:06:49 -0500 [thread overview]
Message-ID: <20191219230649.GT17708@sasha-vm> (raw)
In-Reply-To: <20191212121103.GR3929@suse.cz>
On Thu, Dec 12, 2019 at 01:11:03PM +0100, David Sterba wrote:
>On Tue, Dec 10, 2019 at 04:06:44PM -0500, Sasha Levin wrote:
>> From: Omar Sandoval <osandov@fb.com>
>>
>> [ Upstream commit 9be490f1e15c34193b1aae17da58e14dd9f55a95 ]
>>
>> Currently, end_workqueue_fn() frees the end_io_wq entry (which embeds
>> the work item) and then calls bio_endio(). This is another potential
>> instance of the bug in "btrfs: don't prematurely free work in
>> run_ordered_work()".
>>
>> In particular, the endio call may depend on other work items. For
>> example, btrfs_end_dio_bio() can call btrfs_subio_endio_read() ->
>> __btrfs_correct_data_nocsum() -> dio_read_error() ->
>> submit_dio_repair_bio(), which submits a bio that is also completed
>> through a end_workqueue_fn() work item. However,
>> __btrfs_correct_data_nocsum() waits for the newly submitted bio to
>> complete, thus it depends on another work item.
>>
>> This example currently usually works because we use different workqueue
>> helper functions for BTRFS_WQ_ENDIO_DATA and BTRFS_WQ_ENDIO_DIO_REPAIR.
>> However, it may deadlock with stacked filesystems and is fragile
>> overall. The proper fix is to free the work item at the very end of the
>> work function, so let's do that.
>>
>> Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
>> Signed-off-by: Omar Sandoval <osandov@fb.com>
>> Reviewed-by: David Sterba <dsterba@suse.com>
>> Signed-off-by: David Sterba <dsterba@suse.com>
>> Signed-off-by: Sasha Levin <sashal@kernel.org>
>
>The were more patches in the series, all contain "don't prematurely free
>work in" and were part of a rework of async work processing. They're
>fixing a very uncommon usecase, so if there's desire to backport them
>the whole series needs to go in.
>
>In the autosel list, there are only 2 and without the important fix.
>
>c495dcd6fbe1 btrfs: don't prematurely free work in run_ordered_work()
>9be490f1e15c btrfs: don't prematurely free work in end_workqueue_fn()
>e732fe95e4ca btrfs: don't prematurely free work in reada_start_machine_worker()
>57d4f0b86327 btrfs: don't prematurely free work in scrub_missing_raid56_worker()
I've queued all 4, thanks!
>a0cac0ec961f btrfs: get rid of unique workqueue helper functions
>- this is only a cleanup that removes code obsoleted by the fixes above,
> probably out of scope of stable
>
>I have intentionally not tagged the patches for stable, the usecase is
>is specific to one user (FB), the known reproducer is only their
>workload and the fixes are in their kernel already.
>
>So if there's desire to add the patches to stable trees, then it has to
>be the whole series, but I don't see a strong reason for it.
If it's upstream and broken then it's relevant, it doesn't matter if its
one user or a million users.
--
Thanks,
Sasha
next prev parent reply other threads:[~2019-12-19 23:06 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20191210210735.9077-1-sashal@kernel.org>
2019-12-10 21:06 ` [PATCH AUTOSEL 5.4 299/350] btrfs: don't prematurely free work in end_workqueue_fn() Sasha Levin
2019-12-12 12:11 ` David Sterba
2019-12-19 23:06 ` Sasha Levin [this message]
2019-12-10 21:06 ` [PATCH AUTOSEL 5.4 300/350] btrfs: don't prematurely free work in run_ordered_work() Sasha Levin
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=20191219230649.GT17708@sasha-vm \
--to=sashal@kernel.org \
--cc=dsterba@suse.com \
--cc=dsterba@suse.cz \
--cc=jthumshirn@suse.de \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=osandov@fb.com \
--cc=stable@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox