netdev - Re: Circular dependency between DSA switch driver and tagging protocol driver

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, 8 Sep 2021 17:49:17 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Circular dependency between DSA switch driver and tagging
 protocol driver



On 9/8/2021 5:26 PM, Vladimir Oltean wrote:
> On Wed, Sep 08, 2021 at 03:14:51PM -0700, Florian Fainelli wrote:
>>> Where is the problem?
>>
>> I'd say with 994d2cbb08ca, since the tagger now requires visibility into
>> sja1105_switch_ops which is not great, to say the least. You could solve
>> this by:
>>
>> - splitting up the sja1150 between a library that contains
>> sja1105_switch_ops and does not contain the driver registration code
> 
> I've posted patches which more or less cheat the dependency by creating
> a third module, as you suggest. The tagging protocol still depends on
> the main module, now sans the call to dsa_register_switch, that is
> provided by the third driver, sja1105_probe.ko, which as the name
> suggests probes the hardware. The sja1105_probe.ko also depends on
> sja1105.ko, so the insmod order needs to be:
> 
> insmod sja1105.ko
> insmod tag_sja1105.ko
> insmod sja1105_probe.ko
> 
> I am not really convinced that this change contributes to the overall
> code organization and structure.

Yes, I don't really like it either, maybe we do need to resolve the 
other dependency created with 566b18c8b752 with a function 
pointer/indirect call that gets resolved at run-time, assuming the 
overhead is acceptable.

> 
>> - finding a different way to do a dsa_switch_ops pointer comparison, by
>> e.g.: maintaining a boolean in dsa_port that tracks whether a particular
>> driver is backing that port
> 
> Maybe I just don't see how this would scale. So to clarify, are you
> suggesting to add a struct dsa_port :: bool is_sja1105, which the
> sja1105 driver would set to true in sja1105_setup?

Not necessarily something that is sja1105 specific, but something that 
indicates whether the tagger is operating with its intended switch 
driver, or with a "foreign" switch driver (say: dsa_loop for instance).

> 
> If this was not a driver I would be maintaining, just watching as a
> reviewer, I believe "no" is what I would say to that.
> 

-- 
Florian