Hello Bjorn, On Tue, Oct 03, 2023 at 03:40:56PM -0500, Bjorn Helgaas wrote: > On Tue, Oct 03, 2023 at 10:23:30PM +0200, Uwe Kleine-König wrote: > > On Tue, Oct 03, 2023 at 12:15:24PM +0200, Uwe Kleine-König wrote: > > > On Mon, Oct 02, 2023 at 05:12:18PM -0500, Bjorn Helgaas wrote: > > > > On Sun, Oct 01, 2023 at 07:02:52PM +0200, Uwe Kleine-König wrote: > > > > > With CONFIG_PCIE_KIRIN=y and kirin_pcie_remove() marked with __exit, the > > > > > function is discarded from the driver. In this case a bound device can > > > > > still get unbound, e.g via sysfs. Then no cleanup code is run resulting > > > > > in resource leaks or worse. > > > > > > > > kirin_pcie_driver sets .suppress_bind_attrs = true. > > > > > > > > Doesn't that mean that we can't unbind a device via sysfs in this > > > > case? > > > > > > Oh indeed, that's something I missed. > > > > > > > I don't expect modpost to know about .suppress_bind_attrs, so maybe we > > > > should remove the __exit annotation even if it would be safe to keep > > > > it in this case. It's a tiny function anyway. > > > > > > the right thing to do then is something like: > > > https://lore.kernel.org/linux-rtc/20231002080529.2535610-7-u.kleine-koenig@xxxxxxxxxxxxxx > > > > > > And then it would be consequent to also switch to > > > module_platform_driver_probe and move .probe to __init. Or drop > > > .suppress_bind_attrs and keep/put .probe() and .remove() in .text. > > > > The other three patches in this series don't suffer from this oversight > > and so are (from my POV) ready to go in. > > Agreed. My first impression was that this would be v6.7 material, but > based on > https://lore.kernel.org/linux-kbuild/CAK7LNATyRg6Hc-fnTETERj-tdMFGaBDt0Fyhy9+jKCzAvzQ6Pg@xxxxxxxxxxxxxx/, > I guess that modpost change must be headed for v6.6? No, the modpost change was softend and only triggers (for now) on W=1 builds. There is no urge. > And while I haven't seen problem reports, branching into the weeds > because of a sysfs "remove" would be a pretty bad outcome, so I can > see a case for v6.6 and stable tags as well. Is that your thought > process, too? The change is obviously a fix and a crash after sysfs interaction is bad. It depends on the usecase if this is urgent. I'd say it's not a big deal if it doesn't make it into v6.6, the problem (in this driver) exists since 5.19-rc1 and there are still quite a few similar issues. I'd go for marking for stable and applying for v6.6 if it's convenient. > > If you tell me, which option you prefer for the kirin driver, I'll > > follow up with a matching patch. (If you don't know, my preference would > > be to drop .suppress_bind_attrs and move .probe() and .remove() to > > .text.) > > I agree, dropping .suppress_bind_attrs would be desirable, although I > would hope for some kind of assurance that it's not there because of > an issue with removal or something. If there is a problem with removal, it's relevant for modular drivers at rmmod time already now. I didn't check if there is a problem (and maybe I cannot judge this objectively) but for sure such a problem would be relevant already now. So I'd say this isn't an argument that should stop us. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | https://www.pengutronix.de/ |
Attachment:
signature.asc
Description: PGP signature