linux-kernel - Re: d63e2e1f3df breaks sparc/T5-8

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-next>] [day] [month] [year] [list]

Message-Id: <20150329.113250.2136683943336875789.davem@davemloft.net>
Date:	Sun, 29 Mar 2015 11:32:50 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	bjorn@...gaas.com, bjorn.helgaas@...il.com
Cc:	sparclinux@...r.kernel.org, linux-pci@...r.kernel.org,
	yinghai@...nel.org, david.ahern@...cle.com, bhelgaas@...gle.com,
	linux-kernel@...r.kernel.org
Subject: Re: d63e2e1f3df breaks sparc/T5-8

From: Bjorn Helgaas <bjorn.helgaas@...il.com>
Date: Sun, 29 Mar 2015 08:30:40 -0500

> Help me understand the sparc64 situation: are you saying that BAR
> addresses, i.e., MMIO transactions from a CPU or a peer-to-peer DMA can be
> 64 bits, but a DMA to main memory can only be 32 bits?
> 
> I assume this would work if we made dma_addr_t 64 bits on sparc64.  What
> would be the cost of doing that?

The cost is 4 extra bytes in every datastructure, kernel wide, that
stores DMA addresses.

This choice was very intentional, and well thought out.

Don't use DMA addresses for PCI addresses.  They are absolutely not
the same, especially when an IOMMU is always present because in that
case all DMA addresses are virtual and exist in a different realm
and set of constraints/restrictions.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/