linux-kernel - Re: limits.h in tools/

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <t2n5aj7orslsewknx6vmlf7t4wbnj3u6cabrjjfaptexb64fzn@rbjhcj3uwrkg>
Date: Wed, 24 Apr 2024 09:46:46 -0400
From: "Liam R. Howlett" <Liam.Howlett@...cle.com>
To: Andy Shevchenko <andriy.shevchenko@...el.com>
Cc: Arnaldo Carvalho de Melo <acme@...nel.org>, linux-kernel@...r.kernel.org,
        Willy Tarreau <w@....eu>,
        Thomas Weißschuh <linux@...ssschuh.net>,
        Andrew Morton <akpm@...ux-foundation.org>, willy@...radead.org,
        Namhyung Kim <namhyung@...nel.org>
Subject: Re: limits.h in tools/

* Andy Shevchenko <andriy.shevchenko@...el.com> [240423 15:31]:
> +Cc: Liam, the maintainer of the tool in question.

I maintain the maple.c file in that directory, not the xarray.c one.
xarray is willy, and I depend on some of the functions from the xarray.

> 
> On Tue, Apr 23, 2024 at 10:29:31PM +0300, Andy Shevchenko wrote:
> > On Tue, Apr 23, 2024 at 04:22:01PM -0300, Arnaldo Carvalho de Melo wrote:
> > > On Tue, Apr 23, 2024 at 09:58:07PM +0300, Andy Shevchenko wrote:
> > > > It seems tons of the code in tools include linux/limits.h. But I haven't found
> > > > where do we copy it. Any pointers?
> > > > 
> > > > Based on the discussion 20220603183231.15159C385A9@...p.kernel.org.

I was unable to locate this discussion.

> > > 
> > > ⬢[acme@...lbox perf-tools-next]$ diff -u /usr/include/linux/limits.h include/uapi/linux/limits.h 
> > > --- /usr/include/linux/limits.h	2024-01-31 21:00:00.000000000 -0300
> > > +++ include/uapi/linux/limits.h	2024-02-03 16:18:02.652000641 -0300
> > > @@ -1,6 +1,6 @@
> > >  /* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> > > -#ifndef _LINUX_LIMITS_H
> > > -#define _LINUX_LIMITS_H
> > > +#ifndef _UAPI_LINUX_LIMITS_H
> > > +#define _UAPI_LINUX_LIMITS_H
> > >  
> > >  #define NR_OPEN	        1024
> > >  
> > > ⬢[acme@...lbox perf-tools-next]$
> > > 
> > > And in the places where I test build perf I saw no problem so far, the
> > > build failures below are unrelated, but still outstanding, see below.
> > > 
> > > But then is for building tools/, not the kernel, right? The discussion
> > > you said this question was based on is about changing
> > > include/linux/xarray.h, a kernel file, so should really be including
> > > just kernel headers, files in the kernel source tree, outside tools/, I
> > > don't see where what tools/ uses to build is relevant here? Can you
> > > please elaborate?
> > 
> > I believe the tool in question is tools/testing/radix-tree/xarray.c.

I'm not sure what is being asked.  Are you suggesting that the linux
kernel xarray.h header is including non-kernel headers?  I don't believe
this to be true.

However, the xarray.h tools/testing/radix-tree header certainly pulls in
the kernel version of its header.  The point here is that we want to
test the xarray, so we need to have access to the API, but including it
after setting things up so it will work without the kernel.

The directory you are point to is a testing directory which uses a
combination of kernel headers and custom headers (to avoid pulling in
the entire kernel) to build a test application.  Sometimes the real
headers are used, but other times we are required to write a small
function to do what is expected (eg: allocating kmem_cache objects).

So our tools may include some kernel headers directly, for testing those
functions.  It also includes testing headers where we just need the
defined functionality provided for the testing framework.

Specific to limits.h, if you look in the kernel header, you will see:

#include <uapi/linux/limits.h>

So, most likely, just including the uapi header satisfied the
requirement without pulling in more headers with, potentially, other
issues.  IIRC including the types.h header (also in the kernel limits.h)
caused issues for me in the past.

I hope this helps answer your questions.

Thanks,
Liam