Re: Is request_firmware() really safe to call in resume callback when /usr/lib/firmware is on btrfs?

[Luis Chamberlain <mcgrof@kernel.org>]

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