Received-SPF: pass (google.com: domain of linux-kernel+bounces-46707-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Wed, 31 Jan 2024 07:26:28 -0800 (PST)
Subject:     Re: [PATCH v4 0/2] lib: checksum: Fix issues with checksum tests
In-Reply-To: <20240124-fix_sparse_errors_checksum_tests-v4-0-bc2b8d23a35c@rivosinc.com>
CC: linux@roeck-us.net, David.Laight@aculab.com, linux-kernel@vger.kernel.org,
  Charlie Jenkins <charlie@rivosinc.com>, lkp@intel.com
From: Palmer Dabbelt <palmer@dabbelt.com>
To: Charlie Jenkins <charlie@rivosinc.com>
Message-ID: <mhng-f4463f17-6d60-4313-ac4e-2f00ba71df05@palmer-ri-x1c9a>
Precedence: bulk
Mime-Version: 1.0 (MHng)
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

On Wed, 24 Jan 2024 20:37:23 PST (-0800), Charlie Jenkins wrote:
> The ip_fast_csum and csum_ipv6_magic tests did not have the data
> types properly casted, and improperly misaligned data.
>
> Signed-off-by: Charlie Jenkins <charlie@rivosinc.com>
> ---
> Changes in v4:
> - Pad test values with zeroes (David)
> - Link to v3: https://lore.kernel.org/r/20240123-fix_sparse_errors_checksum_tests-v3-0-efecc7f94297@rivosinc.com
>
> Changes in v3:
> - Don't read memory out of bounds
> - Link to v2: https://lore.kernel.org/r/20240123-fix_sparse_errors_checksum_tests-v2-0-b306b6ce7da5@rivosinc.com
>
> Changes in v2:
> - Add additional patch to fix alignment issues
> - Link to v1: https://lore.kernel.org/r/20240119-fix_sparse_errors_checksum_tests-v1-1-2d3df86d8d78@rivosinc.com
>
> ---
> Charlie Jenkins (2):
>       lib: checksum: Fix type casting in checksum kunits
>       lib: checksum: Use aligned accesses for ip_fast_csum and csum_ipv6_magic tests
>
>  lib/checksum_kunit.c | 389 +++++++++++++++++----------------------------------
>  1 file changed, 129 insertions(+), 260 deletions(-)
> ---
> base-commit: 6613476e225e090cc9aad49be7fa504e290dd33d
> change-id: 20240119-fix_sparse_errors_checksum_tests-26b86b34d784

Acked-by: Palmer Dabbelt <palmer@rivosinc.com>

in case someone wants to take it.  I'm also happy to take this via the 
RISC-V tree, as I recently poked this stuff and that's what caused the 
failures.  Just let me know...