Messages in this thread | | | Date | Thu, 1 Jun 2006 10:40:18 -0700 | From | Andrew Morton <> | Subject | Re: 2.6.17-rc5-mm2 |
| |
On Thu, 01 Jun 2006 19:27:41 +0200 Arjan van de Ven <arjan@linux.intel.com> wrote:
> > > > http://www.stardust.webpages.pl/files/mm/2.6.17-rc5-mm2/bug_2.jpg > > > > So it's claiming that we're taking multiple i_mutexes. > > > > I can't immediately see where we took the outermost i_mutex there. > > inlining caused one level to be removed from the backtrace > one level is in fs_remove_file, the sub level is usbfs_unlink (called > from fs_remove_file)
OK.
I'll duck this patch for now, pending a tested-n-changelogged one, please.
> > Nor is > > it immediately obvious why this is considered to be deadlockable? > > what is missing is that we tell lockdep that there is a parent-child > relationship between those two i_mutexes, so that it knows that 1) > they're separate and 2) that the lock take order is parent->child > > > > (lockdep tells us that a mutex was taken at "mutex_lock+0x8/0xa", which is > > fairly useless. We need to report who the caller of mutex_lock() was). > > yeah this has been bugging me as well; either via a wrapper around > mutex_lock or via the gcc option to backwalk the stack (but that only > works with frame pointers enabled.. sigh)
Actually, __builtin_return_address(0) works OK with -fomit-frame-pointer, and that's all we need here.
- 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/
| |