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

Message-ID: <580bf2db57cefa07631e73e5af453228cfb3cecb.camel@redhat.com>
Date: Tue, 05 Aug 2025 08:18:46 +0200
From: Gabriele Monaco <gmonaco@...hat.com>
To: Palmer Dabbelt <palmer@...belt.com>, rostedt@...dmis.org, 
	namcao@...utronix.de
Cc: 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 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?

I'm not sure if we can get the compiler rid of it completely, but it's
probably not worth it.

What do you think?

Thanks,
Gabriele

> ---
>  kernel/trace/rv/monitors/sleep/sleep.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/kernel/trace/rv/monitors/sleep/sleep.c
> b/kernel/trace/rv/monitors/sleep/sleep.c
> index eea447b06907..c1347da69e9d 100644
> --- a/kernel/trace/rv/monitors/sleep/sleep.c
> +++ b/kernel/trace/rv/monitors/sleep/sleep.c
> @@ -127,7 +127,9 @@ static void handle_sys_enter(void *data, struct
> pt_regs *regs, long id)
>  	mon = ltl_get_monitor(current);
>  
>  	switch (id) {
> +#ifdef __NR_clock_nanosleep
>  	case __NR_clock_nanosleep:
> +#endif
>  #ifdef __NR_clock_nanosleep_time64
>  	case __NR_clock_nanosleep_time64:
>  #endif
> @@ -138,7 +140,9 @@ static void handle_sys_enter(void *data, struct
> pt_regs *regs, long id)
>  		ltl_atom_update(current, LTL_CLOCK_NANOSLEEP, true);
>  		break;
>  
> +#ifdef __NR_futex
>  	case __NR_futex:
> +#endif
>  #ifdef __NR_futex_time64
>  	case __NR_futex_time64:
>  #endif