From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Christian_K=c3=b6nig?= Subject: Re: [PATCH 01/12] dma-buf: add dynamic caching of sg_table Date: Wed, 22 May 2019 19:27:59 +0200 Message-ID: References: <20190416183841.1577-1-christian.koenig@amd.com> <1556323269-19670-1-git-send-email-lmark@codeaurora.org> Reply-To: christian.koenig@amd.com Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Sumit Semwal , Liam Mark Cc: Linaro MM SIG , "open list:DMA BUFFER SHARING FRAMEWORK" , DRI mailing list , amd-gfx list , LKML List-Id: amd-gfx.lists.freedesktop.org QW0gMjIuMDUuMTkgdW0gMTg6MTcgc2NocmllYiBTdW1pdCBTZW13YWw6Cj4gSGkgQ2hyaXN0aWFu LAo+Cj4gT24gU2F0LCAyNyBBcHIgMjAxOSBhdCAwNTozMSwgTGlhbSBNYXJrIDxsbWFya0Bjb2Rl YXVyb3JhLm9yZz4gd3JvdGU6Cj4+IE9uIFR1ZSwgMTYgQXByIDIwMTksIENocmlzdGlhbiBLw7Zu aWcgd3JvdGU6Cj4+Cj4+PiBUbyBhbGxvdyBhIHNtb290aCB0cmFuc2l0aW9uIGZyb20gcGlubmlu ZyBidWZmZXIgb2JqZWN0cyB0byBkeW5hbWljCj4+PiBpbnZhbGlkYXRpb24gd2UgZmlyc3Qgc3Rh cnQgdG8gY2FjaGUgdGhlIHNnX3RhYmxlIGZvciBhbiBhdHRhY2htZW50Cj4+PiB1bmxlc3MgdGhl IGRyaXZlciBleHBsaWNpdGx5IHNheXMgdG8gbm90IGRvIHNvLgo+Pj4KPj4+IC0tLQo+Pj4gICBk cml2ZXJzL2RtYS1idWYvZG1hLWJ1Zi5jIHwgMjQgKysrKysrKysrKysrKysrKysrKysrKysrCj4+ PiAgIGluY2x1ZGUvbGludXgvZG1hLWJ1Zi5oICAgfCAxMSArKysrKysrKysrKwo+Pj4gICAyIGZp bGVzIGNoYW5nZWQsIDM1IGluc2VydGlvbnMoKykKPj4+Cj4+PiBkaWZmIC0tZ2l0IGEvZHJpdmVy cy9kbWEtYnVmL2RtYS1idWYuYyBiL2RyaXZlcnMvZG1hLWJ1Zi9kbWEtYnVmLmMKPj4+IGluZGV4 IDdjODU4MDIwZDE0Yi4uNjUxNjFhODJkNGQ1IDEwMDY0NAo+Pj4gLS0tIGEvZHJpdmVycy9kbWEt YnVmL2RtYS1idWYuYwo+Pj4gKysrIGIvZHJpdmVycy9kbWEtYnVmL2RtYS1idWYuYwo+Pj4gQEAg LTU3Myw2ICs1NzMsMjAgQEAgc3RydWN0IGRtYV9idWZfYXR0YWNobWVudCAqZG1hX2J1Zl9hdHRh Y2goc3RydWN0IGRtYV9idWYgKmRtYWJ1ZiwKPj4+ICAgICAgICBsaXN0X2FkZCgmYXR0YWNoLT5u b2RlLCAmZG1hYnVmLT5hdHRhY2htZW50cyk7Cj4+Pgo+Pj4gICAgICAgIG11dGV4X3VubG9jaygm ZG1hYnVmLT5sb2NrKTsKPj4+ICsKPj4+ICsgICAgIGlmICghZG1hYnVmLT5vcHMtPmR5bmFtaWNf c2d0X21hcHBpbmcpIHsKPj4+ICsgICAgICAgICAgICAgc3RydWN0IHNnX3RhYmxlICpzZ3Q7Cj4+ PiArCj4+PiArICAgICAgICAgICAgIHNndCA9IGRtYWJ1Zi0+b3BzLT5tYXBfZG1hX2J1ZihhdHRh Y2gsIERNQV9CSURJUkVDVElPTkFMKTsKPj4+ICsgICAgICAgICAgICAgaWYgKCFzZ3QpCj4+PiAr ICAgICAgICAgICAgICAgICAgICAgc2d0ID0gRVJSX1BUUigtRU5PTUVNKTsKPj4+ICsgICAgICAg ICAgICAgaWYgKElTX0VSUihzZ3QpKSB7Cj4+PiArICAgICAgICAgICAgICAgICAgICAgZG1hX2J1 Zl9kZXRhY2goZG1hYnVmLCBhdHRhY2gpOwo+Pj4gKyAgICAgICAgICAgICAgICAgICAgIHJldHVy biBFUlJfQ0FTVChzZ3QpOwo+Pj4gKyAgICAgICAgICAgICB9Cj4+PiArICAgICAgICAgICAgIGF0 dGFjaC0+c2d0ID0gc2d0Owo+Pj4gKyAgICAgfQo+Pj4gKwo+Pj4gICAgICAgIHJldHVybiBhdHRh Y2g7Cj4+Pgo+Pj4gICBlcnJfYXR0YWNoOgo+Pj4gQEAgLTU5NSw2ICs2MDksMTAgQEAgdm9pZCBk bWFfYnVmX2RldGFjaChzdHJ1Y3QgZG1hX2J1ZiAqZG1hYnVmLCBzdHJ1Y3QgZG1hX2J1Zl9hdHRh Y2htZW50ICphdHRhY2gpCj4+PiAgICAgICAgaWYgKFdBUk5fT04oIWRtYWJ1ZiB8fCAhYXR0YWNo KSkKPj4+ICAgICAgICAgICAgICAgIHJldHVybjsKPj4+Cj4+PiArICAgICBpZiAoYXR0YWNoLT5z Z3QpCj4+PiArICAgICAgICAgICAgIGRtYWJ1Zi0+b3BzLT51bm1hcF9kbWFfYnVmKGF0dGFjaCwg YXR0YWNoLT5zZ3QsCj4+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IERNQV9CSURJUkVDVElPTkFMKTsKPj4+ICsKPj4+ICAgICAgICBtdXRleF9sb2NrKCZkbWFidWYt PmxvY2spOwo+Pj4gICAgICAgIGxpc3RfZGVsKCZhdHRhY2gtPm5vZGUpOwo+Pj4gICAgICAgIGlm IChkbWFidWYtPm9wcy0+ZGV0YWNoKQo+Pj4gQEAgLTYzMCw2ICs2NDgsOSBAQCBzdHJ1Y3Qgc2df dGFibGUgKmRtYV9idWZfbWFwX2F0dGFjaG1lbnQoc3RydWN0IGRtYV9idWZfYXR0YWNobWVudCAq YXR0YWNoLAo+Pj4gICAgICAgIGlmIChXQVJOX09OKCFhdHRhY2ggfHwgIWF0dGFjaC0+ZG1hYnVm KSkKPj4+ICAgICAgICAgICAgICAgIHJldHVybiBFUlJfUFRSKC1FSU5WQUwpOwo+Pj4KPj4+ICsg ICAgIGlmIChhdHRhY2gtPnNndCkKPj4+ICsgICAgICAgICAgICAgcmV0dXJuIGF0dGFjaC0+c2d0 Owo+Pj4gKwo+PiBJIGFtIGNvbmNlcm5lZCBieSB0aGlzIGNoYW5nZSB0byBtYWtlIGNhY2hpbmcg dGhlIHNnX3RhYmxlIHRoZSBkZWZhdWx0Cj4+IGJlaGF2aW9yIGFzIHRoaXMgd2lsbCByZXN1bHQg aW4gdGhlIGV4cG9ydGVyJ3MgbWFwX2RtYV9idWYvdW5tYXBfZG1hX2J1Zgo+PiBjYWxscyBhcmUg bm8gbG9uZ2VyIGJlaW5nIGNhbGxlZCBpbgo+PiBkbWFfYnVmX21hcF9hdHRhY2htZW50L2RtYV9i dWZfdW5tYXBfYXR0YWNobWVudC4KPiBQcm9iYWJseSB0aGlzIGNvbmNlcm4gZnJvbSBMaWFtIGdv dCBsb3N0IGJldHdlZW4gdmVyc2lvbnMgb2YgeW91cgo+IHBhdGNoZXM7IGNvdWxkIHdlIHBsZWFz ZSByZXF1ZXN0IGEgcmVwbHkgdG8gdGhlc2UgcG9pbnRzIGhlcmU/CgpTb3JyeSBJIGluZGVlZCBu ZXZlciBnb3QgdGhpcyBtYWlsLCBidXQgdGhpcyBpcyBhY3R1YWxseSBub3QgYW4gaXNzdWUgCmJl Y2F1c2UgRGFuaWVsIGhhZCBzaW1pbGFyIGNvbmNlcm5zIGFuZCB3ZSBkaWRuJ3QgbWFkZSB0aGlz IHRoZSBkZWZhdWx0IAppbiB0aGUgZmluYWwgdmVyc2lvbi4KCj4+IFRoaXMgc2VlbXMgY29uY2Vy bmluZyB0byBtZSBhcyBpdCBhcHBlYXJzIHRvIGlnbm9yZSB0aGUgY2FjaGUgbWFpbnRlbmFuY2UK Pj4gYXNwZWN0IG9mIHRoZSBtYXBfZG1hX2J1Zi91bm1hcF9kbWFfYnVmIGNhbGxzLgo+PiBGb3Ig ZXhhbXBsZSB3b24ndCB0aGlzIHBvdGVudGlhbGx5IGNhdXNlIGlzc3VlcyBmb3IgY2xpZW50cyBv ZiBJT04uCj4+Cj4+IElmIHdlIGhhZCB0aGUgZm9sbG93aW5nCj4+IC0gIzEgZG1hX2J1Zl9hdHRh Y2ggY29oZXJlbnRfZGV2aWNlCj4+IC0gIzIgZG1hX2J1ZiBhdHRhY2ggbm9uX2NvaGVyZW50X2Rl dmljZQo+PiAtICMzIGRtYV9idWZfbWFwX2F0dGFjaG1lbnQgbm9uX2NvaGVyZW50X2RldmljZQo+ PiAtICM0IG5vbl9jb2hlcmVudF9kZXZpY2Ugd3JpdGVzIHRvIGJ1ZmZlcgo+PiAtICM1IGRtYV9i dWZfdW5tYXBfYXR0YWNobWVudCBub25fY29oZXJlbnRfZGV2aWNlCj4+IC0gIzYgZG1hX2J1Zl9t YXBfYXR0YWNobWVudCBjb2hlcmVudF9kZXZpY2UKPj4gLSAjNyBjb2hlcmVudF9kZXZpY2UgcmVh ZHMgYnVmZmVyCj4+IC0gIzggZG1hX2J1Zl91bm1hcF9hdHRhY2htZW50IGNvaGVyZW50X2Rldmlj ZQo+Pgo+PiBUaGVyZSB3b3VsZG4ndCBiZSBhbnkgQ01PIGF0IHN0ZXAgIzUgYW55bW9yZSAoc3Bl Y2lmaWNhbGx5IG5vIGludmFsaWRhdGUpCj4+IHNvIG5vdyBhdCBzdGVwICM3IHRoZSBjb2hlcmVu dF9kZXZpY2UgY291bGQgcmVhZCBhIHN0YWxlIGNhY2hlIGxpbmUuCj4+Cj4+IEFsc28sIG5vdyBi eSBkZWZhdWx0IGRtYV9idWZfdW5tYXBfYXR0YWNobWVudCBubyBsb25nZXIgcmVtb3ZlcyB0aGUK Pj4gbWFwcGluZ3MgZnJvbSB0aGUgaW9tbXUsIHNvIG5vdyBieSBkZWZhdWx0IGRtYV9idWZfdW5t YXBfYXR0YWNobWVudCBpcyBub3QKPj4gZG9pbmcgd2hhdCBJIHdvdWxkIGV4cGVjdCBhbmQgY2xp ZW50cyBhcmUgbG9zaW5nIHRoZSBwb3RlbnRpYWwgc2FuZGJveGluZwo+PiBiZW5lZml0cyBvZiBy ZW1vdmluZyB0aGUgbWFwcGluZ3MuCj4+IFNob3VsZG4ndCB0aGlzIGNhY2hpbmcgYmVoYXZpb3Ig YmUgc29tZXRoaW5nIHRoYXQgY2xpZW50cyBvcHQgaW50byBpbnN0ZWFkCj4+IG9mIGJlaW5nIHRo ZSBkZWZhdWx0PwoKV2VsbCwgaXQgc2VlbXMgeW91IGFyZSBtYWtpbmcgaW5jb3JyZWN0IGFzc3Vt cHRpb25zIGFib3V0IHRoZSBjYWNoZSAKbWFpbnRlbmFuY2Ugb2YgRE1BLWJ1ZiBoZXJlLgoKQXQg bGVhc3QgZm9yIGFsbCBEUk0gZGV2aWNlcyBJJ20gYXdhcmUgb2YgbWFwcGluZy91bm1hcHBpbmcg YW4gCmF0dGFjaG1lbnQgZG9lcyAqTk9UKiBoYXZlIGFueSBjYWNoZSBtYWludGVuYW5jZSBpbXBs aWNhdGlvbnMuCgpFLmcuIHRoZSB1c2UgY2FzZSB5b3UgZGVzY3JpYmUgYWJvdmUgd291bGQgY2Vy dGFpbmx5IGZhaWwgd2l0aCBhbWRncHUsIApyYWRlb24sIG5vdXZlYXUgYW5kIGk5MTUgYmVjYXVz ZSBtYXBwaW5nIGEgRE1BLWJ1ZiBkb2Vzbid0IHN0b3AgdGhlIApleHBvcnRlciBmcm9tIHJlYWRp bmcvd3JpdGluZyB0byB0aGF0IGJ1ZmZlciAoanVzdCB0aGUgb3Bwb3NpdGUgYWN0dWFsbHkpLgoK QWxsIG9mIHRoZW0gYXNzdW1lIHBlcmZlY3RseSBjb2hlcmVudCBhY2Nlc3MgdG8gdGhlIHVuZGVy bHlpbmcgbWVtb3J5LiAKQXMgZmFyIGFzIEkga25vdyB0aGVyZSBpcyBubyBkb2N1bWVudGVkIGNh Y2hlIG1haW50ZW5hbmNlIHJlcXVpcmVtZW50cyAKZm9yIERNQS1idWYuCgpUaGUgSU9NTVUgY29u Y2VybiBvbiB0aGUgb3RoZXIgaGFuZCBpcyBjZXJ0YWlubHkgdmFsaWQgYW5kIEkgcGVyZmVjdGx5 IAphZ3JlZSB0aGF0IGtlZXBpbmcgdGhlIG1hcHBpbmcgdGltZSBhcyBzaG9ydCBhcyBwb3NzaWJs ZSBpcyBkZXNpcmFibGUuCgpSZWdhcmRzLApDaHJpc3RpYW4uCgo+PiBMaWFtCj4+Cj4+IFF1YWxj b21tIElubm92YXRpb24gQ2VudGVyLCBJbmMuIGlzIGEgbWVtYmVyIG9mIENvZGUgQXVyb3JhIEZv cnVtLAo+PiBhIExpbnV4IEZvdW5kYXRpb24gQ29sbGFib3JhdGl2ZSBQcm9qZWN0Cj4+Cj4gQmVz dCwKPiBTdW1pdC4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCmRyaS1kZXZlbCBtYWlsaW5nIGxpc3QKZHJpLWRldmVsQGxpc3RzLmZyZWVkZXNrdG9wLm9y ZwpodHRwczovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1kZXZl bA== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1666EC282CE for ; Wed, 22 May 2019 17:28:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id DBE5520863 for ; Wed, 22 May 2019 17:28:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="qSC/E8Xb" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729155AbfEVR2F (ORCPT ); Wed, 22 May 2019 13:28:05 -0400 Received: from mail-wm1-f65.google.com ([209.85.128.65]:53160 "EHLO mail-wm1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727499AbfEVR2E (ORCPT ); Wed, 22 May 2019 13:28:04 -0400 Received: by mail-wm1-f65.google.com with SMTP id y3so3055865wmm.2; Wed, 22 May 2019 10:28:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=reply-to:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=4S0Pec9BfD8kDwkly62E8kWNDoNmW+jmLXii0uHlq84=; b=qSC/E8Xb32KhkpZX/APfXdIGTG2h3A33Q295nP7KBI+d/zKZEyDPBic2fY/4AfElK1 CdqKD9m70g5/oyzWKpWUdlSzNrItRXf5+5B+Fbh9bc1ZnGcUBWBUmCCafNkw8ASARpx8 +3wtKHc/5RtFtzk2URnIEz+Wow7rsZNeI5c5bc3gGNKRkJc4Sdvxi2Uain6tG76D5Z3j S7JvBic6R/by6vzi3Md1y/JyCBwLE+CMci+2VQ26I8ANLdaoSzjcjV78UIUlYfM1twB8 x5VvrP1B+vxF/hxxIiPJCZ8iSVHx2g2I+CDq0Om7XzoGxOA4LKxCszYV7sMVfx58HQdm 8jww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:subject:to:cc:references:from :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding:content-language; bh=4S0Pec9BfD8kDwkly62E8kWNDoNmW+jmLXii0uHlq84=; b=FoSvT16Mu2LkrJrBDgJXLMQdPqjujG4oeTwiXRKYno44eoncIQ1jD2RM/HsHzmmOOY vVQ0030apyxFoDsvQNV9z9u5IWsQb6GSHd+PWy2OVfd9cJN/2AW6aWQriXApUl6loKHB baHXJVVxB7FTeBxVrHWsRpSK5cD3W6rQeea+7BRzkdh4SsQKP/J+gr5cCgP7/jLxyrZ4 Hy25rN7p1lirMudK1yarNyw3nPJV2CfeO4P31jjypHiciq4ICUm40dFosJtGTaYRQ3en ejoDwirMEtk8BsCk35mQZegLGV7qVtgthBPJzN0Pl6/WKZsfl3BIiWmSFH5z4QbLXK95 C64w== X-Gm-Message-State: APjAAAUk/ZG5dC7EcWHm+ArTovxsqCgVNNrcV4U4Q4REJzTs27ELDFdR 21vnoyy1YEka+UsjAIO/V9BmSX6r X-Google-Smtp-Source: APXvYqwD8IBhEolkceHyQXps2P8YYEE22P/lpAoZE3V2IX1M1/rT6DDluSpzupRRYXRQCKwANjBPQQ== X-Received: by 2002:a1c:a7cc:: with SMTP id q195mr8640694wme.53.1558546081898; Wed, 22 May 2019 10:28:01 -0700 (PDT) Received: from ?IPv6:2a02:908:1252:fb60:be8a:bd56:1f94:86e7? ([2a02:908:1252:fb60:be8a:bd56:1f94:86e7]) by smtp.gmail.com with ESMTPSA id m206sm8514022wmf.21.2019.05.22.10.28.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 May 2019 10:28:01 -0700 (PDT) Reply-To: christian.koenig@amd.com Subject: Re: [PATCH 01/12] dma-buf: add dynamic caching of sg_table To: Sumit Semwal , Liam Mark Cc: amd-gfx list , DRI mailing list , Linaro MM SIG , LKML , "open list:DMA BUFFER SHARING FRAMEWORK" References: <20190416183841.1577-1-christian.koenig@amd.com> <1556323269-19670-1-git-send-email-lmark@codeaurora.org> From: =?UTF-8?Q?Christian_K=c3=b6nig?= Message-ID: Date: Wed, 22 May 2019 19:27:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org Am 22.05.19 um 18:17 schrieb Sumit Semwal: > Hi Christian, > > On Sat, 27 Apr 2019 at 05:31, Liam Mark wrote: >> On Tue, 16 Apr 2019, Christian König wrote: >> >>> To allow a smooth transition from pinning buffer objects to dynamic >>> invalidation we first start to cache the sg_table for an attachment >>> unless the driver explicitly says to not do so. >>> >>> --- >>> drivers/dma-buf/dma-buf.c | 24 ++++++++++++++++++++++++ >>> include/linux/dma-buf.h | 11 +++++++++++ >>> 2 files changed, 35 insertions(+) >>> >>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c >>> index 7c858020d14b..65161a82d4d5 100644 >>> --- a/drivers/dma-buf/dma-buf.c >>> +++ b/drivers/dma-buf/dma-buf.c >>> @@ -573,6 +573,20 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf, >>> list_add(&attach->node, &dmabuf->attachments); >>> >>> mutex_unlock(&dmabuf->lock); >>> + >>> + if (!dmabuf->ops->dynamic_sgt_mapping) { >>> + struct sg_table *sgt; >>> + >>> + sgt = dmabuf->ops->map_dma_buf(attach, DMA_BIDIRECTIONAL); >>> + if (!sgt) >>> + sgt = ERR_PTR(-ENOMEM); >>> + if (IS_ERR(sgt)) { >>> + dma_buf_detach(dmabuf, attach); >>> + return ERR_CAST(sgt); >>> + } >>> + attach->sgt = sgt; >>> + } >>> + >>> return attach; >>> >>> err_attach: >>> @@ -595,6 +609,10 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach) >>> if (WARN_ON(!dmabuf || !attach)) >>> return; >>> >>> + if (attach->sgt) >>> + dmabuf->ops->unmap_dma_buf(attach, attach->sgt, >>> + DMA_BIDIRECTIONAL); >>> + >>> mutex_lock(&dmabuf->lock); >>> list_del(&attach->node); >>> if (dmabuf->ops->detach) >>> @@ -630,6 +648,9 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach, >>> if (WARN_ON(!attach || !attach->dmabuf)) >>> return ERR_PTR(-EINVAL); >>> >>> + if (attach->sgt) >>> + return attach->sgt; >>> + >> I am concerned by this change to make caching the sg_table the default >> behavior as this will result in the exporter's map_dma_buf/unmap_dma_buf >> calls are no longer being called in >> dma_buf_map_attachment/dma_buf_unmap_attachment. > Probably this concern from Liam got lost between versions of your > patches; could we please request a reply to these points here? Sorry I indeed never got this mail, but this is actually not an issue because Daniel had similar concerns and we didn't made this the default in the final version. >> This seems concerning to me as it appears to ignore the cache maintenance >> aspect of the map_dma_buf/unmap_dma_buf calls. >> For example won't this potentially cause issues for clients of ION. >> >> If we had the following >> - #1 dma_buf_attach coherent_device >> - #2 dma_buf attach non_coherent_device >> - #3 dma_buf_map_attachment non_coherent_device >> - #4 non_coherent_device writes to buffer >> - #5 dma_buf_unmap_attachment non_coherent_device >> - #6 dma_buf_map_attachment coherent_device >> - #7 coherent_device reads buffer >> - #8 dma_buf_unmap_attachment coherent_device >> >> There wouldn't be any CMO at step #5 anymore (specifically no invalidate) >> so now at step #7 the coherent_device could read a stale cache line. >> >> Also, now by default dma_buf_unmap_attachment no longer removes the >> mappings from the iommu, so now by default dma_buf_unmap_attachment is not >> doing what I would expect and clients are losing the potential sandboxing >> benefits of removing the mappings. >> Shouldn't this caching behavior be something that clients opt into instead >> of being the default? Well, it seems you are making incorrect assumptions about the cache maintenance of DMA-buf here. At least for all DRM devices I'm aware of mapping/unmapping an attachment does *NOT* have any cache maintenance implications. E.g. the use case you describe above would certainly fail with amdgpu, radeon, nouveau and i915 because mapping a DMA-buf doesn't stop the exporter from reading/writing to that buffer (just the opposite actually). All of them assume perfectly coherent access to the underlying memory. As far as I know there is no documented cache maintenance requirements for DMA-buf. The IOMMU concern on the other hand is certainly valid and I perfectly agree that keeping the mapping time as short as possible is desirable. Regards, Christian. >> Liam >> >> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, >> a Linux Foundation Collaborative Project >> > Best, > Sumit.