From: Luis Chamberlain <mcgrof@kernel.org>
To: Lukas Middendorf <kernel@tuxforce.de>,
Greg KH <gregkh@linuxfoundation.org>,
dsterba@suse.cz
Cc: linux-btrfs@vger.kernel.org, Antti Palosaari <crope@iki.fi>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
linux-media@vger.kernel.org
Subject: Re: Is request_firmware() really safe to call in resume callback when /usr/lib/firmware is on btrfs?
Date: Thu, 8 Apr 2021 18:02:24 +0000 [thread overview]
Message-ID: <20210408180224.GV13911@42.do-not-panic.com> (raw)
In-Reply-To: <20210403202538.GW4332@42.do-not-panic.com>
On Sat, Apr 03, 2021 at 08:25:38PM +0000, Luis Chamberlain wrote:
> So creating say 1000 random files in /lib/firmware on a freshly created
> btrfs partition helps reproduce:
>
> mkfs.btrfs /dev/whatever
> mount /dev/wahtever /lib/firmware
> # Put it on /etc/fstab too
>
> Generate 1000 random files on it:
>
> ```
> for n in {1..1000}; do
> dd if=/dev/urandom of=/lib/firmware/file$( printf %03d "$n" ).bin bs=1 count=$((RANDOM + 1024 ))
> done
> ```
>
> Then reboot, upon reboot do:
>
> modprobe test_firmware
> echo 1 > /sys/devices/virtual/misc/test_firmware/config_enable_resume_test
> systemctl suspend
>
> If its a guest wake it up:
>
> virsh dompmwakeup domidofguest
This happens because:
btrfs_lookup() --> ... -->
btrfs_search_slot() --> read_block_for_search() -->
--> read_tree_block() --> btree_read_extent_buffer_pages() -->
--> submit_one_bio() --> btrfs_submit_metadata_bio() -->
--> btrfsic_submit_bio() --> submit_bio()
--> this completes and then
--> wait_on_page_locked() on the first page
--> never returns
I also managed to reproduce this easily with XFS as well, so this is not
a btrfs thing as I suspected. It does not happen with ext4 though.
However I think that's just by chance, it should still be prone to the
same issue.
Either way, I'm dusting off my patches for fs freeze as I believe that
should fix this problem. I am not sure if we want a stop gap hack like
the one I posted in the meantime... I don't think so. I rather fix this
well with the series I'll post for fs freeze. Give me a bit of time and
I'll CC you on the patches.
Luis
next prev parent reply other threads:[~2021-04-08 18:02 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-09 18:51 Is request_firmware() really safe to call in resume callback when /usr/lib/firmware is on btrfs? Lukas Middendorf
2020-08-13 16:37 ` Luis Chamberlain
2020-08-13 21:53 ` Lukas Middendorf
2020-08-13 22:13 ` Luis Chamberlain
2020-08-14 11:38 ` Lukas Middendorf
2020-08-14 16:37 ` Luis Chamberlain
2020-08-14 21:59 ` Lukas Middendorf
2020-08-17 15:20 ` Luis Chamberlain
2020-08-17 22:04 ` Lukas Middendorf
2020-08-18 14:37 ` Luis Chamberlain
2021-04-01 14:59 ` Lukas Middendorf
2021-04-02 18:02 ` Luis Chamberlain
2021-04-02 22:19 ` Luis Chamberlain
2021-04-02 22:58 ` Luis Chamberlain
2021-04-03 10:24 ` Lukas Middendorf
2021-04-03 16:07 ` Lukas Middendorf
2021-04-03 20:25 ` Luis Chamberlain
2021-04-03 21:04 ` Luis Chamberlain
2021-04-05 9:52 ` Lukas Middendorf
2021-04-04 0:50 ` Lukas Middendorf
2021-04-08 18:02 ` Luis Chamberlain [this message]
2021-04-16 23:17 ` Luis Chamberlain
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=20210408180224.GV13911@42.do-not-panic.com \
--to=mcgrof@kernel.org \
--cc=crope@iki.fi \
--cc=dsterba@suse.cz \
--cc=gregkh@linuxfoundation.org \
--cc=kernel@tuxforce.de \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@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;
as well as URLs for NNTP newsgroup(s).