Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 20 Oct 2021 13:56:11 +1100 (AEDT)
From:   Finn Thain <fthain@linux-m68k.org>
To:     James Bottomley <jejb@linux.ibm.com>
cc:     Jiapeng Chong <jiapeng.chong@linux.alibaba.com>,
        kashyap.desai@broadcom.com, sumit.saxena@broadcom.com,
        shivasharan.srikanteshwara@broadcom.com,
        martin.petersen@oracle.com, megaraidlinux.pdl@broadcom.com,
        linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] scsi: megaraid_mbox: return -ENOMEM on megaraid_init_mbox()
 allocation failure
In-Reply-To: <2482854e18365087266c2f0907c1bbfd42bd2731.camel@linux.ibm.com>
Message-ID: <c1a6e7f3-d62f-5c5e-b3ef-2320339e142a@linux-m68k.org>
References: <1634640800-22502-1-git-send-email-jiapeng.chong@linux.alibaba.com> <2482854e18365087266c2f0907c1bbfd42bd2731.camel@linux.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Precedence: bulk

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.