public inbox for passt-dev@passt.top
 help / color / mirror / code / Atom feed
From: Stefano Brivio <sbrivio@redhat.com>
To: Laurent Vivier <lvivier@redhat.com>
Cc: passt-dev@passt.top, Mike Jones <mike@mjones.io>
Subject: Re: [PATCH] checksum: fix checksum with odd base address
Date: Thu, 9 Jan 2025 16:36:42 +0100	[thread overview]
Message-ID: <20250109163642.0a0bfcea@elisabeth> (raw)
In-Reply-To: <20250109130648.326933-1-lvivier@redhat.com>

[Cc'ed Mike who reported this]

On Thu,  9 Jan 2025 14:06:48 +0100
Laurent Vivier <lvivier@redhat.com> wrote:

> csum_unfolded() must call csum_avx2() with a 32byte aligned base address.
> 
> To be able to do that if the buffer is not correctly aligned,
> it splits the buffers in 2 parts, the second part is 32byte aligned and
> can be used with csum_avx2(), the first part is the remaining part, that
> is not 32byte aligned and we use sum_16b() to compute the checksum.
> 
> A problem appears if the length of the first part is odd because
> the checksum is using 16bit words to do the checksum.
> 
> If the length is odd, when the second part is computed, all words are
> shifted by 1 byte, meaning weight of upper and lower byte is swapped.
> 
> For instance a 13 bytes buffer:
> 
> bytes:
> 
> aa AA bb BB cc CC dd DD ee EE ff FF gg
> 
> 16bit words:
> 
> AAaa BBbb CCcc DDdd EEee FFff 00gg
> 
> If we don't split the sequence, the checksum is:
> 
> AAaa + BBbb + CCcc + DDdd + EEee + FFff + 00gg
> 
> If we split the sequence with an even length for the first part:
> 
> (AAaa + BBbb) + (CCcc + DDdd + EEee + FFff + 00gg)
> 
> But if the first part has an odd length:
> 
> (AAaa + BBbb + 00cc) + (ddCC + eeDD + ffEE + ggFF)

Thanks, this description is really helpful.

> To avoid the problem, do not call csum_avx2() if the first part cannot
> have an even length, and compute the checksum of all the buffer using
> sum_16b().
> 
> This is slower but it can only happen if the buffer base address is odd,
> and this can only happen if the binary is built using '-Os', and that
> means we have chosen to prioritize size over speed.

Reported-by: Mike Jones <mike@mjones.io>

> Link: https://bugs.passt.top/show_bug.cgi?id=108
> Signed-off-by: Laurent Vivier <lvivier@redhat.com>
> ---
>  checksum.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/checksum.c b/checksum.c
> index 1c4354d35734..2fd6867cdf75 100644
> --- a/checksum.c
> +++ b/checksum.c
> @@ -452,7 +452,7 @@ uint32_t csum_unfolded(const void *buf, size_t len, uint32_t init)
>  	intptr_t align = ROUND_UP((intptr_t)buf, sizeof(__m256i));
>  	unsigned int pad = align - (intptr_t)buf;
>  
> -	if (len < pad)
> +	if (pad & 1 || len < pad)

I'm fine applying this as it is, because the issue is quite nasty and we
have this great commit message anyway, but for clarity, could we have a
comment mentioning why we're doing this? Something like:

  /* Don't mix sum_16b() and csum_avx2() with odd padding lengths */

(I'm not quite satisfied with it but I find it better than nothing).

>  		pad = len;
>  
>  	if (pad)

-- 
Stefano


  reply	other threads:[~2025-01-09 15:36 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-09 13:06 [PATCH] checksum: fix checksum with odd base address Laurent Vivier
2025-01-09 15:36 ` Stefano Brivio [this message]
2025-01-09 16:47   ` Laurent Vivier
2025-01-09 17:17     ` Stefano Brivio
2025-01-10  2:40 ` David Gibson

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=20250109163642.0a0bfcea@elisabeth \
    --to=sbrivio@redhat.com \
    --cc=lvivier@redhat.com \
    --cc=mike@mjones.io \
    --cc=passt-dev@passt.top \
    /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.
Code repositories for project(s) associated with this public inbox

	https://passt.top/passt

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 IMAP folder(s).