netdev - Re: [PATCH net-next 0/15] Neighbour table and ax25 cleanups

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:	Mon, 02 Mar 2015 16:44:26 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	ebiederm@...ssion.com
Cc:	netdev@...r.kernel.org, ralf@...ux-mips.org,
	linux-hams@...r.kernel.org
Subject: Re: [PATCH net-next 0/15] Neighbour table and ax25 cleanups

From: ebiederm@...ssion.com (Eric W. Biederman)
Date: Sun, 01 Mar 2015 23:59:11 -0600

> While looking at the neighbour table to what it would take to allow
> using next hops in a different address family than the current packets
> I found a partial resolution for my issues and I stumbled upon some
> work that makes the neighbour table code easier to understand and
> maintain.
> 
> Long ago in a much younger kernel ax25 found a hack to use
> dev_rebuild_header to transmit it's packets instead of going through
> what today is ndo_start_xmit.
> 
> When the neighbour table was rewritten into it's current form the ax25
> code was such a challenge that arp_broken_ops appeard in arp.c and
> neigh_compat_output appeared in neighbour.c to keep the ax25 hack alive.
> 
> With a little bit of work I was able to remove some of the hack that
> is the ax25 transmit path for ip packets and to isolate what remains
> into a slightly more readable piece of code in ax25_ip.c.  Removing the
> need for the generic code to worry about ax25 special cases.
> 
> After cleaning up the old ax25 hacks I also performed a little bit of
> work on neigh_resolve_output to remove the need for a dst entry and to
> ensure cached headers get a deterministic protocol value in their cached
> header.   This guarantees that a cached header will not be different
> depending on which protocol of packet is transmitted, and it allows
> packets to be transmitted that don't have a dst entry.  There remains
> a small amount of code that takes advantage of when packets have a dst
> entry but that is something different.

Wow... simply, wow.

I thought we'd be stuck with that crap forever, great work!

Applied to net-next, thanks again!
--
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