From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 6BAF5C77B78 for ; Thu, 4 May 2023 07:57:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 0907340586; Thu, 4 May 2023 07:57:20 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 0907340586 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=osuosl.org; s=default; t=1683187040; bh=ULHeNLexl8pvGPZ6J2LwZh3MaavPKsnZx8H/oko9LM4=; h=Date:From:To:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc:From; b=Q2v8oI8W8TJarr7aONybGgJjNsttxelQ0lFs7cnQNhf0wDiXHab2QV3SNGiNVki63 u8qSBiSGyZcGCKxxwCR0S0konfTO6oVxIkuu71qc6eh15y6oDRs8lxj8W68vgMHZoO a0N4kITrQ3A6w94vVIWZh1r6bNvu5X4HTrGUqQZP612//fIkiY+evsvcMp1V0eek77 WI0M3oHLjODuNf0ljLfx9OHwobWxTrkC3Bp+Zz9GRM3ovOGD7LZbnFnWiIYJ4Q0ZPN A+K16F4XbRxcJPvV3SJsYxJwxo5yblrfNr7n7892olHt1kp1TN0D8rUST0+BZNS+vc 0r5LW7WhIk/Aw== X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyiE1IhGB8ga; Thu, 4 May 2023 07:57:19 +0000 (UTC) Received: from ash.osuosl.org (ash.osuosl.org [140.211.166.34]) by smtp2.osuosl.org (Postfix) with ESMTP id E52E34060B; Thu, 4 May 2023 07:57:18 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org E52E34060B Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by ash.osuosl.org (Postfix) with ESMTP id CC1E81BF3C8 for ; Thu, 4 May 2023 07:57:16 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id A15E683BA6 for ; Thu, 4 May 2023 07:57:16 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org A15E683BA6 X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xumSQNl-_l93 for ; Thu, 4 May 2023 07:57:16 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org D684383F2F Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by smtp1.osuosl.org (Postfix) with ESMTPS id D684383F2F for ; Thu, 4 May 2023 07:57:15 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id CA23C631D3; Thu, 4 May 2023 07:57:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6FED7C433EF; Thu, 4 May 2023 07:57:13 +0000 (UTC) Date: Thu, 4 May 2023 10:57:09 +0300 From: Leon Romanovsky To: "Chittim, Madhu" Message-ID: <20230504075709.GS525452@unreal> References: <20230503031541.27855-1-dinghui@sangfor.com.cn> <20230503031541.27855-3-dinghui@sangfor.com.cn> <20230503082458.GH525452@unreal> <20230503162932.GN525452@unreal> <941ad3cc-22d6-3459-dfbc-36bc47a8a22a@intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <941ad3cc-22d6-3459-dfbc-36bc47a8a22a@intel.com> X-Mailman-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1683187034; bh=BD+fImah7ymy/XPLoxovcxIHeqcAUrR7ThJMZGqhmUY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=VMHxVyXZq7ct+QcEYLotgmRTbNBd5yimQJFWEju0LmqS+/NJuq7PfQIXnuCnqiGTp 5sY39fh68shTCdPyuY90UGqnoBypLT/0OCdQsyv51DE4GdjfPD6LSDFTfcI5yDb5BM OVj6y8h2zCcYPXNjHQCMd8dEZlkVBQmeOr8lYAXW0B5iZLrmPVWgjsps1DepNFoFcr atcpa0nlFVIKoiiQEm06sVCvwO6xncK28bFXPWJVsEKJYkRxnyYHpN5AsxYzuKU6jb wrq9VM7Ule78SRjOnSNJGraAXSjbkfTTgOveVa1Pz4vW+J/jtUb5BAGHvPImEE0Vjd hAyiW2J4mZBpA== X-Mailman-Original-Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=VMHxVyXZ Subject: Re: [Intel-wired-lan] [PATCH net v4 2/2] iavf: Fix out-of-bounds when setting channels on remove X-BeenThere: intel-wired-lan@osuosl.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel Wired Ethernet Linux Kernel Driver Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: pengdonglin@sangfor.com.cn, keescook@chromium.org, gregory.v.rose@intel.com, anthony.l.nguyen@intel.com, mitch.a.williams@intel.com, Ding Hui , jesse.brandeburg@intel.com, huangcun@sangfor.com.cn, linux-kernel@vger.kernel.org, grzegorzx.szczurek@intel.com, edumazet@google.com, michal.kubiak@intel.com, intel-wired-lan@lists.osuosl.org, jeffrey.t.kirsher@intel.com, simon.horman@corigine.com, kuba@kernel.org, netdev@vger.kernel.org, pabeni@redhat.com, davem@davemloft.net, linux-hardening@vger.kernel.org Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: intel-wired-lan-bounces@osuosl.org Sender: "Intel-wired-lan" T24gV2VkLCBNYXkgMDMsIDIwMjMgYXQgMTI6MjI6MDBQTSAtMDcwMCwgQ2hpdHRpbSwgTWFkaHUg d3JvdGU6Cj4gCj4gCj4gT24gNS8zLzIwMjMgOToyOSBBTSwgTGVvbiBSb21hbm92c2t5IHdyb3Rl Ogo+ID4gT24gV2VkLCBNYXkgMDMsIDIwMjMgYXQgMTA6MDA6NDlQTSArMDgwMCwgRGluZyBIdWkg d3JvdGU6Cj4gPiA+IE9uIDIwMjMvNS8zIDQ6MjQg5LiL5Y2ILCBMZW9uIFJvbWFub3Zza3kgd3Jv dGU6Cj4gPiA+ID4gT24gV2VkLCBNYXkgMDMsIDIwMjMgYXQgMTE6MTU6NDFBTSArMDgwMCwgRGlu ZyBIdWkgd3JvdGU6Cj4gPiA+IAo+ID4gPiA+ID4gCj4gPiA+ID4gPiBJZiB3ZSBkZXRlY3RlZCBy ZW1vdmluZyBpcyBpbiBwcm9jZXNzaW5nLCB3ZSBjYW4gYXZvaWQgdW5uZWNlc3NhcnkKPiA+ID4g PiA+IHdhaXRpbmcgYW5kIHJldHVybiBlcnJvciBmYXN0ZXIuCj4gPiA+ID4gPiAKPiA+ID4gPiA+ IE9uIHRoZSBvdGhlciBoYW5kIGluIHRpbWVvdXQgaGFuZGxpbmcsIHdlIHNob3VsZCBrZWVwIHRo ZSBvcmlnaW5hbAo+ID4gPiA+ID4gbnVtX2FjdGl2ZV9xdWV1ZXMgYW5kIHJlc2V0IG51bV9yZXFf cXVldWVzIHRvIDAuCj4gPiA+ID4gPiAKPiA+ID4gPiA+IEZpeGVzOiA0ZTVlNmI1ZDlkMTMgKCJp YXZmOiBGaXggcmV0dXJuIG9mIHNldCB0aGUgbmV3IGNoYW5uZWwgY291bnQiKQo+ID4gPiA+ID4g U2lnbmVkLW9mZi1ieTogRGluZyBIdWkgPGRpbmdodWlAc2FuZ2Zvci5jb20uY24+Cj4gPiA+ID4g PiBDYzogRG9uZ2xpbiBQZW5nIDxwZW5nZG9uZ2xpbkBzYW5nZm9yLmNvbS5jbj4KPiA+ID4gPiA+ IENjOiBIdWFuZyBDdW4gPGh1YW5nY3VuQHNhbmdmb3IuY29tLmNuPgo+ID4gPiA+ID4gUmV2aWV3 ZWQtYnk6IFNpbW9uIEhvcm1hbiA8c2ltb24uaG9ybWFuQGNvcmlnaW5lLmNvbT4KPiA+ID4gPiA+ IFJldmlld2VkLWJ5OiBNaWNoYWwgS3ViaWFrIDxtaWNoYWwua3ViaWFrQGludGVsLmNvbT4KPiA+ ID4gPiA+IC0tLQo+ID4gPiA+ID4gdjMgdG8gdjQ6Cj4gPiA+ID4gPiAgICAgLSBub3RoaW5nIGNo YW5nZWQKPiA+ID4gPiA+IAo+ID4gPiA+ID4gdjIgdG8gdjM6Cj4gPiA+ID4gPiAgICAgLSBmaXgg cmV2aWV3IHRhZwo+ID4gPiA+ID4gCj4gPiA+ID4gPiB2MSB0byB2MjoKPiA+ID4gPiA+ICAgICAt IGFkZCByZXByb2R1Y3Rpb24gc2NyaXB0Cj4gPiA+ID4gPiAKPiA+ID4gPiA+IC0tLQo+ID4gPiA+ ID4gICAgZHJpdmVycy9uZXQvZXRoZXJuZXQvaW50ZWwvaWF2Zi9pYXZmX2V0aHRvb2wuYyB8IDQg KysrLQo+ID4gPiA+ID4gICAgMSBmaWxlIGNoYW5nZWQsIDMgaW5zZXJ0aW9ucygrKSwgMSBkZWxl dGlvbigtKQo+ID4gPiA+ID4gCj4gPiA+ID4gPiBkaWZmIC0tZ2l0IGEvZHJpdmVycy9uZXQvZXRo ZXJuZXQvaW50ZWwvaWF2Zi9pYXZmX2V0aHRvb2wuYyBiL2RyaXZlcnMvbmV0L2V0aGVybmV0L2lu dGVsL2lhdmYvaWF2Zl9ldGh0b29sLmMKPiA+ID4gPiA+IGluZGV4IDZmMTcxZDFkODViNy4uZDhh M2MwY2ZlZGQwIDEwMDY0NAo+ID4gPiA+ID4gLS0tIGEvZHJpdmVycy9uZXQvZXRoZXJuZXQvaW50 ZWwvaWF2Zi9pYXZmX2V0aHRvb2wuYwo+ID4gPiA+ID4gKysrIGIvZHJpdmVycy9uZXQvZXRoZXJu ZXQvaW50ZWwvaWF2Zi9pYXZmX2V0aHRvb2wuYwo+ID4gPiA+ID4gQEAgLTE4NTcsMTMgKzE4NTcs MTUgQEAgc3RhdGljIGludCBpYXZmX3NldF9jaGFubmVscyhzdHJ1Y3QgbmV0X2RldmljZSAqbmV0 ZGV2LAo+ID4gPiA+ID4gICAgCS8qIHdhaXQgZm9yIHRoZSByZXNldCBpcyBkb25lICovCj4gPiA+ ID4gPiAgICAJZm9yIChpID0gMDsgaSA8IElBVkZfUkVTRVRfV0FJVF9DT01QTEVURV9DT1VOVDsg aSsrKSB7Cj4gPiA+ID4gPiAgICAJCW1zbGVlcChJQVZGX1JFU0VUX1dBSVRfTVMpOwo+ID4gPiA+ ID4gKwkJaWYgKHRlc3RfYml0KF9fSUFWRl9JTl9SRU1PVkVfVEFTSywgJmFkYXB0ZXItPmNyaXRf c2VjdGlvbikpCj4gPiA+ID4gPiArCQkJcmV0dXJuIC1FT1BOT1RTVVBQOwo+ID4gPiA+IAo+ID4g PiA+IFRoaXMgbWFrZXMgbm8gc2Vuc2Ugd2l0aG91dCBsb2NraW5nIGFzIGNoYW5nZSB0byBfX0lB VkZfSU5fUkVNT1ZFX1RBU0sKPiA+ID4gPiBjYW4gaGFwcGVuIGFueSB0aW1lLgo+ID4gPiA+IAo+ ID4gPiAKPiA+ID4gVGhlIHN0YXRlIGRvZXNuJ3QgbmVlZCB0byBiZSB0aGF0IHByZWNpc2UgaGVy ZSwgaXQgaXMgb3B0aW1pemVkIG9ubHkgZm9yCj4gPiA+IHRoZSBmYXN0IHBhdGguIER1cmluZyB0 aGUgbGlmZWN5Y2xlIG9mIHRoZSBhZGFwdGVyLCB0aGUgX19JQVZGX0lOX1JFTU9WRV9UQVNLCj4g PiA+IHN0YXRlIHdpbGwgb25seSBiZSBzZXQgYW5kIG5vdCBjbGVhcmVkLgo+ID4gPiAKPiA+ID4g SWYgd2UgZGlkbid0IGRldGVjdCB0aGUgInJlbW92aW5nIiBzdGF0ZSwgd2UgYWxzbyBjYW4gZmFs bGJhY2sgdG8gdGltZW91dAo+ID4gPiBoYW5kbGluZy4KPiA+ID4gCj4gPiA+IFNvIEkgZG9uJ3Qg dGhpbmsgdGhlIGxvY2tpbmcgaXMgbmVjZXNzYXJ5IGhlcmUsIHdoYXQgZG8gdGhlIG1haW50YWlu ZXJzCj4gPiA+IGF0IEludGVsIHRoaW5rPwo+ID4gCj4gPiBJJ20gbm90IEludGVsIG1haW50YWlu ZXIsIGJ1dCB5b3VyIGNoYW5nZSwgZXhwbGFuYXRpb24gYW5kIHRoZSBmb2xsb3dpbmcKPiA+IGxp bmUgZnJvbSB5b3VyIGNvbW1pdCBtZXNzYWdlIGFyZW4ndCByZWFsbHkgYWxpZ25lZC4KPiA+IAo+ ID4gWyAzNTEwLjQwMDc5OV0gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09Cj4gPiBbIDM1MTAuNDAwODIwXSBCVUc6IEtBU0FO OiBzbGFiLW91dC1vZi1ib3VuZHMgaW4gaWF2Zl9mcmVlX2FsbF90eF9yZXNvdXJjZXMrMHgxNTYv MHgxNjAgW2lhdmZdCj4gPiAKPiA+IAo+IAo+IF9fSUFWRl9JTl9SRU1PVkVfVEFTSyBpcyBiZWlu ZyBzZXQgb25seSBpbiBpYXZmX3JlbW92ZSgpIGFuZCB0aGUgYWJvdmUKPiBjaGFuZ2UgaXMgb2sg aW4gdGVybXMgb2YgY29taW5nIG91dCBvZiBzZXR0aW5nIGNoYW5uZWxzIGVhcmx5IGVub3VnaCB3 aGlsZQo+IHJlbW92ZSBpcyBpbiBwcm9ncmVzcy4KCkl0IGlzIG5vdCwgX19JQVZGX0lOX1JFTU9W RV9UQVNLLCBzZXQgYml0IGNhbiBiZSBjaGFuZ2VkIGFueSB0aW1lIGR1cmluZwppYXZmX3NldF9j aGFubmVscygpIGFuZCBpZiBpdCBpcyBub3QsIEkgd291bGQgZXhwZWN0IHRlc3RfYml0KC4uKSBw bGFjZWQKYXQgdGhlIGJlZ2lubmluZyBvZiBpYXZmX3NldF9jaGFubmVscygpIG9yIGV2ZW4gZWFy bGllci4KClRoYW5rcwpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwpJbnRlbC13aXJlZC1sYW4gbWFpbGluZyBsaXN0CkludGVsLXdpcmVkLWxhbkBvc3Vvc2wu b3JnCmh0dHBzOi8vbGlzdHMub3N1b3NsLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ludGVsLXdpcmVk LWxhbgo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 739E1C7EE21 for ; Thu, 4 May 2023 07:57:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229613AbjEDH5R (ORCPT ); Thu, 4 May 2023 03:57:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39958 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229522AbjEDH5Q (ORCPT ); Thu, 4 May 2023 03:57:16 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8BE322728; Thu, 4 May 2023 00:57:15 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id CCC4A631D6; Thu, 4 May 2023 07:57:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6FED7C433EF; Thu, 4 May 2023 07:57:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1683187034; bh=BD+fImah7ymy/XPLoxovcxIHeqcAUrR7ThJMZGqhmUY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=VMHxVyXZq7ct+QcEYLotgmRTbNBd5yimQJFWEju0LmqS+/NJuq7PfQIXnuCnqiGTp 5sY39fh68shTCdPyuY90UGqnoBypLT/0OCdQsyv51DE4GdjfPD6LSDFTfcI5yDb5BM OVj6y8h2zCcYPXNjHQCMd8dEZlkVBQmeOr8lYAXW0B5iZLrmPVWgjsps1DepNFoFcr atcpa0nlFVIKoiiQEm06sVCvwO6xncK28bFXPWJVsEKJYkRxnyYHpN5AsxYzuKU6jb wrq9VM7Ule78SRjOnSNJGraAXSjbkfTTgOveVa1Pz4vW+J/jtUb5BAGHvPImEE0Vjd hAyiW2J4mZBpA== Date: Thu, 4 May 2023 10:57:09 +0300 From: Leon Romanovsky To: "Chittim, Madhu" Cc: Ding Hui , davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, intel-wired-lan@lists.osuosl.org, jesse.brandeburg@intel.com, anthony.l.nguyen@intel.com, keescook@chromium.org, grzegorzx.szczurek@intel.com, mateusz.palczewski@intel.com, mitch.a.williams@intel.com, gregory.v.rose@intel.com, jeffrey.t.kirsher@intel.com, michal.kubiak@intel.com, simon.horman@corigine.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org, pengdonglin@sangfor.com.cn, huangcun@sangfor.com.cn Subject: Re: [PATCH net v4 2/2] iavf: Fix out-of-bounds when setting channels on remove Message-ID: <20230504075709.GS525452@unreal> References: <20230503031541.27855-1-dinghui@sangfor.com.cn> <20230503031541.27855-3-dinghui@sangfor.com.cn> <20230503082458.GH525452@unreal> <20230503162932.GN525452@unreal> <941ad3cc-22d6-3459-dfbc-36bc47a8a22a@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <941ad3cc-22d6-3459-dfbc-36bc47a8a22a@intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-hardening@vger.kernel.org On Wed, May 03, 2023 at 12:22:00PM -0700, Chittim, Madhu wrote: > > > On 5/3/2023 9:29 AM, Leon Romanovsky wrote: > > On Wed, May 03, 2023 at 10:00:49PM +0800, Ding Hui wrote: > > > On 2023/5/3 4:24 下午, Leon Romanovsky wrote: > > > > On Wed, May 03, 2023 at 11:15:41AM +0800, Ding Hui wrote: > > > > > > > > > > > > > If we detected removing is in processing, we can avoid unnecessary > > > > > waiting and return error faster. > > > > > > > > > > On the other hand in timeout handling, we should keep the original > > > > > num_active_queues and reset num_req_queues to 0. > > > > > > > > > > Fixes: 4e5e6b5d9d13 ("iavf: Fix return of set the new channel count") > > > > > Signed-off-by: Ding Hui > > > > > Cc: Donglin Peng > > > > > Cc: Huang Cun > > > > > Reviewed-by: Simon Horman > > > > > Reviewed-by: Michal Kubiak > > > > > --- > > > > > v3 to v4: > > > > > - nothing changed > > > > > > > > > > v2 to v3: > > > > > - fix review tag > > > > > > > > > > v1 to v2: > > > > > - add reproduction script > > > > > > > > > > --- > > > > > drivers/net/ethernet/intel/iavf/iavf_ethtool.c | 4 +++- > > > > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > > > > > > > diff --git a/drivers/net/ethernet/intel/iavf/iavf_ethtool.c b/drivers/net/ethernet/intel/iavf/iavf_ethtool.c > > > > > index 6f171d1d85b7..d8a3c0cfedd0 100644 > > > > > --- a/drivers/net/ethernet/intel/iavf/iavf_ethtool.c > > > > > +++ b/drivers/net/ethernet/intel/iavf/iavf_ethtool.c > > > > > @@ -1857,13 +1857,15 @@ static int iavf_set_channels(struct net_device *netdev, > > > > > /* wait for the reset is done */ > > > > > for (i = 0; i < IAVF_RESET_WAIT_COMPLETE_COUNT; i++) { > > > > > msleep(IAVF_RESET_WAIT_MS); > > > > > + if (test_bit(__IAVF_IN_REMOVE_TASK, &adapter->crit_section)) > > > > > + return -EOPNOTSUPP; > > > > > > > > This makes no sense without locking as change to __IAVF_IN_REMOVE_TASK > > > > can happen any time. > > > > > > > > > > The state doesn't need to be that precise here, it is optimized only for > > > the fast path. During the lifecycle of the adapter, the __IAVF_IN_REMOVE_TASK > > > state will only be set and not cleared. > > > > > > If we didn't detect the "removing" state, we also can fallback to timeout > > > handling. > > > > > > So I don't think the locking is necessary here, what do the maintainers > > > at Intel think? > > > > I'm not Intel maintainer, but your change, explanation and the following > > line from your commit message aren't really aligned. > > > > [ 3510.400799] ================================================================== > > [ 3510.400820] BUG: KASAN: slab-out-of-bounds in iavf_free_all_tx_resources+0x156/0x160 [iavf] > > > > > > __IAVF_IN_REMOVE_TASK is being set only in iavf_remove() and the above > change is ok in terms of coming out of setting channels early enough while > remove is in progress. It is not, __IAVF_IN_REMOVE_TASK, set bit can be changed any time during iavf_set_channels() and if it is not, I would expect test_bit(..) placed at the beginning of iavf_set_channels() or even earlier. Thanks