linux-kernel - Re: [PATCH v6 12/19] swiotlb: don't assume that io_tlb_start-io_tlb

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: <20130930155617.GS3106@phenom.dumpdata.com>
Date:	Mon, 30 Sep 2013 11:56:17 -0400
From:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To:	Stefano Stabellini <stefano.stabellini@...citrix.com>
Cc:	xen-devel@...ts.xensource.com, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, Ian.Campbell@...rix.com
Subject: Re: [PATCH v6 12/19] swiotlb: don't assume that
 io_tlb_start-io_tlb_end is coherent

On Fri, Sep 27, 2013 at 05:10:00PM +0100, Stefano Stabellini wrote:
> The swiotlb code has appropriate calls to dma_mark_clean in place for
> buffers passed to swiotlb_map_page as an argument. However it assumes
> that the swiotlb bounce buffer (io_tlb_start-io_tlb_end) is already
> coherent and doesn't need any calls to dma_mark_clean.
> 
> On ARM the swiotlb bounce buffer is not coherent (the memory is
> writealloc while it should be bufferable) and therefore we need to call
> dma_mark_clean appropriately on the bounce buffer code paths too.
> 
> Note that most architecures have an empty dma_mark_clean implementation
> anyway.

The other architecture that uses swiotlb is IA64 and that does have
an implementation where it touches on page attributes.

Which means I have to figure out why my HP zx6000 won't boot with 3.11 now :-(

> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@...citrix.com>
> ---
>  lib/swiotlb.c |   13 ++++++++++---
>  1 files changed, 10 insertions(+), 3 deletions(-)
> 
> diff --git a/lib/swiotlb.c b/lib/swiotlb.c
> index 4e8686c..eb45d17 100644
> --- a/lib/swiotlb.c
> +++ b/lib/swiotlb.c
> @@ -515,6 +515,7 @@ found:
>  		io_tlb_orig_addr[index+i] = orig_addr + (i << IO_TLB_SHIFT);
>  	if (dir == DMA_TO_DEVICE || dir == DMA_BIDIRECTIONAL)
>  		swiotlb_bounce(orig_addr, tlb_addr, size, DMA_TO_DEVICE);
> +	dma_mark_clean(phys_to_virt(tlb_addr), size);
>  
>  	return tlb_addr;
>  }
> @@ -547,7 +548,10 @@ void swiotlb_tbl_unmap_single(struct device *hwdev, phys_addr_t tlb_addr,
>  	 * First, sync the memory before unmapping the entry
>  	 */
>  	if (orig_addr && ((dir == DMA_FROM_DEVICE) || (dir == DMA_BIDIRECTIONAL)))
> +	{
> +		dma_mark_clean(phys_to_virt(tlb_addr), size);
>  		swiotlb_bounce(orig_addr, tlb_addr, size, DMA_FROM_DEVICE);
> +	}
>  
>  	/*
>  	 * Return the buffer to the free list by setting the corresponding
> @@ -587,17 +591,20 @@ void swiotlb_tbl_sync_single(struct device *hwdev, phys_addr_t tlb_addr,
>  
>  	switch (target) {
>  	case SYNC_FOR_CPU:
> -		if (likely(dir == DMA_FROM_DEVICE || dir == DMA_BIDIRECTIONAL))
> +		if (likely(dir == DMA_FROM_DEVICE || dir == DMA_BIDIRECTIONAL)) {
> +			dma_mark_clean(phys_to_virt(tlb_addr), size);
>  			swiotlb_bounce(orig_addr, tlb_addr,
>  				       size, DMA_FROM_DEVICE);
> +		}
>  		else
>  			BUG_ON(dir != DMA_TO_DEVICE);
>  		break;
>  	case SYNC_FOR_DEVICE:
> -		if (likely(dir == DMA_TO_DEVICE || dir == DMA_BIDIRECTIONAL))
> +		if (likely(dir == DMA_TO_DEVICE || dir == DMA_BIDIRECTIONAL)) {
>  			swiotlb_bounce(orig_addr, tlb_addr,
>  				       size, DMA_TO_DEVICE);
> -		else
> +			dma_mark_clean(phys_to_virt(tlb_addr), size);
> +		} else
>  			BUG_ON(dir != DMA_FROM_DEVICE);
>  		break;
>  	default:
> -- 
> 1.7.2.5
> 
--
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/