linux-kernel - Re: [PATCH] scsi: megaraid_mbox: return -ENOMEM on megaraid_init

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]

Date:   Wed, 20 Oct 2021 13:56:11 +1100 (AEDT)
From:   Finn Thain <fthain@...ux-m68k.org>
To:     James Bottomley <jejb@...ux.ibm.com>
cc:     Jiapeng Chong <jiapeng.chong@...ux.alibaba.com>,
        kashyap.desai@...adcom.com, sumit.saxena@...adcom.com,
        shivasharan.srikanteshwara@...adcom.com,
        martin.petersen@...cle.com, megaraidlinux.pdl@...adcom.com,
        linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] scsi: megaraid_mbox: return -ENOMEM on megaraid_init_mbox()
 allocation failure

On Tue, 19 Oct 2021, James Bottomley wrote:

> On Tue, 2021-10-19 at 18:53 +0800, Jiapeng Chong wrote:
> > From: chongjiapeng <jiapeng.chong@...ux.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.