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
