Re: [PATCH v7 2/4] kernfs: Change kernfs_notify_list to llist.

From: Imran Khan
Date: Fri Jul 01 2022 - 08:20:50 EST


Hello Marek,


On 1/7/22 9:22 pm, Marek Szyprowski wrote:
> Hi All,
>
> On 15.06.2022 04:10, Imran Khan wrote:
>> At present kernfs_notify_list is implemented as a singly linked
>> list of kernfs_node(s), where last element points to itself and
>> value of ->attr.next tells if node is present on the list or not.
>> Both addition and deletion to list happen under kernfs_notify_lock.
>>
>> Change kernfs_notify_list to llist so that addition to list can heppen
>> locklessly.
>>
>> Suggested by: Al Viro <viro@xxxxxxxxxxxxxxxxxx>
>> Signed-off-by: Imran Khan <imran.f.khan@xxxxxxxxxx>
>> Acked-by: Tejun Heo <tj@xxxxxxxxxx>
>
> This patch landed in linux next-20220630 as commit b8f35fa1188b
> ("kernfs: Change kernfs_notify_list to llist."). Unfortunately, it
> causes serious regression on my test systems. It can be easily noticed
> in the logs by the following warning:
>
> ------------[ cut here ]------------
> WARNING: CPU: 1 PID: 34 at fs/kernfs/dir.c:531 kernfs_put.part.0+0x1a4/0x1d8
> kernfs_put: console/active: released with incorrect active_ref 0
> Modules linked in:
> CPU: 1 PID: 34 Comm: kworker/1:4 Not tainted
> 5.19.0-rc4-05465-g5732b42edfd1 #12317
> Hardware name: Samsung Exynos (Flattened Device Tree)
> Workqueue: events kernfs_notify_workfn
>  unwind_backtrace from show_stack+0x10/0x14
>  show_stack from dump_stack_lvl+0x40/0x4c
>  dump_stack_lvl from __warn+0xc8/0x13c
>  __warn from warn_slowpath_fmt+0x90/0xb4
>  warn_slowpath_fmt from kernfs_put.part.0+0x1a4/0x1d8
>  kernfs_put.part.0 from kernfs_notify_workfn+0x1a0/0x1d0
>  kernfs_notify_workfn from process_one_work+0x1ec/0x4cc
>  process_one_work from worker_thread+0x58/0x54c
>  worker_thread from kthread+0xd0/0xec
>  kthread from ret_from_fork+0x14/0x2c
> Exception stack(0xf099dfb0 to 0xf099dff8)
> ...
> ---[ end trace 0000000000000000 ]---
>

Thanks for reporting this issue. It has been reported earlier in [1] as well. I
am unable to reproduce it locally. Could you please test with following patch on
top of linux next-20220630 and let me know if it helps: