linux-kernel - Re: [PATCH 1/3] drm: Widen vblank count to 64 bits. Change vblank time precision to ns

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: <86h8ypd2hd.fsf@keithp.com>
Date:   Thu, 06 Jul 2017 08:11:42 -0700
From:   Keith Packard <keithp@...thp.com>
To:     Michel Dänzer <michel@...nzer.net>,
        Dave Airlie <airlied@...hat.com>,
        Daniel Vetter <daniel@...ll.ch>
Cc:     linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH 1/3] drm: Widen vblank count to 64 bits. Change vblank time precision to ns

Michel Dänzer <michel@...nzer.net> writes:

> BTW, this got me thinking that we should probably treat
> _DRM_VBLANK_NEXTONMISS the same way, i.e. clear the flag after updating
> vblwait->request.sequence. Otherwise there could theoretically (though
> unlikely) be an infinite loop:

I was thinking that we should just re-compute the target sequence from
scratch and not modify the request at all. But, now I see your point --
if the wait is interrupted long after it starts, then we don't want to
change the target number.

I wonder if anyone actually waits for vblank anymore, or if everyone
just uses the event interface...

> ioctl with _DRM_VBLANK_NEXTONMISS, target missed => wait for next vblank
> wait interrupted by signal
> lather, rinse, repeat

Yeah, sounds like a latent bug.

Ok, to retract my last email, I'll go ahead and fix things up so that
the request sequence gets set to the correct absolute value and that any
flags which modify it get cleared.

> I'd advise against adding a "next on miss" flag for the new ioctl until
> there is specific demand for that.

Thanks for your advice :-)

-- 
-keith

Download attachment "signature.asc" of type "application/pgp-signature" (833 bytes)