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]
Date:	Sat, 11 Aug 2012 15:50:36 -0500
From:	Rob Clark <rob.clark@...aro.org>
To:	Rob Clark <rob.clark@...aro.org>,
	Maarten Lankhorst <maarten.lankhorst@...onical.com>,
	sumit.semwal@...aro.org, linaro-mm-sig@...ts.linaro.org,
	linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
	linux-media@...r.kernel.org
Subject: Re: [Linaro-mm-sig] [PATCH 2/4] dma-fence: dma-buf synchronization
 (v8 )

On Sat, Aug 11, 2012 at 2:22 PM, Daniel Vetter <daniel@...ll.ch> wrote:
>> >> +
>> >> +/**
>> >> + * dma_fence_wait - wait for a fence to be signaled
>> >> + *
>> >> + * @fence:   [in]    The fence to wait on
>> >> + * @intr:    [in]    if true, do an interruptible wait
>> >> + * @timeout: [in]    absolute time for timeout, in jiffies.
>> >
>> > I don't quite like this, I think we should keep the styl of all other
>> > wait_*_timeout functions and pass the arg as timeout in jiffies (and also
>> > the same return semantics). Otherwise well have funny code that needs to
>> > handle return values differently depending upon whether it waits upon a
>> > dma_fence or a native object (where it would us the wait_*_timeout
>> > functions directly).
>>
>> We did start out this way, but there was an ugly jiffies roll-over
>> problem that was difficult to deal with properly.  Using an absolute
>> time avoided the problem.
>
> Well, as-is the api works differently than all the other _timeout apis
> I've seen in the kernel, which makes it confusing. Also, I don't quite see
> what jiffies wraparound issue there is?

iirc, the problem was in dmabufmgr, in
dmabufmgr_wait_completed_cpu().. with an absolute timeout, it could
loop over all the fences without having to adjust the timeout for the
elapsed time.  Otherwise it had to adjust the timeout and keep track
of when the timeout elapsed without confusing itself via rollover.

BR,
-R
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ