Skip to contentSkip to conversation

FAILED: patch "[PATCH] blktrace: Protect q->blk_trace with RCU" failed to apply to 5.4-stable tree

PATCH [email protected] 2 participants 2 messages Mar 2, 2020 – Mar 3, 2020

Subsystems (3)
Stable branch Block layer Tracing
lore
Share & tools
lore

[email protected]

author maintainer
#0 lore raw

The patch below does not apply to the 5.4-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.

thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

From c780e86dd48ef6467a1146cf7d0fe1e05a635039 Mon Sep 17 00:00:00 2001
From: Jan Kara <[email protected]>
Date: Thu, 6 Feb 2020 15:28:12 +0100
Subject: [PATCH] blktrace: Protect q->blk_trace with RCU

KASAN is reporting that __blk_add_trace() has a use-after-free issue when accessing q->blk_trace. Indeed the switching of block tracing (and thus eventual freeing of q->blk_trace) is completely unsynchronized with the currently running tracing and thus it can happen that the blk_trace structure is being freed just while __blk_add_trace() works on it. Protect accesses to q->blk_trace by RCU during tracing and make sure we wait for the end of RCU grace period when shutting down tracing. Luckily that is rare enough event that we can afford that. Note that postponing the freeing of blk_trace to an RCU callback should better be avoided as it could have unexpected user visible side-effects as debugfs files would be still existing for a short while block tracing has been shut down.

Link https://bugzilla.kernel.org/show_bug.cgi?id=205711
CC [email protected]
Reviewed-by Chaitanya Kulkarni <[email protected]>
Reviewed-by Ming Lei <[email protected]>
Tested-by Ming Lei <[email protected]>
Reviewed-by Bart Van Assche <[email protected]>
Reported-by Tristan Madani <[email protected]>
Signed-off-by Jan Kara <[email protected]>
Signed-off-by Jens Axboe <[email protected]>
include/linux/blkdev.h +1 -1
index 053ea4b51988..10455b2bbbb4 100644
@@ -524,7 +524,7 @@ struct request_queue {
 	unsigned int		sg_reserved_size;
 	int			node;
 #ifdef CONFIG_BLK_DEV_IO_TRACE
-	struct blk_trace	*blk_trace;
+	struct blk_trace __rcu	*blk_trace;
 	struct mutex		blk_trace_mutex;
 #endif
 	/*
include/linux/blktrace_api.h +13 -5
index 7bb2d8de9f30..3b6ff5902edc 100644
@@ -51,9 +51,13 @@ void __trace_note_message(struct blk_trace *, struct blkcg *blkcg, const char *f
  **/
 #define blk_add_cgroup_trace_msg(q, cg, fmt, ...)			\
 	do {								\
-		struct blk_trace *bt = (q)->blk_trace;			\
+		struct blk_trace *bt;					\
+									\
+		rcu_read_lock();					\
+		bt = rcu_dereference((q)->blk_trace);			\
 		if (unlikely(bt))					\
 			__trace_note_message(bt, cg, fmt, ##__VA_ARGS__);\
+		rcu_read_unlock();					\
 	} while (0)
 #define blk_add_trace_msg(q, fmt, ...)					\
 	blk_add_cgroup_trace_msg(q, NULL, fmt, ##__VA_ARGS__)

@@ -61,10 +65,14 @@ void __trace_note_message(struct blk_trace *, struct blkcg *blkcg, const char *f
 
 static inline bool blk_trace_note_message_enabled(struct request_queue *q)
 {
-	struct blk_trace *bt = q->blk_trace;
-	if (likely(!bt))
-		return false;
-	return bt->act_mask & BLK_TC_NOTIFY;
+	struct blk_trace *bt;
+	bool ret;
+
+	rcu_read_lock();
+	bt = rcu_dereference(q->blk_trace);
+	ret = bt && (bt->act_mask & BLK_TC_NOTIFY);
+	rcu_read_unlock();
+	return ret;
 }
 
 extern void blk_add_driver_data(struct request_queue *q, struct request *rq,
kernel/trace/blktrace.c +83 -31

314 lines not on this page · raw message

maintainer
#1 lore raw
Quoted 30 lines · On Mon, Mar 02, 2020 at 07:32:51PM +0100, [email protected] wrote:

The patch below does not apply to the 5.4-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.

thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

From c780e86dd48ef6467a1146cf7d0fe1e05a635039 Mon Sep 17 00:00:00 2001
From: Jan Kara <[email protected]>
Date: Thu, 6 Feb 2020 15:28:12 +0100
Subject: [PATCH] blktrace: Protect q->blk_trace with RCU

KASAN is reporting that __blk_add_trace() has a use-after-free issue when accessing q->blk_trace. Indeed the switching of block tracing (and thus eventual freeing of q->blk_trace) is completely unsynchronized with the currently running tracing and thus it can happen that the blk_trace structure is being freed just while __blk_add_trace() works on it. Protect accesses to q->blk_trace by RCU during tracing and make sure we wait for the end of RCU grace period when shutting down tracing. Luckily that is rare enough event that we can afford that. Note that postponing the freeing of blk_trace to an RCU callback should better be avoided as it could have unexpected user visible side-effects as debugfs files would be still existing for a short while block tracing has been shut down.

Quoted 9 lines
Link https://bugzilla.kernel.org/show_bug.cgi?id=205711
CC [email protected]
Reviewed-by Chaitanya Kulkarni <[email protected]>
Reviewed-by Ming Lei <[email protected]>
Tested-by Ming Lei <[email protected]>
Reviewed-by Bart Van Assche <[email protected]>
Reported-by Tristan Madani <[email protected]>
Signed-off-by Jan Kara <[email protected]>
Signed-off-by Jens Axboe <[email protected]>

The conflict was because we don't have 67c0496e87d1 ("kernfs: convert kernfs_node->id from union kernfs_node_id to u64") on 5.4. Fixed and queued up.

Signature · 2 lines
Thanks,
Sasha