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: <ZikVCCJRKImZ3zWB@x1>
Date: Wed, 24 Apr 2024 11:19:52 -0300
From: Arnaldo Carvalho de Melo <acme@...nel.org>
To: "Liam R. Howlett" <Liam.Howlett@...cle.com>
Cc: Andy Shevchenko <andriy.shevchenko@...el.com>,
	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/

On Wed, Apr 24, 2024 at 09:46:46AM -0400, Liam R. Howlett wrote:
> * 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.

I managed to do it by using:

  https://lkml.kernel.org/r/ + that Message-ID, i.e.:

https://lkml.kernel.org/r/20220603183231.15159C385A9@smtp.kernel.org.
 
> > > > 
> > > > ⬢[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