All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Linux Crypto Mailing List <linux-crypto@vger.kernel.org>
Subject: Re: [v2 PATCH 2/2] crypto: hash - Use nth_page instead of doing it by hand
Date: Thu, 13 Mar 2025 03:07:41 +0000	[thread overview]
Message-ID: <20250313030741.GA2806970@google.com> (raw)
In-Reply-To: <Z9JEvCT-3Q6BUnOt@gondor.apana.org.au>

On Thu, Mar 13, 2025 at 10:36:44AM +0800, Herbert Xu wrote:
> On Wed, Mar 12, 2025 at 01:09:08PM -0700, Eric Biggers wrote:
> >
> > It seems that the "real bug" mentioned above is the case of
> > scatterlist::offset > PAGE_SIZE.  That's unrelated to the nth_page() fix, which
> > seems to be for scatterlist elements that span physical memory sections.  Also,
> 
> Alright I'll try to split it up.
> 
> > Note that there is also page arithmetic being done in scatterwalk_done_dst() and
> > scomp_acomp_comp_decomp().  Those presumably need the nth_page() fix too.
> 
> Thanks, I had missed the flushing code in scatterwalk.
> 
> As for scomp yes that's already fixed in my acomp series which I
> will repost soon.
> 
> > scomp_acomp_comp_decomp() also assumes that if the first page in a given
> > scatterlist element is lowmem, then any additional pages are lowmem too.  That
> 
> Yes I've fixed that by changing it to test the last page rather than
> the first, assuming that highmem indeed comes after lowmem.
> 
> > sounds like another potentially wrong assumption.  Can scatterlist elements span
> > memory zones?  Or just physical memory sections?
> 
> Theoretically it can cross anything.  Check out the block merging
> code in __blk_rq_map_sg, it tries to merge any physically contiguous
> page.

Actually the block layer avoids this edge case.  See the comment above struct
bio_vec, and the corresponding code in bvec_try_merge_page():

        if (bv->bv_page + bv_end / PAGE_SIZE != page + off / PAGE_SIZE)
                return false;

- Eric

  reply	other threads:[~2025-03-13  3:07 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-12  4:29 [v2 PATCH 0/2] crypto: Use nth_page instead of doing it by hand Herbert Xu
2025-03-12  4:29 ` [v2 PATCH 1/2] crypto: scatterwalk - " Herbert Xu
2025-03-12 19:56   ` Eric Biggers
2025-03-13  1:43     ` Herbert Xu
2025-03-13  3:13       ` Eric Biggers
2025-03-12  4:30 ` [v2 PATCH 2/2] crypto: hash " Herbert Xu
2025-03-12 20:09   ` Eric Biggers
2025-03-13  2:36     ` Herbert Xu
2025-03-13  3:07       ` Eric Biggers [this message]
2025-03-13  4:04         ` Herbert Xu

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=20250313030741.GA2806970@google.com \
    --to=ebiggers@kernel.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.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 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.