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@xxxxxxx> > > --- > > 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 _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
