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.
Could you please suggest me if I should send a v2 of this change with these tags
included or if this mail is enough. Sorry if I am asking something obvious but I
am encountering such situation for first time.
Thanks
-- Imran
