netdev - Re: RFH: problems with adjacency graph

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:   Tue, 11 Oct 2016 13:08:13 -0600
From:   David Ahern <dsahern@...il.com>
To:     Jiri Pirko <jiri@...nulli.us>
Cc:     vfalico@...il.com,
        Nikolay Aleksandrov <nikolay@...ulusnetworks.com>,
        roopa <roopa@...ulusnetworks.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: RFH: problems with adjacency graph

On 10/11/16 12:54 AM, Jiri Pirko wrote:
>>
>> It seems like the complete mesh is not really needed, but cscope shows spectrum, ixgbe and bonding all using the for_each upper and lower device macros.
>>
>> Suggestions?
> 
> Well other possibility is to traverse the tree recursively. But that is
> exactly why the colided lists of all uppers/lowers were introduced to
> avoid this.

The simpler approach is to remove all_adj_list completely and iteratively walk the lower and upper lists in adj_list for the macros that walk all lower and all upper devices. Maintaining a complete linear list per netdev of all lower devices and all upper devices is just not going to work given all combinations of enslave orderings and considering stacks as high as 6 deep. As far as I can tell the netdev_for_each_all_lower_dev, netdev_for_each_all_lower_dev_rcu, and netdev_for_each_all_upper_dev_rcu macros are all used in the slow path so it should be ok. Removing all_adj_list significantly simplifies the dev insert and remove code.