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

[Gerd Rausch <gerd.rausch@oracle.com>]

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@oracle.com>
>> Signed-off-by: Gerd Rausch <gerd.rausch@oracle.com>
>> ---
>>   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