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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20230316161811.64d14cb3@kernel.org>
Date:   Thu, 16 Mar 2023 16:18:11 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     "Russell King (Oracle)" <linux@...linux.org.uk>
Cc:     Andrew Halaney <ahalaney@...hat.com>, linux-kernel@...r.kernel.org,
        agross@...nel.org, andersson@...nel.org, konrad.dybcio@...aro.org,
        davem@...emloft.net, edumazet@...gle.com, pabeni@...hat.com,
        robh+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org,
        vkoul@...nel.org, bhupesh.sharma@...aro.org,
        mturquette@...libre.com, sboyd@...nel.org, peppe.cavallaro@...com,
        alexandre.torgue@...s.st.com, joabreu@...opsys.com,
        mcoquelin.stm32@...il.com, richardcochran@...il.com,
        veekhee@...le.com, tee.min.tan@...ux.intel.com,
        mohammad.athari.ismail@...el.com, jonathanh@...dia.com,
        ruppala@...dia.com, bmasney@...hat.com,
        andrey.konovalov@...aro.org, linux-arm-msm@...r.kernel.org,
        netdev@...r.kernel.org, devicetree@...r.kernel.org,
        linux-clk@...r.kernel.org,
        linux-stm32@...md-mailman.stormreply.com,
        linux-arm-kernel@...ts.infradead.org, ncai@...cinc.com,
        jsuraj@....qualcomm.com, hisunil@...cinc.com
Subject: Re: [PATCH net-next 08/11] net: stmmac: Add EMAC3 variant of dwmac4

On Thu, 16 Mar 2023 23:01:13 +0000 Russell King (Oracle) wrote:
> What I would say is be careful with that - make sure "struct bla" is
> specific to the interface being called and not generic.
> 
> I had that mistake with struct phylink_state... and there is an
> endless stream of people who don't seem to bother reading the
> documentation, who blindly access whatever members of that they
> damn well please because it suits them, even when either they
> shouldn't be writing to them, or when phylink doesn't guarantee
> their contents, they read them.

Right, gotta take it case by case. I really like structs for
const capabilities of the driver / device, which need to be
communicated to the core.

> As a result, I'm now of the opinion that using a struct to pass
> arguments is in principle a bad idea.
> 
> There's other reasons why it's a bad idea. Many ABIs are capable of
> passing arguments to functions via processor registers. As soon as
> one uses a struct, they typically end up being written to memory.
> Not only does that potentially cause cache line churn, it also
> means that there could be more slow memory accesses that have to be
> made at some point, potentially making other accesses slow.
> 
> So, all in all, I'm really not a fan of the struct approach for
> all the reasons above.

Also true, one has to be careful on the fast paths. There are cases
where similar set of arguments is passed multiple functions down.
Making the code hard to follow and extend. But you're right, structs
will be slower for the most part.

For stmmac I figured it can only help. The driver is touched my very
many people, it has layers and confusions...

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ