Re: [PATCH 2/2] time/jiffies: Saturate in mult_hz() instead of wrapping

[Zhan Xusheng]

On Wed, Sep 23, 2026 at 02:27:56PM +0200, Joel Granados wrote:
> Not sure what the difference is but this is the result on my test
> system.
>
>   #  echo 18446744073709552 > /proc/sys/net/ipv4/tcp_keepalive_time
>   -bash: echo: write error: Invalid argument
>   # cat /proc/sys/net/ipv4/tcp_keepalive_time
>   7200
>
> I tested v7.3-rc4. What is your base and did you modify any other sysctl
> before you ran this?

CONFIG_HZ.  My changelog gave a bare number without saying that, sorry.

The value has to exceed ULONG_MAX / HZ for the product to wrap, so it is
HZ specific.  I tested with CONFIG_HZ=1000, where the first wrapping
input is 18446744073709552.  At any lower HZ that same value does not
wrap, the real product exceeds INT_MAX, and proc_int_u2k_conv_uop()
rejects it - which is the EINVAL you saw.  No other sysctl was touched.

	HZ    ULONG_MAX / HZ         first wrapping input   wraps to
	100   184467440737095516     184467440737095517     84
	250   73786976294838206      73786976294838207      134
	300   61489146912365172      61489146912365173      284
	1000  18446744073709551      18446744073709552      384

Measured on v7.3-rc4 with CONFIG_HZ=250, unpatched:

  # cat /proc/sys/net/ipv4/tcp_keepalive_time
  7200
  # echo 73786976294838206 > /proc/sys/net/ipv4/tcp_keepalive_time
  sh: write error: Invalid argument
  # cat /proc/sys/net/ipv4/tcp_keepalive_time
  7200
  # echo 73786976294838207 > /proc/sys/net/ipv4/tcp_keepalive_time
  # cat /proc/sys/net/ipv4/tcp_keepalive_time
  0

One below the threshold is rejected, the one at it is stored as 134
jiffies.  With the patch, same build:

  # cat /proc/sys/net/ipv4/tcp_keepalive_time
  7200
  # echo 73786976294838206 > /proc/sys/net/ipv4/tcp_keepalive_time
  sh: write error: Invalid argument
  # echo 73786976294838207 > /proc/sys/net/ipv4/tcp_keepalive_time
  sh: write error: Invalid argument
  # cat /proc/sys/net/ipv4/tcp_keepalive_time
  7200

tcp_fin_timeout behaves the same.  Legitimate values are unaffected:
7200 reads back as 7200 either way.

I will respin with the threshold written as ULONG_MAX / HZ and the
example labelled with its HZ.