linux-kernel - Re: [PATCH] iio: core: return ENODEV if ioctl is unknown

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:   Sat, 8 May 2021 16:16:43 +0100
From:   Jonathan Cameron <jic23@...nel.org>
To:     Alexandru Ardelean <aardelean@...iqon.com>
Cc:     linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org,
        lars@...afoo.de, Linus Walleij <linus.walleij@...aro.org>,
        Paul Cercueil <paul@...pouillou.net>,
        Nuno Sa <nuno.sa@...log.com>
Subject: Re: [PATCH] iio: core: return ENODEV if ioctl is unknown

On Mon,  3 May 2021 17:43:50 +0300
Alexandru Ardelean <aardelean@...iqon.com> wrote:

> When the ioctl() mechanism was introduced in IIO core to centralize the
> registration of all ioctls in one place via commit 8dedcc3eee3ac ("iio:
> core: centralize ioctl() calls to the main chardev"), the return code was
> changed from ENODEV to EINVAL, when the ioctl code isn't known.
> 
> This was done by accident.
> 
> This change reverts back to the old behavior, where if the ioctl() code
> isn't known, ENODEV is returned (vs EINVAL).
> 
> This was brought into perspective by this patch:
>   https://lore.kernel.org/linux-iio/20210428150815.136150-1-paul@crapouillou.net/
> 
> Fixes: 8dedcc3eee3ac ("iio: core: centralize ioctl() calls to the main chardev")
> Cc: Linus Walleij <linus.walleij@...aro.org>
> Cc: Paul Cercueil <paul@...pouillou.net>
> Cc: Nuno Sa <nuno.sa@...log.com>
> Signed-off-by: Alexandru Ardelean <aardelean@...iqon.com>

This is going to be a little messy to apply as lots of churn in that file.
What I've done for now is pulled the fixes-togreg branch forwards onto
current staging/staging-linus but I'll do that again after
staging/staging-linus moves onto an rc1 or similar base.

Anyhow, applied to that tree which is going to have more than it's
normal share of rebases this cycle.

Thanks,

Jonathan

> ---
>  drivers/iio/industrialio-core.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index efb4cf91c9e4..9a3a83211a90 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -1803,7 +1803,6 @@ static long iio_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
>  	if (!indio_dev->info)
>  		goto out_unlock;
>  
> -	ret = -EINVAL;
>  	list_for_each_entry(h, &iio_dev_opaque->ioctl_handlers, entry) {
>  		ret = h->ioctl(indio_dev, filp, cmd, arg);
>  		if (ret != IIO_IOCTL_UNHANDLED)
> @@ -1811,7 +1810,7 @@ static long iio_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
>  	}
>  
>  	if (ret == IIO_IOCTL_UNHANDLED)
> -		ret = -EINVAL;
> +		ret = -ENODEV;
>  
>  out_unlock:
>  	mutex_unlock(&iio_dev_opaque->info_exist_lock);