Received: by 2002:a25:ca44:0:0:0:0:0 with SMTP id a65csp1897288ybg; Thu, 30 Jul 2020 05:41:22 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy+CxLvdDVRDTeZmxif0mFadVy7qUmcBfdsC1DMcM/1fl5tNe9mQNKSHyOSmX67Ym8ynseU X-Received: by 2002:a17:906:351a:: with SMTP id r26mr2317043eja.526.1596112882714; Thu, 30 Jul 2020 05:41:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1596112882; cv=none; d=google.com; s=arc-20160816; b=UllIwlagHcDXUREvLa7Wnt45nefGshNqE/zbMxGKHBC43Kl9jMK0I+992SbRzHLw/a IFOOGusB55WdO33u9o8hP7kfbNLSG5chKCfVeqgHtjduUxqRxPt8yS5M6qhh7pdYqDd3 idFqz+btogJ2J3SjcG7xkGn9zHqqzHuwI5jks0uAbNYE40RJTk66FpUjqqW525KxPEYI 139vzYc81kGgK2zbqWRP8GilBYcxVEXGXlz44AZWfdzfrKlbxabRS9wYoUoh+ae7ZRYv QaWCBJXaoF+EA3MpB5Hj/QKNZnEAYF9XP2e4uLNXt1THmJ7U1jEabKt6VZelILXCekdK coGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id; bh=Ba4J4sDwFs4s9gysEKARDnQDXxC/IivwQ2ovhHE3ndE=; b=hJ7DEvAZm0+17ivt17yMkhuqspLyMQoMIhM4oxB9guaoun/y1SpTFX00+F0J5A1iN+ OywyeNZUOzo59Ca21vjRpoPLybLQNLUs9queyzhRwekv8e3WzFb2eRgsQ278Qa/OWrUt 3CeFJyd8WpVd+L2horUGk994NFZ/4ZmE475U9IZE0QygHsY70whT2lnBp4Ponopa4WUa fmwjO7hDUNUEKOil3+NDRwalVw8JkThfH+b4x4Pz+3S3uiO7mOswayPUbFMQ6G0Gg67o fYtMm3GmDtrA/e75KnKCdLcwHuRI6yRiwzorlgxOk9DhDA0H0YQPvZkp3V7SsUKfMLl9 Le4Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id rl7si2857819ejb.264.2020.07.30.05.41.00; Thu, 30 Jul 2020 05:41:22 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728192AbgG3Mkm (ORCPT + 99 others); Thu, 30 Jul 2020 08:40:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38402 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726581AbgG3Mkl (ORCPT ); Thu, 30 Jul 2020 08:40:41 -0400 Received: from sipsolutions.net (s3.sipsolutions.net [IPv6:2a01:4f8:191:4433::2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BBAB1C061794; Thu, 30 Jul 2020 05:40:41 -0700 (PDT) Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.93) (envelope-from ) id 1k17rD-00DWUr-5e; Thu, 30 Jul 2020 14:40:23 +0200 Message-ID: <446c9e45b5e904fa747c3d727a2c39ee904789e0.camel@sipsolutions.net> Subject: Re: [RFC 1/7] mac80211: Add check for napi handle before WARN_ON From: Johannes Berg To: Rakesh Pillai , ath10k@lists.infradead.org Cc: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org, kvalo@codeaurora.org, davem@davemloft.net, kuba@kernel.org, netdev@vger.kernel.org, dianders@chromium.org, evgreen@chromium.org Date: Thu, 30 Jul 2020 14:40:21 +0200 In-Reply-To: <000e01d66368$9a6ece70$cf4c6b50$@codeaurora.org> References: <1595351666-28193-1-git-send-email-pillair@codeaurora.org> <1595351666-28193-2-git-send-email-pillair@codeaurora.org> <0dbdef912f9d61521011f638200fd451a3530568.camel@sipsolutions.net> <003201d6611e$c54a1c90$4fde55b0$@codeaurora.org> <000e01d66368$9a6ece70$cf4c6b50$@codeaurora.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.4 (3.36.4-1.fc32) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 2020-07-26 at 21:49 +0530, Rakesh Pillai wrote: > We do have the usage of napi_gro_receive and netif_receive_skb in mac80211. > /* deliver to local stack */ > if (rx->napi) > napi_gro_receive(rx->napi, skb); > else > netif_receive_skb(skb); > > > Also all the rx_handlers are called under the " rx->local->rx_path_lock" lock. > Is the BH disable still required ? I tend to think so, but you're welcome to show that it's not. The lock serves a different purpose. TBH, I don't have all of this in my head at all times either, so please do your own work and analyse why it may or may not be necessary. But without any such analysis I'm not going to take patches that change it. johannes