From: Andrew Morton <akpm@linux-foundation.org>
To: Valdis.Kletnieks@vt.edu
Cc: sct@redhat.com, jack@suse.cz, jbacik@redhat.com,
linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org
Subject: Re: 2.6.25-rc8-mm1 - BUG in fs/jbd/transaction.c
Date: Wed, 2 Apr 2008 12:30:30 -0700 [thread overview]
Message-ID: <20080402123030.67b18bb6.akpm@linux-foundation.org> (raw)
In-Reply-To: <6495.1207163569@turing-police.cc.vt.edu>
On Wed, 02 Apr 2008 15:12:49 -0400
Valdis.Kletnieks@vt.edu wrote:
> On Tue, 01 Apr 2008 21:32:14 PDT, Andrew Morton said:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc8/2.6.25-rc8-mm1/
>
> (Yes, I know the kernel is tainted. Hopefully the traceback will make
> enough sense that it won't matter. I think I cc'd most everybody who is
> listed in MAINTAINERS or had a non-trivial jbd, quota, or ext3 patch in the broken-out/)
>
> So I was running a 'yum update' on my laptop, walked away to ask a cow-orker
> a question, and came back to find it had BUG'ed twice... Amazingly
> enough, although it died in ext3 code, it apparently only nuked whatever
> filesystem it was handling, as syslog was still able to log the gory details
> into a file in /var. Given that a kernel rpm was the one it failed on, the
> I/O was almost certainly on either / or /boot - both ext3. / is mounted
> with quotas, /boot isn't, so I'm betting on /
>
> Apr 2 13:48:07 turing-police yum: Updated: texlive-texmf-latex-2007-18.fc9.noarch
> Apr 2 13:48:08 turing-police yum: Updated: 1:openoffice.org-xsltfilter-2.4.0-12.4.fc9.x86_64
> Apr 2 13:48:09 turing-police yum: Updated: 1:openoffice.org-javafilter-2.4.0-12.4.fc9.x86_64
> Apr 2 13:48:12 turing-police yum: Updated: kernel-headers-2.6.25-0.185.rc7.git6.fc9.x86_64
>
> (here, it started updating kernel-2.6.25-0.185.rc7.git6 and died while I wasn't looking)
>
> [34895.379293] ------------[ cut here ]------------
> [34895.379299] kernel BUG at fs/jbd/transaction.c:275!
> [34895.379302] invalid opcode: 0000 [1] PREEMPT SMP
> [34895.379306] last sysfs file: /sys/devices/platform/coretemp.1/temp1_input
> [34895.379309] CPU 0
> [34895.379311] Modules linked in: gspca(U) compat_ioctl32 videodev v4l1_compat irnet ppp_generic slhc irtty_sir sir_dev ircomm_tty ircomm irda crc_ccitt coretemp vmnet(P)(U) vmmon(P)(U) nf_conntrack_ftp xt_pkttype ipt_REJECT ipt_osf nf_conntrack_ipv4 xt_ipisforif ipt_recent ipt_LOG xt_u32 iptable_filter ip_tables xt_tcpudp nf_conntrack_ipv6 xt_state nf_conntrack ip6t_LOG xt_limit ip6table_filter ip6_tables x_tables sha256_generic aes_generic acpi_cpufreq tpm_tis arc4 pcmcia ecb iwl3945 yenta_socket nvidia(P)(U) iTCO_wdt firmware_class iTCO_vendor_support rsrc_nonstatic mac80211 video watchdog_core thermal ohci1394 pcmcia_core output ieee1394 watchdog_dev processor intel_agp snd_hda_intel(U) battery bay button ac cfg80211 [last unloaded: microcode]
> [34895.379371] Pid: 24617, comm: yum Tainted: P 2.6.25-rc8-mm1 #3
> [34895.379373] RIP: 0010:[<ffffffff80300ba7>] [<ffffffff80300ba7>] journal_start+0x57/0xef
> [34895.379381] RSP: 0018:ffff81000cc49918 EFLAGS: 00010202
> [34895.379383] RAX: 0000000000000001 RBX: ffff81007f6bbf00 RCX: ffff8100347db970
> [34895.379386] RDX: ffff8100347b7d00 RSI: 0000000000000001 RDI: ffffffff806f3530
> [34895.379388] RBP: ffff81000cc49938 R08: 8000000000000000 R09: ffff8100347dbeb8
> [34895.379390] R10: 0000000000000004 R11: ffff8100347d9b58 R12: ffff81007e67d400
> [34895.379393] R13: 0000000000000012 R14: ffff81000cc499d8 R15: 0000000000000080
> [34895.379396] FS: 00007fe4468356f0(0000) GS:ffffffff8073f000(0000) knlGS:0000000000000000
> [34895.379398] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [34895.379401] CR2: 00007f9921d00000 CR3: 000000000cdc3000 CR4: 00000000000006e0
> [34895.379403] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [34895.379405] DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000400
> [34895.379408] Process yum (pid: 24617, threadinfo ffff81000cc48000, task ffff81000cc7c580)
> [34895.379410] Stack: 0000000000000292 ffff8100347dbd30 ffff8100347dbd30 ffff8100347dbd30
> [34895.379417] ffff81000cc49948 ffffffff802f9659 ffff81000cc49978 ffffffff802f9912
> [34895.379422] ffff8100347dbd30 ffff8100347dbd30 ffff8100347dbd30 0000000000000004
> [34895.379427] Call Trace:
> [34895.379433] [<ffffffff802f9659>] ext3_journal_start_sb+0x4a/0x4c
> [34895.379437] [<ffffffff802f9912>] ext3_dquot_drop+0x37/0x81
> [34895.379443] [<ffffffff802aa757>] clear_inode+0xe1/0x153
> [34895.379448] [<ffffffff802aa86f>] dispose_list+0x43/0xf8
> [34895.379453] [<ffffffff802aaaec>] shrink_icache_memory+0x1c8/0x1fe
> [34895.379459] [<ffffffff8027a231>] shrink_slab+0x111/0x1cf
> [34895.379466] [<ffffffff8027ae60>] try_to_free_pages+0x26d/0x35e
> [34895.379473] [<ffffffff80278e67>] ? isolate_pages_global+0x0/0x34
> [34895.379479] [<ffffffff8027537b>] __alloc_pages_internal+0x297/0x421
> [34895.379488] [<ffffffff8027551b>] __alloc_pages+0xb/0xd
> [34895.379493] [<ffffffff802920e3>] cache_alloc_refill+0x2d3/0x533
> [34895.379499] [<ffffffff80555548>] ? _spin_unlock+0x38/0x43
> [34895.379505] [<ffffffff80291dd0>] kmem_cache_alloc+0x5d/0x9d
> [34895.379512] [<ffffffff8033af82>] selinux_inode_alloc_security+0x31/0x8a
> [34895.379517] [<ffffffff80331f47>] security_inode_alloc+0x1c/0x1e
> [34895.379521] [<ffffffff802aa4f2>] alloc_inode+0xe1/0x1da
> [34895.379526] [<ffffffff802aa60c>] new_inode+0x21/0x8b
> [34895.379531] [<ffffffff802ed5f7>] ext3_new_inode+0x55/0xa2a
> [34895.379539] [<ffffffff80300c07>] ? journal_start+0xb7/0xef
> [34895.379545] [<ffffffff802f48c8>] ext3_mkdir+0xc7/0x2e6
> [34895.379551] [<ffffffff8029eb02>] vfs_mkdir+0xe6/0x17b
> [34895.379556] [<ffffffff802a1305>] sys_mkdirat+0xf3/0x149
> [34895.379566] [<ffffffff80213511>] ? syscall_trace_enter+0xa4/0xa9
> [34895.379571] [<ffffffff802a136e>] sys_mkdir+0x13/0x15
> [34895.379574] [<ffffffff8020c3c2>] tracesys+0xd5/0xda
> [34895.379581]
The backtrace tells it all - we were inside a transaction for filesystem A,
went into page reclaim, reclaimed an inode for filesystem B and then
DQUOT_DROP() tried to start a transaction on filesystem B. JBD doesn't
like cross-fs nested transactions (it'll corrupt task_struct.journal_info,
and will cause ab/ba deadlocks). So it went BUG.
Presumably something in the quota updates in -mm caused this.
next prev parent reply other threads:[~2008-04-02 19:31 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-02 4:32 2.6.25-rc8-mm1 Andrew Morton
2008-04-02 5:40 ` 2.6.25-rc8-mm1 Dmitri Vorobiev
2008-04-02 6:03 ` 2.6.25-rc8-mm1 Andrew Morton
2008-04-02 17:33 ` 2.6.25-rc8-mm1 (mips build failure) Christoph Lameter
2008-04-02 18:29 ` Andrew Morton
2008-04-02 18:33 ` Christoph Lameter
2008-04-02 19:06 ` Sam Ravnborg
2008-04-03 16:02 ` Ralf Baechle
2008-04-03 22:17 ` Christoph Lameter
2008-04-03 23:26 ` Dmitri Vorobiev
2008-04-04 10:24 ` Ralf Baechle
2008-04-04 17:36 ` Christoph Lameter
2008-04-04 17:50 ` Christoph Lameter
2008-04-02 6:04 ` 2.6.25-rc8-mm1 Valdis.Kletnieks
2008-04-02 6:15 ` 2.6.25-rc8-mm1 Andrew Morton
2008-04-02 6:25 ` [BUG] 2.6.25-rc8-mm1 kernel panic while bootup on powerpc Kamalesh Babulal
2008-04-02 6:25 ` Kamalesh Babulal
2008-04-02 6:39 ` Andrew Morton
2008-04-02 6:39 ` Andrew Morton
2008-04-02 7:08 ` Kamalesh Babulal
2008-04-02 7:08 ` Kamalesh Babulal
2008-04-02 7:17 ` Michael Ellerman
2008-04-02 7:17 ` Michael Ellerman
2008-04-02 17:09 ` Kamalesh Babulal
2008-04-02 17:09 ` Kamalesh Babulal
2008-04-02 18:15 ` Badari Pulavarty
2008-04-02 18:15 ` Badari Pulavarty
2008-04-02 19:22 ` Badari Pulavarty
2008-04-02 19:22 ` Badari Pulavarty
2008-04-02 21:57 ` Yinghai Lu
2008-04-02 21:57 ` Yinghai Lu
2008-04-02 22:24 ` Yinghai Lu
2008-04-02 22:24 ` Yinghai Lu
2008-04-04 9:24 ` Andy Whitcroft
2008-04-04 9:24 ` Andy Whitcroft
2008-04-02 9:02 ` [BUILD_FAILURE] 2.6.25-rc8-mm1 build failure on x86_64 with randconfig Kamalesh Babulal
2008-04-02 10:49 ` 2.6.25-rc8-mm1 Miles Lane
2008-04-02 11:08 ` 2.6.25-rc8-mm1 Valdis.Kletnieks
2008-04-02 16:58 ` 2.6.25-rc8-mm1 Chatre, Reinette
2008-04-02 19:15 ` 2.6.25-rc8-mm1 Valdis.Kletnieks
2008-04-02 16:20 ` 2.6.25-rc8-mm1 sparc64 build problem: size of array 'type name' is negative Mariusz Kozlowski
2008-04-02 16:20 ` Mariusz Kozlowski
2008-04-02 16:30 ` 2.6.25-rc8-mm1 sparc64 build problem: size of array 'type name' Andrew Morton
2008-04-02 16:30 ` 2.6.25-rc8-mm1 sparc64 build problem: size of array 'type name' is negative Andrew Morton
2008-04-02 19:12 ` 2.6.25-rc8-mm1 - BUG in fs/jbd/transaction.c Valdis.Kletnieks
2008-04-02 19:27 ` Josef Bacik
2008-04-02 19:39 ` Andrew Morton
2008-04-02 19:41 ` Josef Bacik
2008-04-03 18:18 ` Stephen Smalley
2008-04-03 23:02 ` James Morris
2008-04-04 12:46 ` Stephen Smalley
2008-04-06 23:54 ` James Morris
2008-04-04 10:15 ` Jan Kara
2008-04-04 12:53 ` 2.6.25-rc8-mm1 - BUG in fs/jbd/transaction.c' Josef Bacik
2008-04-03 18:25 ` 2.6.25-rc8-mm1 - BUG in fs/jbd/transaction.c Stephen Smalley
2008-04-02 19:30 ` Andrew Morton [this message]
2008-04-03 8:57 ` Jan Kara
2008-04-03 12:11 ` 2.6.25-rc8-mm1 Dave Airlie
2008-04-03 16:59 ` 2.6.25-rc8-mm1 Andrew Morton
2008-04-03 23:08 ` 2.6.25-rc8-mm1: Intel SATA boot failure Tilman Schmidt
2008-04-03 23:17 ` Andrew Morton
2008-04-09 14:29 ` Tilman Schmidt
2008-04-14 0:28 ` Tilman Schmidt
2008-04-14 2:05 ` Andrew Morton
2008-04-15 23:33 ` Tilman Schmidt
2008-04-04 20:16 ` usb unbind/bind => WARNING at fs/sysfs/dir.c [Was: 2.6.25-rc8-mm1] Jiri Slaby
2008-04-04 20:51 ` Greg KH
2008-04-04 21:23 ` Alan Stern
2008-04-05 3:46 ` Alan Stern
2008-04-05 4:37 ` Greg KH
2008-04-05 14:16 ` Alan Stern
2008-04-05 8:17 ` Jiri Slaby
2008-04-07 6:21 ` 2.6.25-rc8-mm1 - BUG: scheduling while atomic: swapper/0/0xffffffff Valdis.Kletnieks
2008-04-07 6:48 ` Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080402123030.67b18bb6.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=Valdis.Kletnieks@vt.edu \
--cc=jack@suse.cz \
--cc=jbacik@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sct@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.