From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 43ED63DB64B for ; Wed, 25 Mar 2026 15:10:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774451459; cv=none; b=ETxzK7NF334TnCQfkcnDNj8onC5A6WSUBCPGCwo7QV+ErH6+SUnCW0Ct5WLiMcSCTTcBic6LzgPB25dVDj0aYXzCNhcwHRq32rL2fsFUkr+iBl3jeO8BSDMKDFSEuXnGb2gvuyAPW/KjN6b/b2XHeOfcckxtgRy2/KvPlgRFjMs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774451459; c=relaxed/simple; bh=iT/s8Nk/XT1vatNd6bVfNfRTok1aKHyoryjCjtBLNbE=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=k7QgN+9jnYCTyyi6ConiJzi6paxz9ADjK65Bc5FcNY9JoYf3xU83+J4+eRJvbLp0yZA/2sBgV/9W6CqgBqrrfxL3pnyA4vfV32cuEADrYMHpGkVU7n2tODmPna8Eor4ZSNo1G/vPVMDs7fpl4AmArWXWfV7Xcy+0pqPiuSN1pp8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Y10peabf; arc=none smtp.client-ip=209.85.128.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Y10peabf" Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-486fd27754bso21517535e9.3 for ; Wed, 25 Mar 2026 08:10:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774451456; x=1775056256; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=3eq5Bfg2+8VmI5h5cy6vFohdWAHh+ZwyFSYt2VZ3Ae4=; b=Y10peabfiQQv4yEsHMOMbUqwNl5gxNt7xxi8SgFOwMgFyyRE/yACFSfu3jzYYk3z9X HMX5kJXW465Ao3Kktd8oDaoM5OPuOcPyXHDX1gb0s2UgZ/SG5d791QHcElB+X/+se5Ug WBqvlqGEYqKjA27RaMf8486ELnEBpzm+ueVt90rIO3RBsiJBfCEdTYhdyxoBPSWCr+Tp 2GqiOwCRDCDlzE2YHtpuhQrCCzn4gu41OHQM/KfUCMcn8nY1cwjmkfPTmUbTFRjkkWGq zWUfHjf5CGSclsWYNO+evo7uEZXdNY5UBLnR47seu2CJc20Rfj4MCT/8C0UqrZ9gz/Ki VYyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774451456; x=1775056256; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=3eq5Bfg2+8VmI5h5cy6vFohdWAHh+ZwyFSYt2VZ3Ae4=; b=odL3N/2pCarnQN31hjvuKbctOgkQ96AHhlGTaWVZ9bgePfliNrWAIrpiamLaj8+Jxl +k15/M5PohoiHMT8CA3GHzC42RcgaZysKz9naBEQGhTO5nPFKAzU/QS89MJjLKFJtvSj 4VVyl+9GMnu1cUpS7bYoHlh1g4x12ZzwxDFNgtbd+bv9JPFt36H/KyDG3d+yqVpOQ/EN EDNC/ESIKtm+/peeu/UiGrV7FNdTa6Arh/5ZyvW25s6uPB8WA+Kr0/zcghIPCgqFR6PT YWemTS5YHgMS2IgPz3TAtSocAWa5LpSEeBxpVQ4t51RbtTtzl/b/1u5dBWyMW2KBJt/G CzMQ== X-Forwarded-Encrypted: i=1; AJvYcCUOUkxWm4kMN/Bm78qFx2l6JoI0J354V69Tl4xs5svL00acirPjVgfZ4e8KMOUVQS4a+GE1xOjtaKxhdCk=@vger.kernel.org X-Gm-Message-State: AOJu0Yy/jm9x/VcVUFeJivvoE8YH1ZXYsKKgtEjvcXhqTAIPICAirR8f LKrcrnA3p9mpeP6EwIqb48rxGxqvb8LtFMv3KLbw6EQDvotnwvjOCf8c X-Gm-Gg: ATEYQzy1Prrgp3BcGYK4IdI3ZZkRnoabs0300nQF42YTj5Tuwtm5bbozaoK3YvQ1oOw hDMlmrOAGPQUDpzSf78b9qAGxyaWbQtFJub+esh3AjuIBvQrdoKjBb53K9uTa7KUEaQzNow9r/1 3qBhftZy486+sAXP64OspLpFA0z3OCfbCPKL19TG6gmmQxW11U5SshUYm3cx2x+CgqSsEsqmlWn Oaajd0oZqWCQ0pT+PjVZBo5ELwU1n8cBCk9kvGkI02xw1Hi+ILvzU3LmOq9+ATYN8S144chZCmd unkx0HJfLEYjKv2zvQj9fyb/guwaAEkUq5HgtDDo3GayAw1iQTnWNQDsAtEHk8qQrHALyxaQn5V nH6SMoh1NI2OKojx3lm/n0wuVLKUSFxy6Xie+Faky/8dnBeYC/h73WbSDZjQzbviaAJbu+ITE+0 FzuLfBLdOhPvpRxvYRqBx5nv+arxSHyUjzENCjattXuknPozvA24iAcLzsiOwTSSCH X-Received: by 2002:a05:600c:8b62:b0:486:f9a4:d487 with SMTP id 5b1f17b1804b1-48715f025f3mr60806025e9.0.1774451456104; Wed, 25 Mar 2026 08:10:56 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4871e603865sm1468345e9.8.2026.03.25.08.10.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 Mar 2026 08:10:55 -0700 (PDT) Date: Wed, 25 Mar 2026 15:10:53 +0000 From: David Laight To: Petr Mladek Cc: "Masami Hiramatsu (Google)" , Steven Rostedt , Andy Shevchenko , Rasmus Villemoes , Sergey Senozhatsky , Andrew Morton , linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 1/2] lib/vsprintf: Fix to check field_width and precision Message-ID: <20260325151053.2bdbadb2@pumpkin> In-Reply-To: <20260325112922.429c4ee4@pumpkin> References: <177440550682.147866.1854734911195480940.stgit@devnote2> <177440551685.147866.4375769344976474036.stgit@devnote2> <20260325112922.429c4ee4@pumpkin> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) 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 Wed, 25 Mar 2026 11:29:22 +0000 David Laight wrote: > On Wed, 25 Mar 2026 11:22:47 +0100 > Petr Mladek wrote: > > > On Wed 2026-03-25 11:25:16, Masami Hiramatsu (Google) wrote: > > > From: Masami Hiramatsu (Google) > > > > > > Check the field_width and presition correctly. Previously it depends > > > on the bitfield conversion from int to check out-of-range error. > > > However, commit 938df695e98d ("vsprintf: associate the format state > > > with the format pointer") changed those fields to int. > > > We need to check the out-of-range correctly without bitfield > > > conversion. > > > > > > --- a/lib/vsprintf.c > > > +++ b/lib/vsprintf.c > > > @@ -2679,9 +2679,6 @@ struct fmt format_decode(struct fmt fmt, struct printf_spec *spec) > > > > > > /* we finished early by reading the precision */ > > > if (unlikely(fmt.state == FORMAT_STATE_PRECISION)) { > > > - if (spec->precision < 0) > > > - spec->precision = 0; > > > > This changes the existing kernel behavior and breaks the existing > > KUnit test in lib/tests/printf_kunit.c: > > > > static void > > test_string(struct kunit *kunittest) > > { > > [...] > > /* > > * POSIX and C99 say that a negative precision (which is only > > * possible to pass via a * argument) should be treated as if > > * the precision wasn't present, and that if the precision is > > * omitted (as in %.s), the precision should be taken to be > > * 0. However, the kernel's printf behave exactly opposite, > > * treating a negative precision as 0 and treating an omitted > > * precision specifier as if no precision was given. > > Ugg... The only format string matches for '".*%[-+ #0]*[0-9]*\.[a-z].*"' are in printf_kuint.c There are some "%*.s" lurking, most are outputting "" or " " for alignment, the '.' can/should be removed, but truncating " " to "" makes no difference. (Well, it might change one pad space to none...) That leaves three "%*.s" in diagnostic printk() in dx_show_leaf() in fs/ext4/namei.c - all should be "%.*s" anyway. So "%.s" can safely be changed to be the same as "%.0s". Changing "%.d" from being "%d" to "%.0d" only affects the conversion of zero. But I didn't find any. It is harder to check the ("%.*s" len, str) cases for a possible negative len. Only really because of the shear number, most are 'namelen, name'. I guess a script/program to convert ("%.*s", prec, ptr) to ("%.*s", FMT_PREC(prec), ptr) then get the compiler to error !statically_true(prec >= 0) and look at what it finds. That should reduce the 700+ cases to a manageable number. David > > David > > > * > > * These test cases document the current behaviour; should > > * anyone ever feel the need to follow the standards more > > * closely, this can be revisited. > > */ > > test(" ", "%4.*s", -5, "123456"); > > [...] > > } > > > > The output is: > > > > [ 86.234405] # test_string: EXPECTATION FAILED at lib/tests/printf_kunit.c:56 > > lib/tests/printf_kunit.c:208: vsnprintf(buf, 256, "%4.*s", ...) returned 6, expected 4 > > [ 86.237524] # test_string: EXPECTATION FAILED at lib/tests/printf_kunit.c:56 > > lib/tests/printf_kunit.c:208: vsnprintf(buf, 2, "%4.*s", ...) returned 6, expected 4 > > [ 86.237542] # test_string: EXPECTATION FAILED at lib/tests/printf_kunit.c:56 > > lib/tests/printf_kunit.c:208: vsnprintf(buf, 0, "%4.*s", ...) returned 6, expected 4 > > [ 86.237559] # test_string: EXPECTATION FAILED at lib/tests/printf_kunit.c:141 > > lib/tests/printf_kunit.c:208: kvasprintf(..., "%4.*s", ...) returned '123456', expected ' ' > > > > Do we really want to change the existing behavior? > > Would it break any existing kernel caller? > > > > I would personally keep the existing behavior unless anyone checks > > the existing callers. > > > > > - > > > fmt.state = FORMAT_STATE_NONE; > > > goto qualifier; > > > } > > > @@ -2802,19 +2799,17 @@ struct fmt format_decode(struct fmt fmt, struct printf_spec *spec) > > > static void > > > set_field_width(struct printf_spec *spec, int width) > > > { > > > - spec->field_width = width; > > > - if (WARN_ONCE(spec->field_width != width, "field width %d too large", width)) { > > > - spec->field_width = clamp(width, -FIELD_WIDTH_MAX, FIELD_WIDTH_MAX); > > > - } > > > + spec->field_width = clamp(width, -FIELD_WIDTH_MAX, FIELD_WIDTH_MAX); > > > + WARN_ONCE(spec->field_width != width, "field width %d out of range", > > > + width); > > > } > > > > > > static void > > > set_precision(struct printf_spec *spec, int prec) > > > { > > > - spec->precision = prec; > > > - if (WARN_ONCE(spec->precision != prec, "precision %d too large", prec)) { > > > - spec->precision = clamp(prec, 0, PRECISION_MAX); > > > - } > > > + /* We allow negative precision, but treat it as if there was no precision. */ > > > + spec->precision = clamp(prec, -1, PRECISION_MAX); > > > > And I would keep clamp(prec, 0, PRECISION_MAX) unless anyone checks > > that changing the existing behavior does not break existing > > callers. > > > > > + WARN_ONCE(spec->precision < prec, "precision %d too large", prec); > > > } > > > > Best Regards, > > Petr >