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: <c8021d03-4da0-4956-8744-4a3a1f8dd533@paulmck-laptop>
Date:   Thu, 13 Apr 2023 10:33:54 -0700
From:   "Paul E. McKenney" <paulmck@...nel.org>
To:     Willy Tarreau <w@....eu>
Cc:     Mark Brown <broonie@...nel.org>,
        Thomas Weißschuh <linux@...ssschuh.net>,
        Shuah Khan <shuah@...nel.org>, linux-kernel@...r.kernel.org,
        linux-kselftest@...r.kernel.org
Subject: Re: [PATCH] tools/nolibc: Fix build of stdio.h due to header ordering

On Thu, Apr 13, 2023 at 07:08:59PM +0200, Willy Tarreau wrote:
> Hi Mark,
> 
> Sorry for this issue, I don't know why it didn't trigger in our tests,
> maybe due to the includes being explicit in the test program.
> 
> On Thu, Apr 13, 2023 at 05:26:32PM +0100, Mark Brown wrote:
> > When we added fd based file streams we created references to STx_FILENO in
> > stdio.h but these constants are declared in unistd.h which is the last file
> > included by the top level nolibc.h meaning those constants are not defined
> > when we try to build stdio.h. This causes programs using nolibc.h to fail
> > to build.
> > 
> > Reorder the headers to avoid this issue.
> > 
> > Fixes: d449546c957f ("tools/nolibc: implement fd-based FILE streams")
> > Signed-off-by: Mark Brown <broonie@...nel.org>
> Acked-by: Willy Tarreau <w@....eu>
> 
> Paul, the commit above is in your rcu/next branch but fortunately not
> in the series you've prepared for 6.4, so it will be sufficient to pick
> it on top of next and you can take it directly if you want.

Queued and pushed, thank you both!

With respect to -next, travel plans next week are causing me to instead
update my rcu/next branch to the merge point of all of this coming
merge window's pull requests.  Though it only makes a difference of a
few days, as I would normally pull rcu/next back the Monday before the
merge window opens.

There is some possibility that I will be off the grid for extended periods
next week, which shouldn't make any difference for nolibc, aside from my
possibly being unresponsive during that time.  The odds of an emergency
fix to last merge window's changes are quite low this late in cycle,
and I will be back before the next merge window opens.

Just let me know what I need to pull in, and I will do that early the
week after this coming one.  Or you can buffer it up and send me one
big series upon my return, your choice.  Either way works for me.  ;-)

							Thanx, Paul

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ