netdev - Re: [PATCH net-next] can: grcan: move napi

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] [day] [month] [year] [list]

Message-ID: <20250111180337.GA1661553@electric-eye.fr.zoreil.com>
Date: Sat, 11 Jan 2025 19:03:37 +0100
From: Francois Romieu <romieu@...zoreil.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: davem@...emloft.net, netdev@...r.kernel.org, edumazet@...gle.com,
        pabeni@...hat.com, andrew+netdev@...n.ch, horms@...nel.org,
        mkl@...gutronix.de, mailhol.vincent@...adoo.fr,
        linux-can@...r.kernel.org
Subject: Re: [PATCH net-next] can: grcan: move napi_enable() from under spin
 lock

Jakub Kicinski <kuba@...nel.org> :
> I don't see any reason why napi_enable() needs to be under the lock,
> only reason I could think of is if the IRQ also took this lock
> but it doesn't. napi_enable() will soon need to sleep.

Anything that depends on the napi handler being run may also behave
differently because of 'priv->resetting = false;' and
'priv->closing = false;' also done under the lock after napi_enable in
the original version.

Both priv->closing and priv->resetting are always accessed with lock
held so it's fine.

(nothing to chew in grcan_start either)

Reviewed-by: Francois Romieu <romieu@...zoreil.com>

-- 
Ueimor