Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp1346647pxu; Thu, 8 Oct 2020 09:15:26 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw/NtqETev0r2cF0rHRga3AtwP4gd3TbWabeq2VlDeth4A8ENs4e7QxglF645hR96V23b2T X-Received: by 2002:aa7:c659:: with SMTP id z25mr9687684edr.219.1602173725766; Thu, 08 Oct 2020 09:15:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1602173725; cv=none; d=google.com; s=arc-20160816; b=mXxJV8sQqn1dTjGBjYXXflWckTWWULVsfP61bv8SNUXLqFpzqXQhiutKcRfgQMlw0o bjlsd0M4oVGLNI6hqow53SVZWpx+tU57bM1j03cSKPEdRE0fiLHds0R41qGJze+NHVZb Ey1x5rguL37HX4tvxLV++607Vj7toMCDRlgm42VFU8yPW17WVcV9u+YIwoZlU5A5RnZI JQo1LAGtzXjhvAtGXyW4nG/fXCU7QU3YQYTeLbULZQk7Wer9oqkgcRCsmBNE29esbH/+ IGxdcCozlAvM5XpGDvAFIOWt0svbLFen/Vgy4KitlWckb+mZsvWPFFzdwm3qiKYIHPsg Judg== 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 :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id; bh=Hb7C64On0Fj7LsdJhxyBQRe021L5NmO10iH90jv+HoQ=; b=wCAjMyhssfjgelMBJCjZvGsXVYx8slICRyJQIbIPiZM3ANrv9VkR+L8aAN43Pi7E3E oZRyWfrfggfOS+TMxs/hM0Y5PspZXKr+YaPRaREYc3dzdWaOgEgpKmLmJ3PJHkG0dCxa jL1VD/WyiSkFTTnOnEC7yEYmyQrqhKndimlR3Gy951tq8ti4Xcz+0DJDMesdmJ4gUgXw RijOSwxw4DhRfQ2YIJM1ef/RZfpPGkPy9XCwfGbi5XyWenWO1jaqSpSy4TBD8Bnslh6b WGoqRxdfXm76GMjI6x8aVVXFmGAQccVVxlQaGjI/ukhSz35XS1TSTcFsnLlyQ3GG4xBc khVw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-wireless-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 v30si3761618edd.561.2020.10.08.09.14.59; Thu, 08 Oct 2020 09:15:25 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-wireless-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-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730596AbgJHQOa (ORCPT + 99 others); Thu, 8 Oct 2020 12:14:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44960 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729164AbgJHQO3 (ORCPT ); Thu, 8 Oct 2020 12:14:29 -0400 Received: from sipsolutions.net (s3.sipsolutions.net [IPv6:2a01:4f8:191:4433::2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D24BFC061755; Thu, 8 Oct 2020 09:14:29 -0700 (PDT) Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.94) (envelope-from ) id 1kQYYa-001jkw-PM; Thu, 08 Oct 2020 18:14:16 +0200 Message-ID: <62f6c2bd11ed8b25c1cd4462ebc6db870adc4229.camel@sipsolutions.net> Subject: Re: [PATCH net 000/117] net: avoid to remove module when its debugfs is being used From: Johannes Berg To: David Laight , 'Taehee Yoo' , "davem@davemloft.net" , "kuba@kernel.org" , "netdev@vger.kernel.org" , Nicolai Stange Cc: "linux-wireless@vger.kernel.org" , "wil6210@qti.qualcomm.com" , "brcm80211-dev-list@cypress.com" , "b43-dev@lists.infradead.org" , "linux-bluetooth@vger.kernel.org" Date: Thu, 08 Oct 2020 18:14:15 +0200 In-Reply-To: <1cbb69d83188424e99b2d2482848ae64@AcuMS.aculab.com> (sfid-20201008_181146_072575_728542C7) References: <20201008155048.17679-1-ap420073@gmail.com> <1cbb69d83188424e99b2d2482848ae64@AcuMS.aculab.com> (sfid-20201008_181146_072575_728542C7) Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.5 (3.36.5-1.fc32) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On Thu, 2020-10-08 at 15:59 +0000, David Laight wrote: > From: Taehee Yoo > > Sent: 08 October 2020 16:49 > > > > When debugfs file is opened, its module should not be removed until > > it's closed. > > Because debugfs internally uses the module's data. > > So, it could access freed memory. > > > > In order to avoid panic, it just sets .owner to THIS_MODULE. > > So that all modules will be held when its debugfs file is opened. > > Can't you fix it in common code? Yeah I was just wondering that too - weren't the proxy_fops even already intended to fix this? The modules _should_ be removing the debugfs files, and then the proxy_fops should kick in, no? So where's the issue? johannes