linux-kernel - Re: [PATCH] rv: Support systems with time64-only syscalls

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] [day] [month] [year] [list]

Message-ID: <20250805121250.XhObb6Oq@linutronix.de>
Date: Tue, 5 Aug 2025 14:12:50 +0200
From: Nam Cao <namcao@...utronix.de>
To: Gabriele Monaco <gmonaco@...hat.com>
Cc: Palmer Dabbelt <palmer@...belt.com>, rostedt@...dmis.org,
	mhiramat@...nel.org, mathieu.desnoyers@...icios.com,
	linux-trace-kernel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] rv: Support systems with time64-only syscalls

On Tue, Aug 05, 2025 at 08:18:46AM +0200, Gabriele Monaco wrote:
> On Mon, 2025-08-04 at 12:45 -0700, Palmer Dabbelt wrote:
> > From: Palmer Dabbelt <palmer@...belt.com>
> > 
> > Some systems (like 32-bit RISC-V) only have the 64-bit time_t
> > versions of syscalls.  So handle the 32-bit time_t version of those
> > being undefined.
> > 
> > Fixes: f74f8bb246cf ("rv: Add rtapp_sleep monitor")
> > Signed-off-by: Palmer Dabbelt <palmer@...belt.com>
> > ---
> > This seems a little ugly, as it'll blow up when neither is defined. 
> > Some #if/#error type stuff seemed uglier, though, and that's the best
> > I could come up with.  I figure anyone without either flavor of futex
> > call is probably deep enough in the weeds to just figure what blows
> > up here...
> 
> Yeah, this is getting ugly.. I wasn't fun of this ifdeffery already but
> a few of them seemed acceptable, if we are really expecting any single
> one of them to potentially not be available, it isn't looking good.
> 
> What about doing in the beginning of the file something like:
> 
> /*
>  * Define dummy syscall numbers for systems not supporting them
>  */
> 
> #ifndef __NR_whatever
> #define __NR_whatever -1
> #endif
> 
> #ifndef __NR_some_exotic_syscall
> #define __NR_some_exotic_syscall -2
> #endif
> 
> The negative number would never match, we may add a mostly
> insignificant overhead checking for it but we keep the function
> readable. What do you think?

That would be much better, but the patch is fine as is, so I'm okay with
merging it:

Acked-by: Nam Cao <namcao@...utronix.de>

The patch is just matching the existing ugly #ifdef style (I wonder who
even wrote that). So cleaning it up can be done in a follow-up patch.

Nam