[lkml]   [2001]   [Feb]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
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 <> 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;

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
More majordomo info at
Please read the FAQ at

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