All of lore.kernel.org
 help / color / mirror / Atom feed
From: Amir Goldstein <amir73il@gmail.com>
To: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Jens Axboe <axboe@kernel.dk>,
	Linux Next Mailing List <linux-next@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: linux-next: manual merge of the akpm-current tree with the block tree
Date: Fri, 3 May 2019 08:35:06 -0400	[thread overview]
Message-ID: <CAOQ4uxikyWj5DMcCLt6kVzLeQt8dg=wMvaXE5vOfbDLaNiqJnw@mail.gmail.com> (raw)
In-Reply-To: <20190503191033.6c56e4c0@canb.auug.org.au>

On Fri, May 3, 2019 at 5:10 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> Today's linux-next merge of the akpm-current tree got a conflict in:
>
>   fs/sync.c
>
> between commit:
>
>   22f96b3808c1 ("fs: add sync_file_range() helper")
>
> from the block tree and commit:
>
>   9a8d18789a18 ("fs/sync.c: sync_file_range(2) may use WB_SYNC_ALL writeback")
>
> from the akpm-current tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>

Fix looks technically correct, but it would have been better if the fat
comment moved to the fat helper and then replace
s/sys_sync_file_range/ksys_sync_file_range with
s/sys_sync_file_range/sync_file_range

It is probably best if either maintainer took both patches through his tree
and if move and update the comment from "sys_sync_file_range" be done
as part of the helper function patch.

Thanks,
Amir.

> --
> Cheers,
> Stephen Rothwell
>
> diff --cc fs/sync.c
> index 01e82170545a,9e8cd90e890f..000000000000
> --- a/fs/sync.c
> +++ b/fs/sync.c
> @@@ -292,10 -348,16 +292,16 @@@ int sync_file_range(struct file *file,
>         }
>
>         if (flags & SYNC_FILE_RANGE_WRITE) {
> +               int sync_mode = WB_SYNC_NONE;
> +
> +               if ((flags & SYNC_FILE_RANGE_WRITE_AND_WAIT) ==
> +                            SYNC_FILE_RANGE_WRITE_AND_WAIT)
> +                       sync_mode = WB_SYNC_ALL;
> +
>                 ret = __filemap_fdatawrite_range(mapping, offset, endbyte,
> -                                                WB_SYNC_NONE);
> +                                                sync_mode);
>                 if (ret < 0)
>  -                      goto out_put;
>  +                      goto out;
>         }
>
>         if (flags & SYNC_FILE_RANGE_WAIT_AFTER)
> @@@ -305,68 -369,6 +311,71 @@@ out
>         return ret;
>   }
>
>  +/*
> -  * sys_sync_file_range() permits finely controlled syncing over a segment of
> ++ * ksys_sync_file_range() permits finely controlled syncing over a segment of
>  + * a file in the range offset .. (offset+nbytes-1) inclusive.  If nbytes is
> -  * zero then sys_sync_file_range() will operate from offset out to EOF.
> ++ * zero then ksys_sync_file_range() will operate from offset out to EOF.
>  + *
>  + * The flag bits are:
>  + *
>  + * SYNC_FILE_RANGE_WAIT_BEFORE: wait upon writeout of all pages in the range
>  + * before performing the write.
>  + *
>  + * SYNC_FILE_RANGE_WRITE: initiate writeout of all those dirty pages in the
>  + * range which are not presently under writeback. Note that this may block for
>  + * significant periods due to exhaustion of disk request structures.
>  + *
>  + * SYNC_FILE_RANGE_WAIT_AFTER: wait upon writeout of all pages in the range
>  + * after performing the write.
>  + *
>  + * Useful combinations of the flag bits are:
>  + *
>  + * SYNC_FILE_RANGE_WAIT_BEFORE|SYNC_FILE_RANGE_WRITE: ensures that all pages
> -  * in the range which were dirty on entry to sys_sync_file_range() are placed
> ++ * in the range which were dirty on entry to ksys_sync_file_range() are placed
>  + * under writeout.  This is a start-write-for-data-integrity operation.
>  + *
>  + * SYNC_FILE_RANGE_WRITE: start writeout of all dirty pages in the range which
>  + * are not presently under writeout.  This is an asynchronous flush-to-disk
>  + * operation.  Not suitable for data integrity operations.
>  + *
>  + * SYNC_FILE_RANGE_WAIT_BEFORE (or SYNC_FILE_RANGE_WAIT_AFTER): wait for
>  + * completion of writeout of all pages in the range.  This will be used after an
>  + * earlier SYNC_FILE_RANGE_WAIT_BEFORE|SYNC_FILE_RANGE_WRITE operation to wait
>  + * for that operation to complete and to return the result.
>  + *
> -  * SYNC_FILE_RANGE_WAIT_BEFORE|SYNC_FILE_RANGE_WRITE|SYNC_FILE_RANGE_WAIT_AFTER:
> ++ * SYNC_FILE_RANGE_WAIT_BEFORE|SYNC_FILE_RANGE_WRITE|SYNC_FILE_RANGE_WAIT_AFTER
> ++ * (a.k.a. SYNC_FILE_RANGE_WRITE_AND_WAIT):
>  + * a traditional sync() operation.  This is a write-for-data-integrity operation
>  + * which will ensure that all pages in the range which were dirty on entry to
> -  * sys_sync_file_range() are committed to disk.
> ++ * ksys_sync_file_range() are committed to disk.  It should be noted that disk
> ++ * caches are not flushed by this call, so there are no guarantees here that the
> ++ * data will be available on disk after a crash.
>  + *
>  + *
>  + * SYNC_FILE_RANGE_WAIT_BEFORE and SYNC_FILE_RANGE_WAIT_AFTER will detect any
>  + * I/O errors or ENOSPC conditions and will return those to the caller, after
>  + * clearing the EIO and ENOSPC flags in the address_space.
>  + *
>  + * It should be noted that none of these operations write out the file's
>  + * metadata.  So unless the application is strictly performing overwrites of
>  + * already-instantiated disk blocks, there are no guarantees here that the data
>  + * will be available after a crash.
>  + */
>  +int ksys_sync_file_range(int fd, loff_t offset, loff_t nbytes,
>  +                       unsigned int flags)
>  +{
>  +      int ret;
>  +      struct fd f;
>  +
>  +      ret = -EBADF;
>  +      f = fdget(fd);
>  +      if (f.file)
>  +              ret = sync_file_range(f.file, offset, nbytes, flags);
>  +
>  +      fdput(f);
>  +      return ret;
>  +}
>  +
>   SYSCALL_DEFINE4(sync_file_range, int, fd, loff_t, offset, loff_t, nbytes,
>                                 unsigned int, flags)
>   {

  reply	other threads:[~2019-05-03 12:35 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-03  9:10 linux-next: manual merge of the akpm-current tree with the block tree Stephen Rothwell
2019-05-03 12:35 ` Amir Goldstein [this message]
  -- strict thread matches above, loose matches on Subject: below --
2021-06-02  5:40 Stephen Rothwell
2021-04-07  9:18 Stephen Rothwell
2021-03-18  6:17 Stephen Rothwell
2021-03-18 17:54 ` Shakeel Butt
2021-03-18 18:19   ` Jens Axboe
2020-11-17  5:05 Stephen Rothwell
2020-10-15  6:27 Stephen Rothwell
2020-09-25  9:57 Stephen Rothwell
2018-10-02  7:21 Stephen Rothwell
2018-08-13  7:51 Stephen Rothwell
2018-08-02  8:31 Stephen Rothwell
2018-03-19  6:36 Stephen Rothwell
2016-07-13  6:14 Stephen Rothwell
2016-07-13 16:31 ` Jens Axboe
2015-12-07  8:12 Stephen Rothwell
2015-12-07 19:44 ` Andrew Morton
2015-12-07 20:24   ` Stephen Rothwell
2015-11-01 15:51 Stephen Rothwell
2015-11-01 16:04 ` kbuild test robot
2015-11-01 16:05 ` kbuild test robot
2015-11-01 18:38 ` Mel Gorman
2015-11-01 21:51   ` Stephen Rothwell
2015-01-21  7:14 Stephen Rothwell
2014-07-02  6:06 Stephen Rothwell
2013-11-05  6:29 Stephen Rothwell
2013-11-05  6:25 Stephen Rothwell

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='CAOQ4uxikyWj5DMcCLt6kVzLeQt8dg=wMvaXE5vOfbDLaNiqJnw@mail.gmail.com' \
    --to=amir73il@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=axboe@kernel.dk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=sfr@canb.auug.org.au \
    /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.