On 29 January 2015 at 21:17, Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> wrote: > 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. > Well, first up, of course the 'migration of backing storage' is an orthogonal problem to what this patchset attempts to do - in this, I am only try to make the relevant information available to the exporter. With that out of the way, some thoughts on what you mentioned: So, IF the exporter needs to support migration of backing storage, even when subsystem Y has mapped the buffer, the exporter knows this (because of the map_dma_buf() dma_buf_op) - and the attach() also is notified to / handled by the exporter. With this information, it could either: a) not let the subsystem Z attach (the 'simpler' approach), or b) hold enough state-information about the Z's attach request internally, then migrate the pages on the unmap_attachment() callback from the subsystem Y? (The exact details for this will need to be thought-of by exporters actually trying to do migration of pages, or delayed allocation, or such, though) > 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. Thanks for pointing that out; I guess we'd have to disallow the attachment which would make that happen. I can add this as another check in calc_constraints(). > >> > 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 :) > Another thanks for making me rack my puny brain on these scenarios! :) [though I strongly suspect I might not have done enough!] > -- > FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up > according to speedtest.net. BR, ~Sumit. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
