All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: Nathan Lynch <nathanl@linux.ibm.com>,
	"linuxppc-dev@ozlabs.org" <linuxppc-dev@ozlabs.org>,
	Vincenzo Frascino <vincenzo.frascino@arm.com>,
	Andreas Schwab <schwab@linux-m68k.org>
Subject: Re: passing NULL to clock_getres (VDSO): terminated by unexpected signal 11
Date: Sun, 20 Oct 2019 13:44:37 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.21.1910201243580.2090@nanos.tec.linutronix.de> (raw)
In-Reply-To: <b64c367b-d1e5-bf26-d452-145c0be6e30a@c-s.fr>

[-- Attachment #1: Type: text/plain, Size: 2052 bytes --]

On Sun, 20 Oct 2019, Christophe Leroy wrote:
> Adding Thomas to the discussion as the commit is from him.
> 
> Le 20/10/2019 à 11:53, Andreas Schwab a écrit :
> > On Okt 20 2019, Christophe Leroy <christophe.leroy@c-s.fr> wrote:
> > 
> > > Le 19/10/2019 à 21:18, Andreas Schwab a écrit :
> > > > On Okt 19 2019, Christophe Leroy <christophe.leroy@c-s.fr> wrote:
> > > > 
> > > > > Hi Nathan,
> > > > > 
> > > > > While trying to switch powerpc VDSO to C version of gettimeofday(),
> > > > > I'm
> > > > > getting the following kind of error with vdsotest:
> > > > > 
> > > > > passing NULL to clock_getres (VDSO): terminated by unexpected signal
> > > > > 11
> > > > > 
> > > > > Looking at commit a9446a906f52 ("lib/vdso/32: Remove inconsistent NULL
> > > > > pointer checks"), it seems that signal 11 is expected when passing
> > > > > NULL
> > > > > pointer.
> > > > > 
> > > > > Any plan to fix vdsotest ?
> > > > 
> > > > Passing NULL to clock_getres is valid, and required to return
> > > > successfully if the clock id is valid.
> > > > 
> > > 
> > > Do you mean the following commit is wrong ?
> > > 
> > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/lib/vdso?id=a9446a906f52292c52ecbd5be78eaa4d8395756c
> > 
> > If it causes a valid call to clock_getres to fail, then yes.

clock_getres(NULL) is hardly valid.

Fact is that 64bit did never check the pointer and unconditionally let the
NULL pointer dereference happen.

Also as documented in the change log, the vdso _cannot_ ever be fully
equivalent to the syscall.

The simple example:

    struct timespec *ts = (struct timespec *) 0xFF;

    clock_getres(clock, ts);

will fault in the VDSO, but not in the syscall.

VDSO can never ever guarantee that any of the clock_* functions will return
EFAULT if the provided pointer points outside of the accessible address
space, is mapped RO etc.

So special casing

    clock_getres(clock, NULL);

just to make a test case happy is a pointless exercise which does not make
any sense at all.

Thanks,

	tglx


  reply	other threads:[~2019-10-20 11:47 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <0fc22a08-31d9-e4d1-557e-bf5b482a9a20__6444.28012180782$1571503753$gmane$org@c-s.fr>
2019-10-19 19:18 ` passing NULL to clock_getres (VDSO): terminated by unexpected signal 11 Andreas Schwab
2019-10-20  9:20   ` Christophe Leroy
2019-10-20  9:53     ` Andreas Schwab
2019-10-20 10:25       ` Christophe Leroy
2019-10-20 11:44         ` Thomas Gleixner [this message]
2019-10-20 12:07           ` Andreas Schwab
2019-10-20 15:45             ` Thomas Gleixner
2019-10-20 16:08               ` Andreas Schwab
2019-10-20 19:53                 ` Thomas Gleixner
2019-10-20 21:17                   ` Andreas Schwab
2019-10-21 10:07                     ` [PATCH] lib/vdso: Make clock_getres() POSIX compliant again Thomas Gleixner
2019-10-21 10:07                       ` Thomas Gleixner
2019-10-21 15:23                       ` Christophe Leroy
2019-10-23 12:50                       ` [tip: timers/urgent] " tip-bot2 for Thomas Gleixner
2019-10-21  9:03                   ` passing NULL to clock_getres (VDSO): terminated by unexpected signal 11 David Laight
2019-10-19 16:46 Christophe Leroy
2019-10-28 15:46 ` Nathan Lynch
2019-10-28 15:50   ` Christophe Leroy

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=alpine.DEB.2.21.1910201243580.2090@nanos.tec.linutronix.de \
    --to=tglx@linutronix.de \
    --cc=christophe.leroy@c-s.fr \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=nathanl@linux.ibm.com \
    --cc=schwab@linux-m68k.org \
    --cc=vincenzo.frascino@arm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.