Messages in this thread | | | Subject | Re: Possible spinlock recursion in search_module_extables() ? | From | Jeff Layton <> | Date | Wed, 08 Nov 2006 12:42:17 -0500 |
| |
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.
-- Jeff
- 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/
| |