Re: scsi: ses: Move a label in ses_enclosure_data_process()

[James Bottomley <jejb@linux.ibm.com>]

On Sat, 2023-12-30 at 08:04 +0100, Markus Elfring wrote:
> > > The kfree() function was called in up to three cases by
> > > the ses_enclosure_data_process() function during error handling
> > > even if the passed variable contained a null pointer.
> > > This issue was detected by using the Coccinelle software.
> > 
> > Why is this an issue?  The whole point of having kfree(NULL) be a
> > nop
> 
> Such “a nop” can trigger the allocation of extra data processing
> resources, can't it?

No.

> > is so we don't have to special case the free path.
> 
> A bit more development attention can hopefully connect the mentioned
> label with a more appropriate jump target directly.

That's making the flow more complex as I pointed out in my initial
email.

> >                                                     The reason we
> > do that is because multiple special case paths through code leads
> > to more complex control flows and more potential bugs.
> 
> You probably know some advices from another information source.
> 
> https://wiki.sei.cmu.edu/confluence/display/c/MEM12-C.+Consider+using+a+goto+chain+when+leaving+a+function+on+error+when+using+and+releasing+resources
> 

Yes, but it's about using staged deallocation at the end of the
function instead of in the if loops.  That's to *simplify* the exit
chain and make the error legs less error prone because the teardown
isn't repeated in if bodies.  It has no bearing on what you just tried
to do.

> >                                               If coccinelle
> > suddenly thinks this is a problem, it's coccinelle that needs
> > fixing.
> 
> This software tool can help to point source code places out for
> further considerations. The search patterns are evolving accordingly.

The pattern is wrong because kfree(NULL) exists as a teardown
simplification.

James