Re: [PATCH net] net: ibm: emac: mal: fix potential system hang in mal_remove()

[Jacob Keller]

On 6/8/2026 5:36 PM, Jakub Kicinski wrote:
> On Thu, 4 Jun 2026 16:03:43 -0700 Rosen Penev wrote:
>>>> -     if (!list_empty(&mal->list))
>>>> +     if (!list_empty(&mal->list)) {
>>>> +             napi_disable(&mal->napi);
>>>>               /* This is *very* bad */
>>>>               WARN(1, KERN_EMERG
>>>>                      "mal%d: commac list is not empty on remove!\n",
>>>>                      mal->index);  
>>>
>>> This one doesn't make sense to me. The list_empty check does a WARN()
>>> indicating that this is not supposed to happen.
>>>
>>> This implies that list_empty should be true, otherwise we'd see a WARN
>>> every time mal_remove is called.
>>>
>>> But in that case, we'd have been calling napi_disable incorrectly in
>>> most cases where it was previously unsafe according to your claim.
>>>
>>> At best, this list_empty check is the wrong way to tell if the napi is
>>> disabled, at worst, this whole change is pointless.  
>> I asked the AI. It doesn't agree:
> 
> FTR I agree with Jake, the patch seems to indicate bigger structural
> issues. Then again I don't want to encourage the stream of patches
> to this driver so let me just apply this..

I don't see how applying this discourages the stream of patches?
Wouldn't that be encouraging? I guess you don't want to encourage a raff
of future changes to try and fix the overall structural issues? and
instead accept the small fix here?

How plausible is it that existing users have *never* called mal_remove??
If the list_empty check is to be believed, we shouldn't be getting to
mal_remove with list_empty being false... (since that implies that the
co-macs are still registered) and users would see the WARN. But if we
are getting here with list_empty, we stall indefinitely.


Ultimately it is that which is bothering me. It feels like a classic
"how did this *ever* work???" scenario...