From: David Sterba <dsterba@suse.cz>
To: Martin Mailand <martin@tuxadero.com>
Cc: linux-btrfs@vger.kernel.org, ceph-devel@vger.kernel.org
Subject: Re: kernel BUG at fs/btrfs/inode.c:1163
Date: Wed, 19 Oct 2011 11:49:25 +0200 [thread overview]
Message-ID: <20111019094925.GA29468@ds.suse.cz> (raw)
In-Reply-To: <4E9DDBB1.2050007@tuxadero.com>
On Tue, Oct 18, 2011 at 10:04:01PM +0200, Martin Mailand wrote:
> [28997.273289] ------------[ cut here ]------------
> [28997.282916] kernel BUG at fs/btrfs/inode.c:1163!
1119 fi = btrfs_item_ptr(leaf, path->slots[0],
1120 struct btrfs_file_extent_item);
1121 extent_type = btrfs_file_extent_type(leaf, fi);
1122
1123 if (extent_type == BTRFS_FILE_EXTENT_REG ||
1124 extent_type == BTRFS_FILE_EXTENT_PREALLOC) {
...
1158 } else if (extent_type == BTRFS_FILE_EXTENT_INLINE) {
1159 extent_end = found_key.offset +
1160 btrfs_file_extent_inline_len(leaf, fi);
1161 extent_end = ALIGN(extent_end, root->sectorsize);
1162 } else {
1163 BUG_ON(1);
1164 }
rc10 kernel sources point to this, can you please verify it in your
sources? if it's really this one, that means that it's an unhandled
extent_type read from the b-tree leaf and could be a corruption. (the
value is directly obtained from file extent type item, line 1121)
It would be interesting what's the value of 'extent_type' at the time of
crash, if it's eg -1 that could point to a real bug, some unhandled
corner case in truncate, for example.
> [28997.507960] Call Trace:
> [28997.507960] [<ffffffffa00903e0>] ? acls_after_inode_item+0xc0/0xc0 [btrfs]
... a corruption caused by overflow of xattrs/acls into inode item bytes?
As ceph stresses xattrs very well, I wouldn't be surprised by that.
david
next prev parent reply other threads:[~2011-10-19 9:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-18 20:04 kernel BUG at fs/btrfs/inode.c:1163 Martin Mailand
2011-10-19 9:49 ` David Sterba [this message]
2011-10-19 12:59 ` Martin Mailand
2011-10-24 11:39 ` David Sterba
2011-10-19 15:02 ` Anand Jain
2011-10-20 13:04 ` Martin Mailand
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=20111019094925.GA29468@ds.suse.cz \
--to=dsterba@suse.cz \
--cc=ceph-devel@vger.kernel.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=martin@tuxadero.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.