Hi Luis, Michal, On Wed, 26 Jul 2023 13:59:06 -0700, Luis Chamberlain wrote: > On Mon, Jul 10, 2023 at 07:43:01AM +0200, Michal Hocko wrote: > > On Fri 07-07-23 11:56:49, Luis Chamberlain wrote: > > > On Mon, Jul 03, 2023 at 03:47:22PM +0200, Michal Hocko wrote: > > > > On Fri 30-06-23 16:05:33, Luis Chamberlain wrote: > > > > [...] > > > > > What prevents code from racing the free with a random module_put() > > > > > called by some other piece of code? > > > > > > > > Wouldn't be ref count a garbage already? How can you race when freeing > > > > if module_put fail? > > > > > > It could yes, ie, so this risks at all being junk. > > > > Could you be more specific please? I still do not see a scenario where > > module string name would be junk while refcount itself would be a valid > > memory. > > That is true, but if refcount is invalid so will the memory for the > string. This isn't how I read the code, and this is exactly the reason why I submitted this patch in the first place. As far as I can see, there are 3 possibilities: 1* The refcount is correct, everything is fine. 2* The refcount is wrong (we are trying to put a ref which was never taken), however the module wasn't unloaded yet, so the module name is still readable. 3* The refcount is wrong and the module has already been unloaded. The memory may have been reused already, so the module name can't be read. My patch is only useful in case 2. Although it doesn't cover all cases, I think it is relevant because unloading modules is something you rarely do in production, so if the refcount goes wrong, we will almost always be in case 2. That being said, if you don't like my proposal for whatever reason, or prefer addressing the issue in a different way, no problem at all. > > It would likely be better to use refcount_t instead of atomic_t. > > Patches welcomed. Michal, do I understand correctly that this would prevent the case our customer had (too many gets), but won't make a difference for actual too-many-puts situations? -- Jean Delvare SUSE L3 Support
