From: Joseph Qi <joseph.qi@linux.alibaba.com> To: Gang He <GHe@suse.com>, "mark@fasheh.com" <mark@fasheh.com>, "jlbec@evilplan.org" <jlbec@evilplan.org>, "gechangwei@live.cn" <gechangwei@live.cn>, Shuning Zhang <sunny.s.zhang@oracle.com> Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "ocfs2-devel@oss.oracle.com" <ocfs2-devel@oss.oracle.com>, "akpm@linux-foundation.org" <akpm@linux-foundation.org> Subject: Re: [PATCH] ocfs2: fix the oops problem when write cloned file Date: Mon, 3 Feb 2020 16:15:12 +0800 [thread overview] Message-ID: <9dfcde60-f8da-6458-4992-ae1d5dcc1ec1@linux.alibaba.com> (raw) In-Reply-To: <CH2PR18MB3206844EE94EC90A2CBFF85CCF000@CH2PR18MB3206.namprd18.prod.outlook.com> On 20/2/3 13:32, Gang He wrote: > Hi Joseph, > > before calling ocfs2_refcount_cow() in the function ocfs2_prepare_inode_for_write(), we do not use inode buffer_head. > So, we can let buffer_head is NULL. > But, when we invoke ocfs2_refcount_cow() function, we have to pass inode buffer_head without NULL pointer. > That is why writing clone file will cause oops and kill the user-space process. > Okay, so before commit e74540b28556, we will always get a valid buffer head in ocfs2_prepare_inode_for_refcount(). You can feel free to add: Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com> BTW, you'd better resend the patch in a single thread, for the convenience of merging by akpm. > > ________________________________________ > From: Joseph Qi <joseph.qi@linux.alibaba.com> > Sent: Monday, February 3, 2020 1:15 PM > To: Gang He; mark@fasheh.com; jlbec@evilplan.org; gechangwei@live.cn; Shuning Zhang > Cc: linux-kernel@vger.kernel.org; ocfs2-devel@oss.oracle.com; akpm@linux-foundation.org > Subject: Re: [PATCH] ocfs2: fix the oops problem when write cloned file > > > > On 20/2/3 10:17, Gang He wrote: >> Hello Joseph, Changwei, Sunny and all, >> >> Could you help to review this patch? >> This patch will fix the oops problem caused by write ocfs2 clone files. >> The root cause is inode buffer head is NULL when calling ocfs2_refcount_cow. >> Secondly, we should use EX meta lock when calling ocfs2_refcount_cow. >> > Before commit e74540b28556, we may also use NULL buffer head in case of > overwrite, so why there is no such issue before? > > Thanks, > Joseph >
WARNING: multiple messages have this Message-ID (diff)
From: Joseph Qi <joseph.qi@linux.alibaba.com> To: ocfs2-devel@oss.oracle.com Subject: [Ocfs2-devel] [PATCH] ocfs2: fix the oops problem when write cloned file Date: Mon, 3 Feb 2020 16:15:12 +0800 [thread overview] Message-ID: <9dfcde60-f8da-6458-4992-ae1d5dcc1ec1@linux.alibaba.com> (raw) In-Reply-To: <CH2PR18MB3206844EE94EC90A2CBFF85CCF000@CH2PR18MB3206.namprd18.prod.outlook.com> On 20/2/3 13:32, Gang He wrote: > Hi Joseph, > > before calling ocfs2_refcount_cow() in the function ocfs2_prepare_inode_for_write(), we do not use inode buffer_head. > So, we can let buffer_head is NULL. > But, when we invoke ocfs2_refcount_cow() function, we have to pass inode buffer_head without NULL pointer. > That is why writing clone file will cause oops and kill the user-space process. > Okay, so before commit e74540b28556, we will always get a valid buffer head in ocfs2_prepare_inode_for_refcount(). You can feel free to add: Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com> BTW, you'd better resend the patch in a single thread, for the convenience of merging by akpm. > > ________________________________________ > From: Joseph Qi <joseph.qi@linux.alibaba.com> > Sent: Monday, February 3, 2020 1:15 PM > To: Gang He; mark at fasheh.com; jlbec at evilplan.org; gechangwei at live.cn; Shuning Zhang > Cc: linux-kernel at vger.kernel.org; ocfs2-devel at oss.oracle.com; akpm at linux-foundation.org > Subject: Re: [PATCH] ocfs2: fix the oops problem when write cloned file > > > > On 20/2/3 10:17, Gang He wrote: >> Hello Joseph, Changwei, Sunny and all, >> >> Could you help to review this patch? >> This patch will fix the oops problem caused by write ocfs2 clone files. >> The root cause is inode buffer head is NULL when calling ocfs2_refcount_cow. >> Secondly, we should use EX meta lock when calling ocfs2_refcount_cow. >> > Before commit e74540b28556, we may also use NULL buffer head in case of > overwrite, so why there is no such issue before? > > Thanks, > Joseph >
next prev parent reply other threads:[~2020-02-03 8:16 UTC|newest] Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-01-21 5:02 [PATCH] ocfs2: fix the oops problem when write cloned file Gang He 2020-01-21 5:02 ` [Ocfs2-devel] " Gang He 2020-01-23 3:17 ` Gang He 2020-01-23 3:17 ` [Ocfs2-devel] " Gang He 2020-02-03 2:17 ` Gang He 2020-02-03 2:17 ` [Ocfs2-devel] " Gang He 2020-02-03 5:15 ` Joseph Qi 2020-02-03 5:15 ` [Ocfs2-devel] " Joseph Qi 2020-02-03 5:32 ` Gang He 2020-02-03 5:32 ` [Ocfs2-devel] " Gang He 2020-02-03 8:15 ` Joseph Qi [this message] 2020-02-03 8:15 ` Joseph Qi 2020-02-03 5:19 ` Changwei Ge 2020-02-03 5:19 ` [Ocfs2-devel] " Changwei Ge 2020-02-03 8:56 Gang He
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=9dfcde60-f8da-6458-4992-ae1d5dcc1ec1@linux.alibaba.com \ --to=joseph.qi@linux.alibaba.com \ --cc=GHe@suse.com \ --cc=akpm@linux-foundation.org \ --cc=gechangwei@live.cn \ --cc=jlbec@evilplan.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mark@fasheh.com \ --cc=ocfs2-devel@oss.oracle.com \ --cc=sunny.s.zhang@oracle.com \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.