[PATCH RFC net-next 0/3] uapi: Use UAPI definitions of INT_MAX and INT_MIN

[PATCH RFC net-next 0/3] uapi: Use UAPI definitions of INT_MAX and INT_MIN

[Thomas Weißschuh]

Using <limits.h> to gain access to INT_MAX and INT_MIN introduces a
dependency on a libc, which UAPI headers should not do.

Introduce and use equivalent UAPI constants.

Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
Thomas Weißschuh (3):
      uapi: add INT_MAX and INT_MIN constants
      ethtool: uapi: Use UAPI definition of INT_MAX
      netfilter: uapi: Use UAPI definition of INT_MAX and INT_MIN

 include/uapi/linux/ethtool.h          | 7 ++-----
 include/uapi/linux/limits.h           | 3 +++
 include/uapi/linux/netfilter_bridge.h | 9 +++------
 include/uapi/linux/netfilter_ipv4.h   | 9 ++++-----
 include/uapi/linux/netfilter_ipv6.h   | 7 +++----
 5 files changed, 15 insertions(+), 20 deletions(-)
---
base-commit: dbf8fe85a16a33d6b6bd01f2bc606fc017771465
change-id: 20251229-uapi-limits-56c45c9369c9

Best regards,
-- 
Thomas Weißschuh <thomas.weissschuh@linutronix.de>

[PATCH RFC net-next 1/3] uapi: add INT_MAX and INT_MIN constants

[Thomas Weißschuh]

Some UAPI headers use INT_MAX and INT_MIN. Currently they include
<limits.h> for their definitions, which introduces a problematic
dependency on libc.

Add custom, namespaced definitions of INT_MAX and INT_MIN using the
same values as the regular kernel code.

Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
 include/uapi/linux/limits.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/uapi/linux/limits.h b/include/uapi/linux/limits.h
index 6bcbe3068761..35ffa2667309 100644
--- a/include/uapi/linux/limits.h
+++ b/include/uapi/linux/limits.h
@@ -18,4 +18,7 @@
 
 #define RTSIG_MAX	  32
 
+#define __KERNEL_INT_MAX ((int)(~0U >> 1))
+#define __KERNEL_INT_MIN (-__KERNEL_INT_MAX - 1)
+
 #endif

-- 
2.52.0

Re: [PATCH RFC net-next 1/3] uapi: add INT_MAX and INT_MIN constants

[Andrew Lunn]

On Mon, Jan 05, 2026 at 09:26:47AM +0100, Thomas Weißschuh wrote:
> Some UAPI headers use INT_MAX and INT_MIN. Currently they include
> <limits.h> for their definitions, which introduces a problematic
> dependency on libc.
> 
> Add custom, namespaced definitions of INT_MAX and INT_MIN using the
> same values as the regular kernel code.

Maybe a dumb question.

> +#define __KERNEL_INT_MAX ((int)(~0U >> 1))
> +#define __KERNEL_INT_MIN (-__KERNEL_INT_MAX - 1)

How does this work for a 32 bit userspace on top of a 64 bit kernel?

And do we need to be careful with KERNEL in the name, in that for a 32
bit userspace, this is going to be 32bit max int, when in fact the
kernel is using 64 bit max int?

       Andrew

Re: [PATCH RFC net-next 1/3] uapi: add INT_MAX and INT_MIN constants

[Thomas Weißschuh]

On Mon, Jan 05, 2026 at 03:37:14PM +0100, Andrew Lunn wrote:
> On Mon, Jan 05, 2026 at 09:26:47AM +0100, Thomas Weißschuh wrote:
> > Some UAPI headers use INT_MAX and INT_MIN. Currently they include
> > <limits.h> for their definitions, which introduces a problematic
> > dependency on libc.
> > 
> > Add custom, namespaced definitions of INT_MAX and INT_MIN using the
> > same values as the regular kernel code.
> 
> Maybe a dumb question.
> 
> > +#define __KERNEL_INT_MAX ((int)(~0U >> 1))
> > +#define __KERNEL_INT_MIN (-__KERNEL_INT_MAX - 1)
> 
> How does this work for a 32 bit userspace on top of a 64 bit kernel?
>
> And do we need to be careful with KERNEL in the name, in that for a 32
> bit userspace, this is going to be 32bit max int, when in fact the
> kernel is using 64 bit max int?

'int' is always 32 bit on Linux.


Thomas

[PATCH RFC net-next 2/3] ethtool: uapi: Use UAPI definition of INT_MAX

[Thomas Weißschuh]

Using <limits.h> to gain access to INT_MAX introduces a dependency on a
libc, which UAPI headers should not do.

Use the equivalent UAPI constant.

Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
 include/uapi/linux/ethtool.h | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
index eb7ff2602fbb..9500236a9d2e 100644
--- a/include/uapi/linux/ethtool.h
+++ b/include/uapi/linux/ethtool.h
@@ -15,13 +15,10 @@
 #define _UAPI_LINUX_ETHTOOL_H
 
 #include <linux/const.h>
+#include <linux/limits.h>
 #include <linux/types.h>
 #include <linux/if_ether.h>
 
-#ifndef __KERNEL__
-#include <limits.h> /* for INT_MAX */
-#endif
-
 /* All structures exposed to userland should be defined such that they
  * have the same layout for 32-bit and 64-bit userland.
  */
@@ -2200,7 +2197,7 @@ enum ethtool_link_mode_bit_indices {
 
 static inline int ethtool_validate_speed(__u32 speed)
 {
-	return speed <= INT_MAX || speed == (__u32)SPEED_UNKNOWN;
+	return speed <= __KERNEL_INT_MAX || speed == (__u32)SPEED_UNKNOWN;
 }
 
 /* Duplex, half or full. */

-- 
2.52.0

[PATCH RFC net-next 3/3] netfilter: uapi: Use UAPI definition of INT_MAX and INT_MIN

[Thomas Weißschuh]

Using <limits.h> to gain access to INT_MAX and INT_MIN introduces a
dependency on a libc, which UAPI headers should not do.

Use the equivalent UAPI constants.

Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
 include/uapi/linux/netfilter_bridge.h | 9 +++------
 include/uapi/linux/netfilter_ipv4.h   | 9 ++++-----
 include/uapi/linux/netfilter_ipv6.h   | 7 +++----
 3 files changed, 10 insertions(+), 15 deletions(-)

diff --git a/include/uapi/linux/netfilter_bridge.h b/include/uapi/linux/netfilter_bridge.h
index 1610fdbab98d..6ace6c8b211b 100644
--- a/include/uapi/linux/netfilter_bridge.h
+++ b/include/uapi/linux/netfilter_bridge.h
@@ -6,15 +6,12 @@
  */
 
 #include <linux/in.h>
+#include <linux/limits.h>
 #include <linux/netfilter.h>
 #include <linux/if_ether.h>
 #include <linux/if_vlan.h>
 #include <linux/if_pppox.h>
 
-#ifndef __KERNEL__
-#include <limits.h> /* for INT_MIN, INT_MAX */
-#endif
-
 /* Bridge Hooks */
 /* After promisc drops, checksum checks. */
 #define NF_BR_PRE_ROUTING	0
@@ -31,14 +28,14 @@
 #define NF_BR_NUMHOOKS		6
 
 enum nf_br_hook_priorities {
-	NF_BR_PRI_FIRST = INT_MIN,
+	NF_BR_PRI_FIRST = __KERNEL_INT_MIN,
 	NF_BR_PRI_NAT_DST_BRIDGED = -300,
 	NF_BR_PRI_FILTER_BRIDGED = -200,
 	NF_BR_PRI_BRNF = 0,
 	NF_BR_PRI_NAT_DST_OTHER = 100,
 	NF_BR_PRI_FILTER_OTHER = 200,
 	NF_BR_PRI_NAT_SRC = 300,
-	NF_BR_PRI_LAST = INT_MAX,
+	NF_BR_PRI_LAST = __KERNEL_INT_MAX,
 };
 
 #endif /* _UAPI__LINUX_BRIDGE_NETFILTER_H */
diff --git a/include/uapi/linux/netfilter_ipv4.h b/include/uapi/linux/netfilter_ipv4.h
index 155e77d6a42d..e675534b2128 100644
--- a/include/uapi/linux/netfilter_ipv4.h
+++ b/include/uapi/linux/netfilter_ipv4.h
@@ -6,13 +6,12 @@
 #define _UAPI__LINUX_IP_NETFILTER_H
 
 
+#include <linux/limits.h>
 #include <linux/netfilter.h>
 
 /* only for userspace compatibility */
 #ifndef __KERNEL__
 
-#include <limits.h> /* for INT_MIN, INT_MAX */
-
 /* IP Hooks */
 /* After promisc drops, checksum checks. */
 #define NF_IP_PRE_ROUTING	0
@@ -28,7 +27,7 @@
 #endif /* ! __KERNEL__ */
 
 enum nf_ip_hook_priorities {
-	NF_IP_PRI_FIRST = INT_MIN,
+	NF_IP_PRI_FIRST = __KERNEL_INT_MIN,
 	NF_IP_PRI_RAW_BEFORE_DEFRAG = -450,
 	NF_IP_PRI_CONNTRACK_DEFRAG = -400,
 	NF_IP_PRI_RAW = -300,
@@ -41,8 +40,8 @@ enum nf_ip_hook_priorities {
 	NF_IP_PRI_NAT_SRC = 100,
 	NF_IP_PRI_SELINUX_LAST = 225,
 	NF_IP_PRI_CONNTRACK_HELPER = 300,
-	NF_IP_PRI_CONNTRACK_CONFIRM = INT_MAX,
-	NF_IP_PRI_LAST = INT_MAX,
+	NF_IP_PRI_CONNTRACK_CONFIRM = __KERNEL_INT_MAX,
+	NF_IP_PRI_LAST = __KERNEL_INT_MAX,
 };
 
 /* Arguments for setsockopt SOL_IP: */
diff --git a/include/uapi/linux/netfilter_ipv6.h b/include/uapi/linux/netfilter_ipv6.h
index 80aa9b0799af..6be21833f696 100644
--- a/include/uapi/linux/netfilter_ipv6.h
+++ b/include/uapi/linux/netfilter_ipv6.h
@@ -9,13 +9,12 @@
 #define _UAPI__LINUX_IP6_NETFILTER_H
 
 
+#include <linux/limits.h>
 #include <linux/netfilter.h>
 
 /* only for userspace compatibility */
 #ifndef __KERNEL__
 
-#include <limits.h> /* for INT_MIN, INT_MAX */
-
 /* IP6 Hooks */
 /* After promisc drops, checksum checks. */
 #define NF_IP6_PRE_ROUTING	0
@@ -32,7 +31,7 @@
 
 
 enum nf_ip6_hook_priorities {
-	NF_IP6_PRI_FIRST = INT_MIN,
+	NF_IP6_PRI_FIRST = __KERNEL_INT_MIN,
 	NF_IP6_PRI_RAW_BEFORE_DEFRAG = -450,
 	NF_IP6_PRI_CONNTRACK_DEFRAG = -400,
 	NF_IP6_PRI_RAW = -300,
@@ -45,7 +44,7 @@ enum nf_ip6_hook_priorities {
 	NF_IP6_PRI_NAT_SRC = 100,
 	NF_IP6_PRI_SELINUX_LAST = 225,
 	NF_IP6_PRI_CONNTRACK_HELPER = 300,
-	NF_IP6_PRI_LAST = INT_MAX,
+	NF_IP6_PRI_LAST = __KERNEL_INT_MAX,
 };
 
 

-- 
2.52.0

Re: [PATCH RFC net-next 3/3] netfilter: uapi: Use UAPI definition of INT_MAX and INT_MIN

[Arnd Bergmann]

On Mon, Jan 5, 2026, at 09:26, Thomas Weißschuh wrote:
> Using <limits.h> to gain access to INT_MAX and INT_MIN introduces a
> dependency on a libc, which UAPI headers should not do.
>
> Use the equivalent UAPI constants.
>
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>

I agree with the idea of the patch series, but I think this
introduces a different problem:

>  #include <linux/in.h>
> +#include <linux/limits.h>

linux/limits.h is not always clean against limits.h. In glibc,
you can include both in any order, but in musl, you cannot:

gcc -xc /dev/null -nostdinc -I /usr/include/aarch64-linux-musl -include limits.h -include linux/limits.h  -o - -Wall  -c 
In file included from <command-line>:
/usr/include/aarch64-linux-musl/linux/limits.h:7: warning: "NGROUPS_MAX" redefined
    7 | #define NGROUPS_MAX    65536    /* supplemental group IDs are available */
      | 
In file included from <command-line>:
/usr/include/aarch64-linux-musl/limits.h:48: note: this is the location of the previous definition
   48 | #define NGROUPS_MAX 32

I can think of two alternative approaches here:

- put the __KERNEL_INT_MIN into a different header -- either a new one
  or maybe uapi/linux/types.h
- use the compiler's built-in __INT_MIN__ instead of INT_MIN in
  UAPI headers.

On the other hand, there are a few other uapi headers
that already include linux/limits.h:

include/uapi/linux/auto_fs.h:#include <linux/limits.h>
include/uapi/linux/fs.h:#include <linux/limits.h>
include/uapi/linux/netfilter/xt_bpf.h:#include <linux/limits.h>
include/uapi/linux/netfilter/xt_cgroup.h:#include <linux/limits.h>
include/uapi/linux/netfilter/xt_hashlimit.h:#include <linux/limits.h>

     Arnd

Re: [PATCH RFC net-next 3/3] netfilter: uapi: Use UAPI definition of INT_MAX and INT_MIN

[Thomas Weißschuh]

On Mon, Jan 05, 2026 at 02:02:17PM +0100, Arnd Bergmann wrote:
> On Mon, Jan 5, 2026, at 09:26, Thomas Weißschuh wrote:
> > Using <limits.h> to gain access to INT_MAX and INT_MIN introduces a
> > dependency on a libc, which UAPI headers should not do.
> >
> > Use the equivalent UAPI constants.
> >
> > Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> 
> I agree with the idea of the patch series, but I think this
> introduces a different problem:
> 
> >  #include <linux/in.h>
> > +#include <linux/limits.h>
> 
> linux/limits.h is not always clean against limits.h. In glibc,
> you can include both in any order, but in musl, you cannot:
> 
> gcc -xc /dev/null -nostdinc -I /usr/include/aarch64-linux-musl -include limits.h -include linux/limits.h  -o - -Wall  -c 
> In file included from <command-line>:
> /usr/include/aarch64-linux-musl/linux/limits.h:7: warning: "NGROUPS_MAX" redefined
>     7 | #define NGROUPS_MAX    65536    /* supplemental group IDs are available */
>       | 
> In file included from <command-line>:
> /usr/include/aarch64-linux-musl/limits.h:48: note: this is the location of the previous definition
>    48 | #define NGROUPS_MAX 32

Ack.

> I can think of two alternative approaches here:
> 
> - put the __KERNEL_INT_MIN into a different header -- either a new one
>   or maybe uapi/linux/types.h

> - use the compiler's built-in __INT_MIN__ instead of INT_MIN in
>   UAPI headers.

If we can rely on compiler built-ins I would prefer this option.

> On the other hand, there are a few other uapi headers
> that already include linux/limits.h:
> 
> include/uapi/linux/auto_fs.h:#include <linux/limits.h>
> include/uapi/linux/fs.h:#include <linux/limits.h>
> include/uapi/linux/netfilter/xt_bpf.h:#include <linux/limits.h>
> include/uapi/linux/netfilter/xt_cgroup.h:#include <linux/limits.h>
> include/uapi/linux/netfilter/xt_hashlimit.h:#include <linux/limits.h>

...


Thomas

Re: [PATCH RFC net-next 3/3] netfilter: uapi: Use UAPI definition of INT_MAX and INT_MIN

[Thomas Weißschuh]

On Fri, Jan 09, 2026 at 11:20:22AM +0100, Thomas Weißschuh wrote:
> On Mon, Jan 05, 2026 at 02:02:17PM +0100, Arnd Bergmann wrote:
> > On Mon, Jan 5, 2026, at 09:26, Thomas Weißschuh wrote:
> > > Using <limits.h> to gain access to INT_MAX and INT_MIN introduces a
> > > dependency on a libc, which UAPI headers should not do.
> > >
> > > Use the equivalent UAPI constants.
> > >
> > > Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> > 
> > I agree with the idea of the patch series, but I think this
> > introduces a different problem:
> > 
> > >  #include <linux/in.h>
> > > +#include <linux/limits.h>
> > 
> > linux/limits.h is not always clean against limits.h. In glibc,
> > you can include both in any order, but in musl, you cannot:

(...)

> > I can think of two alternative approaches here:
> > 
> > - put the __KERNEL_INT_MIN into a different header -- either a new one
> >   or maybe uapi/linux/types.h
> 
> > - use the compiler's built-in __INT_MIN__ instead of INT_MIN in
> >   UAPI headers.
> 
> If we can rely on compiler built-ins I would prefer this option.

It turns out that the compiler only provides __INT_MAX__, not __INT_MIN__.
We can derive INT_MIN from INT_MAX as done in the original commit, but
open-coding it is ugly as heck. So we are back to a definition in a header
file again.

What about putting them in uapi/linux/types.h or adding a new
uapi/linux/typelimits.h?


Thomas

Re: [PATCH RFC net-next 3/3] netfilter: uapi: Use UAPI definition of INT_MAX and INT_MIN

[Arnd Bergmann]

On Mon, Jan 12, 2026, at 09:06, Thomas Weißschuh wrote:
> On Fri, Jan 09, 2026 at 11:20:22AM +0100, Thomas Weißschuh wrote:
>> On Mon, Jan 05, 2026 at 02:02:17PM +0100, Arnd Bergmann wrote:
>> > 
>> > - put the __KERNEL_INT_MIN into a different header -- either a new one
>> >   or maybe uapi/linux/types.h
>> 
>> > - use the compiler's built-in __INT_MIN__ instead of INT_MIN in
>> >   UAPI headers.
>> 
>> If we can rely on compiler built-ins I would prefer this option.
>
> It turns out that the compiler only provides __INT_MAX__, not __INT_MIN__.
> We can derive INT_MIN from INT_MAX as done in the original commit, but
> open-coding it is ugly as heck. So we are back to a definition in a header
> file again.

Indeed, even gcc's own limits.h does the derivation of each
signed type's limits like

#undef INT_MIN
#define INT_MIN (-INT_MAX - 1)
#undef INT_MAX
#define INT_MAX __INT_MAX__

so it's clearly safe, but open-coding is not very clear.

> What about putting them in uapi/linux/types.h or adding a new
> uapi/linux/typelimits.h?

Those both seem fine to me. Or possibly a netfilter-specific
macro in uapi/linux/netfilter.h, as all three headers that
actually need INT_MIN are all netfilter specific and include
that header already.

      Arnd