Re: [PATCH] kernfs: Avoid re-adding kernfs_node into kernfs_notify_list.

[Nathan Chancellor]

On Sat, Jul 02, 2022 at 01:18:09AM +1000, Imran Khan wrote:
> Hello Nathan,
> 
> On 2/7/22 1:10 am, Nathan Chancellor wrote:
> > On Sat, Jul 02, 2022 at 12:50:47AM +1000, Imran Khan wrote:
> >> Kick fsnotify only if an event is not already scheduled for target
> >> kernfs node. commit b8f35fa1188b ("kernfs: Change kernfs_notify_list to
> >> llist.") changed kernfs_notify_list to a llist.
> >> Prior to this list was a singly linked list, protected by
> >> kernfs_notify_lock. Whenever a kernfs_node was added to the list
> >> its ->attr.notify_next was set to head of the list and upon removal
> >> ->attr.notify_next was reset to NULL. Addition to kernfs_notify_list
> >> would only happen if kernfs_node was not already in the list i.e.
> >> if ->attr.notify_next was NULL. commit b8f35fa1188b ("kernfs: Change
> >> kernfs_notify_list to llist.") removed this checking and this was wrong
> >> as it resulted in multiple additions for same kernfs_node.
> >>
> >> So far this bug only got reflected with some console related setting.
> >> Nathan found this issue when console was specified both in DT and in
> >> kernel command line and Marek found this issue when earlycon was enabled.
> >>
> >> This patch avoids adding an already added kernfs_node into notify list.
> >>
> >> Reported-by: Nathan Chancellor <nathan@xxxxxxxxxx>
> >> Reported-by: Marek Szyprowski <m.szyprowski@xxxxxxxxxxx>
> > 
> > This should also include:
> > 
> > Reported-by: Michael Walle <michael@xxxxxxxx>
> > 
> >> Tested-by: Marek Szyprowski <m.szyprowski@xxxxxxxxxxx>
> >> Fixes: b8f35fa1188b ("kernfs: Change kernfs_notify_list to llist.")
> >> Signed-off-by: Imran Khan <imran.f.khan@xxxxxxxxxx>
> > 
> > For the ARCH=um case that I noticed:
> > 
> > Tested-by: Nathan Chancellor <nathan@xxxxxxxxxx>
> > 
> 
> I am really sorry about missing these tags. I was not sure if you have tested
> the patch I sent this morning.

No worries, we all forget tags :) I hadn't tested your patch until this
point so there was no reason for you to add that tag, this was the first
time I provided it so there is no problem there. Thanks for the quick
fix!

Cheers,
Nathan