From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
To: "Martin J. Bligh" <mbligh@aracnet.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
bugzilla@stone.nu, dwmw2@infradead.org,
viro@parcelfarce.linux.theplanet.co.uk,
Mika Fischer <mika_fischer@gmx.net>
Subject: Re: [Bug 2367] New: kernel BUG at inode.c:334!
Date: Fri, 26 Mar 2004 12:58:06 -0300 [thread overview]
Message-ID: <20040326155806.GD3472@logos.cnet> (raw)
In-Reply-To: <20040326154915.GC3472@logos.cnet>
[-- Attachment #1: Type: text/plain, Size: 3634 bytes --]
On Thu, Mar 25, 2004 at 09:32:22AM -0800, Martin J. Bligh wrote:
> http://bugme.osdl.org/show_bug.cgi?id=2367
>
> Summary: kernel BUG at inode.c:334!
> Kernel Version: 2.4.25
> Status: NEW
> Severity: normal
> Owner: axboe@suse.de
> Submitter: bugzilla@stone.nu
>
>
> Distribution: Debian GNU/Linux
> Hardware Environment: IBM Netfinity 6000 / ICP Vortex / EXP300 Disk cabinet
> Software Environment: Vanilla Debian GNU/Linux (woody)
>
> Problem Description:
> kernel BUG at inode.c:334!
> invalid operand: 0000
> CPU: 1
> EIP: 0010:[<c014b8bc>] Not tainted
> Using defaults from ksymoops -t elf32-i386 -a i386
> EFLAGS: 00010202
> eax: f7b0606c ebx: 0000000f ecx: ee95c228 edx: f7b06000
> esi: ee95c220 edi: f7b06064 ebp: f7b0606c esp: f031df88
> ds: 0018 es: 0018 ss: 0018
> Process fsstress (pid: 883, stackpage=f031d000)
> Stack: f7b06000 f031c000 bffffb94 bffff918 f7b06064 c014bd16 f7b06000 00000000
> c0137e4e 00000000 f031c000 400135cc c0137eab 00000000 c0106e77 4012ee48
> 4012ad74 080505a0 400135cc bffffb94 bffff918 00000024 0000002b 0000002b
> Call Trace: [<c014bd16>] [<c0137e4e>] [<c0137eab>] [<c0106e77>]
> Code: 0f 0b 4e 01 b5 a5 2a c0 89 d8 0c 08 24 f8 89 86 1c 01 00 00
>
> >> EIP; c014b8bc <sync_inodes_sb+90/250> <=====
>
> >> eax; f7b0606c <_end+3777e8e8/3865b8dc>
> >> ecx; ee95c228 <_end+2e5d4aa4/3865b8dc>
> >> edx; f7b06000 <_end+3777e87c/3865b8dc>
> >> esi; ee95c220 <_end+2e5d4a9c/3865b8dc>
> >> edi; f7b06064 <_end+3777e8e0/3865b8dc>
> >> ebp; f7b0606c <_end+3777e8e8/3865b8dc>
> >> esp; f031df88 <_end+2ff96804/3865b8dc>
>
> Trace; c014bd16 <sync_inodes+36/4c>
> Trace; c0137e4e <fsync_dev+3a/80>
> Trace; c0137eab <sys_sync+7/10>
> Trace; c0106e77 <system_call+33/38>
>
> Code; c014b8bc <sync_inodes_sb+90/250>
> 00000000 <_EIP>:
> Code; c014b8bc <sync_inodes_sb+90/250> <=====
> 0: 0f 0b ud2a <=====
> Code; c014b8be <sync_inodes_sb+92/250>
> 2: 4e dec %esi
> Code; c014b8bf <sync_inodes_sb+93/250>
> 3: 01 b5 a5 2a c0 89 add %esi,0x89c02aa5(%ebp)
> Code; c014b8c5 <sync_inodes_sb+99/250>
> 9: d8 0c 08 fmuls (%eax,%ecx,1)
> Code; c014b8c8 <sync_inodes_sb+9c/250>
> c: 24 f8 and $0xf8,%al
> Code; c014b8ca <sync_inodes_sb+9e/250>
> e: 89 86 1c 01 00 00 mov %eax,0x11c(%esi)
>
> Steps to reproduce:
> 1) Download the latest LTP testsuite
> 2) Build and install the testsuite
> 3) Make sure the NFS server daemons are running
> 4) Export an XFS filesystem to be used for testing, globally, with root allowed.
> ex: /mnt/xfs *(sync,rw, no_root_squash)
> 5) Change directory to where the LTP is installed
> 6) Change directory to testcases/bin/
> 7) Execute 'nfs_fsstress.sh' and follow the prompts.
> a) Enter your hostname as the server
> b) Enter the export filesystem name, i.e. /mnt/xfs
> c) Enter "10" for the number of hours to execute.
>
> The oops should occur within 2-3h or so.
>
> This was found when trying to resolve XFS bug:
> http://oss.sgi.com/bugzilla/show_bug.cgi?id=309
This is the second bug report of "BUG at inode.c:334" I have seen.
The other one reported by Mika Fischer.
Its indeed not valid for I_LOCK or I_FREEING inode's to be on the
superblock dirty list. I cannot see how this is happening.
Martin, Mika, can you please apply the attached patch and rerun the tests?
It might give a bit more clue. Thanks.
[-- Attachment #2: inode-sync-debug.patch --]
[-- Type: text/plain, Size: 539 bytes --]
--- fs/inode.c.orig 2004-03-26 12:30:01.961087616 -0300
+++ fs/inode.c 2004-03-26 12:42:44.992089272 -0300
@@ -330,8 +330,15 @@
list_del(&inode->i_list);
list_add(&inode->i_list, &inode->i_sb->s_locked_inodes);
- if (inode->i_state & (I_LOCK|I_FREEING))
+ if (inode->i_state & (I_FREEING)) {
+ printk("inode->i_istate:%x \n", inode->i_state);
BUG();
+ }
+
+ if (inode->i_state & (I_LOCK)) {
+ printk("inode->i_istate:%x \n", inode->i_state);
+ BUG();
+ }
/* Set I_LOCK, reset I_DIRTY */
dirty = inode->i_state & I_DIRTY;
next prev parent reply other threads:[~2004-03-26 15:17 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-25 17:32 [Bug 2367] New: kernel BUG at inode.c:334! Martin J. Bligh
[not found] ` <20040326154915.GC3472@logos.cnet>
2004-03-26 15:58 ` Marcelo Tosatti [this message]
[not found] ` <20040326154000.GA28389@panic.unixguru.info>
2004-03-26 18:39 ` 2.4: " Marcelo Tosatti
2004-03-30 14:51 ` Jaco Kroon
2004-03-30 16:51 ` Marcelo Tosatti
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=20040326155806.GD3472@logos.cnet \
--to=marcelo.tosatti@cyclades.com \
--cc=bugzilla@stone.nu \
--cc=dwmw2@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mbligh@aracnet.com \
--cc=mika_fischer@gmx.net \
--cc=viro@parcelfarce.linux.theplanet.co.uk \
/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.