linux-kernel - Re: [PATCH 2/2] module: fix bne2 "gave up waiting for init of module libcrc32c"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.00.1005311311490.3637@i5.linux-foundation.org>
Date:	Mon, 31 May 2010 13:15:37 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
cc:	Rusty Russell <rusty@...tcorp.com.au>,
	Brandon Philips <brandon@...p.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	LKML <linux-kernel@...r.kernel.org>,
	Jon Masters <jonathan@...masters.org>,
	Tejun Heo <htejun@...il.com>,
	Masami Hiramatsu <mhiramat@...hat.com>,
	Kay Sievers <kay.sievers@...y.org>
Subject: Re: [PATCH 2/2] module: fix bne2 "gave up waiting for init of module
 libcrc32c"

On Mon, 31 May 2010, Linus Torvalds wrote:
> 
> It's entirely possible that an interim fix (if we can't just fix the 
> locking) is to _not_ use "strong_try_module_get()" at all, but instead 
> just use "try_module_get()", and then after we've dropped the 
> module_mutex, but _before_ we call the "init" function for the module, we 
> wait for all the modules that this module depends on.
> 
> IOW, we'd link to other modules _before_ they are necessarily initialized 
> (their symbol tables will be as initialized as they are going to be), but 
> then before we call our own initialization routines we make sure that the 
> modules we linked to have finished theirs.
> 
> Doesn't that sound like the logical thing to do? And it wouldn't change 
> any locking.

Ok, this is a two-patch series to do exactly that. It's totally untested, 
although I _have_ booted the result, and tested that module loading and 
unloading works. But I haven't tested the race condition, obviously.

It looks sane, and quite frankly, I think it's a much better design than 
what we have now. I also note that the old code was broken for the case of 
not having CONFIG_MODULE_UNLOAD - I didn't fix it, but it should be easy 
to do (basically, we should do the whole module dependency list regardless 
of whether we can unload modules or not - we _do_ need it in order to get 
that whole case of waiting for them to load right).

The first patch doesn't really change anything, it just cleans things up 
and introduces the two-way module usage list that the second patch needs 
in order to wait for modules that we use to initialize.

Comments? Brandon - does this work for you? I may well have missed 
something.

			Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/