linux-kernel - Re: [PATCH v3 2/2] block-dma: properly take MMIO path

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251027074922.GA14543@lst.de>
Date: Mon, 27 Oct 2025 08:49:22 +0100
From: Christoph Hellwig <hch@....de>
To: Leon Romanovsky <leon@...nel.org>
Cc: Jens Axboe <axboe@...nel.dk>, Keith Busch <kbusch@...nel.org>,
	Christoph Hellwig <hch@....de>, Sagi Grimberg <sagi@...mberg.me>,
	linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-nvme@...ts.infradead.org
Subject: Re: [PATCH v3 2/2] block-dma: properly take MMIO path

> +	switch (iter.p2pdma.map) {
> +	case PCI_P2PDMA_MAP_BUS_ADDR:
> +		iod->flags |= IOD_DATA_P2P;
> +		break;
> +	case PCI_P2PDMA_MAP_THRU_HOST_BRIDGE:
> +		iod->flags |= IOD_DATA_MMIO;
> +		break;
> +	default:
> +		return BLK_STS_RESOURCE;

I almost wonder if we should just the pci_p2pdma_map_type values into
place.  But that's a future cleanup, I'd rather get this going now.

> +static inline bool blk_rq_dma_unmap(struct request *req, struct device *dma_dev,
> +		struct dma_iova_state *state, size_t mapped_len,
> +		enum pci_p2pdma_map_type map)
>  {
> -	if (is_p2p)
> +	if (map == PCI_P2PDMA_MAP_BUS_ADDR)
>  		return true;
>  
>  	if (dma_use_iova(state)) {
> +		unsigned int attrs = 0;
> +
> +		if (map == PCI_P2PDMA_MAP_THRU_HOST_BRIDGE)
> +			attrs |= DMA_ATTR_MMIO;
> +
>  		dma_iova_destroy(dma_dev, state, mapped_len, rq_dma_dir(req),
> -				 0);
> +				 attrs);

The only thing in req that is used now is the data directrion.  I'd be
almost tempted to just pass that and lift this to dma-mapping.h.

But I guess we could just do that in a follow on to not drag in
another subsystem.

Otherwise looks good:

Reviewed-by: Christoph Hellwig <hch@....de>