Messages in this thread | | | Date | Wed, 8 Nov 2006 10:56:25 -0800 | From | Andrew Morton <> | Subject | Re: Possible spinlock recursion in search_module_extables() ? |
| |
On Wed, 08 Nov 2006 12:42:17 -0500 Jeff Layton <jlayton@redhat.com> wrote:
> On Mon, 2006-06-19 at 06:31 -0400, Chuck Ebbert wrote: > > Looking at this code: > > > > const struct exception_table_entry *search_exception_tables(unsigned long addr) > > { > > const struct exception_table_entry *e; > > > > e = search_extable(__start___ex_table, __stop___ex_table-1, addr); > > if (!e) > > e = search_module_extables(addr); > > return e; > > } > > > > const struct exception_table_entry *search_module_extables(unsigned long addr) > > { > > unsigned long flags; > > const struct exception_table_entry *e = NULL; > > struct module *mod; > > > > spin_lock_irqsave(&modlist_lock, flags); > > list_for_each_entry(mod, &modules, list) { > > if (mod->num_exentries == 0) > > continue; > > > > e = search_extable(mod->extable, > > mod->extable + mod->num_exentries - 1, > > addr); > > if (e) > > break; > > } > > spin_unlock_irqrestore(&modlist_lock, flags); > > > > /* Now, if we found one, we are running inside it now, hence > > we cannot unload the module, hence no refcnt needed. */ > > return e; > > } > > > > > > search_module_extables() takes a spinlock. If some kind of fault occurs > > while it's holding that lock (module list corrupted etc.,) won't it be > > re-entered while looking for its own fault handler? If so, would this > > be a possible fix? > > > > const struct exception_table_entry *search_exception_tables(unsigned long addr) > > { > > const struct exception_table_entry *e; > > > > if (core_kernel_text(addr)) > > e = search_extable(__start___ex_table, __stop___ex_table-1, addr); > > else > > e = search_module_extables(addr); > > > > return e; > > } > > I seem to be able to reliably trigger this spinlock recursion problem > with systemtap on a RHEL4 kernel. The patch suggested above does seem to > correct it, but I'm not familiar enough with extables to know whether > the approach here is correct. >
It'll still deadlock if we take an oops from a module, won't it?
The usual way of fixing this sort of thing is to play games with oops_in_progress.
- 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/
| |