public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: linux-kernel@vger.kernel.org, ak@suse.de,
	Mingming Cao <cmm@us.ibm.com>,
	Badari Pulavarty <pbadari@us.ibm.com>
Subject: Re: [discuss] Re: 2.6.16-rc5-mm3: spinlock bad magic on CPU#0 on AMD64
Date: Sun, 12 Mar 2006 14:26:54 -0800	[thread overview]
Message-ID: <20060312142654.650b90fb.akpm@osdl.org> (raw)
In-Reply-To: <200603121349.32374.rjw@sisk.pl>

"Rafael J. Wysocki" <rjw@sisk.pl> wrote:
>
>  Done, and now it looks like this:

Helps a lot, thanks.

>  BUG: spinlock bad magic on CPU#0, soffice.bin/5192
>   lock: ffff81005f79ae28, .magic: 000001ff, .owner: 1..1..|1. |1.|1..|1.___1..|1..1. 1./-1,
>  .owner_cpu: -2141838208
> 
>  Call Trace: <ffffffff80210383>{__alloc_pages+99} <ffffffff802156c3>{spin_bug+195}
>         <ffffffff802077dc>{_raw_spin_lock+44} <ffffffff80270a4e>{_spin_lock+30}
>         <ffffffff8033712d>{journal_extend+77} <ffffffff80327255>{ext3_get_block+165}
>         <ffffffff8022c2f9>{do_mpage_readpage+425} <ffffffff80270cc4>{_write_unlock_irq+20}
>         <ffffffff8020cce2>{add_to_page_cache+162} <ffffffff8023fdee>{mpage_readpages+254}
>         <ffffffff803271b0>{ext3_get_block+0} <ffffffff803271b0>{ext3_get_block+0}
>         <ffffffff803146df>{get_cnode+95} <ffffffff8020a3bb>{get_page_from_freelist+619}
>         <ffffffff80210383>{__alloc_pages+99} <ffffffff80323c1a>{ext3_readpages+26}
>         <ffffffff80214030>{__do_page_cache_readahead+416} <ffffffff80213c12>{poison_obj+66}
>         <ffffffff80232058>{wake_up_bit+40} <ffffffff80243152>{unlock_buffer+18}
>         <ffffffff80315bb8>{reiserfs_prepare_for_journal+104}
>         <ffffffff802b6ab4>{do_page_cache_readahead+100} <ffffffff80215942>{filemap_nopage+322}
>         <ffffffff80208b2c>{__handle_mm_fault+1004} <ffffffff80270e7d>{_spin_unlock_irqrestore+29}
>         <ffffffff8020ae99>{do_page_fault+1257} <ffffffff8026af8d>{error_exit+0}
>         <ffffffff802ffb40>{reiserfs_copy_from_user_to_file_region+80}
>         <ffffffff80302446>{reiserfs_file_write+6102} <ffffffff802f8f4e>{reiserfs_add_entry+1054}
>         <ffffffff8033c1ff>{journal_cancel_revoke+351} <ffffffff80213c12>{poison_obj+66}
>         <ffffffff80236d27>{cache_free_debugcheck+711} <ffffffff80335734>{journal_stop+772}
>         <ffffffff80270f30>{_spin_unlock+16} <ffffffff802193a2>{vfs_write+226}
>         <ffffffff80219c80>{sys_write+80} <ffffffff8026d234>{cstar_do_call+27}
>  BUG: spinlock lockup on CPU#0, soffice.bin/5192, ffff81005f79ae28

It's a pretty vile backtrace.  I supposed you have CONFIG_FRAME_POINTER=n.

Still.  It seems that what's happened is that we took a pagefault while
reiserfs had a transaction open.  The fault is against a mmapped ext3 file
and we ended up in the recently-reworked ext3_get_block() which tests
journal_current_handle() to work out whether we're in a write or a read. 
oops.  The presence of reiserfs journal_info makes it decide it's a write,
not a read so it starts treating a reiserfs journal_info as an ext3 one.

The code used to work OK because it was only for direct-IO, which doesn't
get recurred into like this.  But it got used for regular I/O in -mm.

This should fix:

--- devel/fs/ext3/inode.c~ext3-get-blocks-maping-multiple-blocks-at-a-once-journal-reentry-fix	2006-03-12 14:25:04.000000000 -0800
+++ devel-akpm/fs/ext3/inode.c	2006-03-12 14:25:04.000000000 -0800
@@ -830,7 +830,7 @@ ext3_direct_io_get_blocks(struct inode *
 	handle_t *handle = journal_current_handle();
 	int ret = 0;
 
-	if (!handle)
+	if (!create)
 		goto get_block;		/* A read */
 
 	if (max_blocks == 1)
_


  reply	other threads:[~2006-03-12 22:29 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-11 23:24 2.6.16-rc5-mm3: spinlock bad magic on CPU#0 on AMD64 Rafael J. Wysocki
2006-03-11 23:36 ` Andrew Morton
2006-03-12 10:27   ` Rafael J. Wysocki
2006-03-12 12:49     ` [discuss] " Rafael J. Wysocki
2006-03-12 22:26       ` Andrew Morton [this message]
2006-03-12 15:10         ` Andi Kleen
2006-03-12 23:23           ` Andrew Morton
2006-03-13 11:34         ` Rafael J. Wysocki
2006-03-13 11:45           ` Andrew Morton
2006-03-13 12:07             ` Rafael J. Wysocki
2006-03-13 16:02               ` Badari Pulavarty
2006-03-13 18:12                 ` Rafael J. Wysocki

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=20060312142654.650b90fb.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=ak@suse.de \
    --cc=cmm@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbadari@us.ibm.com \
    --cc=rjw@sisk.pl \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox