Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp2835083ybh; Mon, 16 Mar 2020 10:34:50 -0700 (PDT) X-Google-Smtp-Source: ADFU+vsNJOV96M7uOh4oHJ5fcE4Bp9aNE3HDMyOEt2EpOsSGW39hCX8RAdAY9FdYSD9EuaOw6+l6 X-Received: by 2002:a9d:2215:: with SMTP id o21mr278623ota.113.1584380090248; Mon, 16 Mar 2020 10:34:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584380090; cv=none; d=google.com; s=arc-20160816; b=dbPkAwBBQDBjnbvkELuks9lvY5d9RBfKk6u7boOnu0RJWw5OzpfnTFwVCdJwLsMcpl Qk3nEzgebVFX07dDqe9ayKTZG+8vTvDdhLAh49vcVNx5T3Pty6qbobM/jTWRYR3E6XHr AxnY8zc2fur/l7IZZvWKqQyAnhrKuMwaMR2hJ6P7CsgmtXEsbJWd//cgECQoKNcuHc3G 3qkL1LLC4kH4P+4zB/OBDPhYR+7sK98msLQTQj9pXEJmiC1vEoIQ8eA9V9TckL0suacl iKewsUpk2QBUX8DrknAIBihFuXa0tQTilSiVSgxqtYQU4d5k9WojaSjZ2wZj8pRlhg6B cLuQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=IitBTZw2dXcPErCUHcydxG1yMisPi4S7mrxJ8ILN0bY=; b=Z981SK+6G44eAFon4GkRIhC1/bmHI+ocexKPM12AwT8h15vTvP6JYHjGWU6YSNuh/T dmwvOHoLMcuFib6GiwfzNknupfM6ABtqi5CVGBGVzGUQylu3BcbNTdKV0HTwZWGtgsTE d3xgBG4JNBwaEcWNcr6N7+XNCgb9ZCAiI3hbhDfJVsr+VUPKdZT68yddq+JMlMUpPRiV 3nKRqgpj0b+4hF6ks9Fl6Dcyi7WdmMf/DB8qQ5tAsnzDPALyyAvu/3lOra/XK9z7leAx wsL4iQNRlgFDRKIlV6m4JHmTBW0zjY67HkYfvaJL9V5sROv6/VKz+X4US6mxxQg9muZY FiTQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=rhADrUyB; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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 vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g9si257145otk.97.2020.03.16.10.34.37; Mon, 16 Mar 2020 10:34:50 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=rhADrUyB; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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 S1732008AbgCPReO (ORCPT + 99 others); Mon, 16 Mar 2020 13:34:14 -0400 Received: from mail.kernel.org ([198.145.29.99]:37786 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730437AbgCPReO (ORCPT ); Mon, 16 Mar 2020 13:34:14 -0400 Received: from linux-8ccs (p5B2812F9.dip0.t-ipconnect.de [91.40.18.249]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 74552205ED; Mon, 16 Mar 2020 17:34:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1584380053; bh=d0dyqr+WPlsBEneLL+p3TFD21XBLfy5yd1BTLM2pOqk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=rhADrUyBNJ9VsmcG8CWy4JLDr8n4UU6MCERPUNwVIncQoHdMNwcglKAgMWdvaCMt5 51YYhzTYTmkKIhf4BF/9eDxVEfAcFs2HAFiR7R7ehrlIb0ktINZr7sl6Gl6BEiU3uP xjvbPlFjW1gKsb42WQ8zwZTUASeasyUesRfzel3M= Date: Mon, 16 Mar 2020 18:34:09 +0100 From: Jessica Yu To: Lucas De Marchi Cc: Konstantin Kharlamov , linux-modules , lkml , Steven Rostedt Subject: Re: [RFE] Who's using a module? Message-ID: <20200316173408.GA6841@linux-8ccs> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-OS: Linux linux-8ccs 4.12.14-lp150.12.61-default x86_64 User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org +++ Lucas De Marchi [13/03/20 09:22 -0700]: >+Jessica +Steve +lkml > >On Wed, Mar 11, 2020 at 6:33 AM Konstantin Kharlamov wrote: >> >> Once in a while there's a need to remove a module (for example because you rebuilt it, or to reload it with different parameters, or whatever…). And then doing `rmmod modulename` and `modprobe -r modulename` gives: >> >> rmmod: ERROR: Module modulename is in use >> >> If you're lucky, firing up `lsmod | grep modulename` will get you offenders inside "used by" column. But often there's nothing except the count above zero. It is very easy to reproduce if you check `lsmod` output for your graphics driver. I checked it on `i915` and `amdgpu`: when graphics session is opened you can't remove it and `lsmod` doesn't show who's using it. >> >> There's very popular and old question on SO¹ that at the moment has over 55k views, and the only answer that seem to work for people is insanely big and convoluted; it is using a custom kernel driver and kernel tracing capabilities. I guess this amount of research means: no, currently there's no easy way to get who's using a module. >> >> It would be amazing if kernel has capability to figure out who's using a module. > >Yeah, right now this would need some work on the kernel side to record >the callers of try_module_get()/__module_get()... usually done e.g on >fops-like structs in a owner field. >The only thing we have there right now is the trace. The trace is not >so bad since it can be added in the kernel command line, but would >usually only be enabled while debugging. > >For implementing such a feature I think we would need to add/remove >module owner into the mod struct whenever we have a _get()/_put(). >Maybe it's worth it, but it doesn't >come without overhead. I'd like to hear what other people think. Hmm, we technically have mod->source_list and mod->target_list already, which keeps track of modules that depend on THIS_MODULE and modules that THIS_MODULE depends on, respectively. However, this is limited to symbol dependencies only, which is what is shown in lsmod in the Used By field. In other words, we currently only keep track of module dependencies when a module uses a symbol from another module. Indeed, it could be nice to keep track of try_module_get() callers, but I'm afraid this is not as trivial as simply adding owner to mod->source_list when try_module_get() is called. try_module_get() and module_put() are designed to be quick and callable from interrupt and process context, and mod->{source,target}_list are protected by the module_mutex. Even if we could use module_mutex, it may increase lock contention considerably. So the locking scheme would have to be reworked to make this happen. I suppose this could be introduced as a DEBUG option, and I'd welcome a patch if there's someone out there interested in picking up the legwork. But I don't get the feeling that the demand for this is that high (perhaps I'm totally wrong?), especially for something that ftrace could report on much better. I could for example trace all module_get's and put's from boot and see which processes and even the call sites where these calls stem from. E.g., if I enable tracing in /sys/kernel/debug/tracing/events/module/module_{get,put} (and filter name == "i915"), you'd see output like: X-2404 [000] .... 2334.643888: module_put: i915 call_site=dma_buf_release refcnt=33 X-2404 [000] .... 2334.643990: module_put: i915 call_site=dma_buf_release refcnt=32 kwin_x11-2877 [007] .... 2334.645605: module_get: i915 call_site=dma_buf_export refcnt=33 kwin_x11-2877 [007] .... 2334.650827: module_get: i915 call_site=dma_buf_export refcnt=34 Of course, you'd have to know to enable tracing before the problem occurs.. Hope that helps clarify things a bit, Jessica