From: Willy Tarreau <w@1wt.eu>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: linux-kernel@vger.kernel.org, Warner Losh <imp@bsdimp.com>,
Sven Schnelle <svens@linux.ibm.com>
Subject: Re: [PATCH 0/6] pending bug fixes for nolibc
Date: Tue, 10 Jan 2023 08:28:28 +0100 [thread overview]
Message-ID: <20230110072828.GA3229@1wt.eu> (raw)
In-Reply-To: <20230109191141.GT4028633@paulmck-ThinkPad-P17-Gen-1>
Hello Paul,
On Mon, Jan 09, 2023 at 11:11:41AM -0800, Paul E. McKenney wrote:
> On Mon, Jan 09, 2023 at 08:54:36AM +0100, Willy Tarreau wrote:
> > Hello Paul,
> >
> > please consider the current patch series for merging into your fixes queue.
> > The intent is to get them before 6.2, then backported where relevant.
> >
> > It addresses the following bugs:
> > - fd_set was incorrectly defined as arrays of u32 instead of long,
> > which breaks BE64. Fix courtesy of Sven Schnelle.
> >
> > - S_ISxxx macros were incorrectly testing the bits after applying them
> > instead of applying S_ISFMT to the value. Fix from Warner Losh.
> >
> > - the mips code was randomly broken due to an unprotected "noreorder"
> > directive in the _start code that would prevent the assembler from
> > filling delayed slots, and randomly leaving other instructions there
> >
> > - since the split of the single include file into multiple files, we're
> > implicitly refraining from including some which are not explicitly
> > added in the code. It causes build failures when such files contain
> > definitions for functions that may be used e.g. by libgcc, such as
> > raise() or memset(), which are often called only by a few archs at
> > certain optimization levels only.
> >
> > - gcc 11.3 in ARM thumb2 mode at -O2 was able to recognize a memset()
> > construction inside the memset() definition, and it replaced it with
> > a call to... memset(). We cannot impose to userland to build with
> > -ffreestanding so the introduction of an empty asm() statement in
> > the loop was enough to stop this.
> >
> > - most of the O_* macros were wrong on RISCV because their octal value
> > was used as a hexadecimal one when the platform was introduced. This
> > was revealed by the selftest breaking in getdents64().
> >
> > The series was tested on x86_64, i386, armv5, armv7, thumb1, thumb2,
> > mips and riscv, all at -O0, -Os and -O3. This is based on the "nolibc"
> > branch of your linux-rcu tree. Do not hesitate to let me know if you
> > prefer that I rebase it on a different one.
>
> "81 test(s) passed", so queued at urgent-nolibc.2023.01.09a, thank you!
>
> Also, thank you for the detailed cover letter, which I co-opted into the
> signed tag.
You're welcome!
> But please check to make sure that my wordsmithing didn't
> break anything.
It all looks perfect to me.
> If all goes well, I will send the pull request to Linus before the end
> of this week.
Great, thank you!
Willy
prev parent reply other threads:[~2023-01-10 7:32 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-09 7:54 [PATCH 0/6] pending bug fixes for nolibc Willy Tarreau
2023-01-09 7:54 ` [PATCH 1/6] nolibc: fix fd_set type Willy Tarreau
2023-01-09 7:54 ` [PATCH 2/6] tools/nolibc: Fix S_ISxxx macros Willy Tarreau
2023-01-09 7:54 ` [PATCH 3/6] tools/nolibc: restore mips branch ordering in the _start block Willy Tarreau
2023-01-09 7:54 ` [PATCH 4/6] tools/nolibc: fix missing includes causing build issues at -O0 Willy Tarreau
2023-01-09 7:54 ` [PATCH 5/6] tools/nolibc: prevent gcc from making memset() loop over itself Willy Tarreau
2023-01-09 7:54 ` [PATCH 6/6] tools/nolibc: fix the O_* fcntl/open macro definitions for riscv Willy Tarreau
2023-01-09 19:11 ` [PATCH 0/6] pending bug fixes for nolibc Paul E. McKenney
2023-01-10 7:28 ` Willy Tarreau [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230110072828.GA3229@1wt.eu \
--to=w@1wt.eu \
--cc=imp@bsdimp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@kernel.org \
--cc=svens@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox