From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH v2] dma-buf/fence: Take refcount on the module that owns the fence Date: Tue, 26 Jun 2018 10:17:40 +0200 Message-ID: <20180626081740.GT2958@phenom.ffwll.local> References: <1529660407-6266-1-git-send-email-akhilpo@codeaurora.org> <1529661856.7034.404.camel@padovan.org> <152966212844.11773.6596589902326100250@mail.alporthouse.com> <20180625075040.GK2958@phenom.ffwll.local> <82f8e976-2a5a-56df-28bb-c75314824bf6@codeaurora.org> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Content-Disposition: inline In-Reply-To: <82f8e976-2a5a-56df-28bb-c75314824bf6@codeaurora.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Akhil P Oommen Cc: smasetty@codeaurora.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, linux-arm-msm@vger.kernel.org, linux-media@vger.kernel.org List-Id: linux-arm-msm@vger.kernel.org T24gTW9uLCBKdW4gMjUsIDIwMTggYXQgMDk6MjE6MTVQTSArMDUzMCwgQWtoaWwgUCBPb21tZW4g d3JvdGU6Cj4gCj4gCj4gT24gNi8yNS8yMDE4IDE6MjAgUE0sIERhbmllbCBWZXR0ZXIgd3JvdGU6 Cj4gPiBPbiBGcmksIEp1biAyMiwgMjAxOCBhdCAxMTowODo0OEFNICswMTAwLCBDaHJpcyBXaWxz b24gd3JvdGU6Cj4gPiA+IFF1b3RpbmcgR3VzdGF2byBQYWRvdmFuICgyMDE4LTA2LTIyIDExOjA0 OjE2KQo+ID4gPiA+IEhpIEFraGlsLAo+ID4gPiA+IAo+ID4gPiA+IE9uIEZyaSwgMjAxOC0wNi0y MiBhdCAxNToxMCArMDUzMCwgQWtoaWwgUCBPb21tZW4gd3JvdGU6Cj4gPiA+ID4gPiBFYWNoIGZl bmNlIG9iamVjdCBob2xkcyBmdW5jdGlvbiBwb2ludGVycyBvZiB0aGUgbW9kdWxlIHRoYXQKPiA+ ID4gPiA+IGluaXRpYWxpemVkCj4gPiA+ID4gPiBpdC4gQWxsb3dpbmcgdGhlIG1vZHVsZSB0byB1 bmxvYWQgYmVmb3JlIHRoaXMgZmVuY2UncyByZWxlYXNlIGlzCj4gPiA+ID4gPiBjYXRhc3Ryb3Bo aWMuIFNvLCBrZWVwIGEgcmVmY291bnQgb24gdGhlIG1vZHVsZSB1bnRpbCB0aGUgZmVuY2UgaXMK PiA+ID4gPiA+IHJlbGVhc2VkLgo+ID4gPiA+ID4gCj4gPiA+ID4gPiBTaWduZWQtb2ZmLWJ5OiBB a2hpbCBQIE9vbW1lbiA8YWtoaWxwb0Bjb2RlYXVyb3JhLm9yZz4KPiA+ID4gPiA+IC0tLQo+ID4g PiA+ID4gQ2hhbmdlcyBpbiB2MjoKPiA+ID4gPiA+IC0gYWRkZWQgZGVzY3JpcHRpb24gZm9yIHRo ZSBuZXcgZnVuY3Rpb24gcGFyYW1ldGVyLgo+ID4gPiA+ID4gCj4gPiA+ID4gPiAgIGRyaXZlcnMv ZG1hLWJ1Zi9kbWEtZmVuY2UuYyB8IDE2ICsrKysrKysrKysrKystLS0KPiA+ID4gPiA+ICAgaW5j bHVkZS9saW51eC9kbWEtZmVuY2UuaCAgIHwgMTAgKysrKysrKystLQo+ID4gPiA+ID4gICAyIGZp bGVzIGNoYW5nZWQsIDIxIGluc2VydGlvbnMoKyksIDUgZGVsZXRpb25zKC0pCj4gPiA+ID4gPiAK PiA+ID4gPiA+IGRpZmYgLS1naXQgYS9kcml2ZXJzL2RtYS1idWYvZG1hLWZlbmNlLmMgYi9kcml2 ZXJzL2RtYS1idWYvZG1hLQo+ID4gPiA+ID4gZmVuY2UuYwo+ID4gPiA+ID4gaW5kZXggNGVkYjlm ZC4uMmFhYTQ0ZSAxMDA2NDQKPiA+ID4gPiA+IC0tLSBhL2RyaXZlcnMvZG1hLWJ1Zi9kbWEtZmVu Y2UuYwo+ID4gPiA+ID4gKysrIGIvZHJpdmVycy9kbWEtYnVmL2RtYS1mZW5jZS5jCj4gPiA+ID4g PiBAQCAtMTgsNiArMTgsNyBAQAo+ID4gPiA+ID4gICAgKiBtb3JlIGRldGFpbHMuCj4gPiA+ID4g PiAgICAqLwo+ID4gPiA+ID4gKyNpbmNsdWRlIDxsaW51eC9tb2R1bGUuaD4KPiA+ID4gPiA+ICAg I2luY2x1ZGUgPGxpbnV4L3NsYWIuaD4KPiA+ID4gPiA+ICAgI2luY2x1ZGUgPGxpbnV4L2V4cG9y dC5oPgo+ID4gPiA+ID4gICAjaW5jbHVkZSA8bGludXgvYXRvbWljLmg+Cj4gPiA+ID4gPiBAQCAt MTY4LDYgKzE2OSw3IEBAIHZvaWQgZG1hX2ZlbmNlX3JlbGVhc2Uoc3RydWN0IGtyZWYgKmtyZWYp Cj4gPiA+ID4gPiAgIHsKPiA+ID4gPiA+ICAgICAgICBzdHJ1Y3QgZG1hX2ZlbmNlICpmZW5jZSA9 Cj4gPiA+ID4gPiAgICAgICAgICAgICAgICBjb250YWluZXJfb2Yoa3JlZiwgc3RydWN0IGRtYV9m ZW5jZSwgcmVmY291bnQpOwo+ID4gPiA+ID4gKyAgICAgc3RydWN0IG1vZHVsZSAqbW9kdWxlID0g ZmVuY2UtPm93bmVyOwo+ID4gPiA+ID4gICAgICAgIHRyYWNlX2RtYV9mZW5jZV9kZXN0cm95KGZl bmNlKTsKPiA+ID4gPiA+IEBAIC0xNzgsNiArMTgwLDggQEAgdm9pZCBkbWFfZmVuY2VfcmVsZWFz ZShzdHJ1Y3Qga3JlZiAqa3JlZikKPiA+ID4gPiA+ICAgICAgICAgICAgICAgIGZlbmNlLT5vcHMt PnJlbGVhc2UoZmVuY2UpOwo+ID4gPiA+ID4gICAgICAgIGVsc2UKPiA+ID4gPiA+ICAgICAgICAg ICAgICAgIGRtYV9mZW5jZV9mcmVlKGZlbmNlKTsKPiA+ID4gPiA+ICsKPiA+ID4gPiA+ICsgICAg IG1vZHVsZV9wdXQobW9kdWxlKTsKPiA+ID4gPiA+ICAgfQo+ID4gPiA+ID4gICBFWFBPUlRfU1lN Qk9MKGRtYV9mZW5jZV9yZWxlYXNlKTsKPiA+ID4gPiA+IEBAIC01NDEsNiArNTQ1LDcgQEAgc3Ry dWN0IGRlZmF1bHRfd2FpdF9jYiB7Cj4gPiA+ID4gPiAgIC8qKgo+ID4gPiA+ID4gICAgKiBkbWFf ZmVuY2VfaW5pdCAtIEluaXRpYWxpemUgYSBjdXN0b20gZmVuY2UuCj4gPiA+ID4gPiArICogQG1v ZHVsZTogIFtpbl0gICAgdGhlIG1vZHVsZSB0aGF0IGNhbGxzIHRoaXMgQVBJCj4gPiA+ID4gPiAg ICAqIEBmZW5jZTogICBbaW5dICAgIHRoZSBmZW5jZSB0byBpbml0aWFsaXplCj4gPiA+ID4gPiAg ICAqIEBvcHM6ICAgICBbaW5dICAgIHRoZSBkbWFfZmVuY2Vfb3BzIGZvciBvcGVyYXRpb25zIG9u IHRoaXMKPiA+ID4gPiA+IGZlbmNlCj4gPiA+ID4gPiAgICAqIEBsb2NrOiAgICBbaW5dICAgIHRo ZSBpcnFzYWZlIHNwaW5sb2NrIHRvIHVzZSBmb3IgbG9ja2luZwo+ID4gPiA+ID4gdGhpcyBmZW5j ZQo+ID4gPiA+ID4gQEAgLTU1Niw4ICs1NjEsOSBAQCBzdHJ1Y3QgZGVmYXVsdF93YWl0X2NiIHsK PiA+ID4gPiA+ICAgICogdG8gY2hlY2sgd2hpY2ggZmVuY2UgaXMgbGF0ZXIgYnkgc2ltcGx5IHVz aW5nIGRtYV9mZW5jZV9sYXRlci4KPiA+ID4gPiA+ICAgICovCj4gPiA+ID4gPiAgIHZvaWQKPiA+ ID4gPiA+IC1kbWFfZmVuY2VfaW5pdChzdHJ1Y3QgZG1hX2ZlbmNlICpmZW5jZSwgY29uc3Qgc3Ry dWN0IGRtYV9mZW5jZV9vcHMKPiA+ID4gPiA+ICpvcHMsCj4gPiA+ID4gPiAtICAgICAgICAgICAg c3BpbmxvY2tfdCAqbG9jaywgdTY0IGNvbnRleHQsIHVuc2lnbmVkIHNlcW5vKQo+ID4gPiA+ID4g K19kbWFfZmVuY2VfaW5pdChzdHJ1Y3QgbW9kdWxlICptb2R1bGUsIHN0cnVjdCBkbWFfZmVuY2Ug KmZlbmNlLAo+ID4gPiA+ID4gKyAgICAgICAgICAgICBjb25zdCBzdHJ1Y3QgZG1hX2ZlbmNlX29w cyAqb3BzLCBzcGlubG9ja190ICpsb2NrLAo+ID4gPiA+ID4gKyAgICAgICAgICAgICB1NjQgY29u dGV4dCwgdW5zaWduZWQgc2Vxbm8pCj4gPiA+ID4gPiAgIHsKPiA+ID4gPiA+ICAgICAgICBCVUdf T04oIWxvY2spOwo+ID4gPiA+ID4gICAgICAgIEJVR19PTighb3BzIHx8ICFvcHMtPndhaXQgfHwg IW9wcy0+ZW5hYmxlX3NpZ25hbGluZyB8fAo+ID4gPiA+ID4gQEAgLTU3MSw3ICs1NzcsMTEgQEAg c3RydWN0IGRlZmF1bHRfd2FpdF9jYiB7Cj4gPiA+ID4gPiAgICAgICAgZmVuY2UtPnNlcW5vID0g c2Vxbm87Cj4gPiA+ID4gPiAgICAgICAgZmVuY2UtPmZsYWdzID0gMFVMOwo+ID4gPiA+ID4gICAg ICAgIGZlbmNlLT5lcnJvciA9IDA7Cj4gPiA+ID4gPiArICAgICBmZW5jZS0+b3duZXIgPSBtb2R1 bGU7Cj4gPiA+ID4gPiArCj4gPiA+ID4gPiArICAgICBpZiAoIXRyeV9tb2R1bGVfZ2V0KG1vZHVs ZSkpCj4gPiA+ID4gPiArICAgICAgICAgICAgIGZlbmNlLT5vd25lciA9IE5VTEw7Cj4gPiA+ID4g PiAgICAgICAgdHJhY2VfZG1hX2ZlbmNlX2luaXQoZmVuY2UpOwo+ID4gPiA+ID4gICB9Cj4gPiA+ ID4gPiAtRVhQT1JUX1NZTUJPTChkbWFfZmVuY2VfaW5pdCk7Cj4gPiA+ID4gPiArRVhQT1JUX1NZ TUJPTChfZG1hX2ZlbmNlX2luaXQpOwo+ID4gPiA+IERvIHdlIHN0aWxsIG5lZWQgdG8gZXhwb3J0 IHRoZSBzeW1ib2wsIGl0IHdvbid0IGJlIGNhbGxlZCBmcm9tIG91dHNpZGUKPiA+ID4gPiBhbnlt b3JlPyBPdGhlciB0aGFuIHRoYXQgbG9va3MgZ29vZCB0byBtZToKPiA+ID4gVGhlcmUncyBhIGJp ZyBkcmF3YmFjayBpbiB0aGF0IGEgbW9kdWxlIHJlZmVyZW5jZSBpcyBvZnRlbiBpbnN1ZmZpY2ll bnQsCj4gPiA+IGFuZCB0aGF0IGEgcmVmZXJlbmNlIG9uIHRoZSBkcml2ZXIgKG9yIHdoYXRldmVy IGlzIHJlcXVpcmVkIGZvciB0aGUKPiA+ID4gbGlmZXRpbWUgb2YgdGhlIGZlbmNlKSB3aWxsIGFs cmVhZHkgaG9sZCB0aGUgbW9kdWxlIHJlZmVyZW5jZS4KPiA+ID4gCj4gPiA+IENvbnNpZGVyaW5n IHRoYXQgd2Ugd2FudCBhIGZldyAxMDBrIGZlbmNlcyBpbiBmbGlnaHQgcGVyIHNlY29uZCwgaXMK PiA+ID4gdGhlcmUgbm8gb3RoZXIgd2F5IHRvIG9ubHkgZXhwb3J0IGEgZmVuY2Ugd2l0aCBhIG1v ZHVsZSByZWZlcmVuY2U/Cj4gPiBXZSdkIG5lZWQgdG8gbWFrZSB0aGUgdGltZWxpbmUgYSBmdWxs LWJsb3duIG9iamVjdCAoTWFhcnRlbiBvd2VzIG1lIG9uZQo+ID4gZm9yIHRoYXQgZGVzaWduIHNj cmV3LXVwKSwgYW5kIHRoZW4gd2UgY291bGQgc3R1ZmYgYWxsIHRoZXNlIHRoaW5ncyBpbgo+ID4g dGhlcmUuCj4gPiAKPiA+IEFuZCBJIHRoaW5rIHRoYXQncyB0aGUgcmlnaHQgZml4LCBzaW5jZSB0 cnlfbW9kdWxlX2dldCBmb3IgZXZlcnkKPiA+IGRtYV9mZW5jZV9pbml0IGp1c3QgYWluJ3QgY29v bCByZWFsbHkgOi0pCj4gPiAtRGFuaWVsCj4gVGhhbmtzIGZvciB0aGUgZmVlZGJhY2ssIERhbmll bC4KPiBJIHNlZSB5b3VyIHBvaW50LCBidXQgSSBhbSBub3Qgc3VyZSBob3cgbXVjaCBpbXBhY3Qg YW4gZXh0cmEgcmVmY291bnRpbmcKPiB3b3VsZCBjcmVhdGUgY29uc2lkZXJpbmcgdGhlIHdob2xl IGVmZm9ydCBvZiBzZXR0aW5nIHVwIGEgbmV3IGZlbmNlLiBBbHNvLAo+IHRoaXMgcmVmY291bnRp bmcgaXMgbm90IHJlcXVpcmVkIGZvciBidWlsdC1pbiBtb2R1bGVzLgo+IAo+IEFzIG9mIG5vdywg dW5sb2FkaW5nIGEga2VybmVsIG1vZHVsZSB0aGF0IHVzZXMgZmVuY2VfaW5pdCgpIGlzIGFuIGVh c3kgd2F5Cj4gdG8gYnJpbmcgZG93biB0aGUgc3lzdGVtLiBUaGlzIHBhdGNoIHNpbXBseSBmaXhl cyB0aGF0LiBXaGF0IHlvdSBoYXZlCj4gc3VnZ2VzdGVkIHNvdW5kcyBsaWtlIGEgbm9uLXRyaXZp YWwgZWZmb3J0IHdoaWNoIHNvbWVvbmUgd2hvIGlzIG1vcmUKPiBmYW1pbGlhciB3aXRoIHRoaXMg Y29kZSBiYXNlIGNhbiBkbyBhIGJldHRlciBqb2IgdGhhbiBtZS4gUGVyaGFwcyB3ZSBjYW4KPiB0 YWtlIHRoaXMgcGF0Y2ggbm93IHRvIGZpeCB0aGUgaXNzdWUgYXQgaGFuZCBhbmQgbGF0ZXIgc29t ZWJvZHkgZWxzZSBjYW4KPiBzaGFyZSBhIG1vcmUgb3B0aW1hbCBzb2x1dGlvbi4gOikKCk1vZHVs ZSB1bmxvYWQgaXMgYSBkZXZlbG9wZXItb25seSBmZWF0dXJlIGZvciBhIHJlYXNvbi4gR2l2ZW4g dGhhdCBJIGRvbid0CnRoaW5rIGZpeGluZyB0aGlzIHdpdGggYSBoYWNrIGlzIHRoZSByaWdodCBh cHByb2FjaC4gQW5kIGRtYV9mZW5jZV9pbml0KCkKaXMgc3VwcG9zZWQgdG8gYmUgcmVhbGx5IGZh c3QuCgpBbHNvIG5vdGUgdGhhdCB5b3UgY2FuIGZpeCB0aGlzIGFscmVhZHkgZm9yIHlvdXIgb3du IGRyaXZlciBieSBzaW1wbHkKd2FpdGluZyBmb3IgYWxsIHBlbmRpbmcgZG1hX2ZlbmNlcyB0byBn ZXQgcmVsZWFzZWQsIHNvIEkgZG9uJ3QgdGhpbmsgaXQncwpzdXBlci1pbXBvcnRhbnQgdG8gbGFu ZCB0aGlzIGFzYXAuCgpZZXMgdGhlIHJlYWwgZml4IGlzIGEgYml0IG1vcmUgaW52b2x2ZWQsIGJ1 dCBzaG91bGRuJ3QgYmUgdG9vIGhhcmQgdG8gcHVsbApvZmYgcmVhbGx5LgotRGFuaWVsCgo+IAo+ IEBHdXN0YXZvICYgQFN1bWl0LCBJIHdvdWxkIGxpa2UgdGhlIG1haW50YWluZXJzIHRvIHRha2Ug YSBkZWNpc2lvbiBoZXJlLgo+IAo+IC1Ba2hpbC4KCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18KPiBkcmktZGV2ZWwgbWFpbGluZyBsaXN0Cj4gZHJpLWRl dmVsQGxpc3RzLmZyZWVkZXNrdG9wLm9yZwo+IGh0dHBzOi8vbGlzdHMuZnJlZWRlc2t0b3Aub3Jn L21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCgoKLS0gCkRhbmllbCBWZXR0ZXIKU29mdHdhcmUg RW5naW5lZXIsIEludGVsIENvcnBvcmF0aW9uCmh0dHA6Ly9ibG9nLmZmd2xsLmNoCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmRyaS1kZXZlbCBtYWlsaW5n IGxpc3QKZHJpLWRldmVsQGxpc3RzLmZyZWVkZXNrdG9wLm9yZwpodHRwczovL2xpc3RzLmZyZWVk ZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1kZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-ed1-f68.google.com ([209.85.208.68]:46926 "EHLO mail-ed1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932189AbeFZIRp (ORCPT ); Tue, 26 Jun 2018 04:17:45 -0400 Received: by mail-ed1-f68.google.com with SMTP id r17-v6so428661edo.13 for ; Tue, 26 Jun 2018 01:17:44 -0700 (PDT) Date: Tue, 26 Jun 2018 10:17:40 +0200 From: Daniel Vetter To: Akhil P Oommen Cc: Chris Wilson , Gustavo Padovan , sumit.semwal@linaro.org, jcrouse@codeaurora.org, linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, smasetty@codeaurora.org Subject: Re: [PATCH v2] dma-buf/fence: Take refcount on the module that owns the fence Message-ID: <20180626081740.GT2958@phenom.ffwll.local> References: <1529660407-6266-1-git-send-email-akhilpo@codeaurora.org> <1529661856.7034.404.camel@padovan.org> <152966212844.11773.6596589902326100250@mail.alporthouse.com> <20180625075040.GK2958@phenom.ffwll.local> <82f8e976-2a5a-56df-28bb-c75314824bf6@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <82f8e976-2a5a-56df-28bb-c75314824bf6@codeaurora.org> Sender: linux-media-owner@vger.kernel.org List-ID: On Mon, Jun 25, 2018 at 09:21:15PM +0530, Akhil P Oommen wrote: > > > On 6/25/2018 1:20 PM, Daniel Vetter wrote: > > On Fri, Jun 22, 2018 at 11:08:48AM +0100, Chris Wilson wrote: > > > Quoting Gustavo Padovan (2018-06-22 11:04:16) > > > > Hi Akhil, > > > > > > > > On Fri, 2018-06-22 at 15:10 +0530, Akhil P Oommen wrote: > > > > > Each fence object holds function pointers of the module that > > > > > initialized > > > > > it. Allowing the module to unload before this fence's release is > > > > > catastrophic. So, keep a refcount on the module until the fence is > > > > > released. > > > > > > > > > > Signed-off-by: Akhil P Oommen > > > > > --- > > > > > Changes in v2: > > > > > - added description for the new function parameter. > > > > > > > > > > drivers/dma-buf/dma-fence.c | 16 +++++++++++++--- > > > > > include/linux/dma-fence.h | 10 ++++++++-- > > > > > 2 files changed, 21 insertions(+), 5 deletions(-) > > > > > > > > > > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma- > > > > > fence.c > > > > > index 4edb9fd..2aaa44e 100644 > > > > > --- a/drivers/dma-buf/dma-fence.c > > > > > +++ b/drivers/dma-buf/dma-fence.c > > > > > @@ -18,6 +18,7 @@ > > > > > * more details. > > > > > */ > > > > > +#include > > > > > #include > > > > > #include > > > > > #include > > > > > @@ -168,6 +169,7 @@ void dma_fence_release(struct kref *kref) > > > > > { > > > > > struct dma_fence *fence = > > > > > container_of(kref, struct dma_fence, refcount); > > > > > + struct module *module = fence->owner; > > > > > trace_dma_fence_destroy(fence); > > > > > @@ -178,6 +180,8 @@ void dma_fence_release(struct kref *kref) > > > > > fence->ops->release(fence); > > > > > else > > > > > dma_fence_free(fence); > > > > > + > > > > > + module_put(module); > > > > > } > > > > > EXPORT_SYMBOL(dma_fence_release); > > > > > @@ -541,6 +545,7 @@ struct default_wait_cb { > > > > > /** > > > > > * dma_fence_init - Initialize a custom fence. > > > > > + * @module: [in] the module that calls this API > > > > > * @fence: [in] the fence to initialize > > > > > * @ops: [in] the dma_fence_ops for operations on this > > > > > fence > > > > > * @lock: [in] the irqsafe spinlock to use for locking > > > > > this fence > > > > > @@ -556,8 +561,9 @@ struct default_wait_cb { > > > > > * to check which fence is later by simply using dma_fence_later. > > > > > */ > > > > > void > > > > > -dma_fence_init(struct dma_fence *fence, const struct dma_fence_ops > > > > > *ops, > > > > > - spinlock_t *lock, u64 context, unsigned seqno) > > > > > +_dma_fence_init(struct module *module, struct dma_fence *fence, > > > > > + const struct dma_fence_ops *ops, spinlock_t *lock, > > > > > + u64 context, unsigned seqno) > > > > > { > > > > > BUG_ON(!lock); > > > > > BUG_ON(!ops || !ops->wait || !ops->enable_signaling || > > > > > @@ -571,7 +577,11 @@ struct default_wait_cb { > > > > > fence->seqno = seqno; > > > > > fence->flags = 0UL; > > > > > fence->error = 0; > > > > > + fence->owner = module; > > > > > + > > > > > + if (!try_module_get(module)) > > > > > + fence->owner = NULL; > > > > > trace_dma_fence_init(fence); > > > > > } > > > > > -EXPORT_SYMBOL(dma_fence_init); > > > > > +EXPORT_SYMBOL(_dma_fence_init); > > > > Do we still need to export the symbol, it won't be called from outside > > > > anymore? Other than that looks good to me: > > > There's a big drawback in that a module reference is often insufficient, > > > and that a reference on the driver (or whatever is required for the > > > lifetime of the fence) will already hold the module reference. > > > > > > Considering that we want a few 100k fences in flight per second, is > > > there no other way to only export a fence with a module reference? > > We'd need to make the timeline a full-blown object (Maarten owes me one > > for that design screw-up), and then we could stuff all these things in > > there. > > > > And I think that's the right fix, since try_module_get for every > > dma_fence_init just ain't cool really :-) > > -Daniel > Thanks for the feedback, Daniel. > I see your point, but I am not sure how much impact an extra refcounting > would create considering the whole effort of setting up a new fence. Also, > this refcounting is not required for built-in modules. > > As of now, unloading a kernel module that uses fence_init() is an easy way > to bring down the system. This patch simply fixes that. What you have > suggested sounds like a non-trivial effort which someone who is more > familiar with this code base can do a better job than me. Perhaps we can > take this patch now to fix the issue at hand and later somebody else can > share a more optimal solution. :) Module unload is a developer-only feature for a reason. Given that I don't think fixing this with a hack is the right approach. And dma_fence_init() is supposed to be really fast. Also note that you can fix this already for your own driver by simply waiting for all pending dma_fences to get released, so I don't think it's super-important to land this asap. Yes the real fix is a bit more involved, but shouldn't be too hard to pull off really. -Daniel > > @Gustavo & @Sumit, I would like the maintainers to take a decision here. > > -Akhil. > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch