From: Adam Borowski <kilobyte@angband.pl>
To: Alexander Viro <viro@zeniv.linux.org.uk>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-btrfs@vger.kernel.org, Mark Fasheh <mfasheh@suse.de>,
"Darrick J . Wong" <darrick.wong@oracle.com>
Subject: Re: [PATCH] vfs: allow FILE_EXTENT_SAME (dedupe_file_range) on a file opened ro
Date: Mon, 18 Jul 2016 00:32:27 +0200 [thread overview]
Message-ID: <20160717223227.GA3212@angband.pl> (raw)
In-Reply-To: <1468793618-10496-1-git-send-email-kilobyte@angband.pl>
On Mon, Jul 18, 2016 at 12:13:38AM +0200, Adam Borowski wrote:
> Instead of checking the mode of the file descriptor, let's check whether it
> could have been opened rw. This allows fixing intermittent exec failures
> when deduping a live system: anyone trying to exec a file currently being
> deduped gets ETXTBSY.
>
> Issuing this ioctl on a ro file was already allowed for root/cap.
>
> Tested on btrfs and not-yet-merged xfs, as only them implement this ioctl.
This is a resend of a patch I've targetted at the wrong maintainer (btrfs
guys rather than Al Viro/vfs). Since then, I've tested it on xfs-devel
(f0b34b677df10d9e3deffcd0b1c1aaaaf0234b80 atop of 4.7-rc5 and -rc7).
Review so far:
http://thread.gmane.org/gmane.comp.file-systems.btrfs/56563
An idea to relax the check and allow dedupe to everyone who can read the
file was shot down because of concerns that in some edge cases it might be
possible to clobber a targetted file. Thus, we're back to the original
patch, requiring ro descriptor but rw permission.
Meow!
--
An imaginary friend squared is a real enemy.
next prev parent reply other threads:[~2016-07-17 22:32 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-17 22:13 Adam Borowski
2016-07-17 22:32 ` Adam Borowski [this message]
2016-07-18 19:51 ` Mark Fasheh
2016-07-19 2:41 ` Darrick J. Wong
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=20160717223227.GA3212@angband.pl \
--to=kilobyte@angband.pl \
--cc=darrick.wong@oracle.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mfasheh@suse.de \
--cc=viro@zeniv.linux.org.uk \
/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
all inboxes | Powered by JetHome®