From: Joseph Qi <joseph.qi@linux.alibaba.com>
To: Jan Kara <jack@suse.cz>, Andrew Morton <akpm@linux-foundation.org>
Cc: stable@vger.kernel.org, ocfs2-devel@oss.oracle.com
Subject: Re: [Ocfs2-devel] [PATCH 1/2] ocfs2: Fix data corruption on truncate
Date: Thu, 28 Oct 2021 15:44:15 +0800 [thread overview]
Message-ID: <7b6b56f5-e040-1d85-d7a7-e43bf2dcc1fe@linux.alibaba.com> (raw)
In-Reply-To: <f8c309cf-ace7-f8c7-33d2-9a5fa39cb21b@linux.alibaba.com>
On 10/28/21 3:09 PM, Joseph Qi wrote:
> Hi Jan,
>
> On 10/25/21 11:13 PM, Jan Kara wrote:
>> ocfs2_truncate_file() did unmap invalidate page cache pages before
>> zeroing partial tail cluster and setting i_size. Thus some pages could
>> be left (and likely have left if the cluster zeroing happened) in the
>> page cache beyond i_size after truncate finished letting user possibly
>> see stale data once the file was extended again. Also the tail cluster
>
> I don't quite understand the case.
> truncate_inode_pages() will truncate pages from new_i_size to i_size,
> and the following ocfs2_orphan_for_truncate() will zero range and then
> update i_size for inode as well as dinode.
> So once truncate finished, how stale data exposing happens? Or do you
> mean a race case between the above two steps?
>
Or do you mean ocfs2_zero_range_for_truncate() will grab and zero eof
pages? Though it depends on block_write_full_page() to write out, the
pages are zeroed now. Still a little confused...
_______________________________________________
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel
WARNING: multiple messages have this Message-ID (diff)
From: Joseph Qi <joseph.qi@linux.alibaba.com>
To: Jan Kara <jack@suse.cz>, Andrew Morton <akpm@linux-foundation.org>
Cc: ocfs2-devel@oss.oracle.com, Gang He <ghe@suse.com>,
Mark Fasheh <mark@fasheh.com>, Joel Becker <jlbec@evilplan.org>,
stable@vger.kernel.org
Subject: Re: [PATCH 1/2] ocfs2: Fix data corruption on truncate
Date: Thu, 28 Oct 2021 15:44:15 +0800 [thread overview]
Message-ID: <7b6b56f5-e040-1d85-d7a7-e43bf2dcc1fe@linux.alibaba.com> (raw)
In-Reply-To: <f8c309cf-ace7-f8c7-33d2-9a5fa39cb21b@linux.alibaba.com>
On 10/28/21 3:09 PM, Joseph Qi wrote:
> Hi Jan,
>
> On 10/25/21 11:13 PM, Jan Kara wrote:
>> ocfs2_truncate_file() did unmap invalidate page cache pages before
>> zeroing partial tail cluster and setting i_size. Thus some pages could
>> be left (and likely have left if the cluster zeroing happened) in the
>> page cache beyond i_size after truncate finished letting user possibly
>> see stale data once the file was extended again. Also the tail cluster
>
> I don't quite understand the case.
> truncate_inode_pages() will truncate pages from new_i_size to i_size,
> and the following ocfs2_orphan_for_truncate() will zero range and then
> update i_size for inode as well as dinode.
> So once truncate finished, how stale data exposing happens? Or do you
> mean a race case between the above two steps?
>
Or do you mean ocfs2_zero_range_for_truncate() will grab and zero eof
pages? Though it depends on block_write_full_page() to write out, the
pages are zeroed now. Still a little confused...
next prev parent reply other threads:[~2021-10-28 7:45 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-25 15:13 [Ocfs2-devel] [PATCH 0/2] ocfs2: Truncate data corruption fix Jan Kara
2021-10-25 15:13 ` [Ocfs2-devel] [PATCH 1/2] ocfs2: Fix data corruption on truncate Jan Kara
2021-10-25 15:13 ` Jan Kara
2021-10-28 7:09 ` [Ocfs2-devel] " Joseph Qi
2021-10-28 7:09 ` Joseph Qi
2021-10-28 7:44 ` Joseph Qi [this message]
2021-10-28 7:44 ` Joseph Qi
2021-11-01 11:31 ` [Ocfs2-devel] " Jan Kara
2021-11-01 11:31 ` Jan Kara
2021-11-02 2:36 ` [Ocfs2-devel] " Joseph Qi
2021-11-02 2:36 ` Joseph Qi
2021-11-02 9:55 ` [Ocfs2-devel] " Jan Kara
2021-11-02 9:55 ` Jan Kara
2021-10-25 15:13 ` [Ocfs2-devel] [PATCH 2/2] ocfs2: Do not zero pages beyond i_size Jan Kara
2021-11-02 2:58 ` Joseph Qi
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=7b6b56f5-e040-1d85-d7a7-e43bf2dcc1fe@linux.alibaba.com \
--to=joseph.qi@linux.alibaba.com \
--cc=akpm@linux-foundation.org \
--cc=jack@suse.cz \
--cc=ocfs2-devel@oss.oracle.com \
--cc=stable@vger.kernel.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 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.