Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp8849pxk; Wed, 16 Sep 2020 15:29:36 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwdGGiWgI7ZkQZMmvstAHD1SZENSLMHCfwaHE8ozl4JLg5zrNG2E3fDCO1jz/OEgVvZjgfY X-Received: by 2002:a50:a693:: with SMTP id e19mr29312214edc.205.1600295375871; Wed, 16 Sep 2020 15:29:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600295375; cv=none; d=google.com; s=arc-20160816; b=H5Uw45F8+ynFfhdVT6WIeZVtgti8agKPsR4xaFS2TwKNh651jbX7JwXIWBCEh195jZ FscLDi620LgFSIrn9JLRMli2IxnGKPiq9XWJcrTWDahrp/s8XaN5pIEdANrZpTarlmk1 qb8EWgU4qqziDdDb5L0vQZpMlBveeGs0QwQ7eahrA8NOIRV7mnkOoubFQiQ+nEWklSiB acDQ65oA8gmEP2q772ruL0dL98uhLpnGpyt2qrHRmvhLyJ8GL1kZuFa9prKpOF4U1uz7 TLs2wDw8KMUJciTXplklScIupZzy2kRkKUN+CRa5Qf2DUVV7aZbdedisx/ukIsKhOcYG v+SQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:from:subject:cc:to:message-id:date; bh=0+bnO7a8+2LZ+qeskhrS9ITuT/NDUPjVzd7WliA7gj4=; b=GdX2UhidrrDN//Jfa6egQcWG0Z+n9p/AEGpFYnLlsasKTekVojbdme+Nl1WezjVf9n 5ETtAMa7Wbo+XVgfAohHCqrAHdsHuoiIxqU1Gx1/NSeRI5ftFWj5pZnLUR/msgkfjgom 1qOwOaqefBCUbVozG6UjxZTRB0Q3UJou4pRnTgMr1xpLogupmpO97QPs+Fhusvqzrg8r 234IwAL+/1c12NZBZZIqX2OnFRY9wN8wM4LL0aeRlet9ptKmpsUmJaRX7lZ0ycX+Qit4 HIB1rigPOpjDGyQRh83HFttbJ2tgH7qMRi505BJYIm6UYRkorlRbdM6QpWIcMrMd+SKS vMmA== 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 br19si12046560ejb.151.2020.09.16.15.29.10; Wed, 16 Sep 2020 15:29:35 -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 S1726366AbgIPWZy (ORCPT + 99 others); Wed, 16 Sep 2020 18:25:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50822 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726187AbgIPWZx (ORCPT ); Wed, 16 Sep 2020 18:25:53 -0400 Received: from shards.monkeyblade.net (shards.monkeyblade.net [IPv6:2620:137:e000::1:9]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2B04BC061221; Wed, 16 Sep 2020 15:25:53 -0700 (PDT) Received: from localhost (unknown [IPv6:2601:601:9f00:477::3d5]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: davem-davemloft) by shards.monkeyblade.net (Postfix) with ESMTPSA id 25F8713624E0E; Wed, 16 Sep 2020 15:09:04 -0700 (PDT) Date: Wed, 16 Sep 2020 15:25:50 -0700 (PDT) Message-Id: <20200916.152550.1833517348137875378.davem@davemloft.net> To: vee.khee.wong@intel.com Cc: peppe.cavallaro@st.com, alexandre.torgue@st.com, joabreu@synopsys.com, kuba@kernel.org, mcoquelin.stm32@gmail.com, linux@armlinux.org.uk, netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, boon.leong.ong@intel.com, weifeng.voon@intel.com, yoong.siang.song@intel.com, sadhishkhanna.vijaya.balan@intel.com, chen.yong.seow@intel.com Subject: Re: [PATCH net-next] net: stmmac: Add support to Ethtool get/set ring parameters From: David Miller In-Reply-To: <20200916074020.25491-1-vee.khee.wong@intel.com> References: <20200916074020.25491-1-vee.khee.wong@intel.com> X-Mailer: Mew version 6.8 on Emacs 27.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [2620:137:e000::1:9]); Wed, 16 Sep 2020 15:09:04 -0700 (PDT) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Wong Vee Khee Date: Wed, 16 Sep 2020 15:40:20 +0800 > +int stmmac_reinit_ringparam(struct net_device *dev, u32 rx_size, u32 tx_size) > +{ > + struct stmmac_priv *priv = netdev_priv(dev); > + int ret = 0; > + > + if (netif_running(dev)) > + stmmac_release(dev); ... > + if (netif_running(dev)) > + ret = stmmac_open(dev); > + I've applied this patch but this approach is so fragile, but everyone does it initially because it is so easy. The problem here is that for so many reasons the stmmac_open() can fail, and instead of just the ringparam() operation failing, the interface becomes down and unusable. Can you please eventually implement this properly? Allocate the new ring resources, and only commit the new configuration if it is guaranteed to succeed. Otherwise, backout the ringparam change and keep the old configuration. This way the device stays up regardless of whether the resources (memory, DMA mappings, etc.) can be allocated fully. Right now, if you do a ringparam under hard memory pressure, this will take the inteface down as stmmac_open() fails.