[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bb1cbc3d-fc46-4d0f-90b3-39b25f5bc58e@suse.com>
Date: Thu, 12 Sep 2024 11:37:14 +0200
From: Oliver Neukum <oneukum@...e.com>
To: Jakub Kicinski <kuba@...nel.org>, Oliver Neukum <oneukum@...e.com>
Cc: davem@...emloft.net, edumazet@...gle.com, pabeni@...hat.com,
netdev@...r.kernel.org, linux-usb@...r.kernel.org,
linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCHv2 net] usbnet: fix cyclical race on disconnect with work
queue
On 11.09.24 00:44, Jakub Kicinski wrote:
Hi,
> I have sort of an inverse question to what Paolo asked :)
This is getting interesting.
> AFAIU we need the double-cancel because checking the flag and
> scheduling are not atomic. But if we do that why the memory
Right.
> barriers? They make it seem like we're doing something clever
> with memory ordering, while really we're just depending on normal
> properties of the tasklet/timer/work APIs.
Good question. I added this because they are used in usbnet_defer_kevent()
which can be used in hard irq context. Are you saying I should check
whether this is actually needed?
> FTR disable_work_sync() would work nicely here but it'd be
> a PITA for backports.
So should I use it?
> Also - is this based on some report or syzbot? I'm a bit tempted
> to put this in net-next given how unlikely the race is vs how
> commonly used the driver is.
Having found the thing with the random MAC I decided to look
closely at the driver for overlooked stuff.
Regards
Oliver
Powered by blists - more mailing lists