From: Bart Van Assche <bvanassche@acm.org>
To: shenghui <shhuiw@foxmail.com>,
peterz@infradead.org, mingo@redhat.com, will.deacon@arm.com,
linux-kernel@vger.kernel.org
Subject: Re: "cat /proc/lockdep" after "rmmod <some module>" when !debug_locks will crash the system
Date: Tue, 26 Mar 2019 10:49:02 -0700 [thread overview]
Message-ID: <1553622542.118779.71.camel@acm.org> (raw)
In-Reply-To: <1553622255.118779.69.camel@acm.org>
On Tue, 2019-03-26 at 10:44 -0700, Bart Van Assche wrote:
> On Tue, 2019-03-26 at 08:35 +0800, shenghui wrote:
> > My test steps:
> > --------------
> > 1) bootup the system, and check the calltrace in dmesg. Just warning and ignore it.
> > 2) cat /proc/lockdep # everything is well
> > 3) rmmod some module which provides lock_class in lockdep
> > In my system, module bcache is used: ('grep bcache /proc/lockdep' prints something)
> > * stop bcache set
> > * rmmod bcache
> > I have tried other module, e.g: rmmod iwldvm
> > 4) cat /proc/lockdep # system crash
>
> Hi shenghui,
>
> Thank you for having shared your test steps. I ran a slightly different test
> myself:
>
> while true; do cat /proc/lockdep >/dev/null; done &
> (cd blktests && while ./check -q; do :; done)
It seems like I hit "send" too quickly. That test just triggered the following:
BUG: unable to handle kernel paging request at fffffbfff40ca448
#PF error: [normal kernel read fault]
PGD 13bfde067 P4D 13bfde067 PUD 13bf7a067 PMD 1167d3067 PTE 0
Oops: 0000 [#1] PREEMPT SMP KASAN
CPU: 4 PID: 4529 Comm: cat Tainted: G B W O 5.1.0-rc1-dbg+ #4
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
RIP: 0010:__asan_load1+0x28/0x50
Call Trace:
string+0xac/0x180
vsnprintf+0x23e/0x820
seq_vprintf+0x82/0xc0
seq_printf+0x92/0xb0
print_name+0x34/0xb0
l_show+0x184/0x200
seq_read+0x59e/0x6c0
proc_reg_read+0x11f/0x170
__vfs_read+0x4d/0x90
vfs_read+0xc5/0x1f0
ksys_read+0xab/0x130
__x64_sys_read+0x43/0x50
do_syscall_64+0x71/0x210
entry_SYSCALL_64_after_hwframe+0x49/0xbe
I will have a closer look at this.
Bart.
next prev parent reply other threads:[~2019-03-26 17:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <5c98a345.1c69fb81.21300.0be5SMTPIN_ADDED_BROKEN@mx.google.com>
2019-03-25 15:27 ` "cat /proc/lockdep" after "rmmod <some module>" when !debug_locks will crash the system Bart Van Assche
[not found] ` <5c9973cc.1c69fb81.371e8.7b9fSMTPIN_ADDED_BROKEN@mx.google.com>
2019-03-26 17:44 ` Bart Van Assche
2019-03-26 17:49 ` Bart Van Assche [this message]
2019-03-25 17:06 ` Bart Van Assche
[not found] ` <5c99721b.1c69fb81.5bb69.0006SMTPIN_ADDED_BROKEN@mx.google.com>
2019-03-26 0:54 ` Bart Van Assche
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=1553622542.118779.71.camel@acm.org \
--to=bvanassche@acm.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=shhuiw@foxmail.com \
--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 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.