lkml.org 
[lkml]   [2001]   [Feb]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Linux 2.4.1-ac15
On Mon, 19 Feb 2001, Keith Owens wrote:
> On Mon, 19 Feb 2001 11:35:08 +0000 (GMT),
> Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> >The problem isnt running module code. What happens in this case
> >
> > mod->next = module_list;
> > module_list = mod; /* link it in */
> >
> >Note no write barrier.
>
> <humour>It works on ix86 so the code must be right</humour>

Too bad it doesn't.

> >Delete is even worse
> >
> >We unlink the module
> >We free the memory
> >
> >At the same time another cpu may be walking the exception table that we free.
>
> Another good reason why locking modules via use counts from external
> code is not the right fix. We definitely need a quiesce model for
> module removal.

Unless I'm mistaken, we need both use counts and SMP magic (though not
necessarily as extreme as what the "freeze all other CPUs during module
unload" patch did).


I think something like this would work (in addition to use counts)

int callin_func(void *p)
{
int *cpu = p;

while (*cpu != smp_processor_id()) {
current->cpus_allowed = 1 << *cpu;
schedule();
}

return 0;
}

void callin_other_cpus(void)
{
int cpus[smp_num_cpus];
int i;

for (i=0; i<smp_num_cpus; i++) {
cpus[i] = i;

kernel_thread(callin_func, &cpus[i], ...);
}
}

and call callin_other_cpus() before unloading a module.


I'm not sure how you could make exception handling safe without locking
all accesses to the module list - but that sounds like the sane thing to
do anyway.

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

\
 
 \ /
  Last update: 2005-03-22 13:15    [W:1.251 / U:0.848 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site