From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 6EC01191F84 for ; Wed, 25 Mar 2026 00:33:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774398803; cv=none; b=s2dkbOuqXnQh0Lta5eO8S3dOJwnkGqIQ58kAWJ9Cy51rMcPR/2AW6cADL9na9ahZM8OtihLEwc6wPdod7lBh1YzUAtVa6bmtb1zJudgDZZqMEhJ5qOmYxoAUsRcwsiyUhrNbjkrvJA4nMqmsitNQwICpjARmRyUaG1ElH3iseEI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774398803; c=relaxed/simple; bh=o0P/z56GDJ8oUK0/+AjdHcd7VFF33MkgeaF+MGDcLos=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=uRV/vYMo7fjTnTuItpSkeAIFWVlETFt21pRplZKLjyZMbnuiL7ozjkKVJKLuOmAMPap0tzkfPXr1vPDnsSuT/fuPv8eb585ow0gjrhoZAvieU86K8edyZ0GPcoq4BfzTLAY1hHc4GBVixhjcFWvdjyQlhXWZKb+Dn5otvdODjio= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=H+kQY6p+; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="H+kQY6p+" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C0CE1C19424; Wed, 25 Mar 2026 00:33:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774398803; bh=o0P/z56GDJ8oUK0/+AjdHcd7VFF33MkgeaF+MGDcLos=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=H+kQY6p+bUmvmoQwxyZa4iDxoOxvlKxB2+hyBUWn6+GD1kn2x9H55lEDDAB/MrUd8 WJ/8Phh6xj56ST5q03vqtHVnwdhkTd7afXXg+g95Szij2bsakQdkZskSmn0FE2V90e yRzemeHwPgSx7fsgpNykaH4le9qaHeU0F2JCTVN/TenXMu3N2bFjl4PDKXLrQDl2vh 3YSJTn7G0GAUwpTp8Chlwajs6uvW/wlxYWXzUYbncVcHFSylqgV5c/Q1aUa0WfM9Wc XBCjBdqy6XIukgt50Z+MhrgBpZhoUPQpSERLVwkTtGQgdqJfsHWrsFYq3bRv/7D48Q ajpgjMcFpOblQ== Date: Wed, 25 Mar 2026 09:33:20 +0900 From: Masami Hiramatsu (Google) To: David Laight Cc: Petr Mladek , Rasmus Villemoes , Andy Shevchenko , "Masami Hiramatsu (Google)" , Steven Rostedt , Sergey Senozhatsky , Andrew Morton , linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 1/2] lib/vsprintf: Fix to check field_width and precision Message-Id: <20260325093320.5bc786394face92aadbe4e4b@kernel.org> In-Reply-To: <20260324172433.05292942@pumpkin> References: <177410406326.38798.16853803119128725972.stgit@devnote2> <177410407207.38798.2345647618225402693.stgit@devnote2> <20260323135905.5272127b@pumpkin> <20260324172433.05292942@pumpkin> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) 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-Transfer-Encoding: 7bit On Tue, 24 Mar 2026 17:24:33 +0000 David Laight wrote: > On Tue, 24 Mar 2026 17:45:49 +0100 > Petr Mladek wrote: > > > On Mon 2026-03-23 13:59:05, David Laight wrote: > ... > > > I've also just fixed nolibc's handling of %*.*s (which is in 'next' since > > > I only wrote it recently), the above is actually broken. > > > Negative 'precision' (all values) are fine, they just request the default. > > > > Great catch! We should clamp the precision to (0, PRECISION_MAX). But we > > should warn only when it is outside of (-PRECISION_MAX, PRECISION_MAX). > > No, you are going to clamp it needs to be to (-1, PRECISION_MAX); > but max(precision, PRECISION_MAX) if fine now the value is being saved > in an int. > And there is no need to warn about changing negative values - they > all mean exactly the same thing. Ah, indeed. "A negative precision is taken as if the precision were omitted." > There isn't actually any need to worry about large precision values > for %s - they request truncation, precision only increases the output > for numbers. > > > > > > So the patch needs a big fat NACK... > > > > What is an acceptable solution then, please? > > You could do: > spec->precision = clamp(prec, -1, PRECISION_MAX); > if (spec->precision < prec) > WARN(...); > > David Ah, that looks good to me. Let me update it. Thanks, > > > > > Frankly, I would like to stay on earth. This started as a simple fix > > of a regression added a year ago. For me, any solution which > > restores the year old behavior is good enough. > > > > We might need to find another volunteer to implement a better > > solution, e.g. the new non-panicing MSG_AND_BT() macro. > > > > Alternatively, we could remove the WARN_ONCE() completely. > > It looks acceptable for me. But Rasmus would need to agree as well. > > > > Best Regards, > > Petr > -- Masami Hiramatsu (Google)