Re: FAILED: patch "[PATCH] zram: fix race between backing_dev_show and backing_dev_store" failed to apply to 4.19-stable tree

[Sasha Levin <sashal@kernel.org>]

On Sun, Oct 27, 2019 at 02:46:07PM +0100, gregkh@linuxfoundation.org wrote:
>
>The patch below does not apply to the 4.19-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 f7daefe4231e57381d92c2e2ad905a899c28e402 Mon Sep 17 00:00:00 2001
>From: Chenwandun <chenwandun@huawei.com>
>Date: Fri, 18 Oct 2019 20:20:14 -0700
>Subject: [PATCH] zram: fix race between backing_dev_show and backing_dev_store
>
>CPU0:				       CPU1:
>backing_dev_show		       backing_dev_store
>    ......				   ......
>    file = zram->backing_dev;
>    down_read(&zram->init_lock);	   down_read(&zram->init_init_lock)
>    file_path(file, ...);		   zram->backing_dev = backing_dev;
>    up_read(&zram->init_lock);		   up_read(&zram->init_lock);
>
>gets the value of zram->backing_dev too early in backing_dev_show, which
>resultin the value being NULL at the beginning, and not NULL later.
>
>backtrace:
>  d_path+0xcc/0x174
>  file_path+0x10/0x18
>  backing_dev_show+0x40/0xb4
>  dev_attr_show+0x20/0x54
>  sysfs_kf_seq_show+0x9c/0x10c
>  kernfs_seq_show+0x28/0x30
>  seq_read+0x184/0x488
>  kernfs_fop_read+0x5c/0x1a4
>  __vfs_read+0x44/0x128
>  vfs_read+0xa0/0x138
>  SyS_read+0x54/0xb4
>
>Link: http://lkml.kernel.org/r/1571046839-16814-1-git-send-email-chenwandun@huawei.com
>Signed-off-by: Chenwandun <chenwandun@huawei.com>
>Acked-by: Minchan Kim <minchan@kernel.org>
>Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
>Cc: Jens Axboe <axboe@kernel.dk>
>Cc: <stable@vger.kernel.org>	[4.14+]
>Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

This conflict was due to the refactoring done by 7e5292831b346 ("zram:
refactor flags and writeback stuff"). I originally wanted to take it as
well, but there were too many changes in 4.14, so instead I fixed up the
original conflict and queued it up for 4.19 and 4.14.

-- 
Thanks,
Sasha