All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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.