I've encountered a kernel BUG in jbd during setxattr on 2.5.75, likely
related to the recent xattr locking changes. Originally encountered
with SELinux enabled, but also occurs with SELinux disabled. I have not
been able to reproduce it with 2.5.74.
Relevant kernel config is:
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_SECURITY=y
CONFIG_SECURITY=y
CONFIG_SECURITY_CAPABILITIES=y
# CONFIG_SECURITY_SELINUX is not set
No other kernel patches, and SELinux patch for 2.5.75 only adds the
SELinux module to the security/selinux subdirectory, so there is no
affect when the option is disabled as above. No modules loaded.
A command for reproducing the bug is:
find . -exec setfattr -n security.selinux -v system_u:object_r:staff_home_t {} \;
However, you should be able to use security.foo for the -n and any value
for the -v to achieve the same effect. The only important thing is to
set a value that actually causes a change to any existing value for the
attribute. This was run in a fairly large directory, and took a few
moments to trigger the bug (but < 5 minutes).
Kernel output was:
journal_commit_transaction: freed 4 reserved buffers
journal_commit_transaction: freed 5 reserved buffers
journal_commit_transaction: freed 6 reserved buffers
journal_commit_transaction: freed 7 reserved buffers
Assertion failure in do_get_write_access() at fs/jbd/transaction.c:684: "handle->h_buffer_credits > 0"
------------[ cut here ]------------
kernel BUG at fs/jbd/transaction.c:684!
invalid operand: 0000 [#1]
CPU: 0
EIP: 0060:[<c01b69e9>] Not tainted
EFLAGS: 00010282
EIP is at do_get_write_access+0x7e9/0x870
eax: 0000006a ebx: dcc247f0 ecx: df4580c0 edx: 00000001
esi: df3b6c64 edi: dfdbcb08 ebp: df3b6c64 esp: dce25c68
ds: 007b es: 007b ss: 0068
Process setfattr (pid: 17114, threadinfo=dce24000 task=dd8be0a0)
Stack: c0473880 c0457497 c046fed2 000002ac c046ff8a dfdae168 db03e2c8 00000000
00000000 00000000 dfdae084 c01674e1 dcc247f0 004c0517 00001000 00001000
004c0517 dfdcc63c 0fd578d4 da4d3000 df3b6c64 dd99c41c 0fd578d4 c01b6cf9
Call Trace:
[<c01674e1>] __bread+0x11/0x40
[<c01b6cf9>] journal_get_create_access+0x229/0x2f0
[<c01b4c28>] ext3_xattr_rehash+0x78/0xa0
[<c01b41e5>] ext3_xattr_set_handle2+0x115/0x500
[<c02da824>] pciserial_init_one+0x2a4/0x2e0
[<c01b3c29>] ext3_xattr_set_handle+0x299/0x740
[<c014ad37>] __alloc_percpu+0x87/0xf0
[<c01b4727>] ext3_xattr_delete_inode+0xc7/0x250
[<c01b5494>] start_this_handle+0x194/0x650
[<c01b30a3>] ext3_getxattr+0xd3/0x120
[<c0189552>] sys_setxattr+0x22/0x70
[<c01592a4>] shmem_recalc_inode+0xa4/0xc0
[<c0153c9d>] do_file_page+0x6d/0x130
[<c017efe0>] dput+0x150/0x3a0
[<c0174c43>] link_path_walk+0x7c3/0xb40
[<c017564c>] lock_rename+0xcc/0x160
[<c017564c>] lock_rename+0xcc/0x160
[<c018963f>] sys_fsetxattr+0x2f/0x70
[<c011c520>] do_page_fault+0x20/0x497
[<c010b54b>] syscall_call+0x7/0xb
Code: 0f 0b ac 02 d2 fe 46 c0 8b 54 24 60 8b 42 04 e9 46 ff ff ff
<6>note: setfattr[17114] exited with preempt_count 2
bad: scheduling while atomic!
Call Trace:
[<c011f0b8>] __wake_up_common+0x38/0x60
[<c0151edb>] zap_page_range+0xfb/0x1d0
[<c01520ec>] get_user_pages+0x9c/0x440
[<c0156b7d>] .text.lock.mmap+0x5d/0xb0
[<c01223bb>] mm_release+0x4b/0xa0
[<c01271d1>] do_exit+0x291/0x5d0
[<c010ca60>] do_invalid_op+0x0/0xe0
[<c010c6e3>] die+0x153/0x160
[<c011cf96>] fixup_exception+0x36/0x40
[<c010cb30>] do_invalid_op+0xd0/0xe0
[<c01b69e9>] do_get_write_access+0x7e9/0x870
[<c011f17a>] __wake_up+0x9a/0xc0
[<c011f226>] __wake_up_sync+0x56/0xe0
[<c01253a6>] console_unblank+0x36/0x60
[<c010bfd5>] error_code+0x2d/0x38
[<c01b69e9>] do_get_write_access+0x7e9/0x870
[<c01674e1>] __bread+0x11/0x40
[<c01b6cf9>] journal_get_create_access+0x229/0x2f0
[<c01b4c28>] ext3_xattr_rehash+0x78/0xa0
[<c01b41e5>] ext3_xattr_set_handle2+0x115/0x500
[<c02da824>] pciserial_init_one+0x2a4/0x2e0
[<c01b3c29>] ext3_xattr_set_handle+0x299/0x740
[<c014ad37>] __alloc_percpu+0x87/0xf0
[<c01b4727>] ext3_xattr_delete_inode+0xc7/0x250
[<c01b5494>] start_this_handle+0x194/0x650
[<c01b30a3>] ext3_getxattr+0xd3/0x120
[<c0189552>] sys_setxattr+0x22/0x70
[<c01592a4>] shmem_recalc_inode+0xa4/0xc0
[<c0153c9d>] do_file_page+0x6d/0x130
[<c017efe0>] dput+0x150/0x3a0
[<c0174c43>] link_path_walk+0x7c3/0xb40
[<c017564c>] lock_rename+0xcc/0x160
[<c017564c>] lock_rename+0xcc/0x160
[<c018963f>] sys_fsetxattr+0x2f/0x70
[<c011c520>] do_page_fault+0x20/0x497
[<c010b54b>] syscall_call+0x7/0xb
Hi Stephen and Andrew,
please find attached fixes for three bugs I found while looking into this.
Andrew, could you please push these fixes to Linus? Thanks!
The bug Stephen has triggered is in fs/jbd/transaction.c:
Index: linux-2.5.75/fs/jbd/transaction.c
===================================================================
--- linux-2.5.75.orig/fs/jbd/transaction.c 2003-07-10 22:06:58.000000000
+0200
+++ linux-2.5.75/fs/jbd/transaction.c 2003-07-12 21:31:31.000000000 +0200
@@ -747,7 +747,7 @@
/* We do not want to get caught playing with fields which the
* log thread also manipulates. Make sure that the buffer
* completes any outstanding IO before proceeding. */
- rc = do_get_write_access(handle, jh, 0, NULL);
+ rc = do_get_write_access(handle, jh, 0, credits);
journal_put_journal_head(jh);
return rc;
}
While looking into this issue I found two more bugs in fs/ext3/xattr.c. Fix
below.
- ext3_journal_get_write_access_credits failures break out of the loop in
1058, so <ce> is not released properly.
- <credits> must be reset after journal_release_buffer() in line 1072.
Index: linux-2.5.75/fs/ext3/xattr.c
===================================================================
--- linux-2.5.75.orig/fs/ext3/xattr.c 2003-07-12 13:36:51.000000000 +0200
+++ linux-2.5.75/fs/ext3/xattr.c 2003-07-12 21:35:57.000000000 +0200
@@ -1050,12 +1050,10 @@
ext3_error(inode->i_sb, "ext3_xattr_cache_find",
"inode %ld: block %ld read error",
inode->i_ino, (unsigned long) ce->e_block);
- } else {
+ } else if (ext3_journal_get_write_access_credits(
+ handle, bh, credits) == 0) {
/* ext3_journal_get_write_access() requires an
unlocked
* bh, which complicates things here. */
- if (ext3_journal_get_write_access_credits(handle, bh,
- credits) !=
0)
- return NULL;
lock_buffer(bh);
if (le32_to_cpu(HDR(bh)->h_refcount) >
EXT3_XATTR_REFCOUNT_MAX) {
@@ -1070,6 +1068,7 @@
}
unlock_buffer(bh);
journal_release_buffer(handle, bh, *credits);
+ *credits = 0;
brelse(bh);
}
ce = mb_cache_entry_find_next(ce, 0, inode->i_sb->s_bdev,
hash);
On Friday 11 July 2003 22:41, Stephen Smalley wrote:
> I've encountered a kernel BUG in jbd during setxattr on 2.5.75, likely
> related to the recent xattr locking changes. Originally encountered
> with SELinux enabled, but also occurs with SELinux disabled. I have not
> been able to reproduce it with 2.5.74.
>
> [...]
>
> A command for reproducing the bug is:
> find . -exec setfattr -n security.selinux -v system_u:object_r:staff_home_t
> {} \;
I could reproduce with user.* attributes as well.
Cheers,
Andreas.
------------------------------------------------------------------
Andreas Gruenbacher SuSE Labs, SuSE Linux AG
mailto:[email protected] Deutschherrnstr. 15-19
http://www.suse.de/ D-90429 Nuernberg, Germany
On Sat, 12 Jul 2003, Andreas Gruenbacher wrote:
> please find attached fixes for three bugs I found while looking into this.
Works for me (patch needs to be applied with -l).
- James
--
James Morris
<[email protected]>