From: Sasha Levin <sashal@kernel.org>
To: gregkh@linuxfoundation.org
Cc: sunny.s.zhang@oracle.com, akpm@linux-foundation.org,
gechangwei@live.cn, ghe@suse.com, jiangqi903@gmail.com,
jlbec@evilplan.org, junxiao.bi@oracle.com, mark@fasheh.com,
piaojun@huawei.com, stable@vger.kernel.org,
torvalds@linux-foundation.org
Subject: Re: FAILED: patch "[PATCH] ocfs2: protect extent tree in ocfs2_prepare_inode_for_write()" failed to apply to 5.3-stable tree
Date: Mon, 11 Nov 2019 08:32:04 -0500 [thread overview]
Message-ID: <20191111133204.GS4787@sasha-vm> (raw)
In-Reply-To: <15734523452030@kroah.com>
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
prev parent reply other threads:[~2019-11-11 13:32 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-11 6:05 FAILED: patch "[PATCH] ocfs2: protect extent tree in ocfs2_prepare_inode_for_write()" failed to apply to 5.3-stable tree gregkh
2019-11-11 13:32 ` Sasha Levin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191111133204.GS4787@sasha-vm \
--to=sashal@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=gechangwei@live.cn \
--cc=ghe@suse.com \
--cc=gregkh@linuxfoundation.org \
--cc=jiangqi903@gmail.com \
--cc=jlbec@evilplan.org \
--cc=junxiao.bi@oracle.com \
--cc=mark@fasheh.com \
--cc=piaojun@huawei.com \
--cc=stable@vger.kernel.org \
--cc=sunny.s.zhang@oracle.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).