Re: [PATCH 1/1] time/jiffies: Fix conversion breakage on systems where USER_HZ < HZ

[Gerd Rausch]

Hi Joel,

On 2026-02-27 06:31, Joel Granados wrote:
> On Wed, Feb 25, 2026 at 03:37:49PM -0800, Gerd Rausch wrote:
> > Conversion from user_hz to jiffies broke with
> The internal kernel conversion itself is unchanged, it is informing user
> space about this conversion that broke. Right? In other words, you get
> an error when you read a sysctl file instead of an incorrect converted
> value.
>
> > commit 2dc164a48e6fd ("sysctl: Create converter functions with two new macros")
> >
> > because the old overflow check in do_proc_dointvec_userhz_jiffies_conv()
> > to see if "*u_ptr" was too large got replaced by an unconditional:
> >      +    if (USER_HZ < HZ)
> >      +        return -EINVAL;
> >
> > which will always be true on platforms with "USER_HZ < HZ".
> >
> > We shouldn't need this extra check anyway, because clock_t_to_jiffies()
> > returns ULONG_MAX for the overflow case:
> >      if (x >= ~0UL / (HZ / USER_HZ))
> >          return ~0UL;
> >
> > and proc_int_u2k_conv_uop() checks for "> INT_MAX" after conversion:
> >      if (u > (ulong) INT_MAX)
> >          return -EINVAL;
> >
> > Fixes: 2dc164a48e6fd ("sysctl: Create converter functions with two new macros")
> > Reported-by: Colm Harrington <colm.harrington@xxxxxxxxxx>
> > Signed-off-by: Gerd Rausch <gerd.rausch@xxxxxxxxxx>
> > ---
> >   kernel/time/jiffies.c | 2 --
> >   1 file changed, 2 deletions(-)
> >
> > diff --git a/kernel/time/jiffies.c b/kernel/time/jiffies.c
> > index a5c7d15fce72..9daf8c5d9687 100644
> > --- a/kernel/time/jiffies.c
> > +++ b/kernel/time/jiffies.c
> > @@ -256,8 +256,6 @@ EXPORT_SYMBOL(proc_dointvec_jiffies);
> >   int proc_dointvec_userhz_jiffies(const struct ctl_table *table, int dir,
> >   				 void *buffer, size_t *lenp, loff_t *ppos)
> >   {
> > -	if (SYSCTL_USER_TO_KERN(dir) && USER_HZ < HZ)
> > -		return -EINVAL;
> This fix looks good. I'll put it in next to see if it breaks anything.
>
> >   	return proc_dointvec_conv(table, dir, buffer, lenp, ppos,
> >   				  do_proc_int_conv_userhz_jiffies);
> >   }
> > --
> > 2.39.3
>
> How did you see the bug? Was it trying to read a sysctl file?

My colleague Colm (mentioned under "Reported-by:") saw it:
--------%<--------%<--------%<--------%<--------%<--------%<--------
[root@somemachine]# sysctl -w net.ipv4.neigh.re1.locktime=0
sysctl: setting key "net.ipv4.neigh.re1.locktime": Invalid argument
--------%<--------%<--------%<--------%<--------%<--------%<--------

Thanks,

  Gerd