<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/fs/read_write.c, branch v4.20</title>
<subtitle>Mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
</subtitle>
<id>https://git.shady.money/linux/atom?h=v4.20</id>
<link rel='self' href='https://git.shady.money/linux/atom?h=v4.20'/>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/'/>
<updated>2018-12-04T16:50:49Z</updated>
<entry>
<title>vfs: allow some remap flags to be passed to vfs_clone_file_range</title>
<updated>2018-12-04T16:50:49Z</updated>
<author>
<name>Darrick J. Wong</name>
<email>darrick.wong@oracle.com</email>
</author>
<published>2018-11-30T20:32:38Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=6744557b53a2b710ebce3736a5c27a0119685fcc'/>
<id>urn:sha1:6744557b53a2b710ebce3736a5c27a0119685fcc</id>
<content type='text'>
In overlayfs, ovl_remap_file_range calls vfs_clone_file_range on the
lower filesystem's inode, passing through whatever remap flags it got
from its caller.  Since vfs_copy_file_range first tries a filesystem's
remap function with REMAP_FILE_CAN_SHORTEN, this can get passed through
to the second vfs_copy_file_range call, and this isn't an issue.
Change the WARN_ON to look only for the DEDUP flag.

Signed-off-by: Darrick J. Wong &lt;darrick.wong@oracle.com&gt;
Reviewed-by: Amir Goldstein &lt;amir73il@gmail.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
</content>
</entry>
<entry>
<title>vfs: vfs_dedupe_file_range() doesn't return EOPNOTSUPP</title>
<updated>2018-11-21T18:10:54Z</updated>
<author>
<name>Dave Chinner</name>
<email>dchinner@redhat.com</email>
</author>
<published>2018-11-19T21:31:12Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=494633fac7896afc2bce6f83fe7319946270540b'/>
<id>urn:sha1:494633fac7896afc2bce6f83fe7319946270540b</id>
<content type='text'>
It returns EINVAL when the operation is not supported by the
filesystem. Fix it to return EOPNOTSUPP to be consistent with
the man page and clone_file_range().

Clean up the inconsistent error return handling while I'm there.
(I know, lipstick on a pig, but every little bit helps...)

Signed-off-by: Dave Chinner &lt;dchinner@redhat.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed-by: Darrick J. Wong &lt;darrick.wong@oracle.com&gt;
Signed-off-by: Darrick J. Wong &lt;darrick.wong@oracle.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'xfs-4.20-merge-2' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux</title>
<updated>2018-11-02T16:33:08Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2018-11-02T16:33:08Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=c2aa1a444cab2c673650ada80a7dffc4345ce2e6'/>
<id>urn:sha1:c2aa1a444cab2c673650ada80a7dffc4345ce2e6</id>
<content type='text'>
Pull vfs dedup fixes from Dave Chinner:
 "This reworks the vfs data cloning infrastructure.

  We discovered many issues with these interfaces late in the 4.19 cycle
  - the worst of them (data corruption, setuid stripping) were fixed for
  XFS in 4.19-rc8, but a larger rework of the infrastructure fixing all
  the problems was needed. That rework is the contents of this pull
  request.

  Rework the vfs_clone_file_range and vfs_dedupe_file_range
  infrastructure to use a common .remap_file_range method and supply
  generic bounds and sanity checking functions that are shared with the
  data write path. The current VFS infrastructure has problems with
  rlimit, LFS file sizes, file time stamps, maximum filesystem file
  sizes, stripping setuid bits, etc and so they are addressed in these
  commits.

  We also introduce the ability for the -&gt;remap_file_range methods to
  return short clones so that clones for vfs_copy_file_range() don't get
  rejected if the entire range can't be cloned. It also allows
  filesystems to sliently skip deduplication of partial EOF blocks if
  they are not capable of doing so without requiring errors to be thrown
  to userspace.

  Existing filesystems are converted to user the new remap_file_range
  method, and both XFS and ocfs2 are modified to make use of the new
  generic checking infrastructure"

* tag 'xfs-4.20-merge-2' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux: (28 commits)
  xfs: remove [cm]time update from reflink calls
  xfs: remove xfs_reflink_remap_range
  xfs: remove redundant remap partial EOF block checks
  xfs: support returning partial reflink results
  xfs: clean up xfs_reflink_remap_blocks call site
  xfs: fix pagecache truncation prior to reflink
  ocfs2: remove ocfs2_reflink_remap_range
  ocfs2: support partial clone range and dedupe range
  ocfs2: fix pagecache truncation prior to reflink
  ocfs2: truncate page cache for clone destination file before remapping
  vfs: clean up generic_remap_file_range_prep return value
  vfs: hide file range comparison function
  vfs: enable remap callers that can handle short operations
  vfs: plumb remap flags through the vfs dedupe functions
  vfs: plumb remap flags through the vfs clone functions
  vfs: make remap_file_range functions take and return bytes completed
  vfs: remap helper should update destination inode metadata
  vfs: pass remap flags to generic_remap_checks
  vfs: pass remap flags to generic_remap_file_range_prep
  vfs: combine the clone and dedupe into a single remap_file_range
  ...
</content>
</entry>
<entry>
<title>Merge branch 'work.misc' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs</title>
<updated>2018-11-02T03:19:49Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2018-11-02T03:19:49Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=8adcc59974b8a65b7eac7d503364837c297139bc'/>
<id>urn:sha1:8adcc59974b8a65b7eac7d503364837c297139bc</id>
<content type='text'>
Pull misc vfs updates from Al Viro:
 "No common topic, really - a handful of assorted stuff; the least
  trivial bits are Mark's dedupe patches"

* 'work.misc' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
  fs/exofs: only use true/false for asignment of bool type variable
  fs/exofs: fix potential memory leak in mount option parsing
  Delete invalid assignment statements in do_sendfile
  iomap: remove duplicated include from iomap.c
  vfs: dedupe should return EPERM if permission is not granted
  vfs: allow dedupe of user owned read-only files
  ntfs: don't open-code ERR_CAST
  ext4: don't open-code ERR_CAST
</content>
</entry>
<entry>
<title>vfs: clean up generic_remap_file_range_prep return value</title>
<updated>2018-10-29T23:42:24Z</updated>
<author>
<name>Darrick J. Wong</name>
<email>darrick.wong@oracle.com</email>
</author>
<published>2018-10-29T23:42:24Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=8c5c836bd6c3b9f9fc1c5a210d630b8c42f4f7df'/>
<id>urn:sha1:8c5c836bd6c3b9f9fc1c5a210d630b8c42f4f7df</id>
<content type='text'>
Since the remap prep function can update the length of the remap
request, we can change this function to return the usual return status
instead of the odd behavior it has now.

Signed-off-by: Darrick J. Wong &lt;darrick.wong@oracle.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Dave Chinner &lt;david@fromorbit.com&gt;

</content>
</entry>
<entry>
<title>vfs: hide file range comparison function</title>
<updated>2018-10-29T23:42:17Z</updated>
<author>
<name>Darrick J. Wong</name>
<email>darrick.wong@oracle.com</email>
</author>
<published>2018-10-29T23:42:17Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=c32e5f39953fa6bbff35c655bdcb7b3128f1e79f'/>
<id>urn:sha1:c32e5f39953fa6bbff35c655bdcb7b3128f1e79f</id>
<content type='text'>
There are no callers of vfs_dedupe_file_range_compare, so we might as
well make it a static helper and remove the export.

Signed-off-by: Darrick J. Wong &lt;darrick.wong@oracle.com&gt;
Reviewed-by: Amir Goldstein &lt;amir73il@gmail.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Dave Chinner &lt;david@fromorbit.com&gt;

</content>
</entry>
<entry>
<title>vfs: enable remap callers that can handle short operations</title>
<updated>2018-10-29T23:42:10Z</updated>
<author>
<name>Darrick J. Wong</name>
<email>darrick.wong@oracle.com</email>
</author>
<published>2018-10-29T23:42:10Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=eca3654e3cc7d93e9734d0fa96cfb15c7f356244'/>
<id>urn:sha1:eca3654e3cc7d93e9734d0fa96cfb15c7f356244</id>
<content type='text'>
Plumb in a remap flag that enables the filesystem remap handler to
shorten remapping requests for callers that can handle it.  Now
copy_file_range can report partial success (in case we run up against
alignment problems, resource limits, etc.).

We also enable CAN_SHORTEN for fideduperange to maintain existing
userspace-visible behavior where xfs/btrfs shorten the dedupe range to
avoid stale post-eof data exposure.

Signed-off-by: Darrick J. Wong &lt;darrick.wong@oracle.com&gt;
Reviewed-by: Amir Goldstein &lt;amir73il@gmail.com&gt;
Signed-off-by: Dave Chinner &lt;david@fromorbit.com&gt;

</content>
</entry>
<entry>
<title>vfs: plumb remap flags through the vfs dedupe functions</title>
<updated>2018-10-29T23:42:03Z</updated>
<author>
<name>Darrick J. Wong</name>
<email>darrick.wong@oracle.com</email>
</author>
<published>2018-10-29T23:42:03Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=df3658361951e17364f1e1c3fa92862a990ad8bd'/>
<id>urn:sha1:df3658361951e17364f1e1c3fa92862a990ad8bd</id>
<content type='text'>
Plumb a remap_flags argument through the vfs_dedupe_file_range_one
functions so that dedupe can take advantage of it.

Signed-off-by: Darrick J. Wong &lt;darrick.wong@oracle.com&gt;
Reviewed-by: Amir Goldstein &lt;amir73il@gmail.com&gt;
Signed-off-by: Dave Chinner &lt;david@fromorbit.com&gt;

</content>
</entry>
<entry>
<title>vfs: plumb remap flags through the vfs clone functions</title>
<updated>2018-10-29T23:41:56Z</updated>
<author>
<name>Darrick J. Wong</name>
<email>darrick.wong@oracle.com</email>
</author>
<published>2018-10-29T23:41:56Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=452ce65951a2f0719e4e119ecca134c06cfe22ee'/>
<id>urn:sha1:452ce65951a2f0719e4e119ecca134c06cfe22ee</id>
<content type='text'>
Plumb a remap_flags argument through the {do,vfs}_clone_file_range
functions so that clone can take advantage of it.

Signed-off-by: Darrick J. Wong &lt;darrick.wong@oracle.com&gt;
Reviewed-by: Amir Goldstein &lt;amir73il@gmail.com&gt;
Signed-off-by: Dave Chinner &lt;david@fromorbit.com&gt;

</content>
</entry>
<entry>
<title>vfs: make remap_file_range functions take and return bytes completed</title>
<updated>2018-10-29T23:41:49Z</updated>
<author>
<name>Darrick J. Wong</name>
<email>darrick.wong@oracle.com</email>
</author>
<published>2018-10-29T23:41:49Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=42ec3d4c02187a18e27ff94b409ec27234bf2ffd'/>
<id>urn:sha1:42ec3d4c02187a18e27ff94b409ec27234bf2ffd</id>
<content type='text'>
Change the remap_file_range functions to take a number of bytes to
operate upon and return the number of bytes they operated on.  This is a
requirement for allowing fs implementations to return short clone/dedupe
results to the user, which will enable us to obey resource limits in a
graceful manner.

A subsequent patch will enable copy_file_range to signal to the
-&gt;clone_file_range implementation that it can handle a short length,
which will be returned in the function's return value.  For now the
short return is not implemented anywhere so the behavior won't change --
either copy_file_range manages to clone the entire range or it tries an
alternative.

Neither clone ioctl can take advantage of this, alas.

Signed-off-by: Darrick J. Wong &lt;darrick.wong@oracle.com&gt;
Reviewed-by: Amir Goldstein &lt;amir73il@gmail.com&gt;
Signed-off-by: Dave Chinner &lt;david@fromorbit.com&gt;

</content>
</entry>
</feed>
