Re: [PATCH] firmware_loader: Use init_utsname()->release

[John Garry <john.g.garry@oracle.com>]

On 28/02/2024 15:18, Luis Chamberlain wrote:
>>> But these are expected as the selftests tries silly things to ensure
>>> they are not allowed.
>>>
>>> If you can reproduce it there, it would be appreciated if you look underneath
>>> the hood a bit, or share anything glaring and obvious which may help
>>> reproduce this.
>> Update: commenting-out /lib/udev/rules.d/50-firmware.rules seems to make the
>> test reliably pass for v6.8-rc5,
> Great, note that if you had a hung task even with the udev rule that is
> not expected and is indicative of a bug I cannot reproduce.
> 
>> but not with my patch on top - I still get
>> a hang there. I'll investigate that hang with my patch.
> So your hang is with the udev rule on vanilla v6.8-rc5 ?
> Because for the
> life of me, I don't see it.

I think that I spoke too soon. After adding debug to see any difference 
between mainline and my patch, I get this:

[  806.830318] misc test_firmware: Direct firmware load for 
tmp.k5xh5F4xvG failed with error -2
[  806.830322] misc test_firmware: Falling back to sysfs fallback for: 
tmp.k5xh5F4xvG
[ 1006.958148] INFO: task fw_filesystem.s:5565 blocked for more than 120 
seconds.
[ 1007.045111]       Not tainted 6.8.0-rc5-g11c039aebb43 #40
[ 1007.110262] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" 
disables this message.
[ 1007.204462] task:fw_filesystem.s state:D stack:0     pid:5565 
tgid:5565  ppid:1      flags:0x00000002
[ 1007.204470] Call Trace:
[ 1007.204472]  <TASK>
[ 1007.204477]  __schedule+0x3d7/0x1720
[ 1007.204486]  ? ttwu_do_activate+0x7a/0x260
[ 1007.204493]  ? try_to_wake_up+0x81/0x6c0
[ 1007.204495]  schedule+0x39/0x100
[ 1007.204496]  schedule_timeout+0x14f/0x160
[ 1007.204502]  ? __queue_work+0x212/0x500
[ 1007.204507]  ? fw_devm_match+0x29/0x40
[ 1007.204514]  __wait_for_common+0x8f/0x190
[ 1007.204517]  ? __pfx_schedule_timeout+0x10/0x10
[ 1007.204520]  wait_for_completion+0x28/0x30
[ 1007.204522]  trigger_batched_requests_async_store+0x95/0x220
[ 1007.204532]  dev_attr_store+0x18/0x30
[ 1007.204539]  sysfs_kf_write+0x3f/0x50
[ 1007.204547]  kernfs_fop_write_iter+0x140/0x1d0
[ 1007.204550]  vfs_write+0x311/0x430
[ 1007.204557]  ksys_write+0x6b/0xf0
[ 1007.204560]  __x64_sys_write+0x1d/0x30
[ 1007.204562]  do_syscall_64+0x77/0x120
[ 1007.204568]  ? __count_memcg_events+0x6f/0x110
[ 1007.204576]  ? count_memcg_events.constprop.0+0x1e/0x40
[ 1007.204584]  ? handle_mm_fault+0x192/0x2f0
[ 1007.204587]  ? do_user_addr_fault+0x33f/0x6c0
[ 1007.204594]  ? irqentry_exit_to_user_mode+0x6b/0x180
[ 1007.204599]  ? irqentry_exit+0x3f/0x50
[ 1007.204601]  ? exc_page_fault+0x8e/0x190
[ 1007.204604]  entry_SYSCALL_64_after_hwframe+0x6e/0x76
[ 1007.204609] RIP: 0033:0x7f8172b14887

This is without the udev rule.

I'll try to now see where this hang really is coming from... but it 
might take a while. Maybe first I should enable some more debug config 
options.

Thanks,
John