[PATCH] scsi: megaraid_mbox: return -ENOMEM on megaraid_init_mbox() allocation failure

[PATCH] scsi: megaraid_mbox: return -ENOMEM on megaraid_init_mbox() allocation failure

[Jiapeng Chong]

From: chongjiapeng <jiapeng.chong@linux.alibaba.com>

Fixes the following smatch warning:

drivers/scsi/megaraid/megaraid_mbox.c:715 megaraid_init_mbox() warn:
returning -1 instead of -ENOMEM is sloppy.

Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Fixes: dd00cc486ab1 ("some kmalloc/memset ->kzalloc (tree wide)")
Signed-off-by: chongjiapeng <jiapeng.chong@linux.alibaba.com>
---
 drivers/scsi/megaraid/megaraid_mbox.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/megaraid/megaraid_mbox.c b/drivers/scsi/megaraid/megaraid_mbox.c
index 14f930d27ca1..d98b223eab9a 100644
--- a/drivers/scsi/megaraid/megaraid_mbox.c
+++ b/drivers/scsi/megaraid/megaraid_mbox.c
@@ -712,7 +712,8 @@ megaraid_init_mbox(adapter_t *adapter)
 	 * controllers
 	 */
 	raid_dev = kzalloc(sizeof(mraid_device_t), GFP_KERNEL);
-	if (raid_dev == NULL) return -1;
+	if (raid_dev == NULL)
+		return -ENOMEM;
 
 
 	/*
-- 
2.19.1.6.gb485710b

Re: [PATCH] scsi: megaraid_mbox: return -ENOMEM on megaraid_init_mbox() allocation failure

[James Bottomley]

On Tue, 2021-10-19 at 18:53 +0800, Jiapeng Chong wrote:
> From: chongjiapeng <jiapeng.chong@linux.alibaba.com>
> 
> Fixes the following smatch warning:
> 
> drivers/scsi/megaraid/megaraid_mbox.c:715 megaraid_init_mbox() warn:
> returning -1 instead of -ENOMEM is sloppy.

Why is this a problem?  megaraid_init_mbox() is called using this
pattern:

	// Start the mailbox based controller
	if (megaraid_init_mbox(adapter) != 0) {
		con_log(CL_ANN, (KERN_WARNING
			"megaraid: mailbox adapter did not initialize\n"));

		goto out_free_adapter;
	}

So the only meaningful returns are 0 on success and anything else
(although megaraid uses -1 for this) on failure.   Since -1 is the
conventional failure return, why alter that to something different that
still won't be printed or acted on?  And worse still, if we make this
change, it will likely excite other static checkers to complain we're
losing error information ...

James

Re: [PATCH] scsi: megaraid_mbox: return -ENOMEM on megaraid_init_mbox() allocation failure

[Finn Thain]

On Tue, 19 Oct 2021, James Bottomley wrote:

> On Tue, 2021-10-19 at 18:53 +0800, Jiapeng Chong wrote:
> > From: chongjiapeng <jiapeng.chong@linux.alibaba.com>
> > 
> > Fixes the following smatch warning:
> > 
> > drivers/scsi/megaraid/megaraid_mbox.c:715 megaraid_init_mbox() warn:
> > returning -1 instead of -ENOMEM is sloppy.
> 
> Why is this a problem?  megaraid_init_mbox() is called using this
> pattern:
> 
> 	// Start the mailbox based controller
> 	if (megaraid_init_mbox(adapter) != 0) {
> 		con_log(CL_ANN, (KERN_WARNING
> 			"megaraid: mailbox adapter did not initialize\n"));
> 
> 		goto out_free_adapter;
> 	}
> 
> So the only meaningful returns are 0 on success and anything else
> (although megaraid uses -1 for this) on failure. 

I think you're arguing for a bool (?)

Smatch apparently did not think of that -- probably needs a holiday.

> Since -1 is the conventional failure return, why alter that to something 
> different that still won't be printed or acted on?  And worse still, if 
> we make this change, it will likely excite other static checkers to 
> complain we're losing error information ...
> 

... and arguably they would be correct.

Re: [PATCH] scsi: megaraid_mbox: return -ENOMEM on megaraid_init_mbox() allocation failure

[James Bottomley]

On Wed, 2021-10-20 at 13:56 +1100, Finn Thain wrote:
> On Tue, 19 Oct 2021, James Bottomley wrote:
> 
> > On Tue, 2021-10-19 at 18:53 +0800, Jiapeng Chong wrote:
> > > From: chongjiapeng <jiapeng.chong@linux.alibaba.com>
> > > 
> > > Fixes the following smatch warning:
> > > 
> > > drivers/scsi/megaraid/megaraid_mbox.c:715 megaraid_init_mbox()
> > > warn:
> > > returning -1 instead of -ENOMEM is sloppy.
> > 
> > Why is this a problem?  megaraid_init_mbox() is called using this
> > pattern:
> > 
> > 	// Start the mailbox based controller
> > 	if (megaraid_init_mbox(adapter) != 0) {
> > 		con_log(CL_ANN, (KERN_WARNING
> > 			"megaraid: mailbox adapter did not
> > initialize\n"));
> > 
> > 		goto out_free_adapter;
> > 	}
> > 
> > So the only meaningful returns are 0 on success and anything else
> > (although megaraid uses -1 for this) on failure. 
> 
> I think you're arguing for a bool (?)

I'm not arguing for anything ... I'm just explaining how the current
code works that makes this change pointless.  Megaraid is an older
driver, so even if the current return is two state, changing it to bool
would be unnecessary churn.

> Smatch apparently did not think of that -- probably needs a holiday.
> 
> > Since -1 is the conventional failure return, why alter that to
> > something different that still won't be printed or acted on?  And
> > worse still, if we make this change, it will likely excite other
> > static checkers to complain we're losing error information ...
> > 
> 
> ... and arguably they would be correct.

Well, yes ... that's why I don't want one "fix" that generates a
cascading sequence of further "fixes".

James

Re: [PATCH] scsi: megaraid_mbox: return -ENOMEM on megaraid_init_mbox() allocation failure

[Finn Thain]

On Wed, 20 Oct 2021, James Bottomley wrote:

> > 
> > ... and arguably they would be correct.
> 
> Well, yes ... that's why I don't want one "fix" that generates a 
> cascading sequence of further "fixes".
> 

OTOH, if you don't "fix" it, it generates a cascading sequence of 
copy-and-paste antipatterns in new code, and poor training data for those 
of us reading old code.

Anyway, I agree that the churn would be too risky. But it sure would be 
nice if automatic tools were able to perform a program transformation of 
this kind at the source level, being that the compiler will surely do it 
anyway at a lower level.

There's a lot to be said for source code that reflects the compiler's 
understanding of the logic, rather than the human's.