RE: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c"
From: David Laight <hidden>
Date: 2020-10-21 20:59:51
Also in:
io-uring, keyrings, linux-arch, linux-arm-kernel, linux-block, linux-fsdevel, linux-mips, linux-s390, linux-scsi, linux-security-module, linuxppc-dev, lkml, sparclinux
From: Greg KH
Sent: 21 October 2020 17:13 On Fri, Sep 25, 2020 at 06:51:39AM +0200, Christoph Hellwig wrote:quoted
From: David Laight <redacted> This lets the compiler inline it into import_iovec() generating much better code. Signed-off-by: David Laight <redacted> Signed-off-by: Christoph Hellwig <hch@lst.de> --- fs/read_write.c | 179 ------------------------------------------------ lib/iov_iter.c | 176 +++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 176 insertions(+), 179 deletions(-)Strangely, this commit causes a regression in Linus's tree right now. I can't really figure out what the regression is, only that this commit triggers a "large Android system binary" from working properly. There's no kernel log messages anywhere, and I don't have any way to strace the thing in the testing framework, so any hints that people can provide would be most appreciated.
My original commit just moved the function source from one file to another. So it is odd that it makes any difference. I don't even know if it gets inlined by Christoph's actual patch. (I have another patch that depended on it that I need to resubmit.) Some of the other changes from Christoph's same patch set might make a difference though. Might be worth forcing it to be not inlined - so it is no change. Or try adding a kernel log to import_iovec() or the associated copy failing. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)