Subject: Re: [PATCH net-next v2 03/17] net: stmmac: use correct type for tx_lpi_timer

From: "Russell King (Oracle)" <[email-masked]>
Date: Tue, 7 Jan 2025 15:26:06 +0000

On Tue, Jan 07, 2025 at 02:41:03PM +0000, Simon Horman wrote:
> On Tue, Jan 07, 2025 at 11:57:12AM +0000, Russell King (Oracle) wrote:
> > On Tue, Jan 07, 2025 at 11:28:51AM +0000, Simon Horman wrote:
> > > On Mon, Jan 06, 2025 at 12:24:58PM +0000, Russell King (Oracle) wrote:
> > > > The ethtool interface uses u32 for tx_lpi_timer, and so does phylib.
> > > > Use u32 to store this internally within stmmac rather than "int"
> > > > which could misinterpret large values.
> > > > 
> > > > Since eee_timer is used to initialise priv->tx_lpi_timer, this also
> > > > should be unsigned to avoid a negative number being interpreted as a
> > > > very large positive number.
> > > > 
> > > > Also correct "value" in dwmac4_set_eee_lpi_entry_timer() to use u32
> > > > rather than int, which is derived from tx_lpi_timer, even though
> > > > masking with STMMAC_ET_MAX will truncate the sign bits. u32 is the
> > > > value argument type for writel().
> > > > 
> > > > Signed-off-by: Russell King (Oracle) <[email-masked]>
> > > 
> > > ...
> > > 
> > > > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> > > > index 9a9169ca7cd2..b0ef439b715b 100644
> > > > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> > > > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> > > > @@ -111,8 +111,8 @@ static const u32 default_msg_level = (NETIF_MSG_DRV | NETIF_MSG_PROBE |
> > > >  				      NETIF_MSG_IFDOWN | NETIF_MSG_TIMER);
> > > >  
> > > >  #define STMMAC_DEFAULT_LPI_TIMER	1000
> > > > -static int eee_timer = STMMAC_DEFAULT_LPI_TIMER;
> > > > -module_param(eee_timer, int, 0644);
> > > > +static unsigned int eee_timer = STMMAC_DEFAULT_LPI_TIMER;
> > > > +module_param(eee_timer, uint, 0644);
> > > >  MODULE_PARM_DESC(eee_timer, "LPI tx expiration time in msec");
> > > >  #define STMMAC_LPI_T(x) (jiffies + usecs_to_jiffies(x))
> > > >  
> > > 
> > > Hi Russell,
> > > 
> > > now that eee_timer is unsigned the following check in stmmac_verify_args()
> > > can never be true. I guess it should be removed.
> > > 
> > >         if (eee_timer < 0)
> > >                 eee_timer = STMMAC_DEFAULT_LPI_TIMER;
> > > 
> > 
> > Thanks for finding that. The parameter description doesn't seem to
> > detail whether this is intentional behaviour or not, or whether it is
> > "because someone used int and we shouldn't have negative values here".
> > 
> > I can't see why someone would pass a negative number for eee_timer
> > given that it already defaults to STMMAC_DEFAULT_LPI_TIMER.
> > 
> > So, I'm tempted to remove this.
> 
> I'm not sure either. It did cross my mind that the check could be changed,
> to disallow illegal values (if the range of legal values is not all
> possible unsigned integer values). But it was just an idea without any
> inspection of the code or thought about it's practicality. And my first
> instinct was the same as yours: remove the check.

My reasoning is as follows:

In the existing code with the module paramter is a signed int, then it
take a value up to INT_MAX. Provided sizeof(int) == sizeof(u32), then
this can be reported through the ethtool API. However, ethtool can set
the timer to U32_MAX which can exceed INT_MAX in this case. The driver
doesn't stop this, and uses a software based timer for any delay greater
than the capabilities of the hardware timer (if any.)

So, through ethtool one can set the LPI delay to anything between 0 and
U32_MAX, whereas through the module parameter it's between 0 and
INT_MAX. values between INT_MIN and -1 inclusive result in the default
being used.

It is, of course, absurd to have a negative delay, or even a delay
anywhere near INT_MAX or U32_MAX.

I'll separate out the change to eee_timer so if necessary, that can be
reverted without reverting the entire patch. Oh goodo, an extra patch
for a patchset which already exceeds netdev's 15 patches...

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!