LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Dmitry Vyukov <dvyukov@google.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: syzbot <syzbot+4fd0c066d82852499145@syzkaller.appspotmail.com>,
	Jan Kara <jack@suse.cz>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	syzkaller-bugs@googlegroups.com,
	Al Viro <viro@zeniv.linux.org.uk>,
	zwisler@kernel.org
Subject: Re: WARNING in get_unlocked_entry
Date: Wed, 31 Oct 2018 10:45:13 +0100	[thread overview]
Message-ID: <CACT4Y+YiwPUkZFs8dZZbvefdRzz6ex-iUb=RAMGGjsxA9aPDHQ@mail.gmail.com> (raw)
In-Reply-To: <20181031031842.GI10491@bombadil.infradead.org>

On Wed, Oct 31, 2018 at 4:18 AM, Matthew Wilcox <willy@infradead.org> wrote:
> On Tue, Oct 30, 2018 at 08:00:03AM -0700, syzbot wrote:
>> syzbot found the following crash on:
>>
>> HEAD commit:    4b42745211af Merge tag 'armsoc-soc' of git://git.kernel.or..
>> git tree:       upstream
>> console output: https://syzkaller.appspot.com/x/log.txt?x=1187d06d400000
>> kernel config:  https://syzkaller.appspot.com/x/.config?x=93932074d01b4a5
>> dashboard link: https://syzkaller.appspot.com/bug?extid=4fd0c066d82852499145
>> compiler:       gcc (GCC) 8.0.1 20180413 (experimental)
>>
>> Unfortunately, I don't have any reproducer for this crash yet.
>
> Hmmpf.  Would have been nice if syzbot had caught this during its tests
> of the -next tree ...
>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+4fd0c066d82852499145@syzkaller.appspotmail.com
>>
>> EXT4-fs (sda1): Cannot specify journal on remount
>> EXT4-fs (sda1): DAX enabled. Warning: EXPERIMENTAL, use at your own risk
>> EXT4-fs (sda1): warning: refusing change of dax flag with busy inodes while
>> remounting
>> WARNING: CPU: 0 PID: 12870 at fs/dax.c:227 get_unlocked_entry+0x3ac/0x4d0
>> fs/dax.c:227
>> Kernel panic - not syncing: panic_on_warn set ...
>>
>> CPU: 0 PID: 12870 Comm: syz-executor3 Not tainted 4.19.0+ #87
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> Google 01/01/2011
>> Call Trace:
>>  __dump_stack lib/dump_stack.c:77 [inline]
>>  dump_stack+0x244/0x39d lib/dump_stack.c:113
>>  panic+0x238/0x4e7 kernel/panic.c:184
>>  __warn.cold.8+0x20/0x4a kernel/panic.c:536
>>  report_bug+0x254/0x2d0 lib/bug.c:186
>>  fixup_bug arch/x86/kernel/traps.c:178 [inline]
>>  do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:271
>>  do_invalid_op+0x36/0x40 arch/x86/kernel/traps.c:290
>>  invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:966
>> RIP: 0010:get_unlocked_entry+0x3ac/0x4d0 fs/dax.c:227
>> Code: e8 31 ff 83 e0 01 48 89 c6 48 89 85 10 ff ff ff e8 09 18 96 ff 48 8b
>> 85 10 ff ff ff 48 85 c0 0f 85 34 fe ff ff e8 c4 16 96 ff <0f> 0b e8 bd 16 96
>> ff 48 b8 00 00 00 00 00 fc ff df 48 03 85 f8 fe
>> RSP: 0018:ffff88018025e7b8 EFLAGS: 00010012
>> RAX: 0000000000040000 RBX: ffff88018025ead8 RCX: ffffc90008983000
>> RDX: 0000000000000341 RSI: ffffffff81e94d3c RDI: 0000000000000007
>> RBP: ffff88018025e8c8 R08: ffff88017f862280 R09: ffffed003004bd08
>> R10: ffffed003004bd08 R11: 0000000000000003 R12: dffffc0000000000
>> R13: ffffea0005e01040 R14: ffff88018025e800 R15: ffff88018025e8a0
>>  grab_mapping_entry fs/dax.c:447 [inline]
>
> OK, so I'd like to know what value actually got loaded into 'entry'.
> Maybe my x86-fu is weak, but I don't understand how this register dump
> correlates with the instructions I'm seeing.
>
> Here's the C code:
>
>                 entry = xas_load(xas);
>                 if (!entry || xa_is_internal(entry) ||
>                                 WARN_ON_ONCE(!xa_is_value(entry)) ||
>                                 !dax_is_locked(entry))
>                         return entry;
>
>
> I downloaded the .config that syzbot was using and built fs/dax.o.
> Disassembling it, I get:
>
>                                 WARN_ON_ONCE(!xa_is_value(entry)) ||
>     5e53:       31 ff                   xor    %edi,%edi
>     5e55:       83 e0 01                and    $0x1,%eax
>     5e58:       48 89 c6                mov    %rax,%rsi
>     5e5b:       48 89 85 10 ff ff ff    mov    %rax,-0xf0(%rbp)
>     5e62:       e8 00 00 00 00          callq  5e67 <get_unlocked_entry+0x397>
>                         5e63: R_X86_64_PLT32    __sanitizer_cov_trace_const_cmp8
> -0x4
>     5e67:       48 8b 85 10 ff ff ff    mov    -0xf0(%rbp),%rax
>     5e6e:       48 85 c0                test   %rax,%rax
>     5e71:       0f 85 34 fe ff ff       jne    5cab <get_unlocked_entry+0x1db>
>     5e77:       e8 00 00 00 00          callq  5e7c <get_unlocked_entry+0x3ac>
>                         5e78: R_X86_64_PLT32    __sanitizer_cov_trace_pc-0x4
>     5e7c:       0f 0b                   ud2
>
> That ud2 is the WARN_ON trigger.  It's at offset 0x3ac from the start of
> get_unlocked_entry() so it matches the dump.
>
> The key is 'test %rax,%rax' at 5e6e.  If that passes, we jump to 5cab
> where we do xa_to_value() in order to implement dax_is_locked().  So is
> 'entry' actually 0x0000000000040000 like the dump says?
>
> That's where I get confused.  The previous insn (5e67) loads rax from what
> I presume is the stack, having previously stored it there at insn 535b.
> But insn 5e51 should have reduced %rax to just 0 or 1 in the low bit of
> the register.  So clearly I have my understanding of x86 insns confused.
> If someone could help me out here, I'd be grateful.

There is a call to __sanitizer_cov_trace_pc before ud2 and rax is not
a caller-preserved register. So I think we can just assume that
xa_is_value returned 0.

  reply	other threads:[~2018-10-31  9:45 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-30 15:00 syzbot
2018-10-31  3:18 ` Matthew Wilcox
2018-10-31  9:45   ` Dmitry Vyukov [this message]
2018-10-31  9:46   ` Dmitry Vyukov
2018-10-31 19:18     ` Matthew Wilcox
2018-10-31 19:20       ` Dmitry Vyukov

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='CACT4Y+YiwPUkZFs8dZZbvefdRzz6ex-iUb=RAMGGjsxA9aPDHQ@mail.gmail.com' \
    --to=dvyukov@google.com \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=syzbot+4fd0c066d82852499145@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=willy@infradead.org \
    --cc=zwisler@kernel.org \
    --subject='Re: WARNING in get_unlocked_entry' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).