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

[Sasha Levin <sashal@kernel.org>]

On Mon, Mar 02, 2020 at 07:32:51PM +0100, gregkh@linuxfoundation.org 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 <stable@vger.kernel.org>.
>
>thanks,
>
>greg k-h
>
>------------------ original commit in Linus's tree ------------------
>
>From c780e86dd48ef6467a1146cf7d0fe1e05a635039 Mon Sep 17 00:00:00 2001
>From: Jan Kara <jack@suse.cz>
>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: stable@vger.kernel.org
>Reviewed-by: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
>Reviewed-by: Ming Lei <ming.lei@redhat.com>
>Tested-by: Ming Lei <ming.lei@redhat.com>
>Reviewed-by: Bart Van Assche <bvanassche@acm.org>
>Reported-by: Tristan Madani <tristmd@gmail.com>
>Signed-off-by: Jan Kara <jack@suse.cz>
>Signed-off-by: Jens Axboe <axboe@kernel.dk>

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.

-- 
Thanks,
Sasha