public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

      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