Thread (6 messages) 6 messages, 3 authors, 2022-05-01

RE: [PATCH v2 1/2] module: update dependencies at try_module_get()

From: David Laight <hidden>
Date: 2022-05-01 13:23:15
Also in: alsa-devel, dri-devel, intel-gfx, lkml

From: Mauro Carvalho Chehab
Sent: 30 April 2022 14:38

Em Sat, 30 Apr 2022 14:04:59 +0200
Greg KH [off-list ref] escreveu:
quoted
On Sat, Apr 30, 2022 at 11:30:58AM +0100, Mauro Carvalho Chehab wrote:
quoted
Did you run checkpatch on this?  Please do :)
quoted
+
+	if (mod == this)
+		return 0;
How can this happen?
When people mistakenly call try_module_get(THIS_MODULE)?
Yes. There are lots of place where this is happening:

	$ git grep try_module_get\(THIS_MODULE|wc -l
	82
quoted
We should
throw up a big warning when that happens anyway as that's always wrong.

But that's a different issue from this change, sorry for the noise.
It sounds very weird to use try_module_get(THIS_MODULE).

We could add a WARN_ON() there - or something similar - but I would do it
on a separate patch.
You could add a compile-time check.
But a run-time one seems unnecessary.
Clearly try_module_get(THIS_MODULE) usually succeeds.

I think I can invent a case where it can fail:
The module count must be zero, and a module unload in progress.
The thread doing the unload is blocked somewhere.
Another thread makes a callback into the module for some request
that (for instance) would need to create a kernel thread.
It tries to get a reference for the thread.
So try_module_get(THIS_MODULE) is the right call - and will fail here.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help