From: Rong Chen <rong.a.chen@intel.com>
To: Linus Torvalds <torvalds@linux-foundation.org>,
kernel test robot <oliver.sang@intel.com>
Cc: Andrey Konovalov <andreyknvl@google.com>,
Vincenzo Frascino <Vincenzo.Frascino@arm.com>,
Marco Elver <elver@google.com>,
Alexander Potapenko <glider@google.com>,
Andrey Ryabinin <aryabinin@virtuozzo.com>,
Branislav Rankov <Branislav.Rankov@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Dmitry Vyukov <dvyukov@google.com>,
Evgenii Stepanov <eugenis@google.com>,
Kevin Brodsky <kevin.brodsky@arm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Will Deacon <will.deacon@arm.com>,
Andrew Morton <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>,
lkp@lists.01.org, kernel test robot <lkp@intel.com>
Subject: Re: [LKP] Re: [kasan] 97593cad00: RIP:kasan_record_aux_stack
Date: Thu, 31 Dec 2020 08:37:33 +0800 [thread overview]
Message-ID: <3fdd267a-5a4f-fee8-e0ee-94d1b5229f81@intel.com> (raw)
In-Reply-To: <CAHk-=wgGVoa0jzo5CmtHHmAD44qX+aaa6GOEATiABPKh3Lh5Xg@mail.gmail.com>
On 12/31/20 4:49 AM, Linus Torvalds wrote:
> On Tue, Dec 29, 2020 at 6:59 PM kernel test robot <oliver.sang@intel.com> wrote:
>> [ 235.553325] BUG: sleeping function called from invalid context at arch/x86/mm/fault.c:1351
>> [ 235.554684] in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 7515, name: trinity-c1
>> [ 235.555890] 2 locks held by trinity-c1/7515:
>> [ 235.556506] #0: ffffffff8323dd38 (&ids->rwsem){....}-{3:3}, at: semctl_down+0x6d/0x686
>> [ 235.557684] #1: ffff888128ccc868 (&mm->mmap_lock#2){....}-{3:3}, at: do_user_addr_fault+0x196/0x59e
>> [ 235.559020] CPU: 1 PID: 7515 Comm: trinity-c1 Not tainted 5.10.0-g97593cad003c #2
>> [ 235.560317] Call Trace:
>> [ 235.560767] dump_stack+0x7d/0xa3
>> [ 235.561371] ___might_sleep+0x2c4/0x2df
>> [ 235.562063] ? do_user_addr_fault+0x196/0x59e
>> [ 235.562834] do_user_addr_fault+0x234/0x59e
>> [ 235.563519] exc_page_fault+0x70/0x8b
>> [ 235.564112] asm_exc_page_fault+0x1b/0x20
> Btw, I wonder if the kernel test robot dumps could be please run through the
>
> scripts/decode_stacktrace.sh
>
> script to give line numbers and inlining information?
>
> That does require CONFIG_DEBUG_INFO to work, but it would help things
> like this when you don't have to try to guess where the exact access
> happens.
>
> Now, in this case, it seems to be a recursive issue with the original
> fault happening in:
>
>> [ 235.564754] RIP: 0010:kasan_record_aux_stack+0x64/0x74
> And yeah, that explains why it then bisects to 97593cad003c ("kasan:
> sanitize objects when metadata doesn't fit")
>
> The faulting instruction sequence decodes to
>
> 10: 48 39 f3 cmp %rsi,%rbx
> 13: 48 0f 46 f3 cmovbe %rbx,%rsi
> 17: e8 6f e5 ff ff callq .. something ..
> 1c: bf 00 08 00 00 mov $0x800,%edi
> 21: 48 89 c3 mov %rax,%rbx
> 24:* 8b 40 08 mov 0x8(%rax),%eax <--
> trapping instruction
> 27: 89 43 0c mov %eax,0xc(%rbx)
>
> and I *think* that "call something" is the call to
> kasan_get_alloc_meta. And there is no check for a NULL return.
>
> So I think this was already fixed by commit 13384f6125ad ("kasan: fix
> null pointer dereference in kasan_record_aux_stack").
>
> But see about that "decode_stacktrace,sh" script request. I thought I
> had already asked for this, but I now realize that I think that was
> just for syzbot.
>
> Can we do that for these kernel test robot reports too? Please?
>
> Linus
Hi Linus,
Sorry for the inconvenience and we're working on it right now.
Happy New Year!
Best Regards,
Rong Chen
prev parent reply other threads:[~2020-12-31 0:39 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-30 3:14 kernel test robot
2020-12-30 20:49 ` Linus Torvalds
2020-12-31 0:37 ` Rong Chen [this message]
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=3fdd267a-5a4f-fee8-e0ee-94d1b5229f81@intel.com \
--to=rong.a.chen@intel.com \
--cc=Branislav.Rankov@arm.com \
--cc=Vincenzo.Frascino@arm.com \
--cc=akpm@linux-foundation.org \
--cc=andreyknvl@google.com \
--cc=aryabinin@virtuozzo.com \
--cc=catalin.marinas@arm.com \
--cc=dvyukov@google.com \
--cc=elver@google.com \
--cc=eugenis@google.com \
--cc=glider@google.com \
--cc=gor@linux.ibm.com \
--cc=kevin.brodsky@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=lkp@lists.01.org \
--cc=oliver.sang@intel.com \
--cc=torvalds@linux-foundation.org \
--cc=will.deacon@arm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome