linux-kernel - Re: [PATCH] platform: Provide a remove callback that returns no value

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20221209155207.pyugk2dhpyht5gph@pengutronix.de>
Date:   Fri, 9 Dec 2022 16:52:07 +0100
From:   Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     linux-kernel@...r.kernel.org, kernel@...gutronix.de,
        "Rafael J. Wysocki" <rafael@...nel.org>
Subject: Re: [PATCH] platform: Provide a remove callback that returns no value

Hello Greg,

On Fri, Dec 09, 2022 at 04:21:30PM +0100, Greg Kroah-Hartman wrote:
> On Fri, Dec 09, 2022 at 04:09:14PM +0100, Uwe Kleine-König wrote:
> > struct platform_driver::remove returning an integer made driver authors
> > expect that returning an error code was proper error handling. However
> > the driver core ignores the error and continues to remove the device
> > because there is nothing the core could do anyhow and reentering the
> > remove callback again is only calling for trouble.
> > 
> > So this is an source for errors typically yielding resource leaks in the
> > error path.
> > 
> > As there are too many platform drivers to neatly convert them all to
> > return void in a single go, do it in several steps after this patch:
> > 
> >  a) Convert all drivers to implement .remove_new() returning void instead
> >     of .remove() returning int;
> >  b) Change struct platform_driver::remove() to return void and so make
> >     it identical to .remove_new();
> >  c) Change all drivers back to .remove() now with the better prototype;
> 
> Change c) seems like it will be just as much work as a), right?

Yeah, but c) should be trivially doable per subsystem using coccinelle.
So my plan is to do a) per subsystem with one patch per driver and c)
with one patch per subsystem.

> Who is going to do the work of the conversion to this new prototype?
> I'll be glad to take this, but I don't want to see a half-finished
> conversion happen and us stuck with a "new" and "old" call, as that
> would just be a mess.

The idea is that this becomes my new pet project once 
https://lore.kernel.org/lkml/20221118224540.619276-1-uwe@kleine-koenig.org
is complete. :-)

I intend to work on that once the patch under discussion is included in
an -rc1.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)