From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755745AbbA2Prf (ORCPT ); Thu, 29 Jan 2015 10:47:35 -0500 Received: from pandora.arm.linux.org.uk ([78.32.30.218]:34439 "EHLO pandora.arm.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752955AbbA2Prd (ORCPT ); Thu, 29 Jan 2015 10:47:33 -0500 Date: Thu, 29 Jan 2015 15:47:18 +0000 From: Russell King - ARM Linux To: Sumit Semwal Cc: LKML , "linux-media@vger.kernel.org" , DRI mailing list , Linaro MM SIG Mailman List , "linux-arm-kernel@lists.infradead.org" , "linux-mm@kvack.org" , Linaro Kernel Mailman List , Tomasz Stanislawski , Rob Clark , Daniel Vetter , Robin Murphy , Marek Szyprowski Subject: Re: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms Message-ID: <20150129154718.GB26493@n2100.arm.linux.org.uk> References: <1422347154-15258-1-git-send-email-sumit.semwal@linaro.org> <1422347154-15258-2-git-send-email-sumit.semwal@linaro.org> <20150129143908.GA26493@n2100.arm.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 29, 2015 at 09:00:11PM +0530, Sumit Semwal wrote: > So, short answer is, it is left to the exporter to decide. The dma-buf > framework should not even attempt to decide or enforce any of the > above. > > At each dma_buf_attach(), there's a callback to the exporter, where > the exporter can decide, if it intends to handle these kind of cases, > on the best way forward. > > The exporter might, for example, decide to migrate backing storage, That's a decision which the exporter can not take. Think about it... If subsystem Y has mapped the buffer, it could be accessing the buffer's backing storage at the same time that subsystem Z tries to attach to the buffer. Once the buffer has been exported to another user, the exporter has effectively lost control over mediating accesses to that buffer. All that it can do with the way the dma-buf API is today is to allocate a _different_ scatter list pointing at the same backing storage which satisfies the segment size and number of segments, etc. There's also another issue which you haven't addressed. What if several attachments result in lowering max_segment_size and max_segment_count such that: max_segment_size * max_segment_count < dmabuf->size but individually, the attachments allow dmabuf->size to be represented as a scatterlist? If an exporter were to take notice of the max_segment_size and max_segment_count, the resulting buffer is basically unrepresentable as a scatterlist. > > Please consider the possible sequences of use (such as the scenario > > above) when creating or augmenting an API. > > > > I tried to think of the scenarios I could think of, but If you still > feel this approach doesn't help with your concerns, I'll graciously > accept advice to improve it. See the new one above :) -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from pandora.arm.linux.org.uk ([78.32.30.218]:34439 "EHLO pandora.arm.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752955AbbA2Prd (ORCPT ); Thu, 29 Jan 2015 10:47:33 -0500 Date: Thu, 29 Jan 2015 15:47:18 +0000 From: Russell King - ARM Linux To: Sumit Semwal Cc: LKML , "linux-media@vger.kernel.org" , DRI mailing list , Linaro MM SIG Mailman List , "linux-arm-kernel@lists.infradead.org" , "linux-mm@kvack.org" , Linaro Kernel Mailman List , Tomasz Stanislawski , Rob Clark , Daniel Vetter , Robin Murphy , Marek Szyprowski Subject: Re: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms Message-ID: <20150129154718.GB26493@n2100.arm.linux.org.uk> References: <1422347154-15258-1-git-send-email-sumit.semwal@linaro.org> <1422347154-15258-2-git-send-email-sumit.semwal@linaro.org> <20150129143908.GA26493@n2100.arm.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-media-owner@vger.kernel.org List-ID: On Thu, Jan 29, 2015 at 09:00:11PM +0530, Sumit Semwal wrote: > So, short answer is, it is left to the exporter to decide. The dma-buf > framework should not even attempt to decide or enforce any of the > above. > > At each dma_buf_attach(), there's a callback to the exporter, where > the exporter can decide, if it intends to handle these kind of cases, > on the best way forward. > > The exporter might, for example, decide to migrate backing storage, That's a decision which the exporter can not take. Think about it... If subsystem Y has mapped the buffer, it could be accessing the buffer's backing storage at the same time that subsystem Z tries to attach to the buffer. Once the buffer has been exported to another user, the exporter has effectively lost control over mediating accesses to that buffer. All that it can do with the way the dma-buf API is today is to allocate a _different_ scatter list pointing at the same backing storage which satisfies the segment size and number of segments, etc. There's also another issue which you haven't addressed. What if several attachments result in lowering max_segment_size and max_segment_count such that: max_segment_size * max_segment_count < dmabuf->size but individually, the attachments allow dmabuf->size to be represented as a scatterlist? If an exporter were to take notice of the max_segment_size and max_segment_count, the resulting buffer is basically unrepresentable as a scatterlist. > > Please consider the possible sequences of use (such as the scenario > > above) when creating or augmenting an API. > > > > I tried to think of the scenarios I could think of, but If you still > feel this approach doesn't help with your concerns, I'll graciously > accept advice to improve it. See the new one above :) -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) by kanga.kvack.org (Postfix) with ESMTP id A6E806B0081 for ; Thu, 29 Jan 2015 10:47:37 -0500 (EST) Received: by mail-wi0-f169.google.com with SMTP id h11so11741446wiw.0 for ; Thu, 29 Jan 2015 07:47:37 -0800 (PST) Received: from pandora.arm.linux.org.uk (pandora.arm.linux.org.uk. [2001:4d48:ad52:3201:214:fdff:fe10:1be6]) by mx.google.com with ESMTPS id ce3si1435121wib.0.2015.01.29.07.47.35 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 29 Jan 2015 07:47:36 -0800 (PST) Date: Thu, 29 Jan 2015 15:47:18 +0000 From: Russell King - ARM Linux Subject: Re: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms Message-ID: <20150129154718.GB26493@n2100.arm.linux.org.uk> References: <1422347154-15258-1-git-send-email-sumit.semwal@linaro.org> <1422347154-15258-2-git-send-email-sumit.semwal@linaro.org> <20150129143908.GA26493@n2100.arm.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Sumit Semwal Cc: LKML , "linux-media@vger.kernel.org" , DRI mailing list , Linaro MM SIG Mailman List , "linux-arm-kernel@lists.infradead.org" , "linux-mm@kvack.org" , Linaro Kernel Mailman List , Tomasz Stanislawski , Rob Clark , Daniel Vetter , Robin Murphy , Marek Szyprowski On Thu, Jan 29, 2015 at 09:00:11PM +0530, Sumit Semwal wrote: > So, short answer is, it is left to the exporter to decide. The dma-buf > framework should not even attempt to decide or enforce any of the > above. > > At each dma_buf_attach(), there's a callback to the exporter, where > the exporter can decide, if it intends to handle these kind of cases, > on the best way forward. > > The exporter might, for example, decide to migrate backing storage, That's a decision which the exporter can not take. Think about it... If subsystem Y has mapped the buffer, it could be accessing the buffer's backing storage at the same time that subsystem Z tries to attach to the buffer. Once the buffer has been exported to another user, the exporter has effectively lost control over mediating accesses to that buffer. All that it can do with the way the dma-buf API is today is to allocate a _different_ scatter list pointing at the same backing storage which satisfies the segment size and number of segments, etc. There's also another issue which you haven't addressed. What if several attachments result in lowering max_segment_size and max_segment_count such that: max_segment_size * max_segment_count < dmabuf->size but individually, the attachments allow dmabuf->size to be represented as a scatterlist? If an exporter were to take notice of the max_segment_size and max_segment_count, the resulting buffer is basically unrepresentable as a scatterlist. > > Please consider the possible sequences of use (such as the scenario > > above) when creating or augmenting an API. > > > > I tried to think of the scenarios I could think of, but If you still > feel this approach doesn't help with your concerns, I'll graciously > accept advice to improve it. See the new one above :) -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: linux@arm.linux.org.uk (Russell King - ARM Linux) Date: Thu, 29 Jan 2015 15:47:18 +0000 Subject: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms In-Reply-To: References: <1422347154-15258-1-git-send-email-sumit.semwal@linaro.org> <1422347154-15258-2-git-send-email-sumit.semwal@linaro.org> <20150129143908.GA26493@n2100.arm.linux.org.uk> Message-ID: <20150129154718.GB26493@n2100.arm.linux.org.uk> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thu, Jan 29, 2015 at 09:00:11PM +0530, Sumit Semwal wrote: > So, short answer is, it is left to the exporter to decide. The dma-buf > framework should not even attempt to decide or enforce any of the > above. > > At each dma_buf_attach(), there's a callback to the exporter, where > the exporter can decide, if it intends to handle these kind of cases, > on the best way forward. > > The exporter might, for example, decide to migrate backing storage, That's a decision which the exporter can not take. Think about it... If subsystem Y has mapped the buffer, it could be accessing the buffer's backing storage at the same time that subsystem Z tries to attach to the buffer. Once the buffer has been exported to another user, the exporter has effectively lost control over mediating accesses to that buffer. All that it can do with the way the dma-buf API is today is to allocate a _different_ scatter list pointing at the same backing storage which satisfies the segment size and number of segments, etc. There's also another issue which you haven't addressed. What if several attachments result in lowering max_segment_size and max_segment_count such that: max_segment_size * max_segment_count < dmabuf->size but individually, the attachments allow dmabuf->size to be represented as a scatterlist? If an exporter were to take notice of the max_segment_size and max_segment_count, the resulting buffer is basically unrepresentable as a scatterlist. > > Please consider the possible sequences of use (such as the scenario > > above) when creating or augmenting an API. > > > > I tried to think of the scenarios I could think of, but If you still > feel this approach doesn't help with your concerns, I'll graciously > accept advice to improve it. See the new one above :) -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Russell King - ARM Linux Subject: Re: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms Date: Thu, 29 Jan 2015 15:47:18 +0000 Message-ID: <20150129154718.GB26493@n2100.arm.linux.org.uk> References: <1422347154-15258-1-git-send-email-sumit.semwal@linaro.org> <1422347154-15258-2-git-send-email-sumit.semwal@linaro.org> <20150129143908.GA26493@n2100.arm.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from pandora.arm.linux.org.uk (pandora.arm.linux.org.uk [78.32.30.218]) by gabe.freedesktop.org (Postfix) with ESMTP id F18AE6E7B2 for ; Thu, 29 Jan 2015 07:47:33 -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: Sumit Semwal Cc: Linaro Kernel Mailman List , Robin Murphy , LKML , DRI mailing list , Linaro MM SIG Mailman List , "linux-mm@kvack.org" , Marek Szyprowski , Tomasz Stanislawski , "linux-arm-kernel@lists.infradead.org" , "linux-media@vger.kernel.org" List-Id: dri-devel@lists.freedesktop.org T24gVGh1LCBKYW4gMjksIDIwMTUgYXQgMDk6MDA6MTFQTSArMDUzMCwgU3VtaXQgU2Vtd2FsIHdy b3RlOgo+IFNvLCBzaG9ydCBhbnN3ZXIgaXMsIGl0IGlzIGxlZnQgdG8gdGhlIGV4cG9ydGVyIHRv IGRlY2lkZS4gVGhlIGRtYS1idWYKPiBmcmFtZXdvcmsgc2hvdWxkIG5vdCBldmVuIGF0dGVtcHQg dG8gZGVjaWRlIG9yIGVuZm9yY2UgYW55IG9mIHRoZQo+IGFib3ZlLgo+IAo+IEF0IGVhY2ggZG1h X2J1Zl9hdHRhY2goKSwgdGhlcmUncyBhIGNhbGxiYWNrIHRvIHRoZSBleHBvcnRlciwgd2hlcmUK PiB0aGUgZXhwb3J0ZXIgY2FuIGRlY2lkZSwgaWYgaXQgaW50ZW5kcyB0byBoYW5kbGUgdGhlc2Ug a2luZCBvZiBjYXNlcywKPiBvbiB0aGUgYmVzdCB3YXkgZm9yd2FyZC4KPiAKPiBUaGUgZXhwb3J0 ZXIgbWlnaHQsIGZvciBleGFtcGxlLCBkZWNpZGUgdG8gbWlncmF0ZSBiYWNraW5nIHN0b3JhZ2Us CgpUaGF0J3MgYSBkZWNpc2lvbiB3aGljaCB0aGUgZXhwb3J0ZXIgY2FuIG5vdCB0YWtlLiAgVGhp bmsgYWJvdXQgaXQuLi4KCklmIHN1YnN5c3RlbSBZIGhhcyBtYXBwZWQgdGhlIGJ1ZmZlciwgaXQg Y291bGQgYmUgYWNjZXNzaW5nIHRoZSBidWZmZXIncwpiYWNraW5nIHN0b3JhZ2UgYXQgdGhlIHNh bWUgdGltZSB0aGF0IHN1YnN5c3RlbSBaIHRyaWVzIHRvIGF0dGFjaCB0byB0aGUKYnVmZmVyLgoK T25jZSB0aGUgYnVmZmVyIGhhcyBiZWVuIGV4cG9ydGVkIHRvIGFub3RoZXIgdXNlciwgdGhlIGV4 cG9ydGVyIGhhcwplZmZlY3RpdmVseSBsb3N0IGNvbnRyb2wgb3ZlciBtZWRpYXRpbmcgYWNjZXNz ZXMgdG8gdGhhdCBidWZmZXIuCgpBbGwgdGhhdCBpdCBjYW4gZG8gd2l0aCB0aGUgd2F5IHRoZSBk bWEtYnVmIEFQSSBpcyB0b2RheSBpcyB0byBhbGxvY2F0ZQphIF9kaWZmZXJlbnRfIHNjYXR0ZXIg bGlzdCBwb2ludGluZyBhdCB0aGUgc2FtZSBiYWNraW5nIHN0b3JhZ2Ugd2hpY2gKc2F0aXNmaWVz IHRoZSBzZWdtZW50IHNpemUgYW5kIG51bWJlciBvZiBzZWdtZW50cywgZXRjLgoKVGhlcmUncyBh bHNvIGFub3RoZXIgaXNzdWUgd2hpY2ggeW91IGhhdmVuJ3QgYWRkcmVzc2VkLiAgV2hhdCBpZiBz ZXZlcmFsCmF0dGFjaG1lbnRzIHJlc3VsdCBpbiBsb3dlcmluZyBtYXhfc2VnbWVudF9zaXplIGFu ZCBtYXhfc2VnbWVudF9jb3VudApzdWNoIHRoYXQ6CgoJbWF4X3NlZ21lbnRfc2l6ZSAqIG1heF9z ZWdtZW50X2NvdW50IDwgZG1hYnVmLT5zaXplCgpidXQgaW5kaXZpZHVhbGx5LCB0aGUgYXR0YWNo bWVudHMgYWxsb3cgZG1hYnVmLT5zaXplIHRvIGJlIHJlcHJlc2VudGVkCmFzIGEgc2NhdHRlcmxp c3Q/CgpJZiBhbiBleHBvcnRlciB3ZXJlIHRvIHRha2Ugbm90aWNlIG9mIHRoZSBtYXhfc2VnbWVu dF9zaXplIGFuZAptYXhfc2VnbWVudF9jb3VudCwgdGhlIHJlc3VsdGluZyBidWZmZXIgaXMgYmFz aWNhbGx5IHVucmVwcmVzZW50YWJsZQphcyBhIHNjYXR0ZXJsaXN0LgoKPiA+IFBsZWFzZSBjb25z aWRlciB0aGUgcG9zc2libGUgc2VxdWVuY2VzIG9mIHVzZSAoc3VjaCBhcyB0aGUgc2NlbmFyaW8K PiA+IGFib3ZlKSB3aGVuIGNyZWF0aW5nIG9yIGF1Z21lbnRpbmcgYW4gQVBJLgo+ID4KPiAKPiBJ IHRyaWVkIHRvIHRoaW5rIG9mIHRoZSBzY2VuYXJpb3MgSSBjb3VsZCB0aGluayBvZiwgYnV0IElm IHlvdSBzdGlsbAo+IGZlZWwgdGhpcyBhcHByb2FjaCBkb2Vzbid0IGhlbHAgd2l0aCB5b3VyIGNv bmNlcm5zLCBJJ2xsIGdyYWNpb3VzbHkKPiBhY2NlcHQgYWR2aWNlIHRvIGltcHJvdmUgaXQuCgpT ZWUgdGhlIG5ldyBvbmUgYWJvdmUgOikKCi0tIApGVFRDIGJyb2FkYmFuZCBmb3IgMC44bWlsZSBs aW5lOiBjdXJyZW50bHkgYXQgMTAuNU1icHMgZG93biA0MDBrYnBzIHVwCmFjY29yZGluZyB0byBz cGVlZHRlc3QubmV0LgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwpkcmktZGV2ZWwgbWFpbGluZyBsaXN0CmRyaS1kZXZlbEBsaXN0cy5mcmVlZGVza3RvcC5v cmcKaHR0cDovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1kZXZl bAo=