From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from violet.fr.zoreil.com (violet.fr.zoreil.com [92.243.8.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5BA6F1494CC; Sat, 11 Jan 2025 18:06:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=92.243.8.30 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736618768; cv=none; b=jjZb6yMtdwtsSWRuNDJuznN5ADfT5ZT6axreiqsEsozvSMJcCCr3rC1eX7qNvTD8srN1KwPbOtB8W9nwrYaohEbZp94kcw5WOc28dwnVs8sImfR0am2XthZRFeH5sq+9547KiWL0K8bs9t5PRUO3/Ux06VRf3GwNQPI84T6dy9M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736618768; c=relaxed/simple; bh=KCJpf/fycjR5R30opdT+J866wNUYGNty9NCTTQfwMzs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=I+aOlB/4Ru4rVV0Mz1StrNEBG2n+WSYxLOE+C7++p0CxleEhvvciwa4hMuHWSrV73KVDZ2/+wqzMSpBQc5pcK2dU1tcQzoQAwIANyIbw60ZHVQW46CD1CyUDKywJrhbqNJaZULYGZHjXRJpFgIBq6Mvjwrt4BCaXtjJeKoU+Fao= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=fr.zoreil.com; spf=pass smtp.mailfrom=fr.zoreil.com; dkim=pass (1024-bit key) header.d=fr.zoreil.com header.i=@fr.zoreil.com header.b=mIbj8BiV; arc=none smtp.client-ip=92.243.8.30 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=fr.zoreil.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=fr.zoreil.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=fr.zoreil.com header.i=@fr.zoreil.com header.b="mIbj8BiV" Received: from violet.fr.zoreil.com ([127.0.0.1]) by violet.fr.zoreil.com (8.17.1/8.17.1) with ESMTP id 50BI3bJx1661624; Sat, 11 Jan 2025 19:03:37 +0100 DKIM-Filter: OpenDKIM Filter v2.11.0 violet.fr.zoreil.com 50BI3bJx1661624 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fr.zoreil.com; s=v20220413; t=1736618617; bh=eRjZF3MpIXcgnFTHyt8fWhGiLLRbiirfj+vTsqAXcU4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=mIbj8BiVRo/BxaZB7FTqCP2f6Us6OiLVFCqbMRQK6TQcthUaU33ypzwEiTc4VVzFE 8NTqMhiQbTFMYUAWUbLnJzxrmMeUKDlmabW5kG6iliArSIwApDWvKl1UsQSgFM+Du8 9IFsz6nTNA/4L76DX/Meq7SjoCw+AgNQjR4eZG7E= Received: (from romieu@localhost) by violet.fr.zoreil.com (8.17.1/8.17.1/Submit) id 50BI3bfD1661623; Sat, 11 Jan 2025 19:03:37 +0100 Date: Sat, 11 Jan 2025 19:03:37 +0100 From: Francois Romieu To: Jakub Kicinski Cc: davem@davemloft.net, netdev@vger.kernel.org, edumazet@google.com, pabeni@redhat.com, andrew+netdev@lunn.ch, horms@kernel.org, mkl@pengutronix.de, mailhol.vincent@wanadoo.fr, linux-can@vger.kernel.org Subject: Re: [PATCH net-next] can: grcan: move napi_enable() from under spin lock Message-ID: <20250111180337.GA1661553@electric-eye.fr.zoreil.com> References: <20250111024742.3680902-1-kuba@kernel.org> Precedence: bulk X-Mailing-List: linux-can@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250111024742.3680902-1-kuba@kernel.org> X-Organisation: Land of Sunshine Inc. Jakub Kicinski : > 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 -- Ueimor