[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <9018b003-55af-4877-9166-d70f6d896b06@oracle.com>
Date: Wed, 28 Feb 2024 16:12:45 +0000
From: John Garry <john.g.garry@...cle.com>
To: Luis Chamberlain <mcgrof@...nel.org>
Cc: russ.weight@...ux.dev, gregkh@...uxfoundation.org, rafael@...nel.org,
linux-kernel@...r.kernel.org, masahiroy@...nel.org
Subject: Re: [PATCH] firmware_loader: Use init_utsname()->release
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
Powered by blists - more mailing lists