On Wed, Dec 1, 2010 at 2:13 PM, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Wed, 01 Dec 2010 16:51:12 -0500
> Trond Myklebust <Trond.Myklebust@xxxxxxxxxx> wrote:
>
>> On Wed, 2010-12-01 at 13:38 -0800, Andrew Morton wrote:
>> > Probably on most call paths we'll be OK - if a process is in the middle
>> > of a file truncate, holdin a file* ref which holds an inode ref then
>> > nobody will be unmounting that fs and hence nobody will be unloading
>> > that module.
>> >
>> > However on the random_code->alloc_page->vmscan->releasepage path, none
>> > of that applies.
>>
>> Just out of interest, what ensures that the mapping is still around for
>> the 'spin_unlock_irq(&mapping->tree_lock);' in __remove_mapping()?
>
> Nothing, afacit.
No, we're good.
Module unload has to go through a "stop_machine()" cycle, and that in
turn requires an idle period for everything. And just a preemption
reschedule isn't enough for that.
So what is sufficient is that
- we had the page locked and on the mapping
This implies that we had an inode reference to the module, and the
page lock means that the inode reference cannot go away (because it
will involve invalidate-pages etc)
- we're not sleeping after __remove_mapping, so unload can't happen afterwards.
A _lot_ of the module races depend on that latter thing. We have
almost no cases that are strictly about actual reference counts etc.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
