Received: by 2002:a05:7412:e794:b0:fa:551:50a7 with SMTP id o20csp1651671rdd; Thu, 11 Jan 2024 05:43:24 -0800 (PST) X-Google-Smtp-Source: AGHT+IG3SvXFHEbWxMKvWfGMOsNvxzPYltTZ563sWV7rsq5TYQebwt4zz/i6xhEH1ta04Er5I0RE X-Received: by 2002:a17:90a:f184:b0:28b:e295:fc41 with SMTP id bv4-20020a17090af18400b0028be295fc41mr1061442pjb.95.1704980604484; Thu, 11 Jan 2024 05:43:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704980604; cv=none; d=google.com; s=arc-20160816; b=R3bBqK2lanXHmxKPjEdTNQYAOxnwNznD/aaXhTftP/qrhifR1Ni8htudiLgSTwOfgy ROLf4u3OJD5zko2jgk/m9jZuKYMZ0UvFBFaMSYqJnNQ3EBS0RMO5yvDyKBEc2s2D0gXf 3DwzvBlBcObuenthB+ZedBjWdPPQ3+rrFx8DBqYcwozQTZAMcCNbbaVjtthhaFdVZM0k W8449mEjwUZ8+8bAxofI2J9S0781aCoI0X4aWN45j3GU0v6In7LbdJbcqcf75OeHTnvM sqGQ6+e42fIJbnzbxGjkznuGOLKRPiiy/+gpSEgnvtTGuDUvv9wh0wa7taz2CJXrnbFe w01A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:message-id:subject:cc :to:from:date:dkim-signature; bh=il+w8FtfhJHoKZMk6/3PRsXBylrA/EgWONxoBacvEFk=; fh=kNVP+naO3TBQOpxxN7odz59hdgwC0/9qs2mwkHmyQ/E=; b=NXm8EQDjJgJy19Hitg6gCCg9ViI8XzV8SvBSOvuOgAV/HKXzfq4N5Vtfk0JXPn0FRV G1HBU9ozgKOeYjNVGI65C1RTidrhnhw39UNoHTiqe4VNlbNOYkaRMD84SWDOQmDC/eYX jS7t44676N797RLnv+XySfYTXx1mlyrWJ+D98e+DQ/+UB4LPNTI4Vk6MxepStcvEG9NG 6lDgXK2taUiJfk4/1jTXDKbWSWa0K4zD3gnEQrtYmVebMMe9kjqOtVOdWAdaPMKuE6NP ZUV49g8PexLNslLYvK2g/2VKwklvTL5vOMsmtv00WIaesEUwHvNmhUbg/ZMbIJpYRUYV a2ug== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@lunn.ch header.s=20171124 header.b="Mi/7EUkk"; spf=pass (google.com: domain of linux-kernel+bounces-23671-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-23671-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=lunn.ch Return-Path: Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [147.75.48.161]) by mx.google.com with ESMTPS id s35-20020a17090a69a600b00278f6d616aasi1144126pjj.71.2024.01.11.05.43.23 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Jan 2024 05:43:24 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-23671-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161; Authentication-Results: mx.google.com; dkim=pass header.i=@lunn.ch header.s=20171124 header.b="Mi/7EUkk"; spf=pass (google.com: domain of linux-kernel+bounces-23671-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-23671-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=lunn.ch 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 sy.mirrors.kernel.org (Postfix) with ESMTPS id 67D68B248F9 for ; Thu, 11 Jan 2024 13:41:53 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 0E63132C84; Thu, 11 Jan 2024 13:41:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=lunn.ch header.i=@lunn.ch header.b="Mi/7EUkk" Received: from vps0.lunn.ch (vps0.lunn.ch [156.67.10.101]) (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 CF62B1802D; Thu, 11 Jan 2024 13:41:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lunn.ch Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=lunn.ch DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:From:Sender:Reply-To:Subject: Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:Content-Disposition:In-Reply-To:References; bh=il+w8FtfhJHoKZMk6/3PRsXBylrA/EgWONxoBacvEFk=; b=Mi/7EUkk+96Fu+e4grIj30OKjw s9UyrmWftnrF5wN6Wzm7wk3Z+2ni4VbciRb89fFHNdz7XOhm6n6z8y4JbQdPiM695s0KR7w/ilFeA XRWAAsLwqU88g7nnIBgdyaaEn9mfjf3/lxxelTjQKnISiOWvECOfxFpBj0eCdTv5gTDI=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1rNuvm-00506I-0z; Thu, 11 Jan 2024 14:17:10 +0100 Date: Thu, 11 Jan 2024 14:17:10 +0100 From: Andrew Lunn To: "Gan, Yi Fang" Cc: Russell King , Heiner Kallweit , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Marek =?iso-8859-1?Q?Beh=FAn?= , "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" , "Voon, Weifeng" , "Song, Yoong Siang" , "Choong, Yong Liang" Subject: Re: [PATCH net v3 1/1] net: phylink: Add module_exit() Message-ID: <3e87a5f7-e637-401c-8fe1-9b0c5e6d8289@lunn.ch> References: <20240104101255.3056090-1-yi.fang.gan@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: > 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