From: Hugh Dickins <hughd@google.com>
To: Christian Brauner <brauner@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Klara Modin <klarasmodin@gmail.com>,
Arnd Bergmann <arnd@arndb.de>, Anuj Gupta <anuj20.g@samsung.com>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [GIT PULL 11/14 for v6.17] vfs integrity
Date: Sun, 27 Jul 2025 18:29:29 -0700 (PDT) [thread overview]
Message-ID: <0f40571c-11a2-50f0-1eba-78ab9d52e455@google.com> (raw)
In-Reply-To: <20250725-vfs-integrity-d16cb92bb424@brauner>
On Fri, 25 Jul 2025, Christian Brauner wrote:
> Hey Linus,
>
> /* Summary */
> This adds the new FS_IOC_GETLBMD_CAP ioctl() to query metadata and
> protection info (PI) capabilities. This ioctl returns information about
> the files integrity profile. This is useful for userspace applications
> to understand a files end-to-end data protection support and configure
> the I/O accordingly.
>
> For now this interface is only supported by block devices. However the
> design and placement of this ioctl in generic FS ioctl space allows us
> to extend it to work over files as well. This maybe useful when
> filesystems start supporting PI-aware layouts.
>
> A new structure struct logical_block_metadata_cap is introduced, which
> contains the following fields:
>
> - lbmd_flags:
> bitmask of logical block metadata capability flags
>
> - lbmd_interval:
> the amount of data described by each unit of logical block metadata
>
> - lbmd_size:
> size in bytes of the logical block metadata associated with each
> interval
>
> - lbmd_opaque_size:
> size in bytes of the opaque block tag associated with each interval
>
> - lbmd_opaque_offset:
> offset in bytes of the opaque block tag within the logical block
> metadata
>
> - lbmd_pi_size:
> size in bytes of the T10 PI tuple associated with each interval
>
> - lbmd_pi_offset:
> offset in bytes of T10 PI tuple within the logical block metadata
>
> - lbmd_pi_guard_tag_type:
> T10 PI guard tag type
>
> - lbmd_pi_app_tag_size:
> size in bytes of the T10 PI application tag
>
> - lbmd_pi_ref_tag_size:
> size in bytes of the T10 PI reference tag
>
> - lbmd_pi_storage_tag_size:
> size in bytes of the T10 PI storage tag
>
> The internal logic to fetch the capability is encapsulated in a helper
> function blk_get_meta_cap(), which uses the blk_integrity profile
> associated with the device. The ioctl returns -EOPNOTSUPP, if
> CONFIG_BLK_DEV_INTEGRITY is not enabled.
>
> /* Testing */
>
> gcc (Debian 14.2.0-19) 14.2.0
> Debian clang version 19.1.7 (3)
>
> No build failures or warnings were observed.
>
> /* Conflicts */
>
> Merge conflicts with mainline
> =============================
>
> No known conflicts.
>
> Merge conflicts with other trees
> ================================
>
> No known conflicts.
>
> The following changes since commit 19272b37aa4f83ca52bdf9c16d5d81bdd1354494:
>
> Linux 6.16-rc1 (2025-06-08 13:44:43 -0700)
>
> are available in the Git repository at:
>
> git@gitolite.kernel.org:pub/scm/linux/kernel/git/vfs/vfs tags/vfs-6.17-rc1.integrity
>
> for you to fetch changes up to bc5b0c8febccbeabfefc9b59083b223ec7c7b53a:
>
> block: fix lbmd_guard_tag_type assignment in FS_IOC_GETLBMD_CAP (2025-07-23 14:55:51 +0200)
>
> Please consider pulling these changes from the signed vfs-6.17-rc1.integrity tag.
>
> Thanks!
> Christian
>
> ----------------------------------------------------------------
> vfs-6.17-rc1.integrity
>
> ----------------------------------------------------------------
> Anuj Gupta (5):
> block: rename tuple_size field in blk_integrity to metadata_size
> block: introduce pi_tuple_size field in blk_integrity
> nvme: set pi_offset only when checksum type is not BLK_INTEGRITY_CSUM_NONE
> fs: add ioctl to query metadata and protection info capabilities
> block: fix lbmd_guard_tag_type assignment in FS_IOC_GETLBMD_CAP
>
> Arnd Bergmann (1):
> block: fix FS_IOC_GETLBMD_CAP parsing in blkdev_common_ioctl()
>
> Christian Brauner (1):
> Merge patch series "add ioctl to query metadata and protection info capabilities"
>
> block/bio-integrity-auto.c | 4 +--
> block/blk-integrity.c | 70 ++++++++++++++++++++++++++++++++++++++-
> block/blk-settings.c | 44 ++++++++++++++++++++++--
> block/ioctl.c | 6 ++++
> block/t10-pi.c | 16 ++++-----
> drivers/md/dm-crypt.c | 4 +--
> drivers/md/dm-integrity.c | 12 +++----
> drivers/nvdimm/btt.c | 2 +-
> drivers/nvme/host/core.c | 7 ++--
> drivers/nvme/target/io-cmd-bdev.c | 2 +-
> drivers/scsi/sd_dif.c | 3 +-
> include/linux/blk-integrity.h | 11 ++++--
> include/linux/blkdev.h | 3 +-
> include/uapi/linux/fs.h | 59 +++++++++++++++++++++++++++++++++
> 14 files changed, 213 insertions(+), 30 deletions(-)
It would be great if Klara's patch at
https://lore.kernel.org/lkml/20250725164334.9606-1-klarasmodin@gmail.com/
could follow just after this pull: I had been bisecting -next to find out
why "losetup /dev/loop0 tmpfsfile" was failing, and that patch fixes it -
and presumably other odd failures for anyone without BLK_DEV_INTEGRITY=y.
Thanks,
Hugh
next prev parent reply other threads:[~2025-07-28 1:29 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-25 11:27 [GIT PULL 00/14 for v6.17] vfs 6.17 Christian Brauner
2025-07-25 11:27 ` [GIT PULL 05/14 for v6.17] vfs async dir Christian Brauner
2025-07-28 23:40 ` pr-tracker-bot
2025-07-25 11:27 ` [GIT PULL 09/14 for v6.17] vfs bpf Christian Brauner
2025-07-28 23:40 ` pr-tracker-bot
2025-07-29 18:15 ` Alexei Starovoitov
2025-07-31 8:27 ` Christian Brauner
2025-07-31 21:57 ` Alexei Starovoitov
2025-08-04 14:24 ` Christian Brauner
2025-07-25 11:27 ` [GIT PULL 02/14 for v6.17] vfs coredump Christian Brauner
2025-07-28 18:57 ` Linus Torvalds
2025-07-31 9:37 ` Christian Brauner
2025-07-28 23:40 ` pr-tracker-bot
2025-07-25 11:27 ` [GIT PULL 06/14 for v6.17] vfs fallocate Christian Brauner
2025-07-28 23:40 ` pr-tracker-bot
2025-07-25 11:27 ` [GIT PULL 12/14 for v6.17] vfs fileattr Christian Brauner
2025-07-28 23:40 ` pr-tracker-bot
2025-07-25 11:27 ` [GIT PULL 11/14 for v6.17] vfs integrity Christian Brauner
2025-07-28 1:29 ` Hugh Dickins [this message]
2025-07-28 22:21 ` Linus Torvalds
2025-07-29 7:49 ` Christoph Hellwig
2025-07-29 8:39 ` Linus Torvalds
2025-07-31 8:00 ` Christian Brauner
2025-07-28 23:40 ` pr-tracker-bot
2025-07-25 11:27 ` [GIT PULL 14/14 for v6.17] vfs iomap Christian Brauner
2025-07-27 13:10 ` Sasha Levin
2025-07-28 16:39 ` Joanne Koong
2025-07-31 8:29 ` Christian Brauner
2025-07-28 23:40 ` pr-tracker-bot
2025-07-25 11:27 ` [GIT PULL 01/14 for v6.17] vfs misc Christian Brauner
2025-07-28 23:40 ` pr-tracker-bot
2025-07-25 11:27 ` [GIT PULL 07/14 for v6.17] vfs mmap Christian Brauner
2025-07-28 23:40 ` pr-tracker-bot
2025-07-25 11:27 ` [GIT PULL 04/14 for v6.17] namespace updates Christian Brauner
2025-07-28 23:40 ` pr-tracker-bot
2025-07-25 11:27 ` [GIT PULL 03/14 for v6.17] overlayfs Christian Brauner
2025-07-28 23:40 ` pr-tracker-bot
2025-07-25 11:27 ` [GIT PULL 08/14 for v6.17] vfs pidfs Christian Brauner
2025-07-28 23:40 ` pr-tracker-bot
2025-07-25 11:27 ` [GIT PULL 10/14 for v6.17] vfs rust Christian Brauner
2025-07-28 23:40 ` pr-tracker-bot
2025-07-25 11:27 ` [GIT PULL 13/14 for v6.17] vfs super Christian Brauner
2025-07-28 23:40 ` pr-tracker-bot
2025-07-31 9:40 ` [GIT PULL 00/14 for v6.17] vfs 6.17 Christian Brauner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0f40571c-11a2-50f0-1eba-78ab9d52e455@google.com \
--to=hughd@google.com \
--cc=anuj20.g@samsung.com \
--cc=arnd@arndb.de \
--cc=brauner@kernel.org \
--cc=klarasmodin@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).