netdev - Re: [PATCH net-next] be2net: dma_sync each RX frag before passing it to the stack

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

Message-Id: <20140304.161955.131076054982575581.davem@davemloft.net>
Date:	Tue, 04 Mar 2014 16:19:55 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	sathya.perla@...lex.com
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH net-next] be2net: dma_sync each RX frag before passing
 it to the stack

From: Sathya Perla <sathya.perla@...lex.com>
Date: Tue, 4 Mar 2014 12:14:38 +0530

> The driver currently maps a page for DMA, divides the page into multiple
> frags and posts them to the HW. It un-maps the page after data is received
> on all the frags of the page. This scheme doesn't work when bounce buffers
> are used for DMA (swiotlb=force kernel param).
> 
> This patch fixes this problem by calling dma_sync_single_for_cpu() for each
> frag (excepting the last one) so that the data is copied from the bounce
> buffers. The page is un-mapped only when DMA finishes on the last frag of
> the page.
> (Thanks Ben H. for suggesting the dma_sync API!)
> 
> This patch also renames the "last_page_user" field of be_rx_page_info{}
> struct to "last_frag" to improve readability of the fixed code.
> 
> Reported-by: Li Fengmao <li.fengmao@....com.cn>
> Signed-off-by: Sathya Perla <sathya.perla@...lex.com>
> ---
> 
> Dave, I'm guessing the swiotlb option is not used much(?). So, this patch
> is not a critical fix and is a better fit for the net-next tree. Thanks.

It matters on platforms where dma sync'ing is necessary to achieve
hardware coherence.

All of Sparc64 PCI implementations fall into this category, because
there is a prefetching cache that sits on the front end of the PCI
complex, working in concert with the IOMMU.

Some PowerPC embedded platforms need to do DMA synchronization flushes
too for a similar reason.

But yes these are uncommon configurations so I agree this should go
to net-next.

Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html