Re: [bugreport 5.9-rc8] general protection fault, probably for non-canonical address 0x46b1b0f0d8856e4a: 0000 [#1] SMP NOPTI

From: Ming Lei <tom.leiming@gmail.com>
To: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Cc: linux-block <linux-block@vger.kernel.org>,
	Paolo Valente <paolo.valente@linaro.org>,
	Jens Axboe <axboe@fb.com>,
	Linux List Kernel Mailing <linux-kernel@vger.kernel.org>
Subject: Re: [bugreport 5.9-rc8] general protection fault, probably for non-canonical address 0x46b1b0f0d8856e4a: 0000 [#1] SMP NOPTI
Date: Thu, 4 Mar 2021 16:42:30 +0800	[thread overview]
Message-ID: <CACVXFVOy8928GNowCQRGQKQxuLtHn0V+pYk1kzeOyc0pyDvkjQ@mail.gmail.com> (raw)
In-Reply-To: <CABXGCsP63mN+G1xE7UBfVRuDRcJiRRC7EXU2y25f9rXkoU-0LQ@mail.gmail.com>

On Sat, Oct 10, 2020 at 1:40 PM Mikhail Gavrilov
<mikhail.v.gavrilov@gmail.com> wrote:
>
> Paolo, Jens I am sorry for the noise.
> But today I hit the kernel panic and git blame said that you have
> created the file in which happened panic (this I saw from trace)
>
> $ /usr/src/kernels/`uname -r`/scripts/faddr2line
> /lib/debug/lib/modules/`uname -r`/vmlinux
> __bfq_deactivate_entity+0x15a
> __bfq_deactivate_entity+0x15a/0x240:
> bfq_gt at block/bfq-wf2q.c:20
> (inlined by) bfq_insert at block/bfq-wf2q.c:381
> (inlined by) bfq_idle_insert at block/bfq-wf2q.c:621
> (inlined by) __bfq_deactivate_entity at block/bfq-wf2q.c:1203
>
> https://github.com/torvalds/linux/blame/master/block/bfq-wf2q.c#L1203
>
> $ head /sys/block/*/queue/scheduler
> ==> /sys/block/nvme0n1/queue/scheduler <==
> [none] mq-deadline kyber bfq
>
> ==> /sys/block/sda/queue/scheduler <==
> mq-deadline kyber [bfq] none
>
> ==> /sys/block/zram0/queue/scheduler <==
> none
>
> Trace:
> general protection fault, probably for non-canonical address
> 0x46b1b0f0d8856e4a: 0000 [#1] SMP NOPTI
> CPU: 27 PID: 1018 Comm: kworker/27:1H Tainted: G        W
> --------- ---  5.9.0-0.rc8.28.fc34.x86_64 #1
> Hardware name: System manufacturer System Product Name/ROG STRIX
> X570-I GAMING, BIOS 2606 08/13/2020
> Workqueue: kblockd blk_mq_run_work_fn
> RIP: 0010:__bfq_deactivate_entity+0x15a/0x240
> Code: 48 2b 41 28 48 85 c0 7e 05 49 89 5c 24 18 49 8b 44 24 08 4d 8d
> 74 24 08 48 85 c0 0f 84 d6 00 00 00 48 8b 7b 28 eb 03 48 89 c8 <48> 8b
> 48 28 48 8d 70 10 48 8d 50 08 48 29 f9 48 85 c9 48 0f 4f d6
> RSP: 0018:ffffadf6c0c6fc00 EFLAGS: 00010002
> RAX: 46b1b0f0d8856e4a RBX: ffff8dc2773b5c88 RCX: 46b1b0f0d8856e4a
> RDX: ffff8dc7d02ed0a0 RSI: ffff8dc7d02ed0a8 RDI: 0000584e64e96beb
> RBP: ffff8dc2773b5c00 R08: ffff8dc9054cb938 R09: 0000000000000000
> R10: 0000000000000018 R11: 0000000000000018 R12: ffff8dc904927150
> R13: 0000000000000001 R14: ffff8dc904927158 R15: ffff8dc2773b5c88
> FS:  0000000000000000(0000) GS:ffff8dc90e0c0000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000003e8ebe4000 CR3: 00000007c2546000 CR4: 0000000000350ee0
> Call Trace:
>  bfq_deactivate_entity+0x4f/0xc0

Hello,

The same stack trace was observed in RH internal test too, and kernel
is 5.11.0-0.rc6,
but there isn't reproducer yet.

-- 
Ming Lei