From: Christoph Hellwig <hch@lst.de>
To: Kanchan Joshi <joshi.k@samsung.com>
Cc: kbusch@kernel.org, axboe@kernel.dk, hch@lst.de,
martin.petersen@oracle.com, sagi@grimberg.me,
linux-nvme@lists.infradead.org, linux-block@vger.kernel.org,
gost.dev@samsung.com, Chinmay Gameti <c.gameti@samsung.com>
Subject: Re: [PATCH 2/3] block: support PI at non-zero offset within metadata
Date: Wed, 31 Jan 2024 08:21:24 +0100 [thread overview]
Message-ID: <20240131072124.GB17498@lst.de> (raw)
In-Reply-To: <20240130171206.4845-3-joshi.k@samsung.com>
On Tue, Jan 30, 2024 at 10:42:05PM +0530, Kanchan Joshi wrote:
> The block integrity subsystem assumes that PI appears first in the
> metadata buffer.
> Abolish this assumption by adding the ability to handle PI starting at
> a non-zero offset.
> Calculation of the guard tag includes the metadata buffer up to this
> offset.
Maybe rewrite this as:
Block layer integrity processing currently assumes that protection
information is placed in the first bytes of each metadata block.
Remove this this limitation and include the metadata before the
protection information in the calculation of the guard tag.
> {
> unsigned int i;
> + u8 offset = iter->pi_offset;
Nit: I find it more readable if variables that are initialized at
declaration time come first. Also (with a few exceptions) it's nice
to read longer declarations first.
next prev parent reply other threads:[~2024-01-31 8:31 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20240130171918epcas5p3cd0e3e9c7fb9a74c8464b06779c378ea@epcas5p3.samsung.com>
2024-01-30 17:12 ` [PATCH 0/3] Block integrity with flexibile-offset PI Kanchan Joshi
2024-01-30 17:12 ` [PATCH 1/3] block: refactor guard helpers Kanchan Joshi
2024-01-31 7:16 ` Christoph Hellwig
2024-01-31 12:43 ` Sagi Grimberg
2024-01-30 17:12 ` [PATCH 2/3] block: support PI at non-zero offset within metadata Kanchan Joshi
2024-01-31 7:21 ` Christoph Hellwig [this message]
2024-01-31 12:43 ` Sagi Grimberg
2024-01-30 17:12 ` [PATCH 3/3] nvme: allow integrity when PI is not in first bytes Kanchan Joshi
2024-01-31 7:22 ` Christoph Hellwig
2024-01-31 12:43 ` Sagi Grimberg
2024-01-31 17:44 ` [PATCH 0/3] Block integrity with flexibile-offset PI Keith Busch
2024-01-31 17:48 ` 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=20240131072124.GB17498@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=c.gameti@samsung.com \
--cc=gost.dev@samsung.com \
--cc=joshi.k@samsung.com \
--cc=kbusch@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=martin.petersen@oracle.com \
--cc=sagi@grimberg.me \
/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