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  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:	Sat, 26 Jul 2014 15:42:46 +0200
From:	Hannes Frederic Sowa <>
To:	Jun Zhao <>
Cc:	"David S. Miller" <>,
	Cong Wang <>,
	Pravin B Shelar <>,
	Nicolas Dichtel <>,
	stephen hemminger <>,
	Tom Herbert <>,,
	Francesco Fusco <>,
	Veaceslav Falico <>,
	Duan Jiong <>,
	Jiri Pirko <>,
	David Stevens <>,
	Or Gerlitz <>,
	Daniel Borkmann <>,
Subject: Re: [PATCH 1/1] neighbour : fix ndm_type type error issue


On Sat, Jul 26, 2014, at 02:29, Jun Zhao wrote:
> On Sat, 2014-07-26 at 01:24 +0200, Hannes Frederic Sowa wrote:
> > On Fri, Jul 25, 2014, at 18:38, Jun Zhao wrote:
> > > ndm_type means L3 address type, in neighbour proxy and vxlan, it's
> > > NDA_DST is for netlink TLV type, hence it's not right value in this
> > > context.
> > 
> > The value of NDA_DST == RTN_UNICAST, otherwise we couldn't do this
> > change as it would alter e.g. arpd behavior.
> > 
> > Acked-by: Hannes Frederic Sowa <>
> > 
> > Thanks,
> > Hannes
> But I think NDA_DST/RTN_UNICAST have different means in this context, 
> even though the value of NDA_DST == RTN_UNICAST.
> For arp proxy/NDP proxy context, ndm_type means the peer L3 address,
> so RTN_UNICAST is the right value. For vxlan have similar semantic for
> remote ip.
> BTW: In the source code, implicit think NDA_DST == RTN_UNICAST maybe
> not a good idea when we don't have a comment or the other explain.

I am totally with you and think your change is good, that's why I also
gave my ack to your patch.

My comment above was about my concerns regarding making a user space
visible change, which in the end could alter the behavior of already
existing software.

Developers maybe have debugged code and seen some different value being
propagated from the kernel and this software could now break if we would
change the value after all those years.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists