mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Lucas Stach <l.stach@pengutronix.de>
To: Arnd Bergmann <arnd@arndb.de>
Cc: "Guido Günther" <agx@sigxcpu.org>,
	"Philipp Zabel" <p.zabel@pengutronix.de>,
	"y2038 Mailman List" <y2038@lists.linaro.org>,
	"The etnaviv authors" <etnaviv@lists.freedesktop.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"David Airlie" <airlied@linux.ie>,
	"Christian Gmeiner" <christian.gmeiner@gmail.com>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"Russell King" <linux+etnaviv@armlinux.org.uk>,
	"Emil Velikov" <emil.velikov@collabora.com>,
	"Sam Ravnborg" <sam@ravnborg.org>
Subject: Re: [PATCH v2 13/24] drm/etnaviv: reject timeouts with tv_nsec >= NSEC_PER_SEC
Date: Tue, 21 Jan 2020 11:21:56 +0100	[thread overview]
Message-ID: <8d86fcb526ee14c7e6c80a787db645192c2c7c33.camel@pengutronix.de> (raw)
In-Reply-To: <CAK8P3a3hyDeskg0ix=1+yNihqacZ5rqsXaHbRsBfPt7zFr8EOw@mail.gmail.com>

On Mo, 2020-01-20 at 19:47 +0100, Arnd Bergmann wrote:
> On Mon, Jan 20, 2020 at 6:48 PM Lucas Stach <l.stach@pengutronix.de> wrote:
> > On Fr, 2020-01-17 at 16:47 +0100, Guido Günther wrote:
> > > This breaks rendering here on arm64/gc7000 due to
> > > 
> > > ioctl(6, DRM_IOCTL_ETNAVIV_GEM_CPU_PREP or DRM_IOCTL_MSM_GEM_CPU_PREP, 0xfffff7888680) = -1 EINVAL (Invalid argument)
> > > ioctl(6, DRM_IOCTL_ETNAVIV_GEM_CPU_FINI or DRM_IOCTL_QXL_CLIENTCAP, 0xfffff78885e0) = 0
> > > ioctl(6, DRM_IOCTL_ETNAVIV_GEM_CPU_PREP or DRM_IOCTL_MSM_GEM_CPU_PREP, 0xfffff7888680) = -1 EINVAL (Invalid argument)
> > > ioctl(6, DRM_IOCTL_ETNAVIV_GEM_CPU_FINI or DRM_IOCTL_QXL_CLIENTCAP, 0xfffff78885e0) = 0
> > > ioctl(6, DRM_IOCTL_ETNAVIV_GEM_CPU_PREP or DRM_IOCTL_MSM_GEM_CPU_PREP, 0xfffff7888680) = -1 EINVAL (Invalid argument)
> > > ioctl(6, DRM_IOCTL_ETNAVIV_GEM_CPU_FINI or DRM_IOCTL_QXL_CLIENTCAP, 0xfffff78885e0) = 0
> > > 
> > > This is due to
> > > 
> > >     get_abs_timeout(&req.timeout, 5000000000);
> > > 
> > > in etna_bo_cpu_prep which can exceed NSEC_PER_SEC.
> > > 
> > > Should i send a patch to revert that change since it breaks existing userspace?
> > 
> > No need to revert. This patch has not been applied to the etnaviv tree
> > yet, I guess it's just in one of Arnds branches feeding into -next.
> > 
> > That part of userspace is pretty dumb, as it misses to renormalize
> > tv_nsec when it overflows the second boundary. So if what I see is
> > correct it should be enough to allow 2 * NSEC_PER_SEC, which should
> > both reject broken large timeout and keep existing userspace working.
> 
> Ah, so it's never more than 2 billion nanoseconds in known user space?
> I can definitely change my patch (actually add one on top) to allow that
> and handle it as before, or alternatively accept any 64-bit nanosecond value
> as arm64 already did, but make it less inefficient to handle.

So the broken userspace code looks like this:

static inline void get_abs_timeout(struct drm_etnaviv_timespec *tv, uint64_t ns)
{
        struct timespec t;
        uint32_t s = ns / 1000000000;
        clock_gettime(CLOCK_MONOTONIC, &t);
        tv->tv_sec = t.tv_sec + s;
        tv->tv_nsec = t.tv_nsec + ns - (s * 1000000000);
}

Which means it _tries_ to do the right thing by putting the billion
part into the tv_sec member and only the remaining ns part is added to
tv_nsec, but then it fails to propagate a tv_nsec overflow over
NSEC_PER_SEC into tv_sec.

Which means the tv_nsec should never be more than 2 * NSEC_PER_SEC in
known userspace. I would prefer if we could make the interface as
strict as possible (i.e. no arbitrary large numbers in tv_nsec), while
keeping this specific corner case working.

Regards,
Lucas


  reply	other threads:[~2020-01-21 10:22 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-13 20:49 [PATCH v2 00/24] drivers, fs: y2038 updates Arnd Bergmann
2019-12-13 20:49 ` [PATCH v2 01/24] Input: input_event: fix struct padding on sparc64 Arnd Bergmann
2019-12-13 22:08   ` Dmitry Torokhov
2019-12-13 20:49 ` [PATCH v2 02/24] fat: use prandom_u32() for i_generation Arnd Bergmann
2019-12-13 20:49 ` [PATCH v2 03/24] dlm: use SO_SNDTIMEO_NEW instead of SO_SNDTIMEO_OLD Arnd Bergmann
2019-12-13 20:52 ` [PATCH v2 04/24] xtensa: ISS: avoid struct timeval Arnd Bergmann
2019-12-13 20:52 ` [PATCH v2 05/24] um: ubd: use 64-bit time_t where possible Arnd Bergmann
2019-12-13 20:52 ` [PATCH v2 06/24] acct: stop using get_seconds() Arnd Bergmann
2019-12-13 20:52 ` [PATCH v2 07/24] tsacct: add 64-bit btime field Arnd Bergmann
2019-12-13 20:52 ` [PATCH v2 08/24] packet: clarify timestamp overflow Arnd Bergmann
2019-12-13 20:52 ` [PATCH v2 09/24] quota: avoid time_t in v1_disk_dqblk definition Arnd Bergmann
2019-12-16 13:14   ` Jan Kara
2019-12-13 20:53 ` [PATCH v2 10/24] hostfs: pass 64-bit timestamps to/from user space Arnd Bergmann
2019-12-13 20:53 ` [PATCH v2 11/24] hfs/hfsplus: use 64-bit inode timestamps Arnd Bergmann
2019-12-13 20:53 ` [PATCH v2 12/24] drm/msm: avoid using 'timespec' Arnd Bergmann
2019-12-13 20:53 ` [PATCH v2 13/24] drm/etnaviv: reject timeouts with tv_nsec >= NSEC_PER_SEC Arnd Bergmann
2020-01-08  1:16   ` [Y2038] " Ben Hutchings
2020-01-17 15:47   ` Guido Günther
2020-01-20 17:47     ` Lucas Stach
2020-01-20 18:47       ` Arnd Bergmann
2020-01-21 10:21         ` Lucas Stach [this message]
2020-01-21 11:46           ` Arnd Bergmann
2019-12-13 20:53 ` [PATCH v2 14/24] drm/etnaviv: avoid deprecated timespec Arnd Bergmann
2019-12-13 20:53 ` [PATCH v2 15/24] sunrpc: convert to time64_t for expiry Arnd Bergmann
2019-12-13 20:53 ` [PATCH v2 16/24] nfs: use time64_t internally Arnd Bergmann
2019-12-13 20:53 ` [PATCH v2 17/24] nfs: fix timstamp debug prints Arnd Bergmann
2019-12-13 20:53 ` [PATCH v2 18/24] nfs: fscache: use timespec64 in inode auxdata Arnd Bergmann
2019-12-13 20:53 ` [PATCH v2 19/24] xfs: rename compat_time_t to old_time32_t Arnd Bergmann
2019-12-13 21:18   ` Darrick J. Wong
2019-12-16 16:31     ` Arnd Bergmann
2019-12-13 20:53 ` [PATCH v2 20/24] xfs: disallow broken ioctls without compat-32-bit-time Arnd Bergmann
2019-12-13 21:05   ` Darrick J. Wong
2019-12-16 16:45     ` Arnd Bergmann
2019-12-16 16:52       ` Darrick J. Wong
2019-12-17 15:06         ` Arnd Bergmann
2019-12-13 20:53 ` [PATCH v2 21/24] xfs: quota: move to time64_t interfaces Arnd Bergmann
2019-12-13 21:17   ` Darrick J. Wong
2019-12-16 16:52     ` Arnd Bergmann
2019-12-17 15:02       ` Arnd Bergmann
2019-12-17 22:15         ` Darrick J. Wong
2019-12-18 16:44           ` Arnd Bergmann
2019-12-13 20:53 ` [PATCH v2 22/24] y2038: remove obsolete jiffies conversion functions Arnd Bergmann
2019-12-13 20:53 ` [PATCH v2 23/24] y2038: rename itimerval to __kernel_old_itimerval Arnd Bergmann
2019-12-13 20:53 ` [PATCH v2 24/24] y2038: sparc: remove use of struct timex Arnd Bergmann
2019-12-14  1:37   ` Julian Calaby
2019-12-14 14:44     ` [Y2038] " Arnd Bergmann

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=8d86fcb526ee14c7e6c80a787db645192c2c7c33.camel@pengutronix.de \
    --to=l.stach@pengutronix.de \
    --cc=agx@sigxcpu.org \
    --cc=airlied@linux.ie \
    --cc=arnd@arndb.de \
    --cc=christian.gmeiner@gmail.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=emil.velikov@collabora.com \
    --cc=etnaviv@lists.freedesktop.org \
    --cc=linux+etnaviv@armlinux.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=p.zabel@pengutronix.de \
    --cc=sam@ravnborg.org \
    --cc=y2038@lists.linaro.org \
    /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

all inboxes | Powered by JetHome®