netdev - Re: [PATCH net-next] cxgb4/cxgb4vf: Notify link changes to OS-dependent code

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]

Message-Id: <20180525.151139.21869641462441558.davem@davemloft.net>
Date:   Fri, 25 May 2018 15:11:39 -0400 (EDT)
From:   David Miller <davem@...emloft.net>
To:     ganeshgr@...lsio.com
Cc:     netdev@...r.kernel.org, nirranjan@...lsio.com,
        indranil@...lsio.com, leedom@...lsio.com, arjun@...lsio.com,
        santosh@...lsio.com
Subject: Re: [PATCH net-next] cxgb4/cxgb4vf: Notify link changes to
 OS-dependent code

From: Ganesh Goudar <ganeshgr@...lsio.com>
Date: Thu, 24 May 2018 19:33:37 +0530

> From: Arjun Vynipadath <arjun@...lsio.com>
> 
> We have a confusion of two different abstractions in the Common
> Code:  Physical Link (Port) and Logical Network Interface (Virtual
> Interface), and we haven't been properly managing the state of the
> intersection of those two abstractions.
> On the one hand we have the Physical state of the Link -- up or down --
> and on the other we have the logical state of the VI, enabled or not.
> {ethN} refers to both the Physical and Logical State. In this case,
> ifconfig only affects/interrogates the Logical State of a VI,
> and ethtool only deals with the Physical State. And these are different.
> 
> So, just because we disable the VI, we don't really want to change the
> Physical Link Up/Down state.  Thus, the previous hack to set
> "lc->link_ok = 0" when we disable a VI is completely incorrect.
> 
> Where we get into trouble is where the Physical Link State and the
> Logical VI State cross swords.  And that happens in
> t4_handle_get_port_info() where we need to manage/safe the Physical
> Link State, but we also need to know when the Logical VI State has
> changed and pass that back up to the OS-dependent Driver routine
> t4_os_link_changed() which is concerned about the Logical Interface.
> 
> So we enable a VI and that causes Firmware to send us a new Port
> Information message, but if none of the Physical Link State
> particulars have changed, we don't call t4_os_link_changed().
> 
> This fix uses the existing OS Contract APIs for the Common Code to
> inform the OS-dependent portion of the Host Driver when the "Link" (really
> Logical Network Interface) is "up" or "down". A new API
> t4_enable_pi_params() is added which calls t4_enable_vi_params() and,
> if that is successful, then calls back to the OS Contract API
> t4_os_link_changed() notifying the OS-dependent layer of the
> potential Link State change.
> 
> Original Work by : Casey Leedom <leedom@...lsio.com>
> 
> Signed-off-by: Santosh Rastapur <santosh@...lsio.com>
> Signed-off-by: Arjun Vynipadath <arjun@...lsio.com>
> Signed-off-by: Ganesh Goudar <ganeshgr@...lsio.com>

Applied, thanks.