lkml.org 
[lkml]   [2022]   [Jul]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH v7 2/4] kernfs: Change kernfs_notify_list to llist.
Hi Marek,

On Fri, Jul 1, 2022 at 2:51 PM Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
> On 01.07.2022 14:20, Imran Khan wrote:
> > On 1/7/22 9:22 pm, Marek Szyprowski wrote:
> >> 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@zeniv.linux.org.uk>
> >>> Signed-off-by: Imran Khan <imran.f.khan@oracle.com>
> >>> Acked-by: Tejun Heo <tj@kernel.org>
> >> 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:
>
> Yes, this fixes the issue. Feel free to add:
>
> Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
>
> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
>
> Maybe it is related to the fact, that I have earlycon enabled on those
> machines?

Probably.
I see the issue on
- rbtx4927 (CONFIG_EARLY_PRINTK=y),
- SiPEED MAiXBiT (chosen/bootargs = "earlycon console=ttySIF0",
chosen/stdout-path = "serial0:115200n8")
- Litex/VexRiscV (chosen/bootargs = "console=liteuart earlycon=sbi").

It doesn't happen on the boards that just provide chosen/stdout-path
in DT.

Reverting commit b8f35fa1188b8403 ("kernfs: Change kernfs_notify_list
to llist.") fixes the issue.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

\
 
 \ /
  Last update: 2022-07-05 17:21    [W:0.119 / U:0.264 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site