linux-kernel - RE: [PATCH net v3 3/3] rtase: Fix a type error in min

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <040b019af779423f96752f10a697195b@realtek.com>
Date: Wed, 23 Apr 2025 10:53:53 +0000
From: Justin Lai <justinlai0215@...ltek.com>
To: Simon Horman <horms@...nel.org>
CC: "kuba@...nel.org" <kuba@...nel.org>,
        "davem@...emloft.net"
	<davem@...emloft.net>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        "andrew+netdev@...n.ch"
	<andrew+netdev@...n.ch>,
        "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>,
        "netdev@...r.kernel.org"
	<netdev@...r.kernel.org>,
        Ping-Ke Shih <pkshih@...ltek.com>,
        Larry Chiu
	<larry.chiu@...ltek.com>, Andrew Lunn <andrew@...n.ch>,
        David Laight
	<david.laight.linux@...il.com>
Subject: RE: [PATCH net v3 3/3] rtase: Fix a type error in min_t

> 
> + David Laight
> 
> On Thu, Apr 17, 2025 at 04:56:59PM +0800, Justin Lai wrote:
> > Fix a type error in min_t.
> >
> > Fixes: a36e9f5cfe9e ("rtase: Add support for a pci table in this
> > module")
> > Signed-off-by: Justin Lai <justinlai0215@...ltek.com>
> > Reviewed-by: Andrew Lunn <andrew@...n.ch>
> > ---
> >  drivers/net/ethernet/realtek/rtase/rtase_main.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/realtek/rtase/rtase_main.c
> > b/drivers/net/ethernet/realtek/rtase/rtase_main.c
> > index 55b8d3666153..bc856fb3d6f3 100644
> > --- a/drivers/net/ethernet/realtek/rtase/rtase_main.c
> > +++ b/drivers/net/ethernet/realtek/rtase/rtase_main.c
> > @@ -1923,7 +1923,7 @@ static u16 rtase_calc_time_mitigation(u32
> time_us)
> >       u8 msb, time_count, time_unit;
> >       u16 int_miti;
> >
> > -     time_us = min_t(int, time_us, RTASE_MITI_MAX_TIME);
> > +     time_us = min_t(u32, time_us, RTASE_MITI_MAX_TIME);
> 
> Hi Justin, Andrew, David, all,
> 
> I may be on the wrong track here, but near the top of minmax.h I see:
> 
> /*
>  * min()/max()/clamp() macros must accomplish several things:
>  *
>  * - Avoid multiple evaluations of the arguments (so side-effects like
>  *   "x++" happen only once) when non-constant.
>  * - Perform signed v unsigned type-checking (to generate compile
>  *   errors instead of nasty runtime surprises).
>  * - Unsigned char/short are always promoted to signed int and can be
>  *   compared against signed or unsigned arguments.
>  * - Unsigned arguments can be compared against non-negative signed
> constants.
>  * - Comparison of a signed argument against an unsigned constant fails
>  *   even if the constant is below __INT_MAX__ and could be cast to int.
>  */
> 
> So, considering the 2nd last point, I think we can simply use min() both above
> and below. Which would avoid the possibility of casting to the wrong type again
> in future.
> 
> Also, aside from which call is correct. Please add some colour to the commit
> message describing why this is a bug if it is to be treated as a fix for net rather
> than a clean-up for net-next.
> 
> >
> >       if (time_us > RTASE_MITI_TIME_COUNT_MASK) {
> >               msb = fls(time_us);
> > @@ -1945,7 +1945,7 @@ static u16 rtase_calc_packet_num_mitigation(u16
> pkt_num)
> >       u8 msb, pkt_num_count, pkt_num_unit;
> >       u16 int_miti;
> >
> > -     pkt_num = min_t(int, pkt_num, RTASE_MITI_MAX_PKT_NUM);
> > +     pkt_num = min_t(u16, pkt_num, RTASE_MITI_MAX_PKT_NUM);
> >
> >       if (pkt_num > 60) {
> >               pkt_num_unit = RTASE_MITI_MAX_PKT_NUM_IDX;
> > --
> > 2.34.1
> >

Hi Simon,

According to a more detailed clarification, this part is actually an
enhancement and does not cause any issues during operation, so it is
not a real bug. Therefore, I will post this patch in net-next.

Thanks,
Justin