Hi,
While working on some backport patches for an out-of-tree module and
looking for the exact versions containing the disable_delayed_work_sync
symbol, I stumbled upon occurrences of that function on longterm v6.1
and v6.6 in drivers/usb/phy/phy-fsl-usb.c despite not being declared or
defined anywhere. In fact, disable_delayed_work_sync was introduced by
upstream commit 86898fa6b8cd ("workqueue: Implement disable/enable for
(delayed) work items") and is only available since v6.10. Neither 6.1.y
nor 6.6.y defines it.
Consequently, kernels built with CONFIG_FSL_USB2_OTG fail with:
drivers/usb/phy/phy-fsl-usb.c:990:2: error: call to undeclared function
'disable_delayed_work_sync'; ISO C99 and later do not support implicit function
declarations [-Wimplicit-function-declaration]
990 | disable_delayed_work_sync(&fsl_otg_dev->otg_event);
| ^
drivers/usb/phy/phy-fsl-usb.c:990:2: note: did you mean
'cancel_delayed_work_sync'?
include/linux/workqueue.h:470:13: note: 'cancel_delayed_work_sync' declared here
470 | extern bool cancel_delayed_work_sync(struct delayed_work *dwork);
| ^
I reproduced the failure on PowerPC using corenet64_smp_defconfig with
CONFIG_FSL_USB2_OTG=m, building drivers/usb/phy/phy-fsl-usb.o with
Clang.
AFAICT, in 6.1.y, the regression was introduced in v6.1.160 by commit
4476c73bbbb0 ("usb: phy: fsl-usb: Fix use-after-free in delayed work
during device removal") and remains present in v6.1.185.
In 6.6.y, it was introduced in v6.6.120 by commit 319f7a85b3c4 ("usb:
phy: fsl-usb: Fix use-after-free in delayed work during device removal")
and remains present in v6.6.154.
Note that the same problem was pointed out by Ben Hutchings during the
5.10.y review:
https://lore.kernel.org/all/[email protected]/
The corresponding patches were dropped from 5.10.y and 5.15.y, but
appear to have been retained in 6.1.y and 6.6.y.
Simply replacing disable_delayed_work_sync with cancel_delayed_work_sync
at its current location may not be sufficient: it looks like the delayed
work can also be scheduled from fsl_otg_set_host and from the IRQ
handler but I'm not familiar with this part of the kernel.
Cheers!
--
Ralf Lici
Mandelbit Srl
