Re: FAILED: patch "[PATCH] ocfs2: protect extent tree in ocfs2_prepare_inode_for_write()" failed to apply to 5.3-stable tree

[Sasha Levin <sashal@kernel.org>]

On Mon, Nov 11, 2019 at 07:05:45AM +0100, gregkh@linuxfoundation.org wrote:
>
>The patch below does not apply to the 5.3-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 e74540b285569d2b1e14fe7aee92297078f235ce Mon Sep 17 00:00:00 2001
>From: Shuning Zhang <sunny.s.zhang@oracle.com>
>Date: Tue, 5 Nov 2019 21:16:34 -0800
>Subject: [PATCH] ocfs2: protect extent tree in ocfs2_prepare_inode_for_write()
>
>When the extent tree is modified, it should be protected by inode
>cluster lock and ip_alloc_sem.
>
>The extent tree is accessed and modified in the
>ocfs2_prepare_inode_for_write, but isn't protected by ip_alloc_sem.
>
>The following is a case.  The function ocfs2_fiemap is accessing the
>extent tree, which is modified at the same time.
>
>  kernel BUG at fs/ocfs2/extent_map.c:475!
>  invalid opcode: 0000 [#1] SMP
>  Modules linked in: tun ocfs2 ocfs2_nodemanager configfs ocfs2_stackglue [...]
>  CPU: 16 PID: 14047 Comm: o2info Not tainted 4.1.12-124.23.1.el6uek.x86_64 #2
>  Hardware name: Oracle Corporation ORACLE SERVER X7-2L/ASM, MB MECH, X7-2L, BIOS 42040600 10/19/2018
>  task: ffff88019487e200 ti: ffff88003daa4000 task.ti: ffff88003daa4000
>  RIP: ocfs2_get_clusters_nocache.isra.11+0x390/0x550 [ocfs2]
>  Call Trace:
>    ocfs2_fiemap+0x1e3/0x430 [ocfs2]
>    do_vfs_ioctl+0x155/0x510
>    SyS_ioctl+0x81/0xa0
>    system_call_fastpath+0x18/0xd8
>  Code: 18 48 c7 c6 60 7f 65 a0 31 c0 bb e2 ff ff ff 48 8b 4a 40 48 8b 7a 28 48 c7 c2 78 2d 66 a0 e8 38 4f 05 00 e9 28 fe ff ff 0f 1f 00 <0f> 0b 66 0f 1f 44 00 00 bb 86 ff ff ff e9 13 fe ff ff 66 0f 1f
>  RIP  ocfs2_get_clusters_nocache.isra.11+0x390/0x550 [ocfs2]
>  ---[ end trace c8aa0c8180e869dc ]---
>  Kernel panic - not syncing: Fatal exception
>  Kernel Offset: disabled
>
>This issue can be reproduced every week in a production environment.
>
>This issue is related to the usage mode.  If others use ocfs2 in this
>mode, the kernel will panic frequently.
>
>[akpm@linux-foundation.org: coding style fixes]
>[Fix new warning due to unused function by removing said function - Linus ]
>Link: http://lkml.kernel.org/r/1568772175-2906-2-git-send-email-sunny.s.zhang@oracle.com
>Signed-off-by: Shuning Zhang <sunny.s.zhang@oracle.com>
>Reviewed-by: Junxiao Bi <junxiao.bi@oracle.com>
>Reviewed-by: Gang He <ghe@suse.com>
>Cc: Mark Fasheh <mark@fasheh.com>
>Cc: Joel Becker <jlbec@evilplan.org>
>Cc: Joseph Qi <jiangqi903@gmail.com>
>Cc: Changwei Ge <gechangwei@live.cn>
>Cc: Jun Piao <piaojun@huawei.com>
>Cc: <stable@vger.kernel.org>
>Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

I've cleaned up minor context conflicts and queued it for 5.3 and 4.19.
For older kernels it needs a more complex backport which I have not
attempted.

-- 
Thanks,
Sasha