Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Fri, 3 Jan 2020 11:49:59 +0300
From:   Dan Carpenter <dan.carpenter@oracle.com>
To:     Aditya Pakki <pakki001@umn.edu>
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        devel@driverdev.osuosl.org, Harsh Jain <harshjain32@gmail.com>,
        Vandana BN <bnvandana@gmail.com>, kjlu@umn.edu,
        linux-kernel@vger.kernel.org,
        Simon =?iso-8859-1?Q?Sandstr=F6m?= <simon@nikanor.nu>
Subject: Re: [PATCH] staging: kpc2000: replace assertion with recovery code
Message-ID: <20200103084959.GA3911@kadam>
References: <20191215181243.31519-1-pakki001@umn.edu>
 <20191215182814.GA859066@kroah.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20191215182814.GA859066@kroah.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Sun, Dec 15, 2019 at 07:28:14PM +0100, Greg Kroah-Hartman wrote:
> On Sun, Dec 15, 2019 at 12:12:37PM -0600, Aditya Pakki wrote:
> > In kpc_dma_transfer, if either priv or ldev is NULL, crashing the
> > process is excessive and is not needed. Instead of asserting, by
> > passing the error upstream, the error can be handled.
> > 
> > Signed-off-by: Aditya Pakki <pakki001@umn.edu>
> > ---
> >  drivers/staging/kpc2000/kpc_dma/fileops.c | 6 ++++--
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/staging/kpc2000/kpc_dma/fileops.c b/drivers/staging/kpc2000/kpc_dma/fileops.c
> > index cb52bd9a6d2f..1c4633267cc1 100644
> > --- a/drivers/staging/kpc2000/kpc_dma/fileops.c
> > +++ b/drivers/staging/kpc2000/kpc_dma/fileops.c
> > @@ -49,9 +49,11 @@ static int kpc_dma_transfer(struct dev_private_data *priv,
> >  	u64 dma_addr;
> >  	u64 user_ctl;
> >  
> > -	BUG_ON(priv == NULL);
> > +	if (!priv)
> > +		return -EINVAL;
> 
> How can prive ever be NULL here?  Can you track back to all callers to
> verify this?  If so, just remove the check.
> 

Smatch says that "priv" can't be NULL.

Also if you have a NULL dereference the kernel prints a nice stack
trace.  Normally just doing the NULL dereference and Oopsing is better
than doing a BUG_ON().  The one exception would be when the Oops leads
to filesystem corruption.

regards,
dan carpenter