[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aIh47Ncx5lY1vc9F@infradead.org>
Date: Tue, 29 Jul 2025 00:31:56 -0700
From: Christoph Hellwig <hch@...radead.org>
To: Klara Modin <klarasmodin@...il.com>
Cc: brauner@...nel.org, anuj20.g@...sung.com, arnd@...nel.org,
martin.petersen@...cle.com, joshi.k@...sung.com, hch@...radead.org,
arnd@...db.de, naresh.kamboju@...aro.org, anders.roxell@...aro.org,
axboe@...nel.dk, kbusch@...nel.org, csander@...estorage.com,
asml.silence@...il.com, adobriyan@...il.com, djwong@...nel.org,
linux-block@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] block: change blk_get_meta_cap() stub return -ENOIOCTLCMD
On Fri, Jul 25, 2025 at 06:43:34PM +0200, Klara Modin wrote:
> When introduced in commit 9eb22f7fedfc ("fs: add ioctl to query metadata
> and protection info capabilities") the stub of blk_get_meta_cap() for
> !BLK_DEV_INTEGRITY always returns -EOPNOTSUPP. The motivation was that
> while the command was unsupported in that configuration it was still
> recognized.
>
> A later change instead assumed -ENOIOCTLCMD as is required for unknown
> ioctl commands per Documentation/driver-api/ioctl.rst. The result being
> that on !BLK_DEV_INTEGRITY configs, any ioctl which reaches
> blkdev_common_ioctl() will return -EOPNOTSUPP.
FYI, I still think we should not fail the command for
!BLK_DEV_INTEGRITY, but just report no capabilities.
Powered by blists - more mailing lists