On Wed, Nov 09, 2016 at 11:39:11AM +0900, Gustavo Padovan wrote:
> > On Tue, Nov 08, 2016 at 03:54:50PM +0900, Gustavo Padovan wrote:
> > > + if (!access_ok(VERIFY_WRITE, fence_ptr, sizeof(*fence_ptr)))
> > > + return -EFAULT;
> >
> > Same comment about igt coverage I made for patch 1, but with
> > s/in-fence/out-fence/, and s/~0ULL/8/. I picked 8 as an invalid address !=
> > NULL.
> >
> > And the testcase need to cover all possible combinations of output event
> > generation, i.e. out-fence, event and out-fence+event. So 3x3=9 testcases
> > for this I think.
>
> out-fence and event. so 2x2=4 ;)
3 different igt modes I've counted:
- wrong prop after correct fence prop (early failure)
- atomic_check fails (late failure)
- success
With 3 kinds of events:
- fence only
- event only
- both - which might show up some bug if you bail out after e.g. handling
fences, but before handling events and then leak.
Hence 3x3 ;-) But if some of these aren't reasonable I'm ok with leaving
them out, too.
> > > +static void unprepare_crtc_signaling(struct drm_device *dev,
> > > + struct drm_atomic_state *state,
> > > + struct drm_out_fence_state *fence_state)
> > > +{
> > > + struct drm_crtc *crtc;
> > > + struct drm_crtc_state *crtc_state;
> > > + int i;
> > > +
> > > + for_each_crtc_in_state(state, crtc, crtc_state, i) {
> > > + /*
> > > + * TEST_ONLY and PAGE_FLIP_EVENT are mutually
> > > + * exclusive, if they weren't, this code should be
> > > + * called on success for TEST_ONLY too.
> > > + */
> > > + if (crtc_state->event)
> > > + drm_event_cancel_free(dev,
> > > + &crtc_state->event->base);
> > > + }
> > > +
> > > + for (i = 0; fence_state[i].out_fence_ptr; i++) {
> >
> > This goes boom if you have fences set for every crtc, because then this
> > check will walk past the end of the array and do something undefined. You
> > need to manually count how many of these slots are set (and might want to
> > switch to a krealloc pattern while at it). Sounds like it needs an igt.
>
> On the fd_install loop I was also checking for i <
> dev->mode_config.num_crtcs but forgot to add that here. However having a
> num_fences is a better solution, I'll add that.
And adding num_fence will be a good prep for writeback fences from Brian,
too.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
