linux-kernel - Re: [PATCH v6 1/2] spi: Replace -ENOTSUPP with -EOPNOTSUPP in op checking

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: <054c1d8f-fb23-4793-b6d1-5d8814209992@linaro.org>
Date:   Fri, 17 Nov 2023 09:32:17 +0000
From:   Tudor Ambarus <tudor.ambarus@...aro.org>
To:     AceLan Kao <acelan.kao@...onical.com>,
        Pratyush Yadav <pratyush@...nel.org>,
        Michael Walle <michael@...le.cc>,
        Miquel Raynal <miquel.raynal@...tlin.com>,
        Richard Weinberger <richard@....at>,
        Vignesh Raghavendra <vigneshr@...com>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Dhruva Gole <d-gole@...com>, linux-mtd@...ts.infradead.org,
        Mark Brown <broonie@...nel.org>,
        Kamal Dasu <kamal.dasu@...adcom.com>,
        Jonathan Neuschäfer <j.neuschaefer@....net>,
        Mario Kicherer <dev@...herer.org>,
        Chuanhong Guo <gch981213@...il.com>,
        linux-kernel@...r.kernel.org,
        "linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>
Subject: Re: [PATCH v6 1/2] spi: Replace -ENOTSUPP with -EOPNOTSUPP in op
 checking


I included linux-spi@...r.kernel.org. Please do the same if you're going
to send a new version.

On 11/16/23 02:43, AceLan Kao wrote:
> --- a/drivers/spi/spi-mem.c
> +++ b/drivers/spi/spi-mem.c
> @@ -323,7 +323,7 @@ int spi_mem_exec_op(struct spi_mem *mem, const struct spi_mem_op *op)
>  		return ret;
>  
>  	if (!spi_mem_internal_supports_op(mem, op))
> -		return -ENOTSUPP;
> +		return -EOPNOTSUPP;

this will break user-space if someone uses the return code of
unsupported operations, but I'm not against taking the risk and changing
the return code, as I doubt it's used. Anyway, if we're taking this
path, please specify the risk in the commit message and why we're taking
this risk.