From: Christoph Hellwig <hch@lst.de>
To: Anuj Gupta <anuj20.g@samsung.com>
Cc: Christoph Hellwig <hch@lst.de>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
Kanchan Joshi <joshi.k@samsung.com>,
linux-block@vger.kernel.org, linux-scsi@vger.kernel.org,
linux-nvme@lists.infradead.org
Subject: Re: fine-grained PI control
Date: Mon, 29 Jul 2024 19:03:08 +0200 [thread overview]
Message-ID: <20240729170308.GA31298@lst.de> (raw)
In-Reply-To: <20240726102156.GA17572@green245>
On Fri, Jul 26, 2024 at 03:51:56PM +0530, Anuj Gupta wrote:
>
> I was thinking something like below patch[*] could help us get rid of the
> BIP_USER_CHECK_FOO flags, and also driver can now check flags passed by block
> layer instead of checking if it's user passthrough data. Haven't plumbed the
> scsi side of things, but do you think it can work with scsi?
>
> Subject: [PATCH] block: introduce BIP_CHECK_GUARD/REFTAG/APPTAG bip_flags
>
> This patch introduces BIP_CHECK_GUARD/REFTAG/APPTAG bip_flags which
> indicate how the hardware should check the payload. The driver can now
> just rely on block layer flags, and doesn't need to know the integrity
> source. Submitter of PI chooses which tags to check. This would also
> give us a unified interface for user and kernel generated integrity.
This looks reasonably to me for the in-kernel interface. We'll still
need to deal with the fact that SCSI is a bit selective in what
combination of these flags it actually allows.
next prev parent reply other threads:[~2024-07-29 17:03 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-05 8:32 fine-grained PI control Christoph Hellwig
2024-07-08 14:17 ` Anuj gupta
2024-07-09 7:08 ` Christoph Hellwig
2024-07-09 3:35 ` Martin K. Petersen
2024-07-09 7:16 ` Christoph Hellwig
2024-07-10 3:47 ` Martin K. Petersen
2024-07-11 5:42 ` Christoph Hellwig
2024-07-16 2:07 ` Martin K. Petersen
2024-07-26 10:21 ` Anuj Gupta
2024-07-29 17:03 ` Christoph Hellwig [this message]
2024-09-18 6:39 ` Anuj Gupta
2024-09-24 1:59 ` Martin K. Petersen
2024-09-24 5:36 ` Christoph Hellwig
2024-09-27 2:01 ` Martin K. Petersen
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=20240729170308.GA31298@lst.de \
--to=hch@lst.de \
--cc=anuj20.g@samsung.com \
--cc=joshi.k@samsung.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.