[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YSk5/ebFimHTmIYn@zeniv-ca.linux.org.uk>
Date: Fri, 27 Aug 2021 19:16:13 +0000
From: Al Viro <viro@...iv.linux.org.uk>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Andreas Gruenbacher <agruenba@...hat.com>,
Christoph Hellwig <hch@...radead.org>,
"Darrick J. Wong" <djwong@...nel.org>, Jan Kara <jack@...e.cz>,
Matthew Wilcox <willy@...radead.org>,
cluster-devel <cluster-devel@...hat.com>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
ocfs2-devel@....oracle.com
Subject: Re: [PATCH v7 04/19] iov_iter: Turn iov_iter_fault_in_readable into
fault_in_iov_iter_readable
On Fri, Aug 27, 2021 at 11:57:19AM -0700, Linus Torvalds wrote:
> On Fri, Aug 27, 2021 at 11:53 AM Al Viro <viro@...iv.linux.org.uk> wrote:
> >
> > I really disagree with these calling conventions. "Number not faulted in"
> > is bloody useless
>
> It's what we already have for copy_to/from_user(), so it's actually
> consistent with that.
After copy_to/copy_from you've got the data copied and it's not going
anywhere. After fault-in you still have to copy, and it still can give
you less data than fault-in had succeeded for. So you must handle short
copies separately, no matter how much you've got from fault-in.
> And it avoids changing all the existing tests where people really
> cared only about the "everything ok" case.
The thing is, the checks tend to be wrong. We can't rely upon the full
fault-in to expect the full copy-in/copy-out, so the checks downstream
are impossible to avoid anyway. And fault-in failure is always a slow
path, so we are not saving time here.
And for the memory poisoining we end up aborting a copy potentially
a lot earlier than we should.
> Andreas' first patch did that changed version, and was ugly as hell.
>
> But if you have a version that avoids the ugliness...
I'll need to dig my notes out...
Powered by blists - more mailing lists