The following changes since commit e26081808edadfd257c6c9d81014e3b25e9a6118:
Linux 4.1-rc4 (2015-05-18 10:13:47 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git tags/ext4_for_linus
for you to fetch changes up to a2fd66d069d86d793e9d39d4079b96f46d13f237:
ext4: set lazytime on remount if MS_LAZYTIME is set by mount (2015-06-23 11:03:54 -0400)
----------------------------------------------------------------
A very large number of cleanups and bug fixes --- in particular for
the ext4 encryption patches, which is a new feature added in the last
merge window. Also fix a number of long-standing xfstest failures.
(Quota writes failing due to ENOSPC, a race between truncate and
writepage in data=journalled mode that was causing generic/068 to
fail, and other corner cases.)
Also add support for FALLOC_FL_INSERT_RANGE, and improve jbd2
performance eliminating locking when a buffer is modified more than
once during a transaction (which is very common for allocation
bitmaps, for example), in which case the state of the journalled
buffer head doesn't need to change.
----------------------------------------------------------------
Andreas Dilger (1):
ext4: improve warning directory handling messages
Chao Yu (1):
ext4 crypto: release crypto resource on module exit
Darrick J. Wong (1):
ext4: don't retry file block mapping on bigalloc fs with non-extent file
David Moore (1):
ext4: BUG_ON assertion repeated for inode1, not done for inode2
Dmitry Monakhov (1):
jbd2: use GFP_NOFS in jbd2_cleanup_journal_tail()
Eric Whitney (2):
ext4: minor cleanup of ext4_da_reserve_space()
ext4: make online defrag error reporting consistent
Fabian Frederick (3):
ext4 crypto: fix sparse warnings in fs/ext4/ioctl.c
ext4: use swap() in memswap()
ext4: use swap() in mext_page_double_lock()
Jan Kara (5):
jbd2: simplify code flow in do_get_write_access()
jbd2: simplify error path on allocation failure in do_get_write_access()
jbd2: more simplifications in do_get_write_access()
jbd2: speedup jbd2_journal_get_[write|undo]_access()
jbd2: speedup jbd2_journal_dirty_metadata()
Josef Bacik (1):
ext4: only call ext4_truncate when size <= isize
Joseph Qi (1):
jbd2: fix ocfs2 corrupt when updating journal superblock fails
Lukas Czerner (5):
ext4: verify block bitmap even after fresh initialization
ext4: try to initialize all groups we can in case of failure on ppc64
ext4: return error code from ext4_mb_good_group()
ext4: recalculate journal credits as inode depth changes
ext4: wait for existing dio workers in ext4_alloc_file_blocks()
Michal Hocko (2):
jbd2: revert must-not-fail allocation loops back to GFP_NOFAIL
jbd2: get rid of open coded allocation retry loop
Namjae Jeon (1):
ext4: Add support FALLOC_FL_INSERT_RANGE for fallocate
Rasmus Villemoes (1):
ext4: mballoc: avoid 20-argument function call
Theodore Ts'o (26):
ext4 crypto: optimize filename encryption
ext4 crypto: don't allocate a page when encrypting/decrypting file names
ext4 crypto: separate kernel and userspace structure for the key
ext4 crypto: reorganize how we store keys in the inode
ext4: clean up superblock encryption mode fields
ext4 crypto: use slab caches
ext4 crypto: get rid of ci_mode from struct ext4_crypt_info
ext4 crypto: shrink size of the ext4_crypto_ctx structure
ext4 crypto: require CONFIG_CRYPTO_CTR if ext4 encryption is enabled
ext4 crypto: use per-inode tfm structure
ext4 crypto: fix memory leaks in ext4_encrypted_zeroout
ext4 crypto: set up encryption info for new inodes in ext4_inherit_context()
ext4 crypto: make sure the encryption info is initialized on opendir(2)
ext4 crypto: encrypt tmpfile located in encryption protected directory
ext4 crypto: enforce crypto policy restrictions on cross-renames
ext4 crypto: policies may only be set on directories
ext4 crypto: clean up error handling in ext4_fname_setup_filename
ext4 crypto: allocate the right amount of memory for the on-disk symlink
ext4 crypto: handle unexpected lack of encryption keys
ext4 crypto: allocate bounce pages using GFP_NOWAIT
ext4 crypto: fix ext4_get_crypto_ctx()'s calling convention in ext4_decrypt_one
ext4 crypto: fail the mount if blocksize != pagesize
ext4: fix race between truncate and __ext4_journalled_writepage()
ext4: call sync_blockdev() before invalidate_bdev() in put_super()
ext4: prevent ext4_quota_write() from failing due to ENOSPC
ext4: set lazytime on remount if MS_LAZYTIME is set by mount
fs/ext4/Kconfig | 1 +
fs/ext4/balloc.c | 4 +-
fs/ext4/crypto.c | 211 +++++++++------------------
fs/ext4/crypto_fname.c | 490 ++++++++++++++++-----------------------------------------------
fs/ext4/crypto_key.c | 152 ++++++++++++++++----
fs/ext4/crypto_policy.c | 87 +++++++-----
fs/ext4/dir.c | 29 ++--
fs/ext4/ext4.h | 159 ++++++++++++++-------
fs/ext4/ext4_crypto.h | 51 +++----
fs/ext4/extents.c | 339 +++++++++++++++++++++++++++++++++++++-------
fs/ext4/file.c | 19 +--
fs/ext4/ialloc.c | 45 +++---
fs/ext4/indirect.c | 4 +-
fs/ext4/inline.c | 31 ++--
fs/ext4/inode.c | 93 ++++++------
fs/ext4/ioctl.c | 11 +-
fs/ext4/mballoc.c | 43 ++++--
fs/ext4/move_extent.c | 19 +--
fs/ext4/namei.c | 542 ++++++++++++++++++++++++++++++----------------------------------------
fs/ext4/page-io.c | 2 +-
fs/ext4/readpage.c | 10 +-
fs/ext4/super.c | 60 ++++++--
fs/ext4/symlink.c | 16 +--
fs/jbd2/checkpoint.c | 7 +-
fs/jbd2/journal.c | 57 +++++---
fs/jbd2/revoke.c | 15 +-
fs/jbd2/transaction.c | 303 ++++++++++++++++++++++++---------------
include/linux/jbd2.h | 4 +-
include/trace/events/ext4.h | 35 ++++-
29 files changed, 1486 insertions(+), 1353 deletions(-)
Hi Linus,
Here's my suggested merge resolution to deal with Al Viro's symlink changes.
- Ted
diff --cc fs/ext4/symlink.c
index ba5bd18,68e915a..0000000
--- a/fs/ext4/symlink.c
+++ b/fs/ext4/symlink.c
@@@ -35,19 -34,20 +34,17 @@@ static const char *ext4_follow_link(str
int res;
u32 plen, max_size = inode->i_sb->s_blocksize;
- ctx = ext4_get_fname_crypto_ctx(inode, inode->i_sb->s_blocksize);
- if (IS_ERR(ctx))
- return ERR_CAST(ctx);
- if (!ext4_encrypted_inode(inode))
- return page_follow_link_light(dentry, nd);
-
+ res = ext4_get_encryption_info(inode);
+ if (res)
+ return ERR_PTR(res);
if (ext4_inode_is_fast_symlink(inode)) {
caddr = (char *) EXT4_I(inode)->i_data;
max_size = sizeof(EXT4_I(inode)->i_data);
} else {
cpage = read_mapping_page(inode->i_mapping, 0, NULL);
- if (IS_ERR(cpage)) {
- ext4_put_fname_crypto_ctx(&ctx);
+ if (IS_ERR(cpage))
- return cpage;
+ return ERR_CAST(cpage);
- }
caddr = kmap(cpage);
caddr[size] = 0;
}
@@@ -77,14 -78,13 +75,12 @@@
/* Null-terminate the name */
if (res <= plen)
paddr[res] = '\0';
- ext4_put_fname_crypto_ctx(&ctx);
- nd_set_link(nd, paddr);
if (cpage) {
kunmap(cpage);
page_cache_release(cpage);
}
- return NULL;
+ return *cookie = paddr;
errout:
- ext4_put_fname_crypto_ctx(&ctx);
if (cpage) {
kunmap(cpage);
page_cache_release(cpage);
On Wed, 24 Jun 2015 23:46:26 -0400, Theodore Ts'o wrote:
> ext4: set lazytime on remount if MS_LAZYTIME is set by mount
I was wondering what had happened to this bug and was about to ask, just as I
saw this. It applies cleanly to 4.1 and does the trick - just tested with
util-linux-2.16.2. My / now properly shows lazytime after remount, so
Thank You and:
Tested-By: Holger Hoffstaette <[email protected]>
-h
[ I renamed "ext4_follow_link()" to "ext4_encrypted_follow_link()" in
the merge resolution, to make it clear that that function is _only_
used for encrypted symlinks. The function doesn't actually work for
non-encrypted symlinks at all, and they use the generic helpers
- Linus ]
Thanks, that was on my todo list as a cleanup patch after the merge window closed...
:-)
- Ted
On Wed, Jun 24, 2015 at 8:46 PM, Theodore Ts'o <[email protected]> wrote:
>
> A very large number of cleanups and bug fixes --- in particular for
> the ext4 encryption patches, which is a new feature added in the last
> merge window. Also fix a number of long-standing xfstest failures.
> (Quota writes failing due to ENOSPC, a race between truncate and
> writepage in data=journalled mode that was causing generic/068 to
> fail, and other corner cases.)
>
> Also add support for FALLOC_FL_INSERT_RANGE, and improve jbd2
> performance eliminating locking when a buffer is modified more than
> once during a transaction (which is very common for allocation
> bitmaps, for example), in which case the state of the journalled
> buffer head doesn't need to change.
I think this is very broken.
I just got this while compiling:
------------[ cut here ]------------
kernel BUG at fs/jbd2/transaction.c:1325!
invalid opcode: 0000 [#1] SMP
Modules linked in: bnep bluetooth fuse ip6t_rpfilter ip6t_REJECT
nf_reject_ipv6 nf_conntrack_ipv6 ...
CPU: 7 PID: 5509 Comm: gcc Not tainted 4.1.0-10944-g2a298679b411 #1
Hardware name: /DH87RL, BIOS
RLH8710H.86A.0327.2014.0924.1645 09/24/2014
task: ffff8803bf866040 ti: ffff880308528000 task.ti: ffff880308528000
RIP: jbd2_journal_dirty_metadata+0x237/0x290
Call Trace:
__ext4_handle_dirty_metadata+0x43/0x1f0
ext4_handle_dirty_dirent_node+0xde/0x160
? jbd2_journal_get_write_access+0x36/0x50
ext4_delete_entry+0x112/0x160
? __ext4_journal_start_sb+0x52/0xb0
ext4_unlink+0xfa/0x260
vfs_unlink+0xec/0x190
do_unlinkat+0x24a/0x270
SyS_unlink+0x11/0x20
entry_SYSCALL_64_fastpath+0x12/0x6a
Code: ff f3 90 48 8b 16 f7 c2 00 00 80 00 75 f3 e9 f4 fe ff ff b8
8b ff ff ff e9 8e fe ff ff 31 c0 e9 3a ff ff ff 31 ff e9 26 ff ff ff
<0f> 0b 41 83 7c 24 0c 01 0f 84 e4 fe ff ff 0f 0b 0f 0b 4d 85 c9
RIP jbd2_journal_dirty_metadata+0x237/0x290
---[ end trace ae033ebde8d080b4 ]---
followed by basically a dead machine (SIGSEGV's, unresponsive X etc).
I assume it died with some major jbd2 or ext4 lock held.
The most obvious candidate for a culprit would seem to be
2143c1965a76 "jbd2: speedup jbd2_journal_dirty_metadata()"
which is the commit that introduced the assert that triggers. Ted? Jan?
Nothing particularly odd was going on. I was reading email in a
browser while doing an allmodconfig build with "make -j16". That's
literally all I ever tend to do.
Linus
On Fri, Jun 26, 2015 at 08:05:48PM -0700, Linus Torvalds wrote:
> On Wed, Jun 24, 2015 at 8:46 PM, Theodore Ts'o <[email protected]> wrote:
> >
> > A very large number of cleanups and bug fixes --- in particular for
> > the ext4 encryption patches, which is a new feature added in the last
> > merge window. Also fix a number of long-standing xfstest failures.
> > (Quota writes failing due to ENOSPC, a race between truncate and
> > writepage in data=journalled mode that was causing generic/068 to
> > fail, and other corner cases.)
> >
> > Also add support for FALLOC_FL_INSERT_RANGE, and improve jbd2
> > performance eliminating locking when a buffer is modified more than
> > once during a transaction (which is very common for allocation
> > bitmaps, for example), in which case the state of the journalled
> > buffer head doesn't need to change.
>
> I think this is very broken.
>
> I just got this while compiling:
>
> ------------[ cut here ]------------
> kernel BUG at fs/jbd2/transaction.c:1325!
> ...
>
> The most obvious candidate for a culprit would seem to be
>
> 2143c1965a76 "jbd2: speedup jbd2_journal_dirty_metadata()"
>
> which is the commit that introduced the assert that triggers. Ted? Jan?
I would tend to agree. The weird thing though is that I haven't seen
this problem myself, despite running multiple regression tests before
I sent the pull request, as well as running it on my laptop and doing
kernel compiles with make -j16 and reading e-mail (I'm typing this
e-mail on a 4.1 kernel merged with the ext4 patches for this merge
window, so I have this commit running in my development laptop, and it
hasn't triggered for me).
All of this being said, my suggestion would be to revert it for now
and we'll investigate more closely for the next merge window. This is
just a performance improvement, and so better safe than sorry. Jan,
do you agree?
- Ted
On Sat, Jun 27, 2015 at 12:02:37AM -0400, Theodore Ts'o wrote:
>
> I would tend to agree. The weird thing though is that I haven't seen
> this problem myself, despite running multiple regression tests before
> I sent the pull request, as well as running it on my laptop and doing
> kernel compiles with make -j16 and reading e-mail (I'm typing this
> e-mail on a 4.1 kernel merged with the ext4 patches for this merge
> window, so I have this commit running in my development laptop, and it
> hasn't triggered for me).
Update: I've been able to reproduce the crash using a post merge
kernel (of course, I had to use CONFIG_SLUB since CONFIG_SLAB is
busted) a single time. Unfortunately, I've not been able to reproduce
it reliably so I can't speak to whether reverting 2143c1965a76 will
fix things. But it does seem very likely.
- Ted
On Sat 27-06-15 10:07:43, Ted Tso wrote:
> On Sat, Jun 27, 2015 at 12:02:37AM -0400, Theodore Ts'o wrote:
> >
> > I would tend to agree. The weird thing though is that I haven't seen
> > this problem myself, despite running multiple regression tests before
> > I sent the pull request, as well as running it on my laptop and doing
> > kernel compiles with make -j16 and reading e-mail (I'm typing this
> > e-mail on a 4.1 kernel merged with the ext4 patches for this merge
> > window, so I have this commit running in my development laptop, and it
> > hasn't triggered for me).
>
> Update: I've been able to reproduce the crash using a post merge
> kernel (of course, I had to use CONFIG_SLUB since CONFIG_SLAB is
> busted) a single time. Unfortunately, I've not been able to reproduce
> it reliably so I can't speak to whether reverting 2143c1965a76 will
> fix things. But it does seem very likely.
Sure, I agree with the revert Linus did. That's the best we can do now.
I'm now trying to figure out what could have gone wrong.
Honza
--
Jan Kara <[email protected]>
SUSE Labs, CR
On Sat 27-06-15 10:07:43, Ted Tso wrote:
> On Sat, Jun 27, 2015 at 12:02:37AM -0400, Theodore Ts'o wrote:
> >
> > I would tend to agree. The weird thing though is that I haven't seen
> > this problem myself, despite running multiple regression tests before
> > I sent the pull request, as well as running it on my laptop and doing
> > kernel compiles with make -j16 and reading e-mail (I'm typing this
> > e-mail on a 4.1 kernel merged with the ext4 patches for this merge
> > window, so I have this commit running in my development laptop, and it
> > hasn't triggered for me).
>
> Update: I've been able to reproduce the crash using a post merge
> kernel (of course, I had to use CONFIG_SLUB since CONFIG_SLAB is
> busted) a single time. Unfortunately, I've not been able to reproduce
> it reliably so I can't speak to whether reverting 2143c1965a76 will
> fix things. But it does seem very likely.
BTW, what did you use to trigger the error for you? The ext4 path where the
assertion triggered for Linus is definitely correct so the assertion
failure was a false positive. Since we don't hold proper locks when doing
the assertion, we likely saw an intermediate state where we raced with
__jbd2_journal_refile_buffer() called from jbd2 thread which was doing
jh->b_transaction = jh->b_next_transaction;
jh->b_next_transaction = NULL;
and we saw NULL in b_next_transaction but old content in b_transaction.
Originally I didn't think that's really possible but on a second thought
don't know how I came to that conclusion :-|. Looking at the disassemly of
__jbd2_journal_refile_buffer() I see my compiler compiled the above as:
mov 0x30(%rbx),%rax b_next_transaction -> rax
movq $0x0,0x30(%rbx) NULL -> b_next_transaction
mov %rax,0x28(%rbx) rax -> b_transaction
So even the compiler decided to reorder the stores to memory and I'm not
even speaking of what the CPU could have done with the stores or loads
from the assertion.
I will fix the assertion in the same way the second assertion in
jbd2_journal_dirty_metadata() was fixed - take the necessary locks if it
seems the assertion is violated to make sure we don't see false positives.
Honza
--
Jan Kara <[email protected]>
SUSE Labs, CR
On Sat, Jun 27, 2015 at 11:05 AM, Linus Torvalds
<[email protected]> wrote:
> On Wed, Jun 24, 2015 at 8:46 PM, Theodore Ts'o <[email protected]> wrote:
>>
>> A very large number of cleanups and bug fixes --- in particular for
>> the ext4 encryption patches, which is a new feature added in the last
>> merge window. Also fix a number of long-standing xfstest failures.
>> (Quota writes failing due to ENOSPC, a race between truncate and
>> writepage in data=journalled mode that was causing generic/068 to
>> fail, and other corner cases.)
>>
>> Also add support for FALLOC_FL_INSERT_RANGE, and improve jbd2
>> performance eliminating locking when a buffer is modified more than
>> once during a transaction (which is very common for allocation
>> bitmaps, for example), in which case the state of the journalled
>> buffer head doesn't need to change.
>
> I think this is very broken.
>
> I just got this while compiling:
>
> ------------[ cut here ]------------
> kernel BUG at fs/jbd2/transaction.c:1325!
> invalid opcode: 0000 [#1] SMP
> Modules linked in: bnep bluetooth fuse ip6t_rpfilter ip6t_REJECT
> nf_reject_ipv6 nf_conntrack_ipv6 ...
> CPU: 7 PID: 5509 Comm: gcc Not tainted 4.1.0-10944-g2a298679b411 #1
> Hardware name: /DH87RL, BIOS
> RLH8710H.86A.0327.2014.0924.1645 09/24/2014
> task: ffff8803bf866040 ti: ffff880308528000 task.ti: ffff880308528000
> RIP: jbd2_journal_dirty_metadata+0x237/0x290
> Call Trace:
> __ext4_handle_dirty_metadata+0x43/0x1f0
> ext4_handle_dirty_dirent_node+0xde/0x160
> ? jbd2_journal_get_write_access+0x36/0x50
> ext4_delete_entry+0x112/0x160
> ? __ext4_journal_start_sb+0x52/0xb0
> ext4_unlink+0xfa/0x260
> vfs_unlink+0xec/0x190
> do_unlinkat+0x24a/0x270
> SyS_unlink+0x11/0x20
> entry_SYSCALL_64_fastpath+0x12/0x6a
> Code: ff f3 90 48 8b 16 f7 c2 00 00 80 00 75 f3 e9 f4 fe ff ff b8
> 8b ff ff ff e9 8e fe ff ff 31 c0 e9 3a ff ff ff 31 ff e9 26 ff ff ff
> <0f> 0b 41 83 7c 24 0c 01 0f 84 e4 fe ff ff 0f 0b 0f 0b 4d 85 c9
> RIP jbd2_journal_dirty_metadata+0x237/0x290
> ---[ end trace ae033ebde8d080b4 ]---
>
> followed by basically a dead machine (SIGSEGV's, unresponsive X etc).
> I assume it died with some major jbd2 or ext4 lock held.
>
> The most obvious candidate for a culprit would seem to be
>
> 2143c1965a76 "jbd2: speedup jbd2_journal_dirty_metadata()"
>
> which is the commit that introduced the assert that triggers. Ted? Jan?
>
> Nothing particularly odd was going on. I was reading email in a
> browser while doing an allmodconfig build with "make -j16". That's
> literally all I ever tend to do.
BTW, the similar trace stack can be triggered easily by xfstests
generic 269, see the following trace, and looks the revert does fix it.
[ 2391.200871] run fstests generic/269 at 2015-06-28 16:21:32^M
[ 2391.606047] EXT4-fs (sda): mounted filesystem with ordered data
mode. Opts: acl,user_xattr^M
[ 2395.489941] ------------[ cut here ]------------^M
[ 2395.490652] kernel BUG at fs/jbd2/transaction.c:1325!^M
[ 2395.490652] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC ^M
[ 2395.490652] Dumping ftrace buffer:^M
[ 2395.490652] (ftrace buffer empty)^M
[ 2395.490652] Modules linked in: nbd ipv6 kvm_intel kvm serio_raw
[last unloaded: null_blk]^M
[ 2395.490652] CPU: 10 PID: 2635 Comm: fsstress Not tainted
4.1.0-next-20150626 #359^M
[ 2395.490652] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS Bochs 01/01/2011^M
[ 2395.490652] task: ffff8800ad84a200 ti: ffff88022cf90000 task.ti:
ffff88022cf90000^M
[ 2395.490652] RIP: 0010:[<ffffffff811dbceb>] [<ffffffff811dbceb>]
jbd2_journal_dirty_metadata+0x51/0x207^M
[ 2395.490652] RSP: 0018:ffff88022cf93c98 EFLAGS: 00010207^M
[ 2395.490652] RAX: ffff88022972ae00 RBX: ffff8801f8eede10 RCX:
0000000000000000^M
[ 2395.490652] RDX: ffff8800bb7da300 RSI: ffff8800a5c82208 RDI:
ffff8802345efc00^M
[ 2395.490652] RBP: ffff88022cf93cf8 R08: ffff8800a5c82208 R09:
00000000000009af^M
[ 2395.490652] R10: 0000000000000000 R11: 000000000000000c R12:
ffff8800bb7da300^M
[ 2395.490652] R13: ffff8800a5c82208 R14: 0000000000000000 R15:
ffff8802345efc00^M
[ 2395.490652] FS: 00007f2559cc1740(0000) GS:ffff88023ed40000(0000)
knlGS:0000000000000000^M
[ 2395.490652] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033^M
[ 2395.490652] CR2: 00007f2554109fb8 CR3: 000000021469a000 CR4:
00000000000007e0^M
[ 2395.490652] Stack:^M
[ 2395.490652] ffff88022cf93cb8 ffff88020895e800 0000000000000023
ffff8802345efc00^M
[ 2395.490652] 00000000000009af 0000000000000000 ffff8801f8eede10
ffff8800a5c82208^M
[ 2395.490652] ffff88013bf329a8 0000000000000000 ffff8802345efc00
00000000000003d4^M
[ 2395.490652] Call Trace:^M
[ 2395.490652] [<ffffffff811c7d38>] __ext4_handle_dirty_metadata+0xcf/0x1bf^M
[ 2395.490652] [<ffffffff810d83fb>] ? trace_preempt_on+0x12/0x2f^M
[ 2395.490652] [<ffffffff811a0a53>] __ext4_new_inode+0x930/0xdd0^M
[ 2395.490652] [<ffffffff811acec8>] ext4_mknod+0x8f/0x131^M
[ 2395.490652] [<ffffffff81149193>] vfs_mknod+0x7c/0x9c^M
[ 2395.490652] [<ffffffff8114bf0c>] ? user_path_create+0x2b/0x32^M
[ 2395.490652] [<ffffffff8114c043>] SYSC_mknodat+0x130/0x176^M
[ 2395.490652] [<ffffffff8114cd48>] SyS_mknod+0x1d/0x1f^M
[ 2395.490652] [<ffffffff814f0917>] entry_SYSCALL_64_fastpath+0x12/0x6a^M
[ 2395.490652] Code: 41 89 c6 0f 85 b8 01 00 00 49 8b 45 00 a9 00 00
02 00 0f 84 b1 01 00 00 49 8b 5d 40 48 8b 43 28 4c 39 e0 74 08 4c 39
63 30 74 02 <0f> 0b 83 7b 10 01 75 39 4c 39 e0 0f 85 93 01 00 00 83 7b
0c 01 ^M
[ 2395.490652] RIP [<ffffffff811dbceb>]
jbd2_journal_dirty_metadata+0x51/0x207^M
[ 2395.490652] RSP <ffff88022cf93c98>^M
[ 2395.516997] ---[ end trace dc5028a237345935 ]---^M
--
Ming Lei
On Mon, Jun 29, 2015 at 11:04:37AM +0200, Jan Kara wrote:
>
> BTW, what did you use to trigger the error for you? The ext4 path where the
> assertion triggered for Linus is definitely correct so the assertion
> failure was a false positive.
I've managed to trigger it twice in about 5 or 6 full runs of
"./kvm-xfstests -g auto". Once it was with generic/233 in 1k block
file system mode, the second time it was generic/233 in ext3 compat
mode. i've tried running just generic/233, and it doesn't trigger.
"i.e., "./kvm-xfstests -C 10 generic/233" didn't trigger the bug.
(I'm currently on vacation, so I've been kicking off the run each
morning or evening and then checking to see if it blew up or not.)
Cheers,
- Ted