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@xxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
