Re: Fence, timeline and android sync points

[Maarten Lankhorst <maarten.lankhorst@canonical.com>]

On 14-08-14 20:26, Jerome Glisse wrote:
> On Thu, Aug 14, 2014 at 05:58:48PM +0200, Daniel Vetter wrote:
>> On Thu, Aug 14, 2014 at 10:12:06AM -0400, Jerome Glisse wrote:
>>> On Thu, Aug 14, 2014 at 09:16:02AM -0400, Rob Clark wrote:
>>>> On Wed, Aug 13, 2014 at 1:07 PM, Jerome Glisse <j.glisse@gmail.com> wrote:
>>>>> So this is fundamentaly different, fence as they are now allow random driver
>>>>> callback and this is bound to get ugly this is bound to lead to one driver
>>>>> doing something that seems innocuous but turn out to break heavoc when call
>>>>> from some other driver function.
>>>>
>>>>
>>>> tbh, that seems solvable by some strict rules about what you can do in
>>>> the callback.. ie. don't do anything you couldn't do in atomic, and
>>>> don't signal another fence.. off the top of my head that seems
>>>> sufficient.
>>>>
>>>> If the driver getting the callback needs to do more, then it can
>>>> always schedule a worker..
>>>>
>>>> But I could certainly see the case where the driver waiting on fence
>>>> sets everything up before installing the cb and then just needs to
>>>> write one or a couple regs from the cb.
>>>
>>> Yes sane code will do sane things, sadly i fear we can not enforce sane
>>> code everywhere especialy with out of tree driver and i would rather
>>> force there hand to only allow sane implementation. Providing call back
>>> api obviously allows them to do crazy stuff.
>>
>> Well then don't support out of tree drivers. Fairly easy problem really,
>> and last time I checked "out of tree drivers suck" isn't a valid
>> objections for upstream code ... It's kinda assumed that they all do, it's
>> why we have staging after all.
> 
> As usual i fail at expressing my point. I am not saying do not merge this
> because of out of tree drivers, i am saying while doing an api let make it
> sane and try to make it so that it enforce sanity to anything that lives
> outside our realm.
> 
> And not even thinking outside kernel tree, but someone might come along and
> start using fence, see the callback stuff and start doing crazy stuff with
> that all this inside a different obscur kernel subsystem. Then someone in
> graphic sees that and use that as justification to do crazy thing too,
> because hey, if he is doing why can't i ?
Since when has crazy been contagious?

And here's what stops you:
1. LOCKDEP
2. PROVE_RCU
3. rcu sparse annotations (kbuild test bot)
4. DEBUG_ATOMIC_SLEEP

~Maarten