linux-kernel - Re: [Regression?] Commit cb4f71c429 deliberately changes order of network interfaces

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, 24 Aug 2016 19:10:04 +0200
From:   Ralph Sennhauser <ralph.sennhauser@...il.com>
To:     Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Gregory CLEMENT <gregory.clement@...e-electrons.com>
Subject: Re: [Regression?] Commit cb4f71c429 deliberately changes order of
 network interfaces

On Wed, 24 Aug 2016 16:50:11 +0200
Thomas Petazzoni <thomas.petazzoni@...e-electrons.com> wrote:

> Hello,
> 
> On Sun, 21 Aug 2016 15:11:58 +0200, Ralph Sennhauser wrote:
> 
> > Commit cb4f71c4298853db0c6751b1209e4535956f136c changes the order of
> > the network interfaces for armada-38x. As a special exception to the
> > "order by register address" rule says the comment in the dtsi. The
> > commit messages even calls it a violation.
> > 
> > I can't remember having owned a device were the internal and
> > external numbering actually matched, so the important bit for me is
> > whatever the order is it should remain constant.
> > 
> > Distributions like OpenWrt have to fix their code when moving from
> > 4.4 currently to past 4.6 [1]. Worse the so called "wrong ordering"
> > is actually documented [2]. There are likely more victims out
> > there. In case it goes unnoticed by the distribution the users lan
> > becomes wan and vice versa.  
> 
> We had many many users getting confused by the fact that the order of
> the network interfaces was inverted compared to:
> 
>  * The board documentations
>  * The U-Boot numbering
>  * And to a lesser extent, the vendor kernel
> 

And in how many places this discrepancy was documented? You won't be
able to update them all. Mailing lists, blogs, fora posts and what ever
else. I'd say the damage is done and can't be fixed by simply changing
the order now.

> So having things match the documentation numbering was in our opinion
> the least confusing thing moving forward. We should have done it
> earlier, but we thought that the rule "order by register address" was
> a very strong rule.
> 

Whether strong rule or not, obviously it went in so bending the rule is
at least accepted. It's not what I have an issue with but with the
reordering at this point.

> At this point, reverting the patch is I believe cause more harm than
> good. It's going to re-confuse again people.

I'm clearly not convinced reverting would do more harm than good,
otherwise I wouldn't have brought it up.

> 
> Regarding the fact that the "wrong numbering if actually documented"
> is a fairly specious argument. The OpenWRT Wiki has never been an
> official documentation of any sort. I see it as a much more important
> aspect that the numbering of the Ethernet interfaces matches the user
> manual Marvell provides with its development and evaluation boards.
> The OpenWRT Wiki can certainly be fixed accordingly.
> 

It's not about being able to fix the code or documentation but about
having to do so in the first place.

The nice thing about having the order in the dtb I thought was that it
wont ever change.

Going forward, as we disagree and it's basically a political decision,
whom do we ask to rule here? Linus?

Best regards
Ralph

> Best regards,
> 
> Thomas