Received: by 2002:a05:6358:9144:b0:117:f937:c515 with SMTP id r4csp1048864rwr; Wed, 3 May 2023 09:30:37 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5gjvhNy6kir7qzfF+fdePgszltNMuHaOxxoHHFNi2qsWGei2KEP0bfc42pz5CtdBWRRmkp X-Received: by 2002:a17:90a:df82:b0:24e:1da8:4237 with SMTP id p2-20020a17090adf8200b0024e1da84237mr7442704pjv.38.1683131437373; Wed, 03 May 2023 09:30:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1683131437; cv=none; d=google.com; s=arc-20160816; b=cc7sKfrcLJIcjEZQAxNGcgXnzInmIIYVgH6Z0pLmU77Z5APlAOpV5koKlpK0rRKENK xGo6iSOCNjpSArjSyWWJjdWNGzWplO6PDJ4i5BxaHXmr3h8kfE9e01mqqsvoa2o5XgNM Lx/9bhH7PkGNXPQ1m7zS0XDtv8ZdWRdJVUKNMiHGqhIdLkR7Q+o/qFwX1hXKctaw9i7f qi3I0UfbHZXMXtLgRf1X8bcHRaowviRoi/El8B7B7HEvJjLqES2WuYIQF1R0quVbj3Zl MA3RZL5Z8xcgIbIGS5u0n1TOTLnCvMaIx15zbXq09PcKuEPpxYusb3hfOruSFgyyzias 0AaA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=2b6Whk8MtCBZOw5z3qTRCi6FBeSeQ6+vSjsRAGFZibM=; b=bDhDg5xRhZ4JeJEQ+yH3ZZ2hSlYvJEEGGBs4AjT3oY+6sKxKY+zqsk5dqOZPntAunB 9LDD9W2otpqc/VLBDklJo9CIk5FsQ9CZbseBpNLX4Z+vmDiEttYUe0AsE5tflED4gTZ/ JBFKs5mOH4btbTAB33XD/nmClRCRu4M3IzFvNOvgKrxQDh+nCSmglMZRyIkd4O9YRqlk upIYAZjdyZ0y8fY/ooZMRs8659Ka0kmWQF68IDLSrM2gaT5SdC6n3jGPRSmGUwLcfHQq 9P0Ygn9iH0B3OjZ45B1KyCaJI8lQnoYx7PNP8VuTXI4VVhPbTRe92bmvBS4ZBIkf/MZY co1w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=Ala5bqNF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id mg24-20020a17090b371800b0024b3c34ca20si1836490pjb.55.2023.05.03.09.30.22; Wed, 03 May 2023 09:30:37 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=Ala5bqNF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229650AbjECQ35 (ORCPT + 99 others); Wed, 3 May 2023 12:29:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54784 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229677AbjECQ3y (ORCPT ); Wed, 3 May 2023 12:29:54 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 88A0C72B9; Wed, 3 May 2023 09:29:37 -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 11B496259B; Wed, 3 May 2023 16:29:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AC06CC433D2; Wed, 3 May 2023 16:29:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1683131376; bh=+Fa8lWXq+eKn54nxvLtDWjF14FF8nVDjXsR+6SPokpg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Ala5bqNF4QzuhsDsLBzQ1IP0XdwwIbDJ3GLns3f6uzPfhcI7QGlMw2tqwy04hpTRt 0oHMxsoxfOKIkGu+X4P62VCbNbGiKnb86a3Onb/lBvNbHpJjlMzk060TTdista/eVW RGq0xAj4h2Gi86TTggpW7vmEqbXglXHX8Bz18ffQ9hzgIrWaKg2Ka+YUsfIgHy6RQd oFIzyqUPYoo4Mbd2gW0oaMTZJaBlZJINKgaxGy5x0npQkSQRL6vIu8JBhiWvwvWTj5 heLSJohzf2nBNT9CbXpER2fku1XcLUmA/cFnyLs2j0Fio0ZNCOopL0DdHQglz7JyqF 20zuTnRxMm08g== Date: Wed, 3 May 2023 19:29:32 +0300 From: Leon Romanovsky To: Ding Hui Cc: 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, madhu.chittim@intel.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: <20230503162932.GN525452@unreal> References: <20230503031541.27855-1-dinghui@sangfor.com.cn> <20230503031541.27855-3-dinghui@sangfor.com.cn> <20230503082458.GH525452@unreal> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-7.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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] > > > Thanks > > > > > if (adapter->flags & IAVF_FLAG_RESET_PENDING) > > > continue; > > > break; > > > } > > > if (i == IAVF_RESET_WAIT_COMPLETE_COUNT) { > > > adapter->flags &= ~IAVF_FLAG_REINIT_ITR_NEEDED; > > > - adapter->num_active_queues = num_req; > > > + adapter->num_req_queues = 0; > > > return -EOPNOTSUPP; > > > } > > > -- > > > 2.17.1 > > > > > > > > > > -- > Thanks, > -dinghui > >