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: <a5d8c24b-c605-8753-b022-ab959cf52340@arm.com>
Date:   Mon, 7 Dec 2020 20:32:16 +0000
From:   Robin Murphy <robin.murphy@....com>
To:     Vidya Sagar <vidyas@...dia.com>, jingoohan1@...il.com,
        gustavo.pimentel@...opsys.com, lorenzo.pieralisi@....com,
        bhelgaas@...gle.com, robh@...nel.org, treding@...dia.com,
        jonathanh@...dia.com
Cc:     linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
        kthota@...dia.com, mmaddireddy@...dia.com, sagar.tv@...il.com
Subject: Re: [PATCH] PCI: dwc: Set 32-bit DMA mask for MSI target address
 allocation

On 2020-11-17 16:53, Vidya Sagar wrote:
> Set DMA mask to 32-bit while allocating the MSI target address so that
> the address is usable for both 32-bit and 64-bit MSI capable devices.
> Throw a warning if it fails to set the mask to 32-bit to alert that
> devices that are only 32-bit MSI capable may not work properly.

This is slightly wacky, but no more so than the rest of the not-DMA 
shenanigans here... Ultimately it probably is the least-worst way to 
avoid the issue, so in terms of functionality,

Reviewed-by: Robin Murphy <robin.murphy@....com>

> Signed-off-by: Vidya Sagar <vidyas@...dia.com>
> ---
> Given the other patch that I've pushed to the MSI sub-system
> http://patchwork.ozlabs.org/project/linux-pci/patch/20201117145728.4516-1-vidyas@nvidia.com/
> which is going to catch any mismatch between MSI capability (32-bit) of the
> device and system's inability to allocate the required MSI target address,
> I'm not sure how much sense is this patch going to be make. But, I can
> certainly say that if the memory allocation mechanism gives the addresses
> from 64-bit pool by default, this patch at least makes sure that MSI target
> address is allocated from 32-bit pool.

Note that this doesn't change where anything is allocated as such, it 
just means that on systems with most of their RAM above 4GB, those few 
bytes of private data that you map "for free" will be copied into the 
SWIOTLB buffer and hog 2KB of its typical 64MB capacity effectively for 
ever.

>   drivers/pci/controller/dwc/pcie-designware-host.c | 8 ++++++++
>   1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
> index 44c2a6572199..e6a230eddf66 100644
> --- a/drivers/pci/controller/dwc/pcie-designware-host.c
> +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
> @@ -388,6 +388,14 @@ int dw_pcie_host_init(struct pcie_port *pp)
>   							    dw_chained_msi_isr,
>   							    pp);
>   
> +			ret = dma_set_mask(pci->dev, DMA_BIT_MASK(32));
> +			if (!ret) {
> +				dev_warn(pci->dev,
> +					 "Failed to set DMA mask to 32-bit. "
> +					 "Devices with only 32-bit MSI support"
> +					 " may not work properly\n");
> +			}

Ironically, the only real reason for that dma_set_mask() to ever fail is 
if the system had no 32-bit addressable memory, in which case you could 
likely pick any 32-bit doorbell address with impunity, just not via this 
mechanism (although whether it would be worthwhile is another matter).

Robin.

> +
>   			pp->msi_data = dma_map_single_attrs(pci->dev, &pp->msi_msg,
>   						      sizeof(pp->msi_msg),
>   						      DMA_FROM_DEVICE,
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ