netdev - Re: [PATCH net] ipvlan: fix addr hash list corruption

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: <1427309237.31633.24.camel@redhat.com>
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