RE: [RFE] Who's using a module?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



From: Lucas De Marchi
> Sent: 13 March 2020 16:23
> On Wed, Mar 11, 2020 at 6:33 AM Konstantin Kharlamov <hi-angel@xxxxxxxxx> 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.

Related would be a standard entry point into a module that indicates
that someone would like to unload it.
This would let the module code either error the request (EBUSY)
or start a tidy up sequence that should make it possible to unload
the module sometime later.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)




[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux