From mboxrd@z Thu Jan 1 00:00:00 1970 From: Maarten Lankhorst Subject: Re: Fence, timeline and android sync points Date: Thu, 14 Aug 2014 21:16:30 +0200 Message-ID: <53ED0B0E.4070205@canonical.com> References: <20140812221340.GB5746@gmail.com> <20140813082822.GO10500@phenom.ffwll.local> <20140813133602.GA2666@gmail.com> <20140813155420.GG10500@phenom.ffwll.local> <20140813170719.GD2666@gmail.com> <20140814141205.GB2000@gmail.com> <20140814155848.GZ10500@phenom.ffwll.local> <20140814182611.GE2000@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mblankhorst.nl (mblankhorst.nl [141.105.120.124]) by gabe.freedesktop.org (Postfix) with ESMTP id E25936E359 for ; Thu, 14 Aug 2014 12:16:37 -0700 (PDT) In-Reply-To: <20140814182611.GE2000@gmail.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Jerome Glisse , Daniel Vetter Cc: Daniel Vetter , "dri-devel@lists.freedesktop.org" , Ben Skeggs List-Id: dri-devel@lists.freedesktop.org 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 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