From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933153AbcBYP0z (ORCPT ); Thu, 25 Feb 2016 10:26:55 -0500 Received: from mail-yw0-f176.google.com ([209.85.161.176]:35693 "EHLO mail-yw0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933117AbcBYP0x (ORCPT ); Thu, 25 Feb 2016 10:26:53 -0500 Date: Thu, 25 Feb 2016 12:26:47 -0300 From: Gustavo Padovan To: Tom Cherry Cc: Greg Hackmann , Gustavo Padovan , John Harrison , Greg Kroah-Hartman , linux-kernel@vger.kernel.org, devel@driverdev.osuosl.org, dri-devel@lists.freedesktop.org, daniels@collabora.com, Arve =?iso-8859-1?B?SGr4bm5lduVn?= , Riley Andrews , Daniel Vetter , Rob Clark , Maarten Lankhorst , Dmitry Torokhov Subject: Re: [RFC 26/29] dma-buf/fence: remove pointless fence_timeline_signal at destroy phase Message-ID: <20160225152647.GA2479@joana> Mail-Followup-To: Gustavo Padovan , Tom Cherry , Greg Hackmann , Gustavo Padovan , John Harrison , Greg Kroah-Hartman , linux-kernel@vger.kernel.org, devel@driverdev.osuosl.org, dri-devel@lists.freedesktop.org, daniels@collabora.com, Arve =?iso-8859-1?B?SGr4bm5lduVn?= , Riley Andrews , Daniel Vetter , Rob Clark , Maarten Lankhorst , Dmitry Torokhov References: <1452869739-3304-1-git-send-email-gustavo@padovan.org> <1452869739-3304-27-git-send-email-gustavo@padovan.org> <569930FF.1090601@Intel.com> <20160115180207.GD2664@joana> <569983CC.7000207@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 2016-02-09 Tom Cherry : > On Fri, Jan 15, 2016 at 3:42 PM, Greg Hackmann wrote: > > On 01/15/2016 10:02 AM, Gustavo Padovan wrote: > >> > >> Patches 27 and 28 are attempt to fix that. I assumed that if some code is > >> calling fence_timeline_destroy() it wants to stop everything so I > >> worked on a solution that stops any waiter and allows the timeline to be > >> destroyed. > >> > >> No one is using fence_timeline_destroy() in mainline now, so it is > >> definately a behaviour we can discuss. > >> > >> Gustavo > >> > > > > +Tom Cherry and Dmitry Torokhov recently discovered that this was broken by > > the refactoring of Android sync on top of dma-buf fences. > > > > Tom and Dmitry, did you send the proposed fix upstream? > > There was a similar issue that I had originally thought to be related > to fence_timeline_destroy() but was actually related to > sync_fence_free(). Dmitry sent the patch upstream at > https://lkml.org/lkml/2015/12/14/953, but it does not look like it has > received any feedback. > > We saw real panics without this patch. I didn't see this patch or any > similar changes in the destaging commits, and I would recommend it be > looked at while destaging this driver. This patch is already uptream, Greg pushed it in December. :) Gustavo From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gustavo Padovan Subject: Re: [RFC 26/29] dma-buf/fence: remove pointless fence_timeline_signal at destroy phase Date: Thu, 25 Feb 2016 12:26:47 -0300 Message-ID: <20160225152647.GA2479@joana> References: <1452869739-3304-1-git-send-email-gustavo@padovan.org> <1452869739-3304-27-git-send-email-gustavo@padovan.org> <569930FF.1090601@Intel.com> <20160115180207.GD2664@joana> <569983CC.7000207@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mail-yw0-f170.google.com (mail-yw0-f170.google.com [209.85.161.170]) by gabe.freedesktop.org (Postfix) with ESMTPS id 79D8D6E10D for ; Thu, 25 Feb 2016 15:26:53 +0000 (UTC) Received: by mail-yw0-f170.google.com with SMTP id u200so45201153ywf.0 for ; Thu, 25 Feb 2016 07:26:53 -0800 (PST) Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Tom Cherry Cc: devel@driverdev.osuosl.org, daniels@collabora.com, Greg Kroah-Hartman , linux-kernel@vger.kernel.org, Maarten Lankhorst , Arve =?iso-8859-1?B?SGr4bm5lduVn?= , Dmitry Torokhov , dri-devel@lists.freedesktop.org, Daniel Vetter , Riley Andrews , Gustavo Padovan , John Harrison List-Id: dri-devel@lists.freedesktop.org MjAxNi0wMi0wOSBUb20gQ2hlcnJ5IDx0b21jaGVycnlAZ29vZ2xlLmNvbT46Cgo+IE9uIEZyaSwg SmFuIDE1LCAyMDE2IGF0IDM6NDIgUE0sIEdyZWcgSGFja21hbm4gPGdoYWNrbWFubkBnb29nbGUu Y29tPiB3cm90ZToKPiA+IE9uIDAxLzE1LzIwMTYgMTA6MDIgQU0sIEd1c3Rhdm8gUGFkb3ZhbiB3 cm90ZToKPiA+Pgo+ID4+IFBhdGNoZXMgMjcgYW5kIDI4IGFyZSBhdHRlbXB0IHRvIGZpeCB0aGF0 LiBJIGFzc3VtZWQgdGhhdCBpZiBzb21lIGNvZGUgaXMKPiA+PiBjYWxsaW5nIGZlbmNlX3RpbWVs aW5lX2Rlc3Ryb3koKSBpdCB3YW50cyB0byBzdG9wIGV2ZXJ5dGhpbmcgc28gSQo+ID4+IHdvcmtl ZCBvbiBhIHNvbHV0aW9uIHRoYXQgc3RvcHMgYW55IHdhaXRlciBhbmQgYWxsb3dzIHRoZSB0aW1l bGluZSB0byBiZQo+ID4+IGRlc3Ryb3llZC4KPiA+Pgo+ID4+IE5vIG9uZSBpcyB1c2luZyBmZW5j ZV90aW1lbGluZV9kZXN0cm95KCkgaW4gbWFpbmxpbmUgbm93LCBzbyBpdCBpcwo+ID4+IGRlZmlu YXRlbHkgYSBiZWhhdmlvdXIgd2UgY2FuIGRpc2N1c3MuCj4gPj4KPiA+PiAgICAgICAgIEd1c3Rh dm8KPiA+Pgo+ID4KPiA+ICtUb20gQ2hlcnJ5IGFuZCBEbWl0cnkgVG9yb2tob3YgcmVjZW50bHkg ZGlzY292ZXJlZCB0aGF0IHRoaXMgd2FzIGJyb2tlbiBieQo+ID4gdGhlIHJlZmFjdG9yaW5nIG9m IEFuZHJvaWQgc3luYyBvbiB0b3Agb2YgZG1hLWJ1ZiBmZW5jZXMuCj4gPgo+ID4gVG9tIGFuZCBE bWl0cnksIGRpZCB5b3Ugc2VuZCB0aGUgcHJvcG9zZWQgZml4IHVwc3RyZWFtPwo+IAo+IFRoZXJl IHdhcyBhIHNpbWlsYXIgaXNzdWUgdGhhdCBJIGhhZCBvcmlnaW5hbGx5IHRob3VnaHQgdG8gYmUg cmVsYXRlZAo+IHRvIGZlbmNlX3RpbWVsaW5lX2Rlc3Ryb3koKSBidXQgd2FzIGFjdHVhbGx5IHJl bGF0ZWQgdG8KPiBzeW5jX2ZlbmNlX2ZyZWUoKS4gIERtaXRyeSBzZW50IHRoZSBwYXRjaCB1cHN0 cmVhbSBhdAo+IGh0dHBzOi8vbGttbC5vcmcvbGttbC8yMDE1LzEyLzE0Lzk1MywgYnV0IGl0IGRv ZXMgbm90IGxvb2sgbGlrZSBpdCBoYXMKPiByZWNlaXZlZCBhbnkgZmVlZGJhY2suCj4gCj4gV2Ug c2F3IHJlYWwgcGFuaWNzIHdpdGhvdXQgdGhpcyBwYXRjaC4gIEkgZGlkbid0IHNlZSB0aGlzIHBh dGNoIG9yIGFueQo+IHNpbWlsYXIgY2hhbmdlcyBpbiB0aGUgZGVzdGFnaW5nIGNvbW1pdHMsIGFu ZCBJIHdvdWxkIHJlY29tbWVuZCBpdCBiZQo+IGxvb2tlZCBhdCB3aGlsZSBkZXN0YWdpbmcgdGhp cyBkcml2ZXIuCgpUaGlzIHBhdGNoIGlzIGFscmVhZHkgdXB0cmVhbSwgR3JlZyBwdXNoZWQgaXQg aW4gRGVjZW1iZXIuIDopCgoJR3VzdGF2bwpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXwpkcmktZGV2ZWwgbWFpbGluZyBsaXN0CmRyaS1kZXZlbEBsaXN0cy5m cmVlZGVza3RvcC5vcmcKaHR0cHM6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0 aW5mby9kcmktZGV2ZWwK