-----Original Message----- > From: Antoine Tenart <antoine.tenart@xxxxxxxxxxx> > Sent: Tuesday, July 30, 2019 10:12 AM > To: Pascal van Leeuwen <pascalvanl@xxxxxxxxx> > Cc: linux-crypto@xxxxxxxxxxxxxxx; antoine.tenart@xxxxxxxxxxx; herbert@xxxxxxxxxxxxxxxxxxx; > davem@xxxxxxxxxxxxx; Pascal Van Leeuwen <pvanleeuwen@xxxxxxxxxxxxxx> > Subject: Re: [PATCH] crypto: inside-secure - Fix null ptr derefence on rmmod for > macchiatobin > > Hi Pascal, > > On Fri, Jul 26, 2019 at 05:31:09PM +0200, Pascal van Leeuwen wrote: > > This small patch fixes a null pointer derefence panic that occurred when > > unloading the driver (using rmmod) on macchiatobin due to not setting > > the platform driver data properly in the probe routine. > > > > Signed-off-by: Pascal van Leeuwen <pvanleeuwen@xxxxxxxxxxxxxx> > > As this is a fix you should add a Fixes: tag so that the patch gets > applied to stable trees. You can have a look at what this tag looks like > at: https://www.kernel.org/doc/html/latest/process/submitting-patches.html > As you already figured out by now, this patch just fixes something that was broken by one of my earlier patches (which has not been applied just yet). So I don't think it applies to stable trees. > > --- > > drivers/crypto/inside-secure/safexcel.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/drivers/crypto/inside-secure/safexcel.c b/drivers/crypto/inside- > secure/safexcel.c > > index 45443bf..423ea2d 100644 > > --- a/drivers/crypto/inside-secure/safexcel.c > > +++ b/drivers/crypto/inside-secure/safexcel.c > > @@ -1274,6 +1274,8 @@ static int safexcel_probe(struct platform_device *pdev) > > priv->dev = dev; > > priv->version = (enum safexcel_eip_version)of_device_get_match_data(dev); > > > > + platform_set_drvdata(pdev, priv); > > + > > This is already done in safexcel_probe(), near the end of the function. > I think you should remove the second call, to avoid setting the platform > driver data twice. > Well, actually, my first patch that you are reviewing right now accidentally removed that other call to platform_set_drvdata ... > Out of curiosity, why calling platform_set_drvdata() earlier in the > probe fixes unloading the driver with rmmod? > Not really. As long as it does get set somewhere :-) > Thanks! > Antoine > > -- > Antoine Ténart, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com Regards, Pascal van Leeuwen Silicon IP Architect, Multi-Protocol Engines @ Verimatrix www.insidesecure.com
