[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YL9UMk9SppN7Pk06@zeniv-ca.linux.org.uk>
Date: Tue, 8 Jun 2021 11:27:46 +0000
From: Al Viro <viro@...iv.linux.org.uk>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Christoph Hellwig <hch@...radead.org>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
David Sterba <dsterba@...e.com>,
Miklos Szeredi <miklos@...redi.hu>,
Anton Altaparmakov <anton@...era.com>,
David Howells <dhowells@...hat.com>,
Matthew Wilcox <willy@...radead.org>,
Pavel Begunkov <asml.silence@...il.com>
Subject: Re: [RFC][PATCHSET] iov_iter work
On Mon, Jun 07, 2021 at 04:35:46PM -0700, Linus Torvalds wrote:
> On Mon, Jun 7, 2021 at 3:01 PM Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
> >
> > (b) on all the common non-SET_FS architectures, kernel threads using
> > iov_iter_init() wouldn't work anyway, because on those architectures
> > it would always fill the thing in with an iov, not a kvec.
>
> Thinking more about this thing, I think it means that what we *should*
> do is simply just
>
> void iov_iter_init(struct iov_iter *i, unsigned int direction,
> const struct iovec *iov, unsigned long nr_segs,
> size_t count)
> {
> WARN_ON_ONCE(direction & ~(READ | WRITE));
> iWARN_ON_ONCE(uaccess_kernel());
> *i = (struct iov_iter) {
> .iter_type = ITER_IOVEC,
> .data_source = direction,
> .iov = iov,
> .nr_segs = nr_segs,
> .iov_offset = 0,
> .count = count
> };
> }
>
> because filling it with a kvec is simply wrong. It's wrong exactly due
> to the fact that *if* we have a kernel thread, all the modern
> non-SET_FS architectures will just ignore that entirely, and always
> use the iov meaning.
Updated and pushed out...
Powered by blists - more mailing lists