All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Lucas Stach <l.stach@pengutronix.de>
Cc: "y2038 Mailman List" <y2038@lists.linaro.org>,
	"David Airlie" <airlied@linux.ie>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"Guido Günther" <agx@sigxcpu.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	"The etnaviv authors" <etnaviv@lists.freedesktop.org>,
	"Russell King" <linux+etnaviv@armlinux.org.uk>,
	"Sam Ravnborg" <sam@ravnborg.org>,
	"Christian König" <christian.koenig@amd.com>,
	"Emil Velikov" <emil.velikov@collabora.com>
Subject: Re: [PATCH 15/16] drm/etnaviv: use ktime_t for timeouts
Date: Mon, 11 Nov 2019 17:24:59 +0100	[thread overview]
Message-ID: <CAK8P3a0SA+LbVCnm8qhc-Xk1kboGhkRQsK0XAuMya8TmaD4+TA@mail.gmail.com> (raw)
In-Reply-To: <7379bfe6c530132caab4cd930cd94f0e28c935ff.camel@pengutronix.de>

On Mon, Nov 11, 2019 at 10:55 AM Lucas Stach <l.stach@pengutronix.de> wrote:
> >
> > > If that's the case then we should never encounter a genuine 0 timeout
> > > and this change would be okay.
> >
> > That's quite likely, I'd say any program passing {0,0} as a timeout without
> > ETNA_WAIT_NONBLOCK is already broken, but if we leave it like that,
> > it would be best to describe the reasoning in the changelog.
> >
> > Should I change the changelog, or change the patch to restore the
> > current behavior instead?
> >
> > I guess I could fold the change below into my patch to make it transparent
> > to the application again.
>
> If we assume 0 to never be a valid timeout, due to monotonic clock
> starting at 0 and never wrapping then I think we shouldn't introduce
> any additional code complexity to fix up the return value for this
> specific case. I'm not aware of any etnaviv userspace being broken in
> this way to rely on the return value for an invalid timeout input.
>
> Please just amend the commit message to mention the change in behavior
> and why we think it is safe to do.

Russell had some additional concerns that he raised on IRC,
and I did a new simpler implementation of the patch, plus a related
bugfix.

Please have a look at those.

       Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Lucas Stach <l.stach@pengutronix.de>
Cc: "y2038 Mailman List" <y2038@lists.linaro.org>,
	"Guido Günther" <agx@sigxcpu.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	"The etnaviv authors" <etnaviv@lists.freedesktop.org>,
	"David Airlie" <airlied@linux.ie>,
	"Russell King" <linux+etnaviv@armlinux.org.uk>,
	"Sam Ravnborg" <sam@ravnborg.org>,
	"Christian König" <christian.koenig@amd.com>,
	"Emil Velikov" <emil.velikov@collabora.com>
Subject: Re: [PATCH 15/16] drm/etnaviv: use ktime_t for timeouts
Date: Mon, 11 Nov 2019 17:24:59 +0100	[thread overview]
Message-ID: <CAK8P3a0SA+LbVCnm8qhc-Xk1kboGhkRQsK0XAuMya8TmaD4+TA@mail.gmail.com> (raw)
Message-ID: <20191111162459.GB_pbuJaMgc8n_pmIOSk7sxhP_-6rbHGxsl_mS3mkdg@z> (raw)
In-Reply-To: <7379bfe6c530132caab4cd930cd94f0e28c935ff.camel@pengutronix.de>

On Mon, Nov 11, 2019 at 10:55 AM Lucas Stach <l.stach@pengutronix.de> wrote:
> >
> > > If that's the case then we should never encounter a genuine 0 timeout
> > > and this change would be okay.
> >
> > That's quite likely, I'd say any program passing {0,0} as a timeout without
> > ETNA_WAIT_NONBLOCK is already broken, but if we leave it like that,
> > it would be best to describe the reasoning in the changelog.
> >
> > Should I change the changelog, or change the patch to restore the
> > current behavior instead?
> >
> > I guess I could fold the change below into my patch to make it transparent
> > to the application again.
>
> If we assume 0 to never be a valid timeout, due to monotonic clock
> starting at 0 and never wrapping then I think we shouldn't introduce
> any additional code complexity to fix up the return value for this
> specific case. I'm not aware of any etnaviv userspace being broken in
> this way to rely on the return value for an invalid timeout input.
>
> Please just amend the commit message to mention the change in behavior
> and why we think it is safe to do.

Russell had some additional concerns that he raised on IRC,
and I did a new simpler implementation of the patch, plus a related
bugfix.

Please have a look at those.

       Arnd
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2019-11-11 16:25 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-08 21:32 [PATCH 00/16] drivers: y2038 updates Arnd Bergmann
2019-11-08 21:32 ` [Cluster-devel] " Arnd Bergmann
2019-11-08 21:32 ` Arnd Bergmann
2019-11-08 21:32 ` Arnd Bergmann
2019-11-08 21:32 ` Arnd Bergmann
2019-11-08 21:32 ` Arnd Bergmann
2019-11-08 21:32 ` [PATCH 01/16] staging: exfat: use prandom_u32() for i_generation Arnd Bergmann
2019-11-08 21:32   ` Arnd Bergmann
2019-11-08 21:53   ` Valdis Klētnieks
2019-11-08 21:53     ` Valdis Klētnieks
2019-11-08 21:32 ` [PATCH 02/16] fat: " Arnd Bergmann
2019-11-08 21:32 ` [PATCH 03/16] net: sock: use __kernel_old_timespec instead of timespec Arnd Bergmann
2019-11-09 19:09   ` Deepa Dinamani
2019-11-10  0:46   ` kbuild test robot
2019-11-08 21:32 ` [PATCH 04/16] dlm: use SO_SNDTIMEO_NEW instead of SO_SNDTIMEO_OLD Arnd Bergmann
2019-11-08 21:32   ` [Cluster-devel] " Arnd Bergmann
2019-11-09 19:14   ` Deepa Dinamani
2019-11-08 21:32 ` [PATCH 05/16] xtensa: ISS: avoid struct timeval Arnd Bergmann
2019-11-08 21:38   ` Max Filippov
2019-11-08 21:32 ` [PATCH 06/16] um: ubd: use 64-bit time_t where possible Arnd Bergmann
2019-11-08 21:32   ` Arnd Bergmann
2019-11-08 21:32 ` [PATCH 07/16] acct: stop using get_seconds() Arnd Bergmann
2019-11-08 21:32 ` [PATCH 08/16] tsacct: add 64-bit btime field Arnd Bergmann
2019-11-08 21:32 ` [PATCH 09/16] netfilter: nft_meta: use 64-bit time arithmetic Arnd Bergmann
2019-11-09 11:20   ` Phil Sutter
2019-11-15 22:44   ` Pablo Neira Ayuso
2019-11-08 21:32 ` [PATCH 10/16] packet: clarify timestamp overflow Arnd Bergmann
2019-11-08 21:32 ` [PATCH 11/16] quota: avoid time_t in v1_disk_dqblk definition Arnd Bergmann
2019-11-08 21:32 ` [PATCH 12/16] hostfs: pass 64-bit timestamps to/from user space Arnd Bergmann
2019-11-08 21:32   ` Arnd Bergmann
2019-11-20 20:30   ` [Y2038] " Ben Hutchings
2019-11-20 20:30     ` Ben Hutchings
2019-11-20 20:35     ` Ben Hutchings
2019-11-20 20:35       ` Ben Hutchings
2019-11-08 21:32 ` [PATCH 13/16] hfs/hfsplus: use 64-bit inode timestamps Arnd Bergmann
2019-11-13  3:53   ` Ernesto A. Fernández
2019-11-13  5:59   ` Viacheslav Dubeyko
2019-11-13  8:06     ` [Y2038] " Arnd Bergmann
2019-11-13 17:03       ` Viacheslav Dubeyko
2019-11-08 21:32 ` [PATCH 14/16] drm/msm: avoid using 'timespec' Arnd Bergmann
2019-11-08 21:32   ` Arnd Bergmann
2019-11-12 16:55   ` Jordan Crouse
2019-11-12 16:55     ` Jordan Crouse
2019-11-08 21:32 ` [PATCH 15/16] drm/etnaviv: use ktime_t for timeouts Arnd Bergmann
2019-11-08 21:32   ` Arnd Bergmann
2019-11-08 23:03   ` Lucas Stach
2019-11-08 23:03     ` Lucas Stach
2019-11-09 12:12     ` Arnd Bergmann
2019-11-09 12:12       ` Arnd Bergmann
2019-11-11  9:55       ` Lucas Stach
2019-11-11  9:55         ` Lucas Stach
2019-11-11 16:24         ` Arnd Bergmann [this message]
2019-11-11 16:24           ` Arnd Bergmann
2019-11-08 21:32 ` [PATCH 16/16] firewire: ohci: stop using get_seconds() for BUS_TIME Arnd Bergmann
2019-11-13 20:04   ` Stefan Richter

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=CAK8P3a0SA+LbVCnm8qhc-Xk1kboGhkRQsK0XAuMya8TmaD4+TA@mail.gmail.com \
    --to=arnd@arndb.de \
    --cc=agx@sigxcpu.org \
    --cc=airlied@linux.ie \
    --cc=christian.koenig@amd.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=emil.velikov@collabora.com \
    --cc=etnaviv@lists.freedesktop.org \
    --cc=l.stach@pengutronix.de \
    --cc=linux+etnaviv@armlinux.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --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 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.