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][PATCHES] iov_iter.c rewrite
Date: Mon, 8 Dec 2014 18:35:42 +0000 [thread overview]
Message-ID: <20141208183539.GF22149@ZenIV.linux.org.uk> (raw)
In-Reply-To: <CA+55aFzKGsYKh1HALoeFGYQ46uMHww0WdLf5N-9duNTgMSSFxQ@mail.gmail.com>
On Mon, Dec 08, 2014 at 10:23:26AM -0800, Linus Torvalds wrote:
> Did this actually use to work? Or is it an issue of "the new iov_iter
> is so generic that something that used to just return an error now
> 'works' and triggers the problem"?
Looks like it failed with EINVAL. Which might very well be the sane
reaction - if we run into a vmalloc/module address, act as if we failed
to get that page and exit the loop.
> > What's the sane way to grab struct page * for a vmalloc'ed address?
>
> So "vmalloc_to_page()" should work.
>
> However, it's actually fundamentally racy unless you can guarantee
> that the vmalloc()'ed area in question is stable (so you had better
> have done that allocation yourself, and be in control of the freeing,
> rather than "we look up random vmalloc'ed addresses).
If vfree(buffer) races with kernel_read() into buffer, we are so badly
fucked that stability of pointers to pages is the least of our concerns...
> In general, it's really a horrible thing to use, and tends to be a big
> red sign that "somebody misdesigned this badly"
More like "nobody has thought of that case", at a guess, but then I hadn't
been involved in finit_module() design - I don't even remember the discussions
around it. That would be what, something circa 3.7?
prev parent reply other threads:[~2014-12-08 18:35 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
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 [this message]
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=20141208183539.GF22149@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=kirill@shutemov.name \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).