All of lore.kernel.org
 help / color / mirror / Atom feed
From: 'Andy Shevchenko' <andriy.shevchenko@linux.intel.com>
To: David Laight <David.Laight@aculab.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	'Joe Perches' <joe@perches.com>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH 0/1] Slightly relax the type checking done by min() and max().
Date: Fri, 25 Nov 2022 19:48:01 +0200	[thread overview]
Message-ID: <Y4D/0dqOODs4ZHQM@smile.fi.intel.com> (raw)
In-Reply-To: <0b38ced96519407e95962aef2771bbc6@AcuMS.aculab.com>

On Fri, Nov 25, 2022 at 04:14:58PM +0000, David Laight wrote:
> From: 'Andy Shevchenko'
> > Sent: 25 November 2022 15:58
> > On Fri, Nov 25, 2022 at 03:27:07PM +0000, David Laight wrote:

...

> > Any better example, please?
> 
> How about:

Better, indeed.

> data_size = min_t(u16, buf_size, len);
> 
> https://elixir.bootlin.com/linux/v6.1-rc6/source/kernel/printk/printk_ringbuffer.c#L1738
> 
> Now, maybe, you could claim that buf_size > 64k never happens.
> But the correct cast here is u32 to match buf_size.
> len (being u16) will be promoted to int before the compare.
> 
> Just search the kernel for "min_t(u8," or "min_t(u16," while some might
> be ok, I really wouldn't want to verify each case.
> 
> If you look hard enough there are also some:
> 	u32_var = min_t(u32, u32_val, u64_val);
> where the intent is to limit values that might be invalid for u32.

Wouldn't be better to actually issue a warning if the desired type is shorter
than one of the min_t() arguments?

Then you go through all cases and fix them accordingly.

Blindly relaxing the rules is not an option in my opinion.

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2022-11-25 17:48 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-25 15:00 [PATCH 0/1] Slightly relax the type checking done by min() and max() David Laight
2022-11-25 15:17 ` Andy Shevchenko
2022-11-25 15:22   ` David Laight
2022-11-25 15:20 ` Andy Shevchenko
2022-11-25 15:27   ` David Laight
2022-11-25 15:58     ` 'Andy Shevchenko'
2022-11-25 16:14       ` David Laight
2022-11-25 17:48         ` 'Andy Shevchenko' [this message]
2022-11-25 19:47           ` David Laight
2022-11-26  0:02             ` Andrew Morton
2022-11-26 10:21               ` David Laight

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y4D/0dqOODs4ZHQM@smile.fi.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=David.Laight@aculab.com \
    --cc=akpm@linux-foundation.org \
    --cc=joe@perches.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.