Jens Axboe
a6da0024ff
blktrace: fix unlocked registration of tracepoints
We need to ensure that tracepoints are registered and unregistered
with the users of them. The existing atomic count isn't enough for
that. Add a lock around the tracepoints, so we serialize access
to them.
This fixes cases where we have multiple users setting up and
tearing down tracepoints, like this:
CPU: 0 PID: 2995 Comm: syzkaller857118 Not tainted
4.14.0-rc5-next-20171018+ #36
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:16 [inline]
dump_stack+0x194/0x257 lib/dump_stack.c:52
panic+0x1e4/0x41c kernel/panic.c:183
__warn+0x1c4/0x1e0 kernel/panic.c:546
report_bug+0x211/0x2d0 lib/bug.c:183
fixup_bug+0x40/0x90 arch/x86/kernel/traps.c:177
do_trap_no_signal arch/x86/kernel/traps.c:211 [inline]
do_trap+0x260/0x390 arch/x86/kernel/traps.c:260
do_error_trap+0x120/0x390 arch/x86/kernel/traps.c:297
do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:310
invalid_op+0x18/0x20 arch/x86/entry/entry_64.S:905
RIP: 0010:tracepoint_add_func kernel/tracepoint.c:210 [inline]
RIP: 0010:tracepoint_probe_register_prio+0x397/0x9a0 kernel/tracepoint.c:283
RSP: 0018:ffff8801d1d1f6c0 EFLAGS: 00010293
RAX: ffff8801d22e8540 RBX: 00000000ffffffef RCX: ffffffff81710f07
RDX: 0000000000000000 RSI: ffffffff85b679c0 RDI: ffff8801d5f19818
RBP: ffff8801d1d1f7c8 R08: ffffffff81710c10 R09: 0000000000000004
R10: ffff8801d1d1f6b0 R11: 0000000000000003 R12: ffffffff817597f0
R13: 0000000000000000 R14: 00000000ffffffff R15: ffff8801d1d1f7a0
tracepoint_probe_register+0x2a/0x40 kernel/tracepoint.c:304
register_trace_block_rq_insert include/trace/events/block.h:191 [inline]
blk_register_tracepoints+0x1e/0x2f0 kernel/trace/blktrace.c:1043
do_blk_trace_setup+0xa10/0xcf0 kernel/trace/blktrace.c:542
blk_trace_setup+0xbd/0x180 kernel/trace/blktrace.c:564
sg_ioctl+0xc71/0x2d90 drivers/scsi/sg.c:1089
vfs_ioctl fs/ioctl.c:45 [inline]
do_vfs_ioctl+0x1b1/0x1520 fs/ioctl.c:685
SYSC_ioctl fs/ioctl.c:700 [inline]
SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691
entry_SYSCALL_64_fastpath+0x1f/0xbe
RIP: 0033:0x444339
RSP: 002b:00007ffe05bb5b18 EFLAGS: 00000206 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00000000006d66c0 RCX: 0000000000444339
RDX: 000000002084cf90 RSI: 00000000c0481273 RDI: 0000000000000009
RBP: 0000000000000082 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000206 R12: ffffffffffffffff
R13: 00000000c0481273 R14: 0000000000000000 R15: 0000000000000000
since we can now run these in parallel. Ensure that the exported helpers
for doing this are grabbing the queue trace mutex.
Reported-by: Steven Rostedt <rostedt@goodmis.org>
Tested-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2017-11-10 19:53:25 -07:00
..
2017-11-10 19:53:25 -07:00
2017-08-15 17:32:15 -07:00
2017-09-01 13:55:49 -04:00
2017-06-13 17:13:06 -04:00
2017-03-01 10:26:39 +01:00
2016-04-02 01:09:12 +02:00
2017-08-02 14:23:02 -04:00
2017-08-02 14:23:02 -04:00
2017-04-17 15:21:19 -04:00
2016-12-09 09:13:30 -05:00
2017-01-19 08:57:41 -05:00
2017-03-02 08:42:27 +01:00
2017-05-08 17:15:15 -07:00
2017-08-29 13:29:29 +02:00
2017-09-13 18:53:16 -07:00
2017-03-02 08:42:38 +01:00
2017-03-02 08:42:38 +01:00
2017-09-05 12:00:09 -04:00
2015-11-02 14:28:05 -05:00
2017-09-08 18:26:48 -07:00
2017-06-29 10:05:45 -04:00
2017-05-08 17:15:15 -07:00
2016-12-25 11:04:12 +01:00
2015-09-30 15:22:55 -04:00
2017-08-29 13:29:29 +02:00
2017-09-19 12:36:01 -04:00
2016-03-08 11:23:57 -05:00
2017-06-27 13:30:28 -04:00
2015-09-28 10:16:12 -04:00
2016-06-20 09:46:12 -04:00
2017-02-15 10:32:48 -05:00
2017-03-01 10:26:39 +01:00
2017-06-27 13:30:28 -04:00
2016-12-25 11:04:12 +01:00
2017-09-01 12:04:09 -04:00
2015-02-13 21:21:37 -08:00
2017-09-23 16:50:20 -04:00
2016-03-22 15:36:02 -07:00
2017-09-11 14:28:45 -07:00
2017-08-29 13:29:29 +02:00
2017-09-19 18:33:42 -04:00
2017-09-19 12:36:01 -04:00
2017-08-24 10:05:51 -04:00
2016-04-19 12:16:06 -04:00