Re: ❌ FAIL: Test report for kernel 5.4.0-rc5-34072e5.cki (arm-next)
From: Will Deacon <will@kernel.org>
Date: 2019-10-31 11:26:50
On Thu, Oct 31, 2019 at 11:06:55AM +0000, Catalin Marinas wrote:
On Wed, Oct 30, 2019 at 03:08:36PM +0000, Robin Murphy wrote:quoted
quoted
quoted
quoted
On Wed, Oct 30, 2019 at 06:03:56AM -0400, Jan Stancek wrote:quoted
What's failing is preadv2/readv over PROT_NONE mapping: [pid 2424] mmap(NULL, 1, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0x3ff7f8b0000 [pid 2424] preadv2(3, [{iov_base=0x3ff7f8b0000, iov_len=64}], 1, 0, 0) = 16 Test expects EFAULT. It seems specific to arm64/linux.git as I do not see it fail on Linus' master (v5.4-rc5-34-g23fdb198ae81).[...]quoted
OK, what's up is that we designed the improved fixup logic to support offset addressing in the implicit context of the existing copy template, where accesses were always in strictly increasing order. And then we also plumbed in a clever new template which in certain cases does some out-of-order copying to support overlaps :( If a nonzero return from copy_*_user() is allowed to underestimate how many bytes were actually copied, then I think there should be a relatively simple fix; if it must always be exact, then I've got some more thinking to do...I think in various incarnations of the copy routines we always had some risk of underestimating. For example, we align the source but not the destination. The destination is written via STP post-indexed but if the second 64-bit write fails, we still report the copy based on the unmodified dst, so underestimating by 8 bytes.
I wonder if this could be an issue in general though. If, for example, we took a fault on the second page when crossing a page boundary, any "number of bytes copied" metric returned to userspace probably needs to identify the second page as the faulting one. Perhaps that works out because we only make naturally-aligned accesses, but I'm not super comfortable about the under-estimation. Do other architectures do that? Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel