Linux Test Project
 help / color / mirror / Atom feed
From: Cyril Hrubis <chrubis@suse.cz>
To: Petr Vorel <pvorel@suse.cz>
Cc: Hui Min Mina Chou <minachou@andestech.com>,
	tim609@andestech.com, cynthia@andestech.com, ltp@lists.linux.it
Subject: Re: [LTP] [PATCH] syscalls/setitimer: Pass the kernel-defined struct __kernel_old_itimerval to sys_setitimer().
Date: Mon, 13 May 2024 17:39:27 +0200	[thread overview]
Message-ID: <ZkI0L9xkrsJ-mhPN@yuki> (raw)
In-Reply-To: <20240510153103.GA448405@pevik>

Hi!
> @Cyril the original code prior this patchset in 203ee275c ("Fix struct
> __kernel_old_timeval redefinition on 64bit sparc") did not include
> <linux/time_types.h> for some reason IMHO fallbacks were always used.
> I wonder why and whether we still don't want to use <linux/time_types.h>.

I suppose that this is broken on some old distro, try to run that
through CI and if that passes we can do so.

> Then Fabrice's fix in 12986b755 ("include/tst_timer.h: avoid redefinition of
> kernel structures") add autotools check just for uncommon toolchain (sh4 from
> Texas Instruments). It's somehow hidden (due missing comment it looks like we
> mostly get the definitions from header, but obviously not when we include
> <sys/socket.h>.

I guess that it depends on architecture/libc/kernel headers and it's a
big mess...

> >  AC_CHECK_TYPES([struct futex_waitv],,,[#include <linux/futex.h>])
> >  AC_CHECK_TYPES([struct mount_attr],,,[
> > diff --git a/include/tst_timer.h b/include/tst_timer.h
> > index 703f03294eae..6fb9400206b8 100644
> > --- a/include/tst_timer.h
> > +++ b/include/tst_timer.h
> > @@ -135,6 +135,13 @@ struct __kernel_itimerspec {
> >  	struct __kernel_timespec it_value;       /* timer expiration */
> >  };
> >  #endif
> > +
> > +#ifndef HAVE_STRUCT___KERNEL_OLD_ITIMERVAL
> > +struct __kernel_old_itimerval {
> > +	struct __kernel_old_timeval it_interval;	/* timer interval */
> > +	struct __kernel_old_timeval it_value;		/* current value */
> > +};
> > +#endif
> >  #endif


I've been staring at the kernel and libc code for a while and it seems
that there is not itimerval64 syscall and interval timers are limited to
32bit on 32bit architectures. In reality I suppose that it does not
matter since nobody is going to use intervals that actually need 64bit
amount of seconds anyways.

So libc takes 64bit itimer, converts it to 32bit and kernel does
the oposite conversion.

Also we should really add tests for the libc wrapper as well, since that
is actually more likely to get broken by the double conversion on 32bit
arch, but that should be done in an subsequent patches.

> >  enum tst_ts_type {
> > @@ -370,6 +377,11 @@ static inline int sys_timerfd_settime64(int fd, int flags, void *its,
> >  	return tst_syscall(__NR_timerfd_settime64, fd, flags, its, old_its);
> >  }
> 
> > +static inline int sys_setitimer(int which, void *new_value, void *old_value)
> > +{
> > +	return tst_syscall(__NR_setitimer, which, new_value, old_value);
> > +}
> C
> +1 adding function to the common place.
> 
> IMHO we slightly prefer to add C functions to C file (e.g. lib/tst_timer.c,
> there are other functions) + adding signature to tst_timer.h.

I would say that there is no point to do that for a single line fuctions
like this and actually I guess that this would break the line numbers
and filenames for the tst_sycall() so it's better this way.

So for the patch as it is:

Reviewed-by: Cyril Hrubis <chrubis@suse.cz>

-- 
Cyril Hrubis
chrubis@suse.cz

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

  reply	other threads:[~2024-05-13 15:40 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-28  8:33 [LTP] [PATCH] syscalls/setitimer: Pass the kernel-defined struct __kernel_old_itimerval to sys_setitimer() Hui Min Mina Chou via ltp
2024-05-10 15:31 ` Petr Vorel
2024-05-13 15:39   ` Cyril Hrubis [this message]
2024-05-15  7:21     ` Petr Vorel
2024-05-15  7:30       ` Petr Vorel

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=ZkI0L9xkrsJ-mhPN@yuki \
    --to=chrubis@suse.cz \
    --cc=cynthia@andestech.com \
    --cc=ltp@lists.linux.it \
    --cc=minachou@andestech.com \
    --cc=pvorel@suse.cz \
    --cc=tim609@andestech.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