[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAMuHMdWN=yQCdfJQW+dg7uOc7QbGNXp_AtdR-hJttenu3sm7Xw@mail.gmail.com>
Date: Tue, 5 Jul 2022 17:18:51 +0200
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Marek Szyprowski <m.szyprowski@...sung.com>
Cc: Imran Khan <imran.f.khan@...cle.com>, Tejun Heo <tj@...nel.org>,
Greg KH <gregkh@...uxfoundation.org>,
Al Viro <viro@...iv.linux.org.uk>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
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@...sung.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@...iv.linux.org.uk>
> >>> Signed-off-by: Imran Khan <imran.f.khan@...cle.com>
> >>> Acked-by: Tejun Heo <tj@...nel.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@...sung.com>
>
> Tested-by: Marek Szyprowski <m.szyprowski@...sung.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@...ux-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
Powered by blists - more mailing lists