On Fri, Jan 09, 2026 at 10:10:57AM +0800, Ming Lei wrote:

On Thu, Jan 08, 2026 at 11:17:03AM +0100, Christoph Hellwig wrote:

...

On Thu, Jan 08, 2026 at 10:19:18AM +0800, Ming Lei wrote:

...

...

The feature is in no way nvme specific. nvme is just the initial underlying driver. It makes total sense to support this for any high performance block device, and to pass it through file systems.

But why does FS care the dma buffer attachment? Since high performance host controller is exactly the dma buffer attachment point.

I can't parse what you're trying to say here.

dma buffer attachment is simply none of FS's business.

The file systems should indeed never do a dma buffer attachment itself, but that's not the point.

...

But even when not stacking, the registration still needs to go through the file system even for a single device, never mind multiple controlled by the file system.

dma_buf can have multiple importers, so why does it have to go through FS for single device only?

If the registered buffer is attached to single device before going through FS, it can not support stacking block device, and it can't or not easily to use for multiple block device, no matter if they are behind same host controller or multiple.

Because the file system, or the file_operations instance to be more specific, is the only entity that known what block device(s) or other DMA capable device(s) like (R)NIC a file maps to.