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: <20190215170507.p3kztk7okx4rvfko@shell.armlinux.org.uk>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ