Message ID | 20230811054528.never.165-kees@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b824:0:b0:3f2:4152:657d with SMTP id z4csp895311vqi; Thu, 10 Aug 2023 23:42:12 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHqckg2Nr+z4MTe8aoaaeGEINnk81gWRtU+w119LND5/+X7d4v4yKnNk1n/kcxgkPkVmuwz X-Received: by 2002:a17:906:200a:b0:991:b554:e64b with SMTP id 10-20020a170906200a00b00991b554e64bmr847508ejo.54.1691736131654; Thu, 10 Aug 2023 23:42:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1691736131; cv=none; d=google.com; s=arc-20160816; b=nNGIfAjBZCtUu07n87M2jH3mI5O1+e5kV4IKhRXJhU7ZvJ77SJfm1vGyY9WskkMgd6 sfzNz42HW7que6rTZyQZQYkiGSaVZxF+4bCA5at7iSvIuD8G2chMkp7ARzUFH4CkQpMw gtm2wLD56NnOdxpDfaEOhd6BZH/tTtE0NVBMnWjLCl3k8eMEbzU6nsrIs7YbPMHxHHVW Did2wMFzVUDkMSe4+P05xGagNajqNN/CsdfdpGIoiiz7iS8Ryh9O2TiIVePL9ACxoz4t BsVx/INWc0iYboFnIQVAXOYmL7RdMfgYr2mdldDZvQ03dxK/sbbzB/NCmSnxaDBg+znm L0xg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=vTeKxa1864hX9Aw51WCVjkQ2Cm0F4fAMm4BvD1X8A/w=; fh=+8fsBuOlPGl7/Mvk8/GcarCwaYxS1kswgTwpmC3d324=; b=jJlpSXM6xYlY/xpc97Ik5NsyF4kwrDVazqI8xe2NEU9sVm/s51e5WaFGqmG/Q1AP39 oqmymIwQBtPjvP7DEMME0nO3PVACXlpe5DznLn9oQnteJ243khEXbDcxlWf2jLC3XW84 y5hREb1JLJ8DEnG54L6PVnwYlmny2Bshe/q81/cfs9yAq/0Kls1PUjsGZolOhLYeIx/b 6IKkcyJZHxhLtlNtDJ2kES9U4bBCmtHCF00sR4axIhgb0TXK1vsaugHfluCbYKtJEn8E UwgjgNKJqjd/AG6DR5d+0fcrAD5+sGB0D8HVngt9M934V8o2TawDFNuAf4B9gdygFqVI hAWA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=ZFniN104; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id jj4-20020a170907984400b00992f45c9342si2657551ejc.1020.2023.08.10.23.41.48; Thu, 10 Aug 2023 23:42:11 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=ZFniN104; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229592AbjHKFpi (ORCPT <rfc822;shaohuahua6@gmail.com> + 99 others); Fri, 11 Aug 2023 01:45:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36732 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229726AbjHKFph (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 11 Aug 2023 01:45:37 -0400 Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EC78B2700 for <linux-kernel@vger.kernel.org>; Thu, 10 Aug 2023 22:45:36 -0700 (PDT) Received: by mail-pg1-x532.google.com with SMTP id 41be03b00d2f7-5656a5c6721so552799a12.1 for <linux-kernel@vger.kernel.org>; Thu, 10 Aug 2023 22:45:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1691732736; x=1692337536; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=vTeKxa1864hX9Aw51WCVjkQ2Cm0F4fAMm4BvD1X8A/w=; b=ZFniN104HNYjmigZFPtbzk4Zw6qS9pf+Et2Pd10K+5vMDpWBP3veR3Utp7cRCTxVye GHR1TldZa+oirz7lT/KUkE55d3Tm0rbRSOjtDd0fdKfW47vFhrLw6f5uvH86KSCmWRuh zpVojA9PpH9BiqcZXC6EnWZZ8IPEfHVp9CJVI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691732736; x=1692337536; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=vTeKxa1864hX9Aw51WCVjkQ2Cm0F4fAMm4BvD1X8A/w=; b=Nb774BpVpm2fxQrsqDkFoPdolQStvfqBhXnU5cU8ihR0M83a9E3EfR8JSLNvvGoaoy dpCzIvnMkd6TXkGjh79SVopTZbMe2ND5QCYa8xiOWw0SvWOba1A8YUbjtRu50oWfRj9v Zh7hFx6a4a9vp5bG84MgUNTkubbMW9EhogsyeJzF/9+TFzlfDZXYbsm8OeYCzu2xiPfF UdX3SJKHhBeEb1f4jUyhCXyhQ8udNgBXv1kYTXWosn6sZHGN/eaTU2OlD+JIFpmaBGnI fL2tg7XyFEFWMthW8uPhEmo9o2Jnw/OK+BwON1e/TRJq5TzrBlH0xJRYtxPw+D+aGC85 8DAg== X-Gm-Message-State: AOJu0YyCnPsN0t0s1R0XMkL8xwIBSFyirfd+Yxs/qApWIiFfptOjnZqw Ylnv/c17bTAK8gmXFdNWbn5voQ== X-Received: by 2002:a05:6a20:be1b:b0:133:3682:3cdf with SMTP id ge27-20020a056a20be1b00b0013336823cdfmr785320pzb.11.1691732736198; Thu, 10 Aug 2023 22:45:36 -0700 (PDT) Received: from www.outflux.net (198-0-35-241-static.hfc.comcastbusiness.net. [198.0.35.241]) by smtp.gmail.com with ESMTPSA id c2-20020aa78802000000b00687087d8bc3sm2557075pfo.141.2023.08.10.22.45.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Aug 2023 22:45:35 -0700 (PDT) From: Kees Cook <keescook@chromium.org> To: Petr Mladek <pmladek@suse.com> Cc: Kees Cook <keescook@chromium.org>, Sergey Senozhatsky <senozhatsky@chromium.org>, Steven Rostedt <rostedt@goodmis.org>, John Ogness <john.ogness@linutronix.de>, Vijay Balakrishna <vijayb@linux.microsoft.com>, stable@vger.kernel.org, Tony Luck <tony.luck@intel.com>, "Guilherme G. Piccoli" <gpiccoli@igalia.com>, "Paul E. McKenney" <paulmck@kernel.org>, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org Subject: [PATCH] printk: ringbuffer: Fix truncating buffer size min_t cast Date: Thu, 10 Aug 2023 22:45:32 -0700 Message-Id: <20230811054528.never.165-kees@kernel.org> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=1390; i=keescook@chromium.org; h=from:subject:message-id; bh=LSsQlfVwJGANZC4BMOlstWxt7EAJ8V19cSaVUMG+hnA=; b=owEBbQKS/ZANAwAKAYly9N/cbcAmAcsmYgBk1cr8i9Tw8GnNz3kTm1mkiIrZuI7bebooN5tFQ YTs1cel/WeJAjMEAAEKAB0WIQSlw/aPIp3WD3I+bhOJcvTf3G3AJgUCZNXK/AAKCRCJcvTf3G3A JqK9D/4hSDCX6PHtUGQaGrmuI0S5HitVkvLsSFBNe+yoYZStF8nq/g9woA7dMsmU3ypkEM+DRLO l9dXpbwr6JTWsjkCECKWqZjA29PjXGG8bkgkQrpVWWQWuy0Rg4h8EnsfuuVJEGtbU8U4Vlmlv2w DTytv5P8uyalfVbyF1UaEAt/PhCvZpu/UJo5xyYwO2IXSG68ouUHeN+8kCKCnlu/a3Sd66lR4Fp PEYJAG9WkSVfQ8i4vM4c7I5eke7YNosDJ0umAuPgZ2oOQlABn0ZeDmjPVbYCqfzUseB9ycnmkBa 7yVK8LPcupe+IcUA8sS0VBNN3pZQrb/2mE/PwX/0e+ZVTu/ROfugMBfGqNJwSqim44ROSFJeUek gslo9slDbwJt5EixSB4xtPWfs3AHEG3GQkzp/sIBNMHHzjJRT5GFk65/qWpnQhzlG5IMe57xFHM xOVdwl+VeevpJAAly9QrGDl7tR6xyC4Pia+sgvlIKATvpmPTziSBt/X32h8/vtOpbyvli9O/idy LJzwBKtdr9dI2ynun4ZQHr5QvD2j9w0NGmojOIJ0OTXBCZ45ZDF32r/qqjXwd06jtK70FlApiUX Wy9/1LA5N8VsjPT2HqFYXTpxS6BTHSD5VSvYhCEYhkeNcFHjkx5EzKdQyN/sv+vbDNh7MO0Nzjp RpC5fZy dRA1n43A== X-Developer-Key: i=keescook@chromium.org; a=openpgp; fpr=A5C3F68F229DD60F723E6E138972F4DFDC6DC026 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1773913906159998959 X-GMAIL-MSGID: 1773913906159998959 |
Series |
printk: ringbuffer: Fix truncating buffer size min_t cast
|
|
Commit Message
Kees Cook
Aug. 11, 2023, 5:45 a.m. UTC
If an output buffer size exceeded U16_MAX, the min_t(u16, ...) cast in
copy_data() was causing writes to truncate. This manifested as output
bytes being skipped, seen as %NUL bytes in pstore dumps when the available
record size was larger than 65536. Fix the cast to no longer truncate
the calculation.
Cc: Petr Mladek <pmladek@suse.com>
Cc: Sergey Senozhatsky <senozhatsky@chromium.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: John Ogness <john.ogness@linutronix.de>
Reported-by: Vijay Balakrishna <vijayb@linux.microsoft.com>
Closes: https://lore.kernel.org/lkml/d8bb1ec7-a4c5-43a2-9de0-9643a70b899f@linux.microsoft.com/
Fixes: b6cf8b3f3312 ("printk: add lockless ringbuffer")
Cc: stable@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
---
kernel/printk/printk_ringbuffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On 8/10/23 22:45, Kees Cook wrote: > If an output buffer size exceeded U16_MAX, the min_t(u16, ...) cast in > copy_data() was causing writes to truncate. This manifested as output > bytes being skipped, seen as %NUL bytes in pstore dumps when the available > record size was larger than 65536. Fix the cast to no longer truncate > the calculation. > > Cc: Petr Mladek <pmladek@suse.com> > Cc: Sergey Senozhatsky <senozhatsky@chromium.org> > Cc: Steven Rostedt <rostedt@goodmis.org> > Cc: John Ogness <john.ogness@linutronix.de> > Reported-by: Vijay Balakrishna <vijayb@linux.microsoft.com> > Closes: https://lore.kernel.org/lkml/d8bb1ec7-a4c5-43a2-9de0-9643a70b899f@linux.microsoft.com/ > Fixes: b6cf8b3f3312 ("printk: add lockless ringbuffer") > Cc: stable@vger.kernel.org > Signed-off-by: Kees Cook <keescook@chromium.org> Excellent. I have verified on v5.10. Tested-by: Vijay Balakrishna <vijayb@linux.microsoft.com> Thanks, Vijay
Great finding! Thanks a lot for the report and the fix - oneliners are
usually the most challenging to debug.
Tested it in the Steam Deck, and it works perfectly - I saw eventually
one line or two filled with NULLs, now they're gone.
Feel free to add:
Tested-by: Guilherme G. Piccoli <gpiccoli@igalia.com> # Steam Deck
On 2023-08-10 22:45:32, Kees Cook wrote: > If an output buffer size exceeded U16_MAX, the min_t(u16, ...) cast in > copy_data() was causing writes to truncate. This manifested as output > bytes being skipped, seen as %NUL bytes in pstore dumps when the available > record size was larger than 65536. Fix the cast to no longer truncate > the calculation. > > Cc: Petr Mladek <pmladek@suse.com> > Cc: Sergey Senozhatsky <senozhatsky@chromium.org> > Cc: Steven Rostedt <rostedt@goodmis.org> > Cc: John Ogness <john.ogness@linutronix.de> > Reported-by: Vijay Balakrishna <vijayb@linux.microsoft.com> > Closes: https://lore.kernel.org/lkml/d8bb1ec7-a4c5-43a2-9de0-9643a70b899f@linux.microsoft.com/ > Fixes: b6cf8b3f3312 ("printk: add lockless ringbuffer") > Cc: stable@vger.kernel.org > Signed-off-by: Kees Cook <keescook@chromium.org> Nice find! Reviewed-by: Tyler Hicks (Microsoft) <code@tyhicks.com> Tested-by: Tyler Hicks (Microsoft) <code@tyhicks.com> Verified the fix by applying it to an instrumented v6.5-rc5 kernel that allows userspace to execute kmsg_dump(), detects NULL bytes in data copied from the ring buffer, and warns about invalid truncation due to the min_t(u16, ...) casting bug. Everything looks good! Tyler > --- > kernel/printk/printk_ringbuffer.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/printk/printk_ringbuffer.c b/kernel/printk/printk_ringbuffer.c > index 2dc4d5a1f1ff..fde338606ce8 100644 > --- a/kernel/printk/printk_ringbuffer.c > +++ b/kernel/printk/printk_ringbuffer.c > @@ -1735,7 +1735,7 @@ static bool copy_data(struct prb_data_ring *data_ring, > if (!buf || !buf_size) > return true; > > - data_size = min_t(u16, buf_size, len); > + data_size = min_t(unsigned int, buf_size, len); > > memcpy(&buf[0], data, data_size); /* LMM(copy_data:A) */ > return true; > -- > 2.34.1 >
On 2023-08-10, Kees Cook <keescook@chromium.org> wrote: > If an output buffer size exceeded U16_MAX, the min_t(u16, ...) cast in > copy_data() was causing writes to truncate. This manifested as output > bytes being skipped, seen as %NUL bytes in pstore dumps when the available > record size was larger than 65536. Fix the cast to no longer truncate > the calculation. Thanks for tracking this down. Reviewed-by: John Ogness <john.ogness@linutronix.de>
On (23/08/10 22:45), Kees Cook wrote: > If an output buffer size exceeded U16_MAX, the min_t(u16, ...) cast in > copy_data() was causing writes to truncate. This manifested as output > bytes being skipped, seen as %NUL bytes in pstore dumps when the available > record size was larger than 65536. Fix the cast to no longer truncate > the calculation. > > Cc: Petr Mladek <pmladek@suse.com> > Cc: Sergey Senozhatsky <senozhatsky@chromium.org> > Cc: Steven Rostedt <rostedt@goodmis.org> > Cc: John Ogness <john.ogness@linutronix.de> > Reported-by: Vijay Balakrishna <vijayb@linux.microsoft.com> > Closes: https://lore.kernel.org/lkml/d8bb1ec7-a4c5-43a2-9de0-9643a70b899f@linux.microsoft.com/ > Fixes: b6cf8b3f3312 ("printk: add lockless ringbuffer") > Cc: stable@vger.kernel.org > Signed-off-by: Kees Cook <keescook@chromium.org> Thanks a lot! Reviewed-by: Sergey Senozhatsky <senozhatsky@chromium.org>
From: Kees Cook > Sent: 11 August 2023 06:46 > > If an output buffer size exceeded U16_MAX, the min_t(u16, ...) cast in > copy_data() was causing writes to truncate. This manifested as output > bytes being skipped, seen as %NUL bytes in pstore dumps when the available > record size was larger than 65536. Fix the cast to no longer truncate > the calculation. > ... > diff --git a/kernel/printk/printk_ringbuffer.c b/kernel/printk/printk_ringbuffer.c > index 2dc4d5a1f1ff..fde338606ce8 100644 > --- a/kernel/printk/printk_ringbuffer.c > +++ b/kernel/printk/printk_ringbuffer.c > @@ -1735,7 +1735,7 @@ static bool copy_data(struct prb_data_ring *data_ring, > if (!buf || !buf_size) > return true; > > - data_size = min_t(u16, buf_size, len); > + data_size = min_t(unsigned int, buf_size, len); I'd noticed that during one of my test compiles while looking at making min() less fussy. A better fix would be: data_size = min(buf_size + 0u, len); Or put an ack on my patch 3/5 to minmax.h and then min(buf_size, len) will be fine (because both arguments are unsigned). David > > memcpy(&buf[0], data, data_size); /* LMM(copy_data:A) */ > return true; > -- > 2.34.1 - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
On Thu 2023-08-10 22:45:32, Kees Cook wrote: > If an output buffer size exceeded U16_MAX, the min_t(u16, ...) cast in > copy_data() was causing writes to truncate. This manifested as output > bytes being skipped, seen as %NUL bytes in pstore dumps when the available > record size was larger than 65536. Fix the cast to no longer truncate > the calculation. > > Cc: Petr Mladek <pmladek@suse.com> > Cc: Sergey Senozhatsky <senozhatsky@chromium.org> > Cc: Steven Rostedt <rostedt@goodmis.org> > Cc: John Ogness <john.ogness@linutronix.de> > Reported-by: Vijay Balakrishna <vijayb@linux.microsoft.com> > Closes: https://lore.kernel.org/lkml/d8bb1ec7-a4c5-43a2-9de0-9643a70b899f@linux.microsoft.com/ checkpatch.pl suggested that "Link:" should be used instead of "Closes:". > Fixes: b6cf8b3f3312 ("printk: add lockless ringbuffer") > Cc: stable@vger.kernel.org > Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Petr Mladek <pmladek@suse.com> Thanks a lot for tracking this down. The patch has been comitted into printk/linux.git, branch for-6.6. I though about pushing it for 5.5-rc7. But it is pretty old issue. It does not break the system. I wanted to give it some spin in linux-next. And I leave for vacation on Thursday. I will not have internet connection until Aug 28. Best Regards, Petr
On Mon 2023-08-14 10:42:26, David Laight wrote: > From: Kees Cook > > Sent: 11 August 2023 06:46 > > > > If an output buffer size exceeded U16_MAX, the min_t(u16, ...) cast in > > copy_data() was causing writes to truncate. This manifested as output > > bytes being skipped, seen as %NUL bytes in pstore dumps when the available > > record size was larger than 65536. Fix the cast to no longer truncate > > the calculation. > > > ... > > diff --git a/kernel/printk/printk_ringbuffer.c b/kernel/printk/printk_ringbuffer.c > > index 2dc4d5a1f1ff..fde338606ce8 100644 > > --- a/kernel/printk/printk_ringbuffer.c > > +++ b/kernel/printk/printk_ringbuffer.c > > @@ -1735,7 +1735,7 @@ static bool copy_data(struct prb_data_ring *data_ring, > > if (!buf || !buf_size) > > return true; > > > > - data_size = min_t(u16, buf_size, len); > > + data_size = min_t(unsigned int, buf_size, len); > > I'd noticed that during one of my test compiles while looking > at making min() less fussy. > > A better fix would be: > data_size = min(buf_size + 0u, len); This looks like a magic to me. The types are: unsigned int data_size; unsigned int buf_size; u16 len I would naively expect that data_size = min(buf_size, len); would do the right job and expand @len to "unsigned int". I do not remember why "min_t" was used. Was it an optimization? Did we miss the problem with casting "u32" down to "u16"? I tried to read the discussion at https://lore.kernel.org/lkml/b6a49ed73aba427ca8bb433763fa94e9@AcuMS.aculab.com/ but it is more about "signed" vs. "unsigned" problem. Maybe it is more complicated that I expected. > Or put an ack on my patch 3/5 to minmax.h and then min(buf_size, len) > will be fine (because both arguments are unsigned). Do you mean https://lore.kernel.org/lkml/6dc20ac7cb6f4570a0160f076e8362e3@AcuMS.aculab.com/ ? It seems to be just indentation cleanup. Best Regards, Petr PS: I have already pushed the patch because it looked reasonable and got testing. I have to admit that I am probably in a pre-vacation hurry mode.
From: Petr Mladek > Sent: 14 August 2023 13:56 > > On Mon 2023-08-14 10:42:26, David Laight wrote: > > From: Kees Cook > > > Sent: 11 August 2023 06:46 > > > > > > If an output buffer size exceeded U16_MAX, the min_t(u16, ...) cast in > > > copy_data() was causing writes to truncate. This manifested as output > > > bytes being skipped, seen as %NUL bytes in pstore dumps when the available > > > record size was larger than 65536. Fix the cast to no longer truncate > > > the calculation. > > > > > ... > > > diff --git a/kernel/printk/printk_ringbuffer.c b/kernel/printk/printk_ringbuffer.c > > > index 2dc4d5a1f1ff..fde338606ce8 100644 > > > --- a/kernel/printk/printk_ringbuffer.c > > > +++ b/kernel/printk/printk_ringbuffer.c > > > @@ -1735,7 +1735,7 @@ static bool copy_data(struct prb_data_ring *data_ring, > > > if (!buf || !buf_size) > > > return true; > > > > > > - data_size = min_t(u16, buf_size, len); > > > + data_size = min_t(unsigned int, buf_size, len); > > > > I'd noticed that during one of my test compiles while looking > > at making min() less fussy. > > > > A better fix would be: > > data_size = min(buf_size + 0u, len); > > This looks like a magic to me. The types are: Not quite the right magic though, needs to be 'len + 0u'. > > unsigned int data_size; > unsigned int buf_size; > u16 len > > I would naively expect that > > data_size = min(buf_size, len); > > would do the right job and expand @len to "unsigned int". > > I do not remember why "min_t" was used. Was it an optimization? > Did we miss the problem with casting "u32" down to "u16"? The underlying problem is that (presumably) in order to stop min(signed_a, unsigned_b) converting a negative value to a large unsigned one (very nasty) min() contains (effectively) sizeof(&a == &b) so barfs if the types differ at all. I'm sure the intent was that the types would be fixed - in this case chasing 'len' back all the way back and using 'unsigned int'. (That probably generates better code as well.) However everyone just uses min_t(type,a,b) if type is 32bit unsigned they are mostly ok because the kernel only really deals in 'small' unsigned values. But, as in the case here, it is easy to pick a type that is too small. Pretty much all the min_t() with u8/u16 are likely to be dubious. I found an 'unsigned long' case in a filesystem where one value was u64 - could be problematic for a large file on 32bit. (The u64 definitely contained a 'file size' value.) The patch set I proposed (see https://lore.kernel.org/lkml/01e3e09005e9434b8f558a893a47c053@AcuMS.aculab.com/) changes the basic test to (is_signed(a) == is_signed(b)) which will never generate the 'nasty' conversion of -1 to 0xffffffffull. Of course, it is never quite that simple :-) Linus seems willing to accept min(unsigned_var, 20) but not min(signed_var, 20u) - typically as min(signed_var, sizeof(type)). ... > PS: I have already pushed the patch because it looked reasonable and > got testing. I have to admit that I am probably in a pre-vacation > hurry mode. Don't worry it is now not any worse than the other 4500 min_t(). Much the same as the number of min(). David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
diff --git a/kernel/printk/printk_ringbuffer.c b/kernel/printk/printk_ringbuffer.c index 2dc4d5a1f1ff..fde338606ce8 100644 --- a/kernel/printk/printk_ringbuffer.c +++ b/kernel/printk/printk_ringbuffer.c @@ -1735,7 +1735,7 @@ static bool copy_data(struct prb_data_ring *data_ring, if (!buf || !buf_size) return true; - data_size = min_t(u16, buf_size, len); + data_size = min_t(unsigned int, buf_size, len); memcpy(&buf[0], data, data_size); /* LMM(copy_data:A) */ return true;