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:	Wed, 25 Mar 2015 13:47:17 -0500
From:	Dan Williams <dcbw@...hat.com>
To:	Mahesh Bandewar <maheshb@...gle.com>
Cc:	David Miller <davem@...emloft.net>, jbenc@...hat.com,
	linux-netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH net] ipvlan: fix addr hash list corruption

On Wed, 2015-03-25 at 11:11 -0700, Mahesh Bandewar wrote:
> On Wed, Mar 25, 2015 at 8:46 AM, David Miller <davem@...emloft.net> wrote:
> > From: Jiri Benc <jbenc@...hat.com>
> > Date: Wed, 25 Mar 2015 09:58:51 +0100
> >
> >> On Tue, 24 Mar 2015 16:16:38 -0700, Mahesh Bandewar wrote:
> >>> Well, we already have hlist_unhashed().The following patch should fix
> >>> the duplicate addition as well as deletion. Please give it a try.
> >>
> >> Good idea, it's surely better than adding a new boolean.
> >>
> >> However, I'm wondering that when there's apparently no problem with the
> >> addresses being on the hash list when interface is down, what's the
> >> point in clearing the hash list in the ndo_stop handler and
> >> repopulating it in ndo_open?
> >>
> >> The following patch fixes the problem, too, and as a bonus removes code:
> >
> > I'll let Mahesh reply to this.
> 
> Yes functionally you will get the same result. However during the RX
> processing, that code helps ipvlan-demux machine along with
> packet-dispatcher to determine it early to drop the packet rather than
> later. Also note that addition / deletion of address entries in
> hash-table is done in control-path while the demux / dispatcher
> operate in data-path. So for this reason I would prefer to leave the
> hash-table entries addition / deletion as it is.

Jiri's patch was actually prompted by my testing of ipvlan with L2 mode.
How much testing of L2 have you given ipvlan internally and what setups
have you tested?  It doesn't look like ipvlan handles ARP/ICMP very well
at all right now, and while I've got patches to fix some of that I'm
trying to characterize the rest.  Also, have you ever tested it with
DHCP?

Dan

--
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