Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp1967145ybh; Fri, 13 Mar 2020 10:30:54 -0700 (PDT) X-Google-Smtp-Source: ADFU+vtwcsYGaTkYr/jlAjkbH4mZ0ArcCU1oBPbD4/oOAU8TDDtkV312mHI8n4qfwdsmeqYe7t6U X-Received: by 2002:aca:62d5:: with SMTP id w204mr1130211oib.119.1584120653904; Fri, 13 Mar 2020 10:30:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584120653; cv=none; d=google.com; s=arc-20160816; b=v+7Jl5uEYiRqAEmH2Vu256jgQxJhDIsV7tC7edlcwfgPlJh+IXjSckVAvai7QooC+6 uUzxZQ+RuPD9ug/V8NGQmsK3fdJXQxKxqJ8oaDsoZeYEiADEszpzTd0MxM+No2lo7XmS 8VMhRUiFXcZReRuB1nb2TFai3cCO5gwyedh+qLFuMQ2IZhje9s34lbVMKLGAOG7Cj/q7 vxfM6dp7nlNYCN0j4Xox+DfzFv1QaJ/rpSOSX0X6Zoc7KrkpU860oMBu3ugQE1Wf6t53 2je9YG84VhLFjk0fkm/+AVjNFcY7z2LJzDtDAcMObFJpVSVlZ2g7ikxTkIOoh+Daujcl gsWQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=Athf30B+VmdNay5if1gLPNSw/wXHFCYLW8ZtaX+VfAU=; b=j5aiNSiskaRV042X64D9Z93sQKhxITcw3UvuWuCuYTLMJdTPUg5GQ4bS3WOaU8dsIb eMc8SHNx9c3U9Y9lfH+LMa4DX4xANN4ib8c8n3lFMjY5pP8Z6R7uZCNXQ8i3B5DWFoS7 U7IlyF0/PIBO0bn0yPHHporTRK7dc4CapBU2In8DtLV2ywfkXh3qc/2nBWGfn2TIxIk3 wWJMJJR5zzRS0SwO/9l/tfaCgxBRVe9wbBnJNs5Mx+c8AkRa8f1BLTlcZUHrECGlw9m6 5sqf4NFpMzH6n1iehRtzW0g73NhVVqjI3JYkMRDoCF8NS3OZ5RoZ+X5C6vt9WvnMOZkG HA3Q== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q206si3107862oig.71.2020.03.13.10.30.41; Fri, 13 Mar 2020 10:30:53 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727133AbgCMRaE convert rfc822-to-8bit (ORCPT + 99 others); Fri, 13 Mar 2020 13:30:04 -0400 Received: from mail.kernel.org ([198.145.29.99]:58708 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726446AbgCMRaC (ORCPT ); Fri, 13 Mar 2020 13:30:02 -0400 Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (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 DA224206BE; Fri, 13 Mar 2020 17:30:00 +0000 (UTC) Date: Fri, 13 Mar 2020 13:29:58 -0400 From: Steven Rostedt To: Lucas De Marchi Cc: Konstantin Kharlamov , linux-modules , Jessica Yu , lkml Subject: Re: [RFE] Who's using a module? Message-ID: <20200313132958.29029440@gandalf.local.home> In-Reply-To: References: X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 13 Mar 2020 09:22:33 -0700 Lucas De Marchi wrote: > +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. I believe that the issue is a task did a get on the module and hasn't released it. As it is using that module. If anything, you can trace all the function of the module if it isn't loaded yet. Simply do the following: # trace-cmd start -p function -l :mod:modname -e module_get -f 'name == "modname"' -R stacktrace # modprobe modname # trace-cmd show For example I did the following: # trace-cmd start -p function -l :mod:ebtables -e module_get -f 'name == "ebtables"' -R stacktrace plugin 'function' # modprobe ebtable_filter # trace-cmd show # tracer: function # # entries-in-buffer/entries-written: 7/7 #P:8 # # _-----=> irqs-off # / _----=> need-resched # | / _---=> hardirq/softirq # || / _--=> preempt-depth # ||| / delay # TASK-PID CPU# |||| TIMESTAMP FUNCTION # | | | |||| | | modprobe-1720 [001] .... 823.724284: ebtables_init <-do_one_initcall modprobe-1720 [001] ...1 823.724989: module_get: ebtables call_site=ref_module refcnt=2 modprobe-1720 [001] ...2 823.724995: => trace_event_raw_event_module_refcnt => try_module_get.part.50 => ref_module => resolve_symbol => load_module => __do_sys_finit_module => do_syscall_64 => entry_SYSCALL_64_after_hwframe => 0xc032e68fffffffff => 0x2946ffffffff => 0x68600000001 => hp_wmi_perform_query => ebtables_init => 0x1020e9006 => 0xc08e900000000686 => 0xc032e6baffffffff modprobe-1720 [001] .... 823.725147: ebt_register_table <-ops_init modprobe-1720 [001] .... 823.725153: translate_table <-ebt_register_table modprobe-1720 [001] .... 823.725296: ebt_register_table <-ops_init modprobe-1720 [001] .... 823.725301: translate_table <-ebt_register_table Not sure if this is something you are looking for. -- Steve > > > > > > 1: https://stackoverflow.com/questions/448999/is-there-a-way-to-figure-out-what-is-using-a-linux-kernel-module > > > > P.S.: please, add me to CC when replying, I'm not subscribed to the list. > > > > -- > Lucas De Marchi