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

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

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

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