From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from hall.aurel32.net (hall.aurel32.net [195.154.119.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C00F139734A for ; Sat, 22 Aug 2026 09:53:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=195.154.119.183 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787392404; cv=none; b=OkAFjF/sCW8ggxOz3seL71uN17XXJzZ6PGthDitI8AeWtbdivenKrc+YWWLO4v/LqjmwkzsJQ5kbP1u3vb53zuhPaIAiMoMmc70OFLAHYwlbKwEHzqElo2U9s8gLXO2DSiO09Ncahkttbw4+YH35qsfU1LUSSLjQIzuwU9VQic8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787392404; c=relaxed/simple; bh=h6Dev4DaFvLFnUKYT/ada6Ij1pX5TLWCsz8Pu08tEPU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=SS0AbxHFomU2HH+yqqMZ81rYUCj62EVuIprsNY3qeci9NgWfv4mn+v4i6NGly3JgmFwKbD3tADId01SGSzTtos52A6B9Xn3qrKtW+FVcgVStxCTHme1ejJQcUVoYyYRsTTnCjfRN4GmwOCMkH9HldZ8j2H62MUNQsqXEmwsKR4s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=aurel32.net; spf=pass smtp.mailfrom=aurel32.net; dkim=pass (2048-bit key) header.d=aurel32.net header.i=@aurel32.net header.b=WID03Aem; arc=none smtp.client-ip=195.154.119.183 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=aurel32.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=aurel32.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=aurel32.net header.i=@aurel32.net header.b="WID03Aem" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=aurel32.net ; s=202004.hall; h=In-Reply-To:Content-Type:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Content-Transfer-Encoding:From:Reply-To: Subject:Content-ID:Content-Description:X-Debbugs-Cc; bh=jg9y4mI5v5W79aBW5EPfVqWvy0/7GhcpTvwiYa0ffF0=; b=WID03Aemp+e0J9keA6q1A7lTRY 4hyWskXvElzC4uLsCLCZ89BBMX5pzjzSPRBZ976sAwbcw6QhITIW5DAse64b/CXvbQZaZLrTmU84A 9yo9M0Gqcd37+C88yIAWmpIhRSrwiLQON1pG4vAOWtL3LZU3Qu8VfNFhfdDQQIXzENOTd6tnNFs6D iKIJA116hbcoCeeRTlY432rR0zIxu4Hnx9Jruoi5ozA4VMxp65mG9PFCjZgq0jtCAFzwgJR4BNQIl NxnWIUiD8Ky2siZ29a3NM4A89dXoH+uGAW1qJbv19Old6lEjQ3Z536ojQicjJAkbenxY/1YXadki5 DS8kQ9YA==; Received: from authenticated user by hall.aurel32.net with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wxiPb-0000000GiHh-3ff0; Sat, 22 Aug 2026 11:53:15 +0200 Date: Sat, 22 Aug 2026 11:53:15 +0200 From: Aurelien Jarno To: gao.rui@zte.com.cn Cc: pjw@kernel.org, palmer@dabbelt.com, aou@eecs.berkeley.edu, alex@ghiti.fr, jiangfeng@kylinos.cn, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] riscv: lib: Fix address overflow due to large count values in strnlen ZBB path Message-ID: Mail-Followup-To: gao.rui@zte.com.cn, pjw@kernel.org, palmer@dabbelt.com, aou@eecs.berkeley.edu, alex@ghiti.fr, jiangfeng@kylinos.cn, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org References: <20260819161821053fNUWuvdGIo4HUBmxlcNfG@zte.com.cn> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260819161821053fNUWuvdGIo4HUBmxlcNfG@zte.com.cn> User-Agent: Mutt/2.4.1 (2026-07-04) Hi, On 2026-08-19 16:18, gao.rui@zte.com.cn wrote: > Hi all, > > This patch fixes an issue in the RISC-V ZBB optimized strnlen implementation. > > Problem description: When using the ZBB optimized strnlen implementation, passing very large count values (such as SIZE_MAX) can cause address overflow and return incorrect results. > > This issue was observed in device-mapper tests: > > sh-5.2# dmsetup create testname9 --table "0 8 zero" > sh-5.2# cat /sys/block/dm-*/dm/name > testname > sh-5.2# dmsetup remove testname9 > > The overflow in strnlen caused failures in string handling during device-mapper operations. > > Patch summary: > - Explicitly introduce the strnlen_generic label. > - Simplify the generic implementation loop. This part should be in a separate patch, separated from the bug fix, and if possible with some benchmark. > - Add fallback logic in strnlen_zbb to redirect to the generic path when a0 + a1 overflows. > This ensures correct behavior for large count values and SIZE_MAX cases. Is there a way to instead to fix the strnlen_zbb to avoid the fallback? Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://aurel32.net