From: Shiyang Ruan <ruansy.fnst@fujitsu.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: <linux-fsdevel@vger.kernel.org>, <nvdimm@lists.linux.dev>,
<dan.j.williams@intel.com>, <willy@infradead.org>, <jack@suse.cz>,
<djwong@kernel.org>
Subject: Re: [PATCH] fsdax: unshare: zero destination if srcmap is HOLE or UNWRITTEN
Date: Fri, 24 Mar 2023 09:50:54 +0800 [thread overview]
Message-ID: <a30006e8-2896-259e-293b-2a5d873d42aa@fujitsu.com> (raw)
In-Reply-To: <20230323151112.1cc3cf57b35f2dc704ff1af8@linux-foundation.org>
在 2023/3/24 6:11, Andrew Morton 写道:
> On Thu, 23 Mar 2023 14:50:38 +0800 Shiyang Ruan <ruansy.fnst@fujitsu.com> wrote:
>
>>
>>
>> 在 2023/3/23 7:03, Andrew Morton 写道:
>>> On Wed, 22 Mar 2023 11:11:09 +0000 Shiyang Ruan <ruansy.fnst@fujitsu.com> wrote:
>>>
>>>> unshare copies data from source to destination. But if the source is
>>>> HOLE or UNWRITTEN extents, we should zero the destination, otherwise the
>>>> result will be unexpectable.
>>>
>>> Please provide much more detail on the user-visible effects of the bug.
>>> For example, are we leaking kernel memory contents to userspace?
>>
>> This fixes fail of generic/649.
>
> OK, but this doesn't really help. I'm trying to determine whether this
> fix should be backported into -stable kernels and whether it should be
> fast-tracked into Linus's current -rc tree.
>
> But to determine this I (and others) need to know what effect the bug
> has upon our users.
I didn't get any bug report form users. I just found this by running
xfstests. The phenomenon of this problem is: if we funshare a reflinked
file which contains HOLE extents, the result of the HOLE extents should
be zero but actually not (unexpectable data).
The other patch also has no reports from users.
--
Thanks,
Ruan.
next prev parent reply other threads:[~2023-03-24 1:51 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-22 11:11 [PATCH] fsdax: unshare: zero destination if srcmap is HOLE or UNWRITTEN Shiyang Ruan
2023-03-22 23:03 ` Andrew Morton
2023-03-23 6:50 ` Shiyang Ruan
2023-03-23 14:59 ` Darrick J. Wong
2023-03-23 22:11 ` Andrew Morton
2023-03-24 1:50 ` Shiyang Ruan [this message]
2023-03-24 3:33 ` Matthew Wilcox
2023-03-24 3:42 ` Shiyang Ruan
2023-03-24 4:17 ` Matthew Wilcox
2023-03-24 4:28 ` Shiyang Ruan
2023-03-24 20:44 ` Andrew Morton
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=a30006e8-2896-259e-293b-2a5d873d42aa@fujitsu.com \
--to=ruansy.fnst@fujitsu.com \
--cc=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.com \
--cc=djwong@kernel.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=nvdimm@lists.linux.dev \
--cc=willy@infradead.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.