On Mon, Jun 10, 2019 at 07:54:52PM +0300, Amir Goldstein wrote: > On Mon, Jun 10, 2019 at 7:06 PM Darrick J. Wong <darrick.wong@xxxxxxxxxx> wrote: > > > > On Mon, Jun 10, 2019 at 09:31:31AM -0400, Theodore Ts'o wrote: > > > On Mon, Jun 10, 2019 at 09:37:32AM +0300, Amir Goldstein wrote: > > > > > > > >Why do you think thhis is xfs_io fall back and not kernel fall back to > > > >do_splice_direct()? Anyway, both cases allow read from swapfile > > > >on upstream. > > > > > > Ah, I had assumed this was changed that was made because if you are > > > implementing copy_file_range in terms of some kind of reflink-like > > > mechanism, it becomes super-messy since you know have to break tons > > > and tons of COW sharing each time the kernel swaps to the swap file. > > > > > > I didn't think we had (or maybe we did, and I missed it) a discussion > > > about whether reading from a swap file should be prohibited. > > > Personally, I think it's security theatre, and not worth the > > > effort/overhead, but whatever.... my main complaint was with the > > > unnecessary test failures with upstream kernels. > > > > > > > Trying to understand the desired flow of tests and fixes. > > > > I agree that generic/554 failure may be a test/interface bug that > > > > we should fix in a way that current upstream passes the test for > > > > ext4. Unless there is objection, I will send a patch to fix the test > > > > to only test copy *to* swapfile. > > > > > > > > generic/553, OTOH, is expected to fail on upstream kernel. > > > > Are you leaving 553 in appliance build in anticipation to upstream fix? > > > > I guess the answer is in the ext4 IS_IMMUTABLE patch that you > > > > posted and plan to push to upstream/stable sooner than VFS patches. > > > > > > So I find it kind of annoying when tests land before the fixes do > > > upstream. I still have this in my global_exclude file: > > > > Yeah, it's awkward for VFS fixes because on the one hand we don't want > > to have multiyear regressions like generic/484, but OTOH stuffing tests > > in before code goes upstream enables broader testing by the other fs > > maintainers. > > And to prove this point, Ted pointed out a test bug in 554, which also > affects the kernel and man pages fixes, so it was really worth it ;-) :D > > > > In any case, the fixes are in the copy-range-fixes branch which I'm > > finally publishing... > > > > > # The proposed fix for generic/484, "locks: change POSIX lock > > > # ownership on execve when files_struct is displaced" would break NFS > > > # Jeff Layton and Eric Biederman have some ideas for how to address it > > > # but fixing it is non-trivial > > > > Also, uh, can we remove this from the auto and quick groups for now? > > > > I am not opposed to removing these test from auto,quick, although removing > from quick is a bit shady. I would like to mark them explicitly with group > known_issues, so that users can run ./check -g quick -x known_issues. > BTW, overlay/061 is also a known_issue that is going to be hard to fix. > > But anyway, neither 553 nor 554 fall into that category. Sorry, I was unclear -- I was asking to remove g/484 from auto/quick. --D > Thanks, > Amir.
