linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Luis Chamberlain <mcgrof@kernel.org>
To: Lukas Middendorf <kernel@tuxforce.de>,
	Greg KH <gregkh@linuxfoundation.org>,
	dsterba@suse.cz, Jan Kara <jack@suse.cz>,
	Bart Van Assche <bvanassche@acm.org>,
	fsdevel@vger.kernel.org
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: Fri, 16 Apr 2021 23:17:56 +0000	[thread overview]
Message-ID: <20210416231756.GW13911@42.do-not-panic.com> (raw)
In-Reply-To: <20210408180224.GV13911@42.do-not-panic.com>

On Thu, Apr 08, 2021 at 06:02:24PM +0000, Luis Chamberlain wrote:
> 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.

Low and behold, as I suspectd, my old VFS fsfreeze / thaw patch series
this. However I should note that I needed to add remove also the
WQ_FREEZABLE from fs as well, which was missing in my patch series, and
which Jan Kara had pointed out.

However, the VFS freeze work is quite a bit of work which we are still
discussing, so in the meantime, I think we have no other option but
to put the stop-gap patch I suggested with the usermode helper lock.
I will just modify it a bit more.

I'll also post my fs freeze work now again, but I'll note that it
still requires some more work to address everything which we have
discussed in the community. I'll post the patches as I think others
may be interested in the progress of that.

  Luis

      reply	other threads:[~2021-04-16 23:18 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
2021-04-16 23:17                                 ` Luis Chamberlain [this message]

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=20210416231756.GW13911@42.do-not-panic.com \
    --to=mcgrof@kernel.org \
    --cc=bvanassche@acm.org \
    --cc=crope@iki.fi \
    --cc=dsterba@suse.cz \
    --cc=fsdevel@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jack@suse.cz \
    --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).