- 29 Oct, 2018 27 commits
-
-
Darrick J. Wong authored
Since xfs_file_remap_range is a thin wrapper, move the contents of xfs_reflink_remap_range into the shell. This cuts down on the vfs calls being made from internal xfs code. Signed-off-by:
Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by:
Dave Chinner <dchinner@redhat.com> Signed-off-by:
Dave Chinner <david@fromorbit.com>
-
Darrick J. Wong authored
Now that we've moved the partial EOF block checks to the VFS helpers, we can remove the redundant functionality from XFS. Signed-off-by:
-
Darrick J. Wong authored
Back when the XFS reflink code only supported clone_file_range, we were only able to return zero or negative error codes to userspace. However, now that copy_file_range (which returns bytes copied) can use XFS' clone_file_range, we have the opportunity to return partial results. For example, if userspace sends a 1GB clone request and we run out of space halfway through, we at least can tell userspace that we completed 512M of that request like a regular write. Signed-off-by:
-
Darrick J. Wong authored
Move the offset <-> blocks unit conversions into xfs_reflink_remap_blocks to make the call site less ugly. Signed-off-by:
-
Darrick J. Wong authored
Prior to remapping blocks, it is necessary to remove pages from the destination file's page cache. Unfortunately, the truncation is not aggressive enough -- if page size > block size, we'll end up zeroing subpage blocks instead of removing them. So, round the start offset down and the end offset up to page boundaries. We already wrote all the dirty data so the larger range shouldn't be a problem. Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Darrick J. Wong authored
Since ocfs2_remap_file_range is a thin shell around ocfs2_remap_remap_range, move everything from the latter into the former. Signed-off-by:
-
Darrick J. Wong authored
Change the ocfs2 remap code to allow for returning partial results. Signed-off-by:
-
Darrick J. Wong authored
Prior to remapping blocks, it is necessary to remove pages from the destination file's page cache. Unfortunately, the truncation is not aggressive enough -- if page size > block size, we'll end up zeroing subpage blocks instead of removing them. So, round the start offset down and the end offset up to page boundaries. We already wrote all the dirty data so the larger range should be fine. Signed-off-by:
-
Darrick J. Wong authored
When cloning blocks into another file, truncate the page cache before we start remapping blocks so that concurrent reads wait for us to finish. Signed-off-by:
-
Darrick J. Wong authored
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 authored
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:
Amir Goldstein <amir73il@gmail.com> Reviewed-by:
-
Darrick J. Wong authored
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 authored
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 authored
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 authored
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 ->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 authored
Extend generic_remap_file_range_prep to handle inode metadata updates when remapping into a file. If the operation can possibly alter the file contents, we must update the ctime and mtime and remove security privileges, just like we do for regular file writes. Signed-off-by:
-
Darrick J. Wong authored
Pass the same remap flags to generic_remap_checks for consistency. Signed-off-by:
-
Darrick J. Wong authored
Plumb the remap flags through the filesystem from the vfs function dispatcher all the way to the prep function to prepare for behavior changes in subsequent patches. Signed-off-by:
-
Darrick J. Wong authored
Combine the clone_file_range and dedupe_file_range operations into a single remap_file_range file operation dispatch since they're fundamentally the same operation. The differences between the two can be made in the prep functions. Signed-off-by:
-
Darrick J. Wong authored
Since we use clone_verify_area for both clone and dedupe range checks, rename the function to make it clear that it's for both. Signed-off-by:
-
Darrick J. Wong authored
The vfs_clone_file_prep is a generic function to be called by filesystem implementations only. Rename the prefix to generic_ and make it more clear that it applies to remap operations, not just clones. Signed-off-by:
-
Darrick J. Wong authored
Don't bother calling the filesystem for a zero-length dedupe request; we can return zero and exit. Signed-off-by:
-
Darrick J. Wong authored
A deduplication data corruption is exposed in XFS and btrfs. It is caused by extending the block match range to include the partial EOF block, but then allowing unknown data beyond EOF to be considered a "match" to data in the destination file because the comparison is only made to the end of the source file. This corrupts the destination file when the source extent is shared with it. The VFS remapping prep functions only support whole block dedupe, but we still need to appear to support whole file dedupe correctly. Hence if the dedupe request includes the last block of the souce file, don't include it in the actual dedupe operation. If the rest of the range dedupes successfully, then reject the entire request. A subsequent patch will enable us to shorten dedupe requests correctly. When reflinking sub-file ranges, a data corruption can occur when the source file range includes a partial EOF block. This shares the unknown data beyond EOF into the second file at a position inside EOF, exposing stale data in the second file. If the reflink request includes the last block of the souce file, only proceed with the reflink operation if it lands at or past the destination file's current EOF. If it lands within the destination file EOF, reject the entire request with -EINVAL and make the caller go the hard way. A subsequent patch will enable us to shorten reflink requests correctly. Signed-off-by:
-
Darrick J. Wong authored
File range remapping, if allowed to run past the destination file's EOF, is an optimization on a regular file write. Regular file writes that extend the file length are subject to various constraints which are not checked by range cloning. This is a correctness problem because we're never allowed to touch ranges that the page cache can't support (s_maxbytes); we're not supposed to deal with large offsets (MAX_NON_LFS) if O_LARGEFILE isn't set; and we must obey resource limits (RLIMIT_FSIZE). Therefore, add these checks to the new generic_remap_checks function so that we curtail unexpected behavior. Signed-off-by:
-
Darrick J. Wong authored
If a remap caller asks us to remap to the source file's EOF and the source file length leaves us with a zero byte request, exit early. Signed-off-by:
-
Darrick J. Wong authored
Move the file range checks from vfs_clone_file_prep into a separate generic_remap_checks function so that all the checks are collected in a central location. This forms the basis for adding more checks from generic_write_checks that will make cloning's input checking more consistent with write input checking. Signed-off-by:
-
Darrick J. Wong authored
vfs_clone_file_prep_inodes cannot return 0 if it is asked to remap from a zero byte file because that's what btrfs does. Signed-off-by:
-
- 22 Oct, 2018 8 commits
-
-
Greg Kroah-Hartman authored
-
Greg Kroah-Hartman authored
As I introduced these files, I'm willing to be the maintainer of them as well. Acked-by:
Chris Mason <clm@fb.com> Acked-by:
Olof Johansson <olof@lixom.net> Acked-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Acked-by:
Theodore Ts'o <tytso@mit.edu> Acked-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
The contact point for the kernel's Code of Conduct should now be the Code of Conduct Committee, not the full TAB. Change the email address in the file to properly reflect this. Acked-by:
-
Greg Kroah-Hartman authored
There was a blank <URL> reference for how to find the Code of Conduct Committee. Fix that up by pointing it to the correct kernel.org website page location. Acked-by:
-
Greg Kroah-Hartman authored
Create a link between the Code of Conduct and the Code of Conduct Interpretation so that people can see that they are related. Acked-by:
-
Greg Kroah-Hartman authored
We use the term "TAB" before defining it later in the document. Fix that up by defining it at the first location. Reported-by:
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Acked-by:
-
Greg Kroah-Hartman authored
Code of Conduct Interpretation: Add document explaining how the Code of Conduct is to be interpreted The Contributor Covenant Code of Conduct is a general document meant to provide a set of rules for almost any open source community. Every open-source community is unique and the Linux kernel is no exception. Because of this, this document describes how we in the Linux kernel community will interpret it. We also do not expect this interpretation to be static over time, and will adjust it as needed. This document was created with the input and feedback of the TAB as well as many current kernel maintainers. Co-Developed-by:
Alex Deucher <alexander.deucher@amd.com> Acked-by:
Alexei Starovoitov <ast@kernel.org> Acked-by:
Andrew Morton <akpm@linux-foundation.org> Acked-by:
Andy Lutomirski <luto@kernel.org> Acked-by:
Anna-Maria Gleixner <anna-maria@linutronix.de> Acked-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by:
Boris Brezillon <boris.brezillon@bootlin.com> Acked-by:
Borislav Petkov <bp@kernel.org> Acked-by:
Christian Lütke-Stetzkamp <christian@lkamp.de> Acked-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
Dan Williams <dan.j.williams@intel.com> Acked-by:
Daniel Borkmann <daniel@iogearbox.net> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by:
Dave Airlie <airlied@redhat.com> Acked-by:
Dave Hansen <dave.hansen@linux.intel.com> Acked-by:
David Ahern <dsa@cumulusnetworks.com> Acked-by:
David Sterba <kdave@kernel.org> Acked-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by:
Dominik Brodowski <linux@dominikbrodowski.de> Acked-by:
Eric Dumazet <eric.dumazet@gmail.com> Acked-by:
Felipe Balbi <balbi@kernel.org> Acked-by:
Felix Kuehling <Felix.Kuehling@amd.com> Acked-by:
Florian Fainelli <f.fainelli@gmail.com> Acked-by:
Geert Uytterhoeven <geert@linux-m68k.org> Acked-by:
Grant Likely <grant.likely@secretlab.ca> Acked-by:
Gregory CLEMENT <gregory.clement@bootlin.com> Acked-by:
Guenter Roeck <linux@roeck-us.net> Acked-by:
Gustavo A. R. Silva <gustavo@embeddedor.com> Acked-by:
Hans Verkuil <hverkuil@xs4all.nl> Acked-by:
Hans de Goede <j.w.r.degoede@gmail.com> Acked-by:
Harry Wentland <harry.wentland@amd.com> Acked-by:
Heiko Stuebner <heiko@sntech.de> Acked-by:
Ingo Molnar <mingo@kernel.org> Acked-by:
Jaegeuk Kim <jaegeuk@kernel.org> Acked-by:
James Smart <james.smart@broadcom.com> Acked-by:
James Smart <jsmart2021@gmail.com> Acked-by:
Jan Kara <jack@ucw.cz> Acked-by:
Jani Nikula <jani.nikula@intel.com> Acked-by:
Jason A. Donenfeld <Jason@zx2c4.com> Acked-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Acked-by:
Jens Axboe <axboe@kernel.dk> Acked-by:
Jessica Yu <jeyu@kernel.org> Acked-by:
Jia-Ju Bai <baijiaju1990@gmail.com> Acked-by:
Jiri Kosina <jikos@kernel.org> Acked-by:
Jiri Olsa <jolsa@redhat.com> Acked-by:
Joerg Roedel <joro@8bytes.org> Acked-by:
Johan Hovold <johan@kernel.org> Acked-by:
Johannes Thumshirn <jth@kernel.org> Acked-by:
Jonathan Corbet <corbet@lwn.net> Acked-by:
Julia Lawall <julia.lawall@lip6.fr> Acked-by:
Kees Cook <keescook@chromium.org> Acked-by:
Kirill Tkhai <ktkhai@virtuozzo.com> Acked-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by:
Lina Iyer <ilina@codeaurora.org> Acked-by:
Linus Torvalds <torvalds@linux-foundation.org> Acked-by:
Linus Walleij <linus.walleij@linaro.org> Acked-by:
Mark Brown <broonie@kernel.org> Acked-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by:
Masami Hiramatsu <mhiramat@kernel.org> Acked-by:
Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Acked-by:
Matias Bjørling <mb@lightnvm.io> Acked-by:
Mauro Carvalho Chehab <mchehab@kernel.org> Acked-by:
Maxime Ripard <maxime.ripard@bootlin.com> Acked-by:
Michael Ellerman <mpe@ellerman.id.au> Acked-by:
Mike Rapoport <rppt@linux.ibm.com> Acked-by:
Mimi Zohar <zohar@linux.ibm.com> Acked-by:
Miquel Raynal <miquel.raynal@bootlin.com> Acked-by:
Mishi Choudhary <mishi@linux.com> Acked-by:
Nikolay Borisov <n.borisov.lkml@gmail.com> Acked-by:
Oded Gabbay <oded.gabbay@gmail.com> Acked-by:
Palmer Dabbelt <palmer@dabbelt.com> Acked-by:
Paul E. McKenney <paulmck@linux.ibm.com> Acked-by:
Peter Zijlstra <peterz@infradead.org> Acked-by:
Rafael J. Wysocki <rafael@kernel.org> Acked-by:
Richard Weinberger <richard@nod.at> Acked-by:
Rik van Riel <riel@surriel.com> Acked-by:
Rob Clark <robdclark@gmail.com> Acked-by:
Rob Herring <robh@kernel.org> Acked-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by:
Sean Paul <sean@poorly.run> Acked-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Acked-by:
Sebastian Reichel <sre@kernel.org> Acked-by:
Sergio Paracuellos <sergio.paracuellos@gmail.com> Acked-by:
Shawn Guo <shawnguo@kernel.org> Acked-by:
Shuah Khan <shuah@kernel.org> Acked-by:
Simon Horman <horms@verge.net.au> Acked-by:
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Acked-by:
Stephen Hemminger <stephen@networkplumber.org> Acked-by:
Takashi Iwai <tiwai@kernel.org> Acked-by:
Tejun Heo <tj@kernel.org> Acked-by:
Thierry Reding <thierry.reding@gmail.com> Acked-by:
Todd Poynor <toddpoynor@google.com> Acked-by:
Viresh Kumar <viresh.kumar@linaro.org> Acked-by:
Wei Yongjun <weiyongjun1@huawei.com> Acked-by:
YueHaibing <yuehaibing@huawei.com> Reviewed-by:
-
Chris Mason authored
As it was originally worded, this paragraph requires maintainers to enforce the code of conduct, or face potential repercussions. It sends the wrong message, when really we just want maintainers to be part of the solution and not violate the code of conduct themselves. Removing it doesn't limit our ability to enforce the code of conduct, and we can still encourage maintainers to help maintain high standards for the level of discourse in their subsystem. Signed-off-by:
Florian Westphal <fw@strlen.de> Acked-by:
Tim Bird <tim.bird@sony.com> Acked-by:
Trond Myklebust <trond.myklebust@hammerspace.com> Acked-by:
-
- 21 Oct, 2018 3 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linuxGreg Kroah-Hartman authored
Wolfram writes: "i2c for 4.19 Another driver bugfix and MAINTAINERS addition from I2C." * 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: rcar: cleanup DMA for all kinds of failure MAINTAINERS: Add entry for Broadcom STB I2C controller
-
git://git.kernel.org/pub/scm/linux/kernel/git/davem/netGreg Kroah-Hartman authored
David writes: "Networking: A few straggler bug fixes: 1) Fix indexing of multi-pass dumps of ipv6 addresses, from David Ahern. 2) Revert RCU locking change for bonding netpoll, causes worse problems than it solves. 3) pskb_trim_rcsum_slow() doesn't handle odd trim offsets, resulting in erroneous bad hw checksum triggers with CHECKSUM_COMPLETE devices. From Dimitris Michailidis. 4) a revert to some neighbour code changes that adjust notifications in a way that confuses some apps." * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: Revert "neighbour: force neigh_invalidate when NUD_FAILED update is from admin" net/ipv6: Fix index counter for unicast addresses in in6_dump_addrs net: fix pskb_trim_rcsum_slow() with odd trim offset Revert "bond: take rcu lock in netpoll_send_skb_on_dev" -
Roopa Prabhu authored
This reverts commit 8e326289. This patch results in unnecessary netlink notification when one tries to delete a neigh entry already in NUD_FAILED state. Found this with a buggy app that tries to delete a NUD_FAILED entry repeatedly. While the notification issue can be fixed with more checks, adding more complexity here seems unnecessary. Also, recent tests with other changes in the neighbour code have shown that the INCOMPLETE and PROBE checks are good enough for the original issue. Signed-off-by:
Roopa Prabhu <roopa@cumulusnetworks.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- 20 Oct, 2018 2 commits
-
-
David Ahern authored
The loop wants to skip previously dumped addresses, so loops until current index >= saved index. If the message fills it wants to save the index for the next address to dump - ie., the one that did not fit in the current message. Currently, it is incrementing the index counter before comparing to the saved index, and then the saved index is off by 1 - it assumes the current address is going to fit in the message. Change the index handling to increment only after a succesful dump. Fixes: 502a2ffd ("ipv6: convert idev_list to list macros") Signed-off-by:
David Ahern <dsahern@gmail.com> Signed-off-by:
-
Wolfram Sang authored
DMA needs to be cleaned up not only on timeout, but on all errors where it has been setup before. Fixes: 73e8b052 ("i2c: rcar: add DMA support") Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de>
-
