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: <whrf4yfvi5oea2kw7mw6rjmuxh4vg45wi7ucg7j4iowufp2tav@mnqgaq6lpd64>
Date: Wed, 24 Apr 2024 10:40:40 -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> [240424 10:19]:
..

> > > 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.
> 
>   `b4 mbox 20220603183231.15159C385A9@...p.kernel.org`
> 
> works for me
> 
> $ b4 mbox 20220603183231.15159C385A9@...p.kernel.org
> Grabbing thread from lore.kernel.org/all/20220603183231.15159C385A9@...p.kernel.org/t.mbox.gz
> 8 messages in the thread
> Saved ./20220603183231.15159C385A9@...p.kernel.org.mbx

Interesting, I usually use the web search for the id and that failed me
in this case.  I use b4 for patch fetching and reviewing.

> 
> > > > > ⬢[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.
> 
> No. The problem here that tooling relies basically on the external limitsh.
> I.o.w. from the current user space.

Indeed this is the case.  I verified with an ifndef, error in main.c and
we seem to be using the non-uapi version.

maple.c also depends on external libraries (userspace rcu) being
installed, so I'm not entirely sure how isolated we need the testing to
be as they are not shipped or built besides by developers (and bots) to
test the functionality in userspace.

As for limits.h, we can probably migrate to the uapi version but I don't
really see a reason.

Thanks,
Liam