On Thu, Aug 14, 2014 at 10:12 AM, Jerome Glisse <j.glisse@xxxxxxxxx> 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. callback's hard, let's go shopping.. But seriously, we've solved problems like this w/ various kernel debug features before. I am pretty sure we could make lock debugging, and maybe some new fence debugging option, catch a lot of things. There is probably a better way, but a dummy spinlock around the callback, or maybe preempt_enable()/disable() around the callback? And we should be able to come up with a way to catch signalling a fence from cb.. A bit of extra rope with a warning sign not to hang yourself and debug features to tell people when they are hanging themselves seems like the better option to me. BR, -R >> >> BR, >> -R _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
