Message ID | 20240104101255.3056090-1-yi.fang.gan@intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-16496-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:6f82:b0:100:9c79:88ff with SMTP id tb2csp5520408dyb; Thu, 4 Jan 2024 02:16:33 -0800 (PST) X-Google-Smtp-Source: AGHT+IHynetzl4wuWk15YEw0kcRTi3eEUiFUSyYEXqCT+5DPZHB8zZ3fmSvOVHWT8sCQbLds+/la X-Received: by 2002:a05:6a20:2a23:b0:197:c5b7:4ac6 with SMTP id e35-20020a056a202a2300b00197c5b74ac6mr239772pzh.84.1704363393438; Thu, 04 Jan 2024 02:16:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704363393; cv=none; d=google.com; s=arc-20160816; b=0KZZm/wFDOKxyjhu5cCvILiN5ZtP/nvjyjtQ54/ggljM3ReIrkp7vp02IeE/XG7EcJ hRwo8SiC+7YtVmR59nv/miGvMv3RQLmkIWnslJVg/DIE0eLn5VgP4E+RdYkC4k3xNozt UoZoI8wDgTa563VhhUqBcdvitLjw0zY5UzEnPEHvL70X9pT5xzqUOD8qYSpYyE3lsJ7d KOSfpzi1ZLaEN9vp6KhFx9rg4MPkIozjA/HfdUoj8SX/WfjuBdqiPb+EAu6AjiQJMY4C 8yH+jOufwbdaiTdn2xjxSdDCG3eOMJt5+uAPK36MJjHcROXEJBkfvyCqEXdEBGPZSXhi pYNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=1RRGQm73k5YoZQIO5FPgJZmEYBndzH/DRTI7eQ1DoE4=; fh=2S3hQtJz4VqUkjXYtLKDTc/HXHFpzbbJL3EnOxiabGE=; b=slfnE0NFH/oNaIj6DGzzpGzA9lWmHv0F/ygPAuNi6/ryUBvozA/ED6HzP4938Y46+C K6+PH1WXaSAfrJeQcFxGk+UFo40SmhFe85bJepCiAsOXDijILjyAjNYVaCBEPUCwodpO 0Bda6zyiuNT2dGCwlE1usTbsGPiCkcAlMO1JTAlBc7rViT2XbM2VEqFqUhlYctowuQx5 FCXoeEs66wy/2tmjrzezAh1snSqTYJtLktj9/i/uGBUHGuXomTdrWHQcuKnOFm8O006n vyVy9B+8q+FuKjNziIjHpLFqOQU+aJJoltEsSXf6KHcVG+oUDv55H63aMy5RRWgIWS1w tVwg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=VOstGvTA; spf=pass (google.com: domain of linux-kernel+bounces-16496-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-16496-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id fj30-20020a056a003a1e00b006dabc650b5bsi1772296pfb.315.2024.01.04.02.16.33 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Jan 2024 02:16:33 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-16496-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=VOstGvTA; spf=pass (google.com: domain of linux-kernel+bounces-16496-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-16496-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 00272286F27 for <ouuuleilei@gmail.com>; Thu, 4 Jan 2024 10:16:33 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 9290C20DC6; Thu, 4 Jan 2024 10:16:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="VOstGvTA" X-Original-To: linux-kernel@vger.kernel.org Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.9]) (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 8E95520B15; Thu, 4 Jan 2024 10:16:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1704363372; x=1735899372; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=HCrXfWmSxLvasPVqx5bvaAF0h2FNR5wLkTJHVmOM0RI=; b=VOstGvTAOg1F3IHa4NSWlzhz4NelAc0PB8oU0LXSVB+rnYyms0oiX8w0 YGGOjw0zawEx963H1ZkAwTfGDhvDEkRL1/jAGcioQW1QSV9ZihlCSyO1M Vi3L14XNZilImGD0V49DKbhcGHZr/OqQVV3P4Ci0CRcnOQs7wEs9+dYBa urn/1dPCE3KzKI9BUTz0pShu5NZmuv0yBE9uWoY78IVYfKeizhOTlMo0q zqsx+4zcENDHpB8nEHFBBXhyRJ7Kl7V8CPQuN4LubSOuKIinmCacjGcvm 2dsQ8S1dtrDwaTx5llb88HmHnBGxnN1lJgF1eA3VNMBSlThp1/jeBRWXG Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10942"; a="15831368" X-IronPort-AV: E=Sophos;i="6.04,330,1695711600"; d="scan'208";a="15831368" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orvoesa101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Jan 2024 02:16:12 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10942"; a="903761717" X-IronPort-AV: E=Sophos;i="6.04,330,1695711600"; d="scan'208";a="903761717" Received: from ssid-ilbpg3-teeminta.png.intel.com (HELO localhost.localdomain) ([10.88.227.74]) by orsmga004.jf.intel.com with ESMTP; 04 Jan 2024 02:16:06 -0800 From: "Gan, Yi Fang" <yi.fang.gan@intel.com> To: Russell King <linux@armlinux.org.uk>, Andrew Lunn <andrew@lunn.ch>, Heiner Kallweit <hkallweit1@gmail.com>, "David S . Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, =?utf-8?q?Marek_Beh=C3=BAn?= <kabel@kernel.org>, netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Cc: Looi Hong Aun <hong.aun.looi@intel.com>, Voon Weifeng <weifeng.voon@intel.com>, Song Yoong Siang <yoong.siang.song@intel.com>, Choong Yong Liang <yong.liang.choong@intel.com>, Gan Yi Fang <yi.fang.gan@intel.com> Subject: [PATCH net v3 1/1] net: phylink: Add module_exit() Date: Thu, 4 Jan 2024 18:12:55 +0800 Message-Id: <20240104101255.3056090-1-yi.fang.gan@intel.com> X-Mailer: git-send-email 2.34.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1787154549607760846 X-GMAIL-MSGID: 1787154549607760846 |
Series |
[net,v3,1/1] net: phylink: Add module_exit()
|
|
Commit Message
Gan, Yi Fang
Jan. 4, 2024, 10:12 a.m. UTC
In delete_module(), if mod->init callback is defined but mod->exit callback is not defined, it will assume the module cannot be removed and return EBUSY. The module_exit() is missing from current phylink module drive causing failure while unloading it. This patch introduces phylink_exit() for phylink module removal. Fixes: eca68a3c7d05 ("net: phylink: pass supported host PHY interface modes to phylib for SFP's PHYs") Cc: <stable@vger.kernel.org> # 6.1+ Signed-off-by: Lai Peter Jun Ann <jun.ann.lai@intel.com> Signed-off-by: Gan, Yi Fang <yi.fang.gan@intel.com> --- v1 -> v2: Introduce a macro function to reduce the boilerplate v2 -> v3: Remove the macro function as it is rejected and fix the format issue suggested from v1 drivers/net/phy/phylink.c | 6 ++++++ 1 file changed, 6 insertions(+)
Comments
On Thu, Jan 04, 2024 at 06:12:55PM +0800, Gan, Yi Fang wrote: 65;7401;1c> In delete_module(), if mod->init callback is defined but mod->exit callback > is not defined, it will assume the module cannot be removed and return > EBUSY. The module_exit() is missing from current phylink module drive > causing failure while unloading it. This is still missing the explanation why this is safe. Andrew --- pw-bot: cr
> -----Original Message----- > From: Andrew Lunn <andrew@lunn.ch> > Sent: Thursday, January 4, 2024 9:05 PM > To: Gan, Yi Fang <yi.fang.gan@intel.com> > Cc: Russell King <linux@armlinux.org.uk>; Heiner Kallweit > <hkallweit1@gmail.com>; David S . Miller <davem@davemloft.net>; Eric > Dumazet <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo > Abeni <pabeni@redhat.com>; Marek BehĂșn <kabel@kernel.org>; > netdev@vger.kernel.org; linux-stm32@st-md-mailman.stormreply.com; linux- > arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org; Looi, Hong Aun > <hong.aun.looi@intel.com>; Voon, Weifeng <weifeng.voon@intel.com>; Song, > Yoong Siang <yoong.siang.song@intel.com>; Choong, Yong Liang > <yong.liang.choong@intel.com> > Subject: Re: [PATCH net v3 1/1] net: phylink: Add module_exit() > > On Thu, Jan 04, 2024 at 06:12:55PM +0800, Gan, Yi Fang wrote: > 65;7401;1c> In delete_module(), if mod->init callback is defined but mod->exit > callback > > is not defined, it will assume the module cannot be removed and return > > EBUSY. The module_exit() is missing from current phylink module drive > > causing failure while unloading it. > > This is still missing the explanation why this is safe. > > > Andrew > > --- > pw-bot: cr Hi Andrew, Regarding the justification on why it is safe to remove phylink, we had done some memory leak check when unloading the phylink module. root@localhost:~# lsmod | grep "phylink" phylink 73728 0 root@localhost:~# rmmod phylink root@localhost:~# echo scan > /sys/kernel/debug/kmemleak root@localhost:~# cat /sys/kernel/debug/kmemleak root@localhost:~# So far, we didn't observe any memory leaking happened when unloading phylink module. Is it sufficient or do you have any other suggestions to check on whether the module is safe to remove? Best Regards, Gan Yi Fang
On Thu, Jan 11, 2024 at 06:38:58AM +0000, Gan, Yi Fang wrote: > Hi Andrew, > > Regarding the justification on why it is safe to remove phylink, > we had done some memory leak check when unloading the phylink module. > > root@localhost:~# lsmod | grep "phylink" > phylink 73728 0 > root@localhost:~# rmmod phylink > root@localhost:~# echo scan > /sys/kernel/debug/kmemleak > root@localhost:~# cat /sys/kernel/debug/kmemleak > root@localhost:~# > > So far, we didn't observe any memory leaking happened when unloading > phylink module. Is it sufficient or do you have any other suggestions to check > on whether the module is safe to remove? I have no idea why one would think that memory leaks are in some way related to whether a module can be removed or not. To me at least they are two separate issues. I'll continue waiting for the justification...
> Hi Andrew, > > Regarding the justification on why it is safe to remove phylink, > we had done some memory leak check when unloading the phylink module. > > root@localhost:~# lsmod | grep "phylink" > phylink 73728 0 > root@localhost:~# rmmod phylink > root@localhost:~# echo scan > /sys/kernel/debug/kmemleak > root@localhost:~# cat /sys/kernel/debug/kmemleak > root@localhost:~# > > So far, we didn't observe any memory leaking happened when unloading > phylink module. Is it sufficient or do you have any other suggestions to check > on whether the module is safe to remove? In general, leaked memory is safe. Being leaked, nothing is using it. If nothing is using it, how can it cause an opps, corrupt a file system, etc. What you need to do is review all users of phylink, and determine if any of them retains a pointer to anything which phylink manages and will not be freed or uninitialized when it is unloaded. Is all polling of GPIOs cleanly stopped? Are interrupt handlers disabled and removed. Are PCS and MAC drivers cleanly unloaded first? Are hwmon entries cleanly removed, taking into account that user space might have them open? All ethtool ioctl/netlink calls are out of the code before it is removed, etc. Andrew
diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c index 25c19496a336..4a05cda74d42 100644 --- a/drivers/net/phy/phylink.c +++ b/drivers/net/phy/phylink.c @@ -3726,5 +3726,11 @@ static int __init phylink_init(void) module_init(phylink_init); +static void __exit phylink_exit(void) +{ +} + +module_exit(phylink_exit); + MODULE_LICENSE("GPL v2"); MODULE_DESCRIPTION("phylink models the MAC to optional PHY connection");