[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220120140629.ffe26hen5cxwzexi@carbon.lan>
Date: Thu, 20 Jan 2022 15:06:29 +0100
From: Daniel Wagner <dwagner@...e.de>
To: Ming Lei <ming.lei@...hat.com>
Cc: linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
Jens Axboe <axboe@...nel.dk>, Hannes Reinecke <hare@...e.de>
Subject: Re: [PATCH 2/2] block: hold queue lock while iterating in
diskstats_show
On Thu, Jan 20, 2022 at 03:01:27PM +0100, Daniel Wagner wrote:
> On Thu, Jan 20, 2022 at 09:51:18PM +0800, Ming Lei wrote:
> > Then Can you figure out where blk_mq_queue_tag_busy_iter+0x1e4 points to
> > in source code? And what is NULL pointer?
Yes %rax is NULL
> Here we go:
>
> /usr/src/debug/kernel-default-5.3.18-59.27.1.x86_64/linux-5.3/linux-obj/../include/linux/sbitmap.h: 249
> 0xffffffffb244a254 <blk_mq_queue_tag_busy_iter+484>: mov (%rax),%rdx
>
> 234static inline void __sbitmap_for_each_set(struct sbitmap *sb,
> 235 unsigned int start,
> 236 sb_for_each_fn fn, void *data)
> 237{
> 238 unsigned int index;
> 239 unsigned int nr;
> 240 unsigned int scanned = 0;
> 241
> 242 if (start >= sb->depth)
> 243 start = 0;
> 244 index = SB_NR_TO_INDEX(sb, start);
> 245 nr = SB_NR_TO_BIT(sb, start);
> 246
> 247 while (scanned < sb->depth) {
> 248 unsigned long word;
> 249 unsigned int depth = min_t(unsigned int,
> 250 sb->map[index].depth - nr,
> 251 sb->depth - scanned);
forgot to add this
crash> bt
PID: 17640 TASK: ffff956f4a468000 CPU: 13 COMMAND: "iostat"
#0 [ffffb701aefb7980] machine_kexec at ffffffffba66fb91
#1 [ffffb701aefb79d8] __crash_kexec at ffffffffba75927d
#2 [ffffb701aefb7aa0] crash_kexec at ffffffffba75a13d
#3 [ffffb701aefb7ab8] oops_end at ffffffffba636cdf
#4 [ffffb701aefb7ad8] no_context at ffffffffba682baf
#5 [ffffb701aefb7b40] do_page_fault at ffffffffba683e30
#6 [ffffb701aefb7b70] page_fault at ffffffffbb0012fe
[exception RIP: blk_mq_queue_tag_busy_iter+484]
RIP: ffffffffbaa4a254 RSP: ffffb701aefb7c20 RFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000
RDX: ffff954f43c14c00 RSI: ffffffffbaa442c0 RDI: ffff954fb3749010
RBP: 0000000000000000 R8: 0000000800000000 R9: 00000008ffffffff
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: ffff9567b2200000 R14: ffff954798c09bc0 R15: ffff954798c09c20
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
#7 [ffffb701aefb7cb0] blk_mq_in_flight at ffffffffbaa461e5
#8 [ffffb701aefb7cd0] diskstats_show at ffffffffbaa4f00d
#9 [ffffb701aefb7e50] seq_read at ffffffffba90df16
#10 [ffffb701aefb7eb0] proc_reg_read at ffffffffba96d789
#11 [ffffb701aefb7ec8] vfs_read at ffffffffba8e4c39
#12 [ffffb701aefb7ef8] ksys_read at ffffffffba8e4fc1
#13 [ffffb701aefb7f38] do_syscall_64 at ffffffffba60538b
#14 [ffffb701aefb7f50] entry_SYSCALL_64_after_hwframe at ffffffffbb00008c
RIP: 00007f6031f4eb5e RSP: 00007ffd187a7e88 RFLAGS: 00000246
RAX: ffffffffffffffda RBX: 00005577a698c2c0 RCX: 00007f6031f4eb5e
RDX: 0000000000000400 RSI: 00005577a698f480 RDI: 0000000000000003
RBP: 00007f603222e300 R8: 0000000000000000 R9: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000000a
R13: 0000000000000d68 R14: 00007f603222d700 R15: 0000000000000d68
ORIG_RAX: 0000000000000000 CS: 0033 SS: 002b
I've tried to figure out the request_pointer from the registers and I
think the pointer is still in %rdi
struct request_queue {
last_merge = 0x0,
elevator = 0x0,
stats = 0xffff956f45a9bec0,
rq_qos = 0xffff954f54c57558,
mq_ops = 0xffffffffc0c27140 <nvme_tcp_mq_ops>,
queue_ctx = 0x4151cf2266c0,
queue_depth = 0x0,
queue_hw_ctx = 0xffff954f43c14c00,
nr_hw_queues = 0x50,
backing_dev_info = 0xffff953fae3ae800,
queuedata = 0xffff953622282800,
queue_flags = 0x5041d0,
View attachment "request_queue.log" of type "text/plain" (15850 bytes)
Powered by blists - more mailing lists