[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <B8C511D7-3653-4CC4-9BCC-B03B8E422791@sun.com>
Date: Sun, 10 Jan 2010 03:45:59 -0700
From: Andreas Dilger <adilger@....com>
To: bugzilla-daemon@...zilla.kernel.org
Cc: linux-ext4@...r.kernel.org
Subject: Re: [Bug 15018] New: ext4 backtraces out of nowhere
On 2010-01-09, at 12:01, bugzilla-daemon@...zilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=15018
>
> While doing an rsync to an ext4 filesystem, suddenly the above
> showed up in my dmesg:
>
> Jan 9 15:55:20 pannekake kernel: [61568.551238] Pid: 28573, comm:
> rsync Not
> tainted 2.6.33-rc3 #2
> Jan 9 15:55:20 pannekake kernel: [61568.557085] Call Trace:
> Jan 9 15:55:20 pannekake kernel: [61568.559623] [<ffffffffa0253aa1>]
> ext4_write_inode+0x4d/0xc7 [ext4]
>
> It showed up again ~20 minutes later, and since then I haven't seen
> it. I'm a bit puzzled since I don't actually see any error messages
> (just the backtrace), and I'm not able to find any ill effects
> except for the traceback, but I guess it still shouldn't happen.
>
> FWIW, the ext4 is on an LVM whose one of the component RAID-5s was
> resyncing at the time. I don't know if that is relevant or not.
In ext4_write_inode it has a dump_stack() in the case where
ext4_journal_current_handle() is non-NULL.
This is a bug, because later on it calls ext4_force_commit(), which
would end up blocking on the journal commit to finish, which is
blocked waiting on the journal handle held by the selfsame thread that
started the journal commit in the first place.
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists