linux-kernel - Re: [RFC PATCH 4/5] iommu/dma: Export non-static functions to use in modules

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]

Date:   Wed, 5 Jul 2017 17:22:06 +0100
From:   Robin Murphy <robin.murphy@....com>
To:     Tomasz Figa <tfiga@...omium.org>, iommu@...ts.linux-foundation.org
Cc:     linux-kernel@...r.kernel.org, Christoph Hellwig <hch@....de>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Joerg Roedel <joro@...tes.org>,
        Will Deacon <will.deacon@....com>,
        Vineet Gupta <vgupta@...opsys.com>,
        Hans-Christian Noren Egtvedt <egtvedt@...fundet.no>,
        Mitchel Humpherys <mitchelh@...eaurora.org>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Arnd Bergmann <arnd@...db.de>
Subject: Re: [RFC PATCH 4/5] iommu/dma: Export non-static functions to use in
 modules

On 05/07/17 08:12, Tomasz Figa wrote:
> There is nothing wrong in having a loadable module implementing DMA API,
> for example to be used for sub-devices registered by the module. However,
> most of the functions from dma-iommu do not have their symbols exported,
> making it impossible to use them from loadable modules.
> 
> Export all the non-static functions in the file, so that loadable modules
> can benefit from them. Use EXPORT_SYMBOL() for consistency with other
> exports in the file.

To echo what Christoph said, everything not already exported here
shouldn't in any way be considered a driver-facing API in the general
sense, it's horrible glue code to sit behind an arch-specific DMA
mapping implementation (and frankly I'd consider even the current
exports more of an unfortunate abstraction leakage).

> Signed-off-by: Tomasz Figa <tfiga@...omium.org>
> ---

[...]

> @@ -829,17 +838,20 @@ dma_addr_t iommu_dma_map_resource(struct device *dev, phys_addr_t phys,
>  	return __iommu_dma_map(dev, phys, size,
>  			dma_info_to_prot(dir, false, attrs) | IOMMU_MMIO);
>  }
> +EXPORT_SYMBOL(iommu_dma_map_resource);
>  
>  void iommu_dma_unmap_resource(struct device *dev, dma_addr_t handle,
>  		size_t size, enum dma_data_direction dir, unsigned long attrs)
>  {
>  	__iommu_dma_unmap(iommu_get_domain_for_dev(dev), handle, size);
>  }
> +EXPORT_SYMBOL(iommu_dma_unmap_resource);

Do you need these two? Unless your custom DMA ops really have to support
slave DMA or other peer-to-peer traffic through their IOMMU, I'd be more
inclined to implement dma_map_resource as "return 0;" and ignore
dma_unmap_resource.

> @@ -913,3 +925,4 @@ void iommu_dma_map_msi_msg(int irq, struct msi_msg *msg)
>  		msg->address_lo += lower_32_bits(msi_page->iova);
>  	}
>  }
> +EXPORT_SYMBOL(iommu_dma_map_msi_msg);

Given the nature of the kind of irqchip drivers this exists for, the
chances of one ever being modular seem vanishingly small.

Robin.