From: Al Viro <viro@ZenIV•linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation•org>
Cc: "Kirill A. Shutemov" <kirill@shutemov•name>,
Linux Kernel Mailing List <linux-kernel@vger•kernel.org>,
linux-fsdevel <linux-fsdevel@vger•kernel.org>,
Network Development <netdev@vger•kernel.org>
Subject: Re: [RFC] iov_iter_get_pages() semantics
Date: Wed, 1 Apr 2015 20:23:31 +0100 [thread overview]
Message-ID: <20150401192331.GB889@ZenIV.linux.org.uk> (raw)
In-Reply-To: <CA+55aFyP4C_x-SPLZZbJaSp6=_nJ01rVp1ABYg0kg_Boi4BfMQ@mail.gmail.com>
On Wed, Apr 01, 2015 at 11:15:17AM -0700, Linus Torvalds wrote:
> Seriously.
>
> If y9ou want an sg-table, how the hell do you know that some user
> won't be doing "get_page()" etc on the resulting pages?
>
> Answer: you don't. If you pass this off to networking or whatever,
> and it does some zero-copy thing, it may well be playing games with
> the 'struct page'. After all, that's why it exists in the first place.
>
> So no. You *MUST*NOT* turn random vmalloc space (or non-vmalloc space,
> for that matter) kernel mappings into struct page arrays. It's wrong.
> It's fundamentally invalid crap.
For non-vmalloc space you've just described sg_set_buf() (and sg_init_one(),
which is a wrapper for it)...
> If there are specific cases where it is valid, those specific cases
> need to be special-cased.
>
> NO WAY IN HELL do we add generic support for doing shit. Really. If p9
> does crazy crap, that is not an excuse to extend the crazy crap to
> more code.
OK... The scenario you've described might actually be a real bug in
net/p9 - I'm not familiar enough with virtio to tell. AFAICS, all it
wants with them is sg_phys() + length, which would be safe, but I could
easily be missing something...
Oh, well - virtio is already in somewhat incestous relationship with
iov_iter. I wonder if an analogue of virtqueue_add_sgs() that would
take iov_iter would be the right approach long-term...
Anyway, for now I'll just switch p9_client_{read,write}() to saner
calling conventions and let it look into iov_iter internals in that one
place (p9_get_mapped_pages()). For IOVEC_ITER case we can use
iov_iter_get_pages() there, for ITER_BVEC - pick the page from
iter->bvec->bv_page, for ITER_KVEC - take the first element of iter->kvec
and do that vmalloc_to_page()/virt_to_page() thing.
It's no worse than what we do right now, doesn't introduce new primitives
that would invite abuse and it allows to make things much simpler for
the rest of net/9p and for fs/9p...
next prev parent reply other threads:[~2015-04-01 19:23 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-04 20:20 [RFC][PATCHES] iov_iter.c rewrite Al Viro
2014-12-04 20:23 ` [RFC][PATCH 01/13] iov_iter.c: macros for iterating over iov_iter Al Viro
2014-12-04 20:23 ` [RFC][PATCH 02/13] iov_iter.c: iterate_and_advance Al Viro
2014-12-04 20:23 ` [RFC][PATCH 03/13] iov_iter.c: convert iov_iter_npages() to iterate_all_kinds Al Viro
2014-12-04 20:23 ` [RFC][PATCH 04/13] iov_iter.c: convert iov_iter_get_pages() " Al Viro
2014-12-04 20:23 ` [RFC][PATCH 05/13] iov_iter.c: convert iov_iter_get_pages_alloc() " Al Viro
2014-12-04 20:23 ` [RFC][PATCH 06/13] iov_iter.c: convert iov_iter_zero() to iterate_and_advance Al Viro
2014-12-04 20:23 ` [RFC][PATCH 07/13] iov_iter.c: get rid of bvec_copy_page_{to,from}_iter() Al Viro
2014-12-05 12:28 ` Sergei Shtylyov
2014-12-04 20:23 ` [RFC][PATCH 08/13] iov_iter.c: convert copy_from_iter() to iterate_and_advance Al Viro
2014-12-04 20:23 ` [RFC][PATCH 09/13] iov_iter.c: convert copy_to_iter() " Al Viro
2014-12-04 20:23 ` [RFC][PATCH 10/13] iov_iter.c: handle ITER_KVEC directly Al Viro
2014-12-04 20:23 ` [RFC][PATCH 11/13] csum_and_copy_..._iter() Al Viro
2014-12-04 20:23 ` [RFC][PATCH 12/13] new helper: iov_iter_kvec() Al Viro
2014-12-04 20:23 ` [RFC][PATCH 13/13] copy_from_iter_nocache() Al Viro
2014-12-08 16:46 ` [RFC][PATCHES] iov_iter.c rewrite Kirill A. Shutemov
2014-12-08 17:58 ` Al Viro
2014-12-08 18:08 ` Al Viro
2014-12-08 18:14 ` Linus Torvalds
2014-12-08 18:20 ` Al Viro
2014-12-08 18:37 ` Linus Torvalds
2014-12-08 18:46 ` Al Viro
2014-12-08 18:57 ` Linus Torvalds
2014-12-08 19:28 ` Al Viro
2014-12-08 19:48 ` Linus Torvalds
2014-12-09 1:56 ` Al Viro
2014-12-09 2:21 ` Kirill A. Shutemov
2015-04-01 2:33 ` [RFC] iov_iter_get_pages() semantics Al Viro
2015-04-01 16:45 ` Linus Torvalds
2015-04-01 18:08 ` Al Viro
2015-04-01 18:15 ` Linus Torvalds
2015-04-01 19:23 ` Al Viro [this message]
2015-04-01 18:26 ` Linus Torvalds
2015-04-01 18:34 ` Linus Torvalds
2015-04-01 20:15 ` Al Viro
2015-04-01 21:57 ` Linus Torvalds
2015-04-01 19:50 ` Al Viro
2014-12-08 18:56 ` [RFC][PATCHES] iov_iter.c rewrite Kirill A. Shutemov
2014-12-08 19:01 ` Linus Torvalds
2014-12-08 19:15 ` Dave Jones
2014-12-08 19:23 ` Kirill A. Shutemov
2014-12-08 22:14 ` Theodore Ts'o
2014-12-08 22:23 ` Linus Torvalds
2014-12-08 22:31 ` Dave Jones
2014-12-08 18:07 ` Linus Torvalds
2014-12-08 18:14 ` Al Viro
2014-12-08 18:23 ` Linus Torvalds
2014-12-08 18:35 ` Al Viro
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150401192331.GB889@ZenIV.linux.org.uk \
--to=viro@zeniv$(echo .)linux.org.uk \
--cc=kirill@shutemov$(echo .)name \
--cc=linux-fsdevel@vger$(echo .)kernel.org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=netdev@vger$(echo .)kernel.org \
--cc=torvalds@linux-foundation$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox