public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: David Laight <David.Laight@ACULAB.COM>
Cc: "'Zhangjin Wu'" <falcon@tinylab.org>,
	"arnd@arndb.de" <arnd@arndb.de>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-kselftest@vger.kernel.org"
	<linux-kselftest@vger.kernel.org>,
	"thomas@t-8ch.de" <thomas@t-8ch.de>
Subject: Re: [PATCH v5] tools/nolibc: fix up size inflate regression
Date: Mon, 14 Aug 2023 14:09:41 +0200	[thread overview]
Message-ID: <20230814120941.GA18837@1wt.eu> (raw)
In-Reply-To: <6fef903020954515abdcee7261918903@AcuMS.aculab.com>

Hi David,

On Mon, Aug 14, 2023 at 11:15:51AM +0000, David Laight wrote:
> From: Zhangjin Wu
> > Sent: 14 August 2023 11:42
> ...
> > [...]
> > > > > Sure it's not pretty, and I'd rather just go back to SET_ERRNO() to be
> > > > > honest, because we're there just because of the temptation to remove
> > > > > lines that were not causing any difficulties :-/
> > > > >
> > > > > I think we can do something in-between and deal only with signed returns,
> > > > > and explicitly place the test for MAX_ERRNO on the two unsigned ones
> > > > > (brk and mmap). It should look approximately like this:
> > > > >
> > > > >  #define __sysret(arg)                                                \
> > > > >  ({                                                                   \
> > > > >  	__typeof__(arg) __sysret_arg = (arg);                           \
> > > > >  	(__sysret_arg < 0) ? ({           /* error ? */                 \
> > > > >  		SET_ERRNO(-__sysret_arg); /* yes: errno != -ret */      \
> > > > >  		((__typeof__(arg)) -1);   /*      return -1 */          \
> 
> I'm pretty sure you don't need the explicit cast.
> (It would be needed for a pointer type.)
> Can you use __arg < ? SET_ERRNO(-__arg), -1 : __arg
> 
> Thinking, maybe it should be:
> 
> #define __sysret(syscall_fn_args)
> ({
> 	__typeof__(syscall_fn_args) __rval = syscall_fn_args;
> 	__rval >= 0 ? __rval : SET_ERRNO(-__rval), -1;
> })

Yeah almost, since arg is necessarily signed in this version, it's
just that I manually edited the previous macro in the mail and limited
the amount of changes to what was necessary. It's just that SET_ERRNO
only is an instruction, not an expression:

   #define SET_ERRNO(v) do { errno = (v); } while (0)

Thus the return value doesn't even pass through it. That's why it was
so much simpler before. The rationale behind this was to bring the
ability to completely drop errno for programs where you didn't care
about it. It's particularly interesting when you don't need any other
data either as the program gets strunk from a complete section.

> Since, IIRC, the usage is return __sysret(sycall_fn(args));
 
> I'm not sure how public SET_ERRO() is.

For now it is entirely, though it's not supposed to. Thomas and I
have been discussing about renaming some internal-use macros and
functions to avoid needlessly exposing them by accident to the
application. These one definitely qualifies.

> But it could include the negate have the value of -1 cast to its argument type?
> I think:
> 	error = -(int)(long)(arg + 0u);
> will avoid any sign extension - the (int) might not even be needed.

So with a signed (int/long) input and errno as int, I don't think
we can have any case where there's any such extension anyway. In
any case we're either copying the int as-is or truncating it.

Regards,
Willy

  reply	other threads:[~2023-08-14 12:11 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-07 20:04 [PATCH v5] tools/nolibc: fix up size inflate regression Zhangjin Wu
2023-08-08 18:49 ` Willy Tarreau
2023-08-09 22:17   ` Zhangjin Wu
2023-08-13  8:51     ` Willy Tarreau
2023-08-13 13:26       ` Zhangjin Wu
2023-08-14  8:22         ` Willy Tarreau
2023-08-14 10:42           ` Zhangjin Wu
2023-08-14 11:15             ` David Laight
2023-08-14 12:09               ` Willy Tarreau [this message]
2023-08-14 12:27                 ` David Laight
2023-08-14 13:22                   ` Willy Tarreau
2023-08-14 14:18                     ` Zhangjin Wu
2023-08-14 15:03                       ` Zhangjin Wu
2023-08-14 17:22             ` Zhangjin Wu

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=20230814120941.GA18837@1wt.eu \
    --to=w@1wt.eu \
    --cc=David.Laight@ACULAB.COM \
    --cc=arnd@arndb.de \
    --cc=falcon@tinylab.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=thomas@t-8ch.de \
    /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