linux-kernel - Re: [PATCH char-misc v1] misc: Add Renesas Synchronization Management Unit (SMU) support

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] [day] [month] [year] [list]

Message-ID: <YFLp6n70JBXDYvxI@kroah.com>
Date:   Thu, 18 Mar 2021 06:49:30 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     min.li.xe@...esas.com
Cc:     derek.kiernan@...inx.com, dragan.cvetic@...inx.com, arnd@...db.de,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH char-misc v1] misc: Add Renesas Synchronization
 Management Unit (SMU) support

On Wed, Mar 17, 2021 at 05:14:34PM -0400, min.li.xe@...esas.com wrote:
> +static int
> +rsmu_open(struct inode *iptr, struct file *fptr)
> +{
> +	struct rsmu_cdev *rsmu;
> +
> +	rsmu = container_of(iptr->i_cdev, struct rsmu_cdev, rsmu_cdev);
> +	if (!rsmu)
> +		return -EAGAIN;

This check will never happen, so why are you making it?

And what does -EAGIN mean in this case?

> +
> +	fptr->private_data = rsmu;
> +	return 0;
> +}
> +
> +static int
> +rsmu_release(struct inode *iptr, struct file *fptr)
> +{
> +	struct rsmu_cdev *rsmu;
> +
> +	rsmu = container_of(iptr->i_cdev, struct rsmu_cdev, rsmu_cdev);
> +	if (!rsmu)
> +		return -EAGAIN;

Same here, this is impossible to ever have happen.  Please look up how
container_of() works.


> +
> +	return 0;
> +}
> +
> +static long
> +rsmu_ioctl(struct file *fptr, unsigned int cmd, unsigned long data)
> +{
> +	struct rsmu_cdev *rsmu = fptr->private_data;
> +	void __user *arg = (void __user *)data;
> +	int err = 0;
> +
> +	if (!rsmu)
> +		return -EINVAL;

How can this happen?

Why all of these impossible checks?

And the build failures that the kernel test robot obviously need to be
fixed as well...

thanks,

greg k-h