netdev - Re: [PATCH] net: marvell: mvneta: fix DMA debug warning

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]

Date:   Fri, 15 Feb 2019 17:05:07 +0000
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     Gregory CLEMENT <gregory.clement@...tlin.com>
Cc:     Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH] net: marvell: mvneta: fix DMA debug warning

On Fri, Feb 15, 2019 at 03:31:06PM +0100, Gregory CLEMENT wrote:
> Hi Russell,
>  
>  On ven., févr. 15 2019, Russell King <rmk+kernel@...linux.org.uk> wrote:
> 
> > Booting 4.20 on SolidRun Clearfog issues this warning with DMA API
> > debug enabled:
> >
> > WARNING: CPU: 0 PID: 555 at kernel/dma/debug.c:1230 check_sync+0x514/0x5bc
> > mvneta f1070000.ethernet: DMA-API: device driver tries to sync DMA memory it has not allocated [device address=0x000000002dd7dc00] [size=240 bytes]
> > Modules linked in: ahci mv88e6xxx dsa_core xhci_plat_hcd xhci_hcd devlink armada_thermal marvell_cesa des_generic ehci_orion phy_armada38x_comphy mcp3021 spi_orion evbug sfp mdio_i2c ip_tables x_tables
> > CPU: 0 PID: 555 Comm: bridge-network- Not tainted 4.20.0+ #291
> > Hardware name: Marvell Armada 380/385 (Device Tree)
> > [<c0019638>] (unwind_backtrace) from [<c0014888>] (show_stack+0x10/0x14)
> > [<c0014888>] (show_stack) from [<c07f54e0>] (dump_stack+0x9c/0xd4)
> > [<c07f54e0>] (dump_stack) from [<c00312bc>] (__warn+0xf8/0x124)
> > [<c00312bc>] (__warn) from [<c00313b0>] (warn_slowpath_fmt+0x38/0x48)
> > [<c00313b0>] (warn_slowpath_fmt) from [<c00b0370>] (check_sync+0x514/0x5bc)
> > [<c00b0370>] (check_sync) from [<c00b04f8>] (debug_dma_sync_single_range_for_cpu+0x6c/0x74)
> > [<c00b04f8>] (debug_dma_sync_single_range_for_cpu) from [<c051bd14>] (mvneta_poll+0x298/0xf58)
> > [<c051bd14>] (mvneta_poll) from [<c0656194>] (net_rx_action+0x128/0x424)
> > [<c0656194>] (net_rx_action) from [<c000a230>] (__do_softirq+0xf0/0x540)
> > [<c000a230>] (__do_softirq) from [<c00386e0>] (irq_exit+0x124/0x144)
> > [<c00386e0>] (irq_exit) from [<c009b5e0>] (__handle_domain_irq+0x58/0xb0)
> > [<c009b5e0>] (__handle_domain_irq) from [<c03a63c4>] (gic_handle_irq+0x48/0x98)
> > [<c03a63c4>] (gic_handle_irq) from [<c0009a10>] (__irq_svc+0x70/0x98)
> > ...
> >
> > This appears to be caused by mvneta_rx_hwbm() calling
> > dma_sync_single_range_for_cpu() with the wrong struct device pointer,
> > as the buffer manager device pointer is used to map and unmap the
> > buffer.  Fix this.
> >
> 
> For me it makes sens to associate the DMA buffer to the HWBM, so this
> fixes looks good for me.

I'd still question which device is the one doing DMA to the buffer.
The HWBM surely is just a management agent passing cookies that
happen to be physical addresses to mvneta for it to then do DMA on
the resulting buffer.  If that's true, then the correct device to
map/sync/unmap these buffers against is mvneta, not hwbm.

> Reviwed-by: Gregory CLEMENT <gregory.clement@...tlin.com>
> 
> Thanks,
> 
> Gregory
> 
> 
> > Signed-off-by: Russell King <rmk+kernel@...linux.org.uk>
> > ---
> > Please check that this is the correct fix.
> >
> >  drivers/net/ethernet/marvell/mvneta.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
> > index ef0a85bbc586..0e1f87fca952 100644
> > --- a/drivers/net/ethernet/marvell/mvneta.c
> > +++ b/drivers/net/ethernet/marvell/mvneta.c
> > @@ -2086,7 +2086,7 @@ static int mvneta_rx_hwbm(struct napi_struct *napi,
> >  			if (unlikely(!skb))
> >  				goto err_drop_frame_ret_pool;
> >  
> > -			dma_sync_single_range_for_cpu(dev->dev.parent,
> > +			dma_sync_single_range_for_cpu(&pp->bm_priv->pdev->dev,
> >  			                              rx_desc->buf_phys_addr,
> >  			                              MVNETA_MH_SIZE + NET_SKB_PAD,
> >  			                              rx_bytes,
> > -- 
> > 2.7.4
> >
> 
> -- 
> Gregory Clement, Bootlin
> Embedded Linux and Kernel engineering
> http://bootlin.com
> 

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up