Messages in this thread | | | From | Geert Uytterhoeven <> | Date | Tue, 5 Jul 2022 17:18:51 +0200 | Subject | Re: [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
| |