[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1349a6d1-f2fb-480f-8879-78ad29dea206@intel.com>
Date: Fri, 24 Oct 2025 13:20:33 -0700
From: Jacob Keller <jacob.e.keller@...el.com>
To: I Viswanath <viswanathiyyappan@...il.com>
CC: <davem@...emloft.net>, <edumazet@...gle.com>, <kuba@...nel.org>,
<pabeni@...hat.com>, <horms@...nel.org>, <sdf@...ichev.me>,
<kuniyu@...gle.com>, <ahmed.zaki@...el.com>, <aleksander.lobakin@...el.com>,
<andrew+netdev@...n.ch>, <netdev@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <skhan@...uxfoundation.org>,
<linux-kernel-mentees@...ts.linux.dev>, <david.hunter.linux@...il.com>,
<khalid@...nel.org>
Subject: Re: [RFC net-next PATCH 0/2] net: Split ndo_set_rx_mode into snapshot
and deferred write
On 10/23/2025 10:31 PM, I Viswanath wrote:
> On Thu, 23 Oct 2025 at 05:16, Jacob Keller <jacob.e.keller@...el.com> wrote:
>>
>> Is there any mechanism to make this guarantee either implemented or at
>> least verified by the core? If not that, what about some sort of way to
>> lint driver code and make sure its correct?
>
> From my observations, The sane drivers modify rx_config related
> registers either through the set_rx_mode function or the unlocked
> version (prefixed with __)
> I am not sure how to convert this to a validation of that kind.
>
Right.
> Basically the end result should be that warnings are generated when
> those functions are called
> normally but not when they are called through ops->set_rx_mode.
> Coccinelle might be able to do
> something like this.
>
> Related to this, I don't think a sed would be sufficient as there
> might be (in theory) cases where
> the function has to do a "synchronous" rx write (flush the work queue)
> for correctness
> but it should be good enough for most cases.
>
> I am also not sure what is to be done if the scheduled function just
> never executes.
I'm not sure what the best mechanism is for helping make sure drivers
get it right. I just know that past experience shows that without some
sort of check, we end up burdening reviewers with another thing they
have to double check, and inevitably some drivers will screw it up and
we'll end up with a long tail of fixes.
If we can't come up with something, I don't think it would prevent
moving this forward. I just want to spend a little thought to make sure
nothing obvious was missed.
Thanks,
Jake
Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (237 bytes)
Powered by blists - more mailing lists