[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANn89i+n4bpxUXMOiYdFa57SATCreum+XQAd8DtkLOFpic0a=A@mail.gmail.com>
Date: Wed, 22 Jan 2025 15:25:46 +0100
From: Eric Dumazet <edumazet@...gle.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: davem@...emloft.net, netdev@...r.kernel.org, pabeni@...hat.com,
andrew+netdev@...n.ch, horms@...nel.org, dan.carpenter@...aro.org,
nbd@....name, lorenzo@...nel.org, ryder.lee@...iatek.com,
shayne.chen@...iatek.com, sean.wang@...iatek.com, kvalo@...nel.org,
matthias.bgg@...il.com, angelogioacchino.delregno@...labora.com,
quan.zhou@...iatek.com, johannes.berg@...el.com, emmanuel.grumbach@...el.com,
leitao@...ian.org, mingyen.hsieh@...iatek.com, leon.yen@...iatek.com,
deren.wu@...iatek.com, chui-hao.chiu@...iatek.com, kuniyu@...zon.com,
romieu@...zoreil.com, linux-wireless@...r.kernel.org
Subject: Re: [PATCH net-next 7/7] wifi: mt76: move napi_enable() from under BH
On Tue, Jan 21, 2025 at 11:15 PM Jakub Kicinski <kuba@...nel.org> wrote:
>
> mt76 does a lot of:
>
> local_bh_disable();
> napi_enable(...napi);
> napi_schedule(...napi);
> local_bh_enable();
>
> local_bh_disable() is not a real lock, its most likely taken
> because napi_schedule() requires it. napi_enable() needs
> to take a mutex, so move it from under the BH protection.
>
> Fixes: 413f0271f396 ("net: protect NAPI enablement with netdev_lock()")
> Reported-by: Dan Carpenter <dan.carpenter@...aro.org>
> Link: https://lore.kernel.org/dcfd56bc-de32-4b11-9e19-d8bd1543745d@stanley.mountain
> Signed-off-by: Jakub Kicinski <kuba@...nel.org>
Reviewed-by: Eric Dumazet <edumazet@...gle.com>
napi_schedule() can run from arbitrary contexts though...
BH protection seems strange to me, but this is orthogonal to your fix.
Powered by blists - more mailing lists