linux-cifs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: ronnie sahlberg <ronniesahlberg@gmail.com>
To: Pavel Shilovsky <piastryyy@gmail.com>
Cc: Steve French <smfrench@gmail.com>,
	Ronnie Sahlberg <lsahlber@redhat.com>,
	linux-cifs <linux-cifs@vger.kernel.org>
Subject: Re: [PATCH] cifs: add support for fallocate mode 0 for non-sparse files
Date: Fri, 17 Jan 2020 10:56:19 +1000	[thread overview]
Message-ID: <CAN05THS80kOBNha3Cia2ufaf_WOyLJ-ebR43WupHSvN6Hb8NBg@mail.gmail.com> (raw)
In-Reply-To: <CAKywueTB28BQDdBPo=RDHxjPydrKcniRJmbHGaJ3jOD0KKTzVA@mail.gmail.com>

On Fri, Jan 17, 2020 at 10:27 AM Pavel Shilovsky <piastryyy@gmail.com> wrote:
>

Thanks.

> чт, 16 янв. 2020 г. в 01:05, ronnie sahlberg <ronniesahlberg@gmail.com>:
> >
> > The bug is basically that if we extend a file by fallocate mode==0
> > and immediately afterwards mmap() the file we will only mmap() as much
> > as end-of-file was
> > prior to the truncate  and then if we try to touch any
> > address in this extended region userspace dies with bus error.
> >
> > The patch added "extend a file with fallocate mode==0 for NON-Sparse
> > files" and caused xfstest to fail.
> > The fix is to force us to revalidate the file attributes (the size is
> > the important one) when we extend the file so
> > mmap() will work properly.
> > I have fixed this in the patch and will resend tomorrow after some more testing.
> >
> > Looking for other SMB2_set_eof() callsites I see we already had the
> > same bug for the case of extending a SPARSE
>
> I agree that regardless of file being sparse or not, we should somehow
> update a size in the VFS after calling SMB2_set_eof().
>
> > file using fallocate mode==0. I fixed that too and will audit all
> > other plases where we use SMB2_set_eof()
> > to see if they are safe or not before resending.
>
> One of those places where SMB2_set_eof() is called is
> cifs_set_file_size() which does call the following after getting a
> successful response from the server:
>
> 2250 >-------if (rc == 0) {
> 2251 >------->-------cifsInode->server_eof = attrs->ia_size;
> 2252 >------->-------cifs_setsize(inode, attrs->ia_size);
> 2253 >------->-------cifs_truncate_page(inode->i_mapping, inode->i_size);
> 2254 >-------}
>
> This is called by cifs_setattr_[no]unix() which does the following afterwards:
>
> 2569 >-------if ((attrs->ia_valid & ATTR_SIZE) &&
> 2570 >-------    attrs->ia_size != i_size_read(inode))
> 2571 >------->-------truncate_setsize(inode, attrs->ia_size);
>
> truncate_setsize() does  similar things as cifs_setsize() besides
> setting cinode->time to 0. This code path probably needs to be
> refactored. But putting this aside, for the current fallocate fix I
> think we should use the same existing mechanism to update a file size
> in the VFS without revalidating the inode.

I can do that change. Note however that since we are still setting
cinode->time to 0
we are still going to trigger a revalidation at some stage.

>
> --
> Best regards,
> Pavel Shilovsky

  reply	other threads:[~2020-01-17  0:56 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-15  1:23 [PATCH 0/1] add support for fallocate mode 0 Ronnie Sahlberg
2020-01-15  1:23 ` [PATCH] cifs: add support for fallocate mode 0 for non-sparse files Ronnie Sahlberg
2020-01-15  1:25   ` Steve French
2020-01-15  2:25     ` ronnie sahlberg
2020-01-15 20:14       ` Steve French
2020-01-16  2:03         ` Steve French
2020-01-16  8:42           ` ronnie sahlberg
2020-01-17  0:27             ` Pavel Shilovsky
2020-01-17  0:56               ` ronnie sahlberg [this message]
2020-01-17  0:04 Ronnie Sahlberg
2020-01-17  1:15 Ronnie Sahlberg

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=CAN05THS80kOBNha3Cia2ufaf_WOyLJ-ebR43WupHSvN6Hb8NBg@mail.gmail.com \
    --to=ronniesahlberg@gmail.com \
    --cc=linux-cifs@vger.kernel.org \
    --cc=lsahlber@redhat.com \
    --cc=piastryyy@gmail.com \
    --cc=smfrench@gmail.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 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).