From: Luis Henriques <lhenriques@suse.com>
To: Ilya Dryomov <idryomov@gmail.com>
Cc: Jeff Layton <jlayton@kernel.org>, Sage Weil <sage@redhat.com>,
"Yan, Zheng" <zyan@redhat.com>,
Gregory Farnum <gfarnum@redhat.com>,
Ceph Development <ceph-devel@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
stable@vger.kernel.org
Subject: Re: [PATCH] ceph: fix copy_file_range error path in short copies
Date: Wed, 5 Feb 2020 19:24:14 +0000 [thread overview]
Message-ID: <20200205192414.GA27345@suse.com> (raw)
In-Reply-To: <CAOi1vP8w_ssGZJTimgDMULgd4jyb_CYuxNyjvHhbBR9FgAqB9A@mail.gmail.com>
On Wed, Feb 05, 2020 at 12:16:02PM +0100, Ilya Dryomov wrote:
> On Wed, Feb 5, 2020 at 11:28 AM Luis Henriques <lhenriques@suse.com> wrote:
> >
> > When there's an error in the copying loop but some bytes have already been
> > copied into the destination file, it is necessary to dirty the caps and
> > eventually update the MDS with the file metadata (timestamps, size). This
> > patch fixes this error path.
> >
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Luis Henriques <lhenriques@suse.com>
> > ---
> > fs/ceph/file.c | 12 ++++++++++--
> > 1 file changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/fs/ceph/file.c b/fs/ceph/file.c
> > index 11929d2bb594..7be47d24edb1 100644
> > --- a/fs/ceph/file.c
> > +++ b/fs/ceph/file.c
> > @@ -2104,9 +2104,16 @@ static ssize_t __ceph_copy_file_range(struct file *src_file, loff_t src_off,
> > CEPH_OSD_OP_FLAG_FADVISE_DONTNEED, 0);
> > if (err) {
> > dout("ceph_osdc_copy_from returned %d\n", err);
> > - if (!ret)
> > + /*
> > + * If we haven't done any copy yet, just exit with the
> > + * error code; otherwise, return the number of bytes
> > + * already copied, update metadata and dirty caps.
> > + */
> > + if (!ret) {
> > ret = err;
> > - goto out_caps;
> > + goto out_caps;
> > + }
> > + goto out_early;
> > }
> > len -= object_size;
> > src_off += object_size;
> > @@ -2118,6 +2125,7 @@ static ssize_t __ceph_copy_file_range(struct file *src_file, loff_t src_off,
> > /* We still need one final local copy */
> > do_final_copy = true;
> >
> > +out_early:
>
> out_early is misleading, especially given that there already
> is out_caps, which just puts caps. I suggest something like
> update_dst_inode.
>
> > file_update_time(dst_file);
> > inode_inc_iversion_raw(dst_inode);
> >
>
> I think this is still buggy. What follows is this:
>
> if (endoff > size) {
> int caps_flags = 0;
>
> /* Let the MDS know about dst file size change */
> if (ceph_quota_is_max_bytes_approaching(dst_inode, endoff))
> caps_flags |= CHECK_CAPS_NODELAY;
> if (ceph_inode_set_size(dst_inode, endoff))
> caps_flags |= CHECK_CAPS_AUTHONLY;
> if (caps_flags)
> ceph_check_caps(dst_ci, caps_flags, NULL);
> }
>
> with endoff being:
>
> size = i_size_read(dst_inode);
> endoff = dst_off + len;
>
> So a short copy effectively zero-fills the destination file...
Ah! What a surprise! Yet another bug in copy_file_range. /me hides
I guess that replacing 'endoff' by 'dst_off' in the 'if' statement above
(including the condition itself) should fix it. But I start to think that
I'm biased and unable to see the most obvious issues with this code :-/
Cheers,
--
Luís
next prev parent reply other threads:[~2020-02-05 19:24 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-05 10:28 [PATCH] ceph: fix copy_file_range error path in short copies Luis Henriques
2020-02-05 11:16 ` Ilya Dryomov
2020-02-05 19:24 ` Luis Henriques [this message]
2020-02-06 10:38 ` [PATCH v2] " Luis Henriques
2020-02-06 11:46 ` Jeff Layton
2020-02-10 18:38 ` Ilya Dryomov
2020-02-11 10:32 ` Luis Henriques
2020-02-11 10:32 ` Luis Henriques
2020-02-11 11:04 ` Ilya Dryomov
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=20200205192414.GA27345@suse.com \
--to=lhenriques@suse.com \
--cc=ceph-devel@vger.kernel.org \
--cc=gfarnum@redhat.com \
--cc=idryomov@gmail.com \
--cc=jlayton@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sage@redhat.com \
--cc=stable@vger.kernel.org \
--cc=zyan@redhat.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: 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.