netdev - Re: [PATCH net-next 0/5] Code movement to br

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]

Message-ID: <20211102120206.ak2j7dnhx6clvd46@skbuf>
Date:   Tue, 2 Nov 2021 12:02:06 +0000
From:   Vladimir Oltean <vladimir.oltean@....com>
To:     Jiri Pirko <jiri@...nulli.us>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Jakub Kicinski <kuba@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Roopa Prabhu <roopa@...dia.com>,
        Nikolay Aleksandrov <nikolay@...dia.com>,
        Jiri Pirko <jiri@...dia.com>, Ido Schimmel <idosch@...dia.com>
Subject: Re: [PATCH net-next 0/5] Code movement to br_switchdev.c

On Tue, Nov 02, 2021 at 12:49:53PM +0100, Jiri Pirko wrote:
> Tue, Nov 02, 2021 at 12:11:59PM CET, vladimir.oltean@....com wrote:
> >On Mon, Nov 01, 2021 at 04:05:45PM +0100, Jiri Pirko wrote:
> >> Wed, Oct 27, 2021 at 06:21:14PM CEST, vladimir.oltean@....com wrote:
> >> >This is one more refactoring patch set for the Linux bridge, where more
> >> >logic that is specific to switchdev is moved into br_switchdev.c, which
> >> >is compiled out when CONFIG_NET_SWITCHDEV is disabled.
> >> 
> >> Looks good.
> >> 
> >> While you are at it, don't you plan to also move switchdev.c into
> >> br_switchdev.c and eventually rename to br_offload.c ?
> >> 
> >> Switchdev is about bridge offloading only anyway.
> >
> >You mean I should effectively make switchdev part of the bridge?
> 
> Yes.

Ok, have you actually seen the commit message linked below? Basically it
says that there are drivers that depend on switchdev.c being this
neutral third party, forwarding events on notifier chains back and forth
between the bridge and the drivers. If we make switchdev.c part of the
bridge, then drivers can no longer be compiled without bridge support.
Currently br_switchdev.c is compiled as follows:

bridge-$(CONFIG_NET_SWITCHDEV) += br_switchdev.o

whereas switchdev.c is compiled as follows:

obj-y += switchdev.o

So to rephrase the question: unless you're suggesting that I should
build br_switchdev.o as part of obj-$(CONFIG_NET_SWITCHDEV) instead of
bridge-$(CONFIG_NET_SWITCHDEV), then what do we do with the drivers that
assume that the switchdev functions they call into are present when the
bridge is not compiled, or is compiled as module?

> >See commit 957e2235e526 ("net: make switchdev_bridge_port_{,unoffload}
> >loosely coupled with the bridge").