Re: [PATCH 1/2] vfs: allow dedupe of user owned read-only files

On Fri, May 11, 2018 at 12:26:50PM -0700, Mark Fasheh wrote: > The permission check in vfs_dedupe_file_range() is too coarse - We > only allow dedupe of the destination file if the user is root, or > they have the file open for write. > > This effectively limits a non-root user from deduping their

Re: [PATCH 2/2] vfs: dedupe should return EPERM if permission is not granted

On Sat, May 12, 2018 at 3:06 AM, Darrick J. Wong wrote: > On Fri, May 11, 2018 at 12:26:51PM -0700, Mark Fasheh wrote: >> Right now we return EINVAL if a process does not have permission to dedupe a >> file. This was an oversight on my part. EPERM gives a true description of >> the nature of our e

Re: [PATCH 2/2] vfs: dedupe should return EPERM if permission is not granted

Darrick J. Wong posted on Fri, 11 May 2018 17:06:34 -0700 as excerpted: > On Fri, May 11, 2018 at 12:26:51PM -0700, Mark Fasheh wrote: >> Right now we return EINVAL if a process does not have permission to dedupe a >> file. This was an oversight on my part. EPERM gives a true description of >> the

"decompress failed" in 1-2 files always causes kernel oops, check/scrub pass

100% reproducible, booting from disk, or even Arch installation ISO. Kernel 4.16.7. btrfs-progs v4.16. Reading one of two journalctl files causes a kernel oops. Initially ran into it from "journalctl --list-boots", but cat'ing the file does it too. I believe this shows there's compressed data t

<    1   2