Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754057AbcDOTbl (ORCPT ); Fri, 15 Apr 2016 15:31:41 -0400 Received: from mail-wm0-f65.google.com ([74.125.82.65]:35720 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753185AbcDOTbh (ORCPT ); Fri, 15 Apr 2016 15:31:37 -0400 Date: Fri, 15 Apr 2016 21:31:33 +0200 From: Daniel Vetter To: Gustavo Padovan , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Daniel Stone , Arve =?iso-8859-1?B?SGr4bm5lduVn?= , Riley Andrews , Rob Clark , Greg Hackmann , John Harrison , laurent.pinchart@ideasonboard.com, seanpaul@google.com, marcheu@google.com, m.chehab@samsung.com, Maarten Lankhorst , Gustavo Padovan Subject: Re: [RFC 5/8] drm/fence: add fence to drm_pending_event Message-ID: <20160415193133.GA2510@phenom.ffwll.local> Mail-Followup-To: Gustavo Padovan , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Daniel Stone , Arve =?iso-8859-1?B?SGr4bm5lduVn?= , Riley Andrews , Rob Clark , Greg Hackmann , John Harrison , laurent.pinchart@ideasonboard.com, seanpaul@google.com, marcheu@google.com, m.chehab@samsung.com, Maarten Lankhorst , Gustavo Padovan References: <1460683781-22535-1-git-send-email-gustavo@padovan.org> <1460683781-22535-6-git-send-email-gustavo@padovan.org> <20160415080948.GS2510@phenom.ffwll.local> <20160415185900.GD23954@joana> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160415185900.GD23954@joana> X-Operating-System: Linux phenom 4.4.0-1-amd64 User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1643 Lines: 43 On Fri, Apr 15, 2016 at 11:59:00AM -0700, Gustavo Padovan wrote: > 2016-04-15 Daniel Vetter : > > On Thu, Apr 14, 2016 at 06:29:38PM -0700, Gustavo Padovan wrote: > > > diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c > > > index aeef58e..38def49 100644 > > > --- a/drivers/gpu/drm/drm_fops.c > > > +++ b/drivers/gpu/drm/drm_fops.c > > > @@ -801,8 +801,9 @@ void drm_send_event_locked(struct drm_device *dev, struct drm_pending_event *e) > > > { > > > assert_spin_locked(&dev->event_lock); > > > > > > - if (!e->file_priv) { > > > - e->destroy(e); > > > + if (!e->file_priv || !e->event) { > > > > This would be a bug: e->file_priv != NULL iff e->event != NULL. How did > > this happen? > > Not sure now. But I needed this to prevent a crash, I don't have logs of > it anymore, I'll check this again. There was a massive irc discussion with Daniel Stone, so I'll try to summarize it here. There are 3 possible cases: e->file_priv == NULL && e->event == NULL: This is a drm_event without a drm_event. Probably e->fence is set, if not then it's a completeley useless thing (but not forbidden). e->file_priv != NULL && e->event != NULL: drm_event with an event for the given file_priv attached. e->file_priv == NULL && e->event != NULL: Above case, but with the file_priv closed and unlinked from the event. The 4th case, which is the only case things will change with the above hunk, is not allowed. If you hit it, there's a bug somewhere. This is all completely idependent of e->fence, which this patch adds. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch