All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Keith Busch <kbusch@kernel.org>
Cc: Keith Busch <kbusch@meta.com>,
	linux-block@vger.kernel.org, hch@lst.de, axboe@kernel.dk,
	"Martin K. Petersen" <martin.petersen@oracle.com>
Subject: Re: [PATCHv4] blk-integrity: support arbitrary buffer alignment
Date: Thu, 13 Nov 2025 20:21:03 +0000	[thread overview]
Message-ID: <20251113202103.GC3971299@google.com> (raw)
In-Reply-To: <aRY7jDVt2jpLCWoO@kbusch-mbp>

On Thu, Nov 13, 2025 at 03:11:56PM -0500, Keith Busch wrote:
> On Thu, Nov 13, 2025 at 08:02:37PM +0000, Eric Biggers wrote:
> > On Thu, Nov 13, 2025 at 02:48:43PM -0500, Keith Busch wrote:
> > > Like on real hardware? I'm a bit at a loss as to how, I've never seen
> > > anything subscribe to this format, not even in emulation. The only thing
> > > I can readily do to test this is run random data through the old code,
> > > print the result, then run the same data through the new code and see if
> > > they're the same. That test is successful. Not good enough?
> > 
> > ip_compute_csum() returns a folded 16-bit checksum, whereas
> > csum_partial() returns an unfolded 32-bit checksum.
> 
> Sorry, I must be missing something. do_csum() returns an unfolded 32-bit
> result

Nope.  It returns a folded 16-bit result.

> In any case, I find that running any random data through it at block
> interval lengths (4k or 512b) is always producing results that fit in 16
> bits anyway, so maybe that's why it appears to be working?

Your kernel build may be using the generic csum_partial(), which folds
the checksum more frequently than the x86 one (and maybe some of the
other arch-optimized implementations too).  Try the x86 one.

- Eric

  reply	other threads:[~2025-11-13 20:21 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-13 15:26 [PATCHv4] blk-integrity: support arbitrary buffer alignment Keith Busch
2025-11-13 17:31 ` Eric Biggers
2025-11-13 18:14   ` Keith Busch
2025-11-13 19:20     ` Eric Biggers
2025-11-13 19:48       ` Keith Busch
2025-11-13 19:55         ` Martin K. Petersen
2025-11-13 19:57           ` Keith Busch
2025-11-13 20:02         ` Eric Biggers
2025-11-13 20:11           ` Keith Busch
2025-11-13 20:21             ` Eric Biggers [this message]
2025-11-13 20:21             ` Keith Busch

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=20251113202103.GC3971299@google.com \
    --to=ebiggers@kernel.org \
    --cc=axboe@kernel.dk \
    --cc=hch@lst.de \
    --cc=kbusch@kernel.org \
    --cc=kbusch@meta.com \
    --cc=linux-block@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.