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]
Date:	Sun, 4 Apr 2010 19:19:07 +0900
From:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
To:	eric.dumazet@...il.com
Cc:	fujita.tomonori@....ntt.co.jp, netdev@...r.kernel.org,
	davem@...emloft.net
Subject: Re: [BUG] latest net-next-2.6 doesnt fly

On Sun, 04 Apr 2010 11:29:55 +0200
Eric Dumazet <eric.dumazet@...il.com> wrote:

> > I think, if pdev is null, returning 1 here is safer since the device
> > doesn't set up dma info properly.
> > 
> > Do you know what device hits this bug? You said that you use bnx2 and
> > tg3. Both call SET_NETDEV_DEV with pdev->dev. I tested bnx2 and seems
> > that netdev->dev.parent is set up correctly.
> > --
> 
> Might be because of my setup, I suspect I had two reasons to hit the
> bug :
> 
> A bonding of eth2 (bnx2) and eth3 (tg3)
> 
> Then vlans on top of this bond0
> 
> When first dev_queue_xmit() was called, it was for a virtual device :)

Thanks! So it's due to bond or vlan (or both).

I guess that returning zero here with a null pdev is fine. If we
return 1, probably some people would complain about performance
regression. Like the block layer does, coping the dma restriction info
from the lower devices can solve this problem but I guess that it's
over engineering. My original patch doesn't loosen the DMA restriction
checking so returning zero shouldn't break anything. If when we fix
the usage of NETIF_F_HIGHDMA in each driver and also check the usage
of netdev->dev.parent, everything should be fine.
--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ