linux-kernel - Re: [net-next PATCH 1/3] net: introduce napi_is

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: <651abb07.050a0220.5435c.9eae@mx.google.com>
Date:   Mon, 2 Oct 2023 14:43:47 +0200
From:   Christian Marangi <ansuelsmth@...il.com>
To:     Eric Dumazet <edumazet@...gle.com>
Cc:     Vincent Whitchurch <vincent.whitchurch@...s.com>,
        Raju Rangoju <rajur@...lsio.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Alexandre Torgue <alexandre.torgue@...s.st.com>,
        Jose Abreu <joabreu@...opsys.com>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        Ping-Ke Shih <pkshih@...ltek.com>,
        Kalle Valo <kvalo@...nel.org>, Simon Horman <horms@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Jiri Pirko <jiri@...nulli.us>,
        Hangbin Liu <liuhangbin@...il.com>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        linux-stm32@...md-mailman.stormreply.com,
        linux-arm-kernel@...ts.infradead.org,
        linux-wireless@...r.kernel.org
Subject: Re: [net-next PATCH 1/3] net: introduce napi_is_scheduled helper

On Mon, Oct 02, 2023 at 02:35:22PM +0200, Eric Dumazet wrote:
> On Mon, Oct 2, 2023 at 2:29 PM Christian Marangi <ansuelsmth@...il.com> wrote:
> 
> > Ehhh the idea here was to reduce code duplication since the very same
> > test will be done in stmmac. So I guess this code cleanup is a NACK and
> > I have to duplicate the test in the stmmac driver.
> 
> I simply wanted to add a comment in front of this function/helper,
> advising not using it unless absolutely needed.
> 
> Thus my question "In which context is it safe to call this helper ?"
> 
> As long as it was private with a driver, I did not mind.
> 
> But if made public in include/linux/netdevice.h, I would rather not
> have to explain
> to future users why it can be problematic.

Oh ok!

We have plenty of case similar to this. (example some clock API very
internal that should not be used normally or regmap related)

I will include some comments warning that this should not be used in
normal circumstances and other warnings. If you have suggestion on what
to add feel free to write them.

Any clue on how to proceed with the sge driver? 

-- 
	Ansuel