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: <20190115175418.GA11402@lst.de>
Date:   Tue, 15 Jan 2019 18:54:18 +0100
From:   Christoph Hellwig <hch@....de>
To:     Joerg Roedel <joro@...tes.org>
Cc:     Christoph Hellwig <hch@....de>,
        "Michael S . Tsirkin" <mst@...hat.com>,
        Jason Wang <jasowang@...hat.com>,
        Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
        Jens Axboe <axboe@...nel.dk>,
        virtualization@...ts.linux-foundation.org,
        linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
        iommu@...ts.linux-foundation.org, jfehlig@...e.com,
        jon.grimm@....com, brijesh.singh@....com, jroedel@...e.de
Subject: Re: [PATCH 2/3] dma: Introduce dma_max_mapping_size()

On Tue, Jan 15, 2019 at 05:23:22PM +0100, Joerg Roedel wrote:
> Right, I thought about that too, but didn't find a generic way to check
> for all the cases. There are various checks that could be done:
> 
> 	1) Check if SWIOTLB is initialized at all, if not, return
> 	   SIZE_MAX as the limit. This can't be checked from dma-direct
> 	   code right now, but could be easily implemented.

Yes, this is the low hanging fruit.

> 	2) Check for swiotlb=force needs to be done.
> 
> 	3) Check whether the device can access all of available RAM. I
> 	   have no idea how to check that in an architecture independent
> 	   way. It also has to take memory hotplug into account as well
> 	   as the DMA mask of the device.
> 
> 	   An easy approximation could be to omit the limit if the
> 	   dma-mask covers all of the physical address bits available
> 	   on the platform. It would require to pass the dma-mask as an
> 	   additional parameter like it is done in dma_supported().
> 
> Any better ideas for how to implement 3)?

And yeah, this is hard.  So I'd just go for the low hanging fruit
for now and only implement 1) with a comment mentioning that
we are a little pessimistic.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ