linux-kernel - Re: [PATCH 2/4] tools/nolibc: avoid unused parameter warnings for ENOSYS fallbacks

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: <2bd688b7-5f1b-44ca-a41b-6e90dc3e8557@t-8ch.de>
Date:   Sun, 17 Sep 2023 07:49:57 +0200
From:   Thomas Weißschuh <linux@...ssschuh.net>
To:     Willy Tarreau <w@....eu>
Cc:     Paul Walmsley <paul.walmsley@...ive.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        Shuah Khan <shuah@...nel.org>, linux-kernel@...r.kernel.org,
        linux-riscv@...ts.infradead.org, linux-kselftest@...r.kernel.org
Subject: Re: [PATCH 2/4] tools/nolibc: avoid unused parameter warnings for
 ENOSYS fallbacks

On 2023-09-17 04:58:51+0200, Willy Tarreau wrote:
> On Thu, Sep 14, 2023 at 06:01:18PM +0200, Thomas Weißschuh wrote:
> > The ENOSYS fallback code does not use its functions parameters.
> > This can lead to compiler warnings about unused parameters.
> > 
> > Explicitly avoid these warnings.
> 
> Just out of curiosity, did you find a valid case for enabling this
> warning or were you trying various combinations ? I'm asking because
> I've never seen it enabled anywhere given that it's probably the most 
> useless and unusable warning: as soon as you're dealing with function
> pointers, you start to have multiple functions with a similar
> prototype, some of which just don't need certain arguments, and the
> only way to shut the warning is to significantly uglify the code.

nolibc-test uses it currently and I also used it in some projects.

> If really needed, I'm wondering if instead we shouldn't have an
> "no_syscall*" set of macros, that would have the same signature
> as my_syscall* to just consume all args in the same order and
> return -ENOSYS. E.g, consider the following:
> 
>   @@ -934,6 +960,11 @@ int sys_select(int nfds, fd_set *rfds, fd_set *wfds, fd_set *efds, struct timeva
>    #endif
>    	return my_syscall5(__NR__newselect, nfds, rfds, wfds, efds, timeout);
>    #else
>   +	(void)nfds;
>   +	(void)rfds;
>   +	(void)wfds;
>   +	(void)efds;
>   +	(void)timeout;
>    	return -ENOSYS;
>    #endif
> 
> It would become:
> 
>   @@ -934,6 +960,11 @@ int sys_select(int nfds, fd_set *rfds, fd_set *wfds, fd_set *efds, struct timeva
>    #endif
>    	return my_syscall5(__NR__newselect, nfds, rfds, wfds, efds, timeout);
>    #else
>   +	return no_syscall5(nfds, rfds, wfds, efds, timeout);
>   -	return -ENOSYS;
>    #endif
> 
> What do you think ?

The idea sounds good. But "no_syscall5" sounds a bit non-obvious to me.

Maybe the macro-equivalent of this?

static inline int __nolibc_enosys(...)
{
	return -ENOSYS;
}

The only-vararg function unfortunately needs C23 so we can't use it.

It's clear to the users that this is about ENOSYS and we don't need a
bunch of new macros similar.

I'll check if it is cleaner to implement a generic macro or a few
numbered ones.


Thomas