From: Al Viro <viro@ZenIV.linux.org.uk>
To: Mike Marshall <hubcap@omnibond.com>
Cc: Christoph Hellwig <hch@lst.de>,
Linus Torvalds <torvalds@linux-foundation.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Boaz Harrosh <ooo@electrozaur.com>,
Greg Kroah-Hartman <greg@kroah.com>
Subject: Re: [GIT PULL] Orangefs (text only resend)
Date: Sun, 6 Sep 2015 21:20:19 +0100 [thread overview]
Message-ID: <20150906202019.GJ22011@ZenIV.linux.org.uk> (raw)
In-Reply-To: <CAOg9mSQwVuEsZnawEyZ-wwZfrveSkv1hZ8CpbBX8OL9K+vbRmA@mail.gmail.com>
On Sun, Sep 06, 2015 at 10:52:16AM -0400, Mike Marshall wrote:
> int pvfs_bufmap_copy_to_user_iovec2(struct pvfs2_bufmap *bufmap,
> struct iov_iter *iter,
> size_t total_size,
> int buffer_index)
> {
> struct pvfs_bufmap_desc *from;
> int ret = 0; void *from_kaddr = NULL;
> from = &bufmap->desc_array[buffer_index];
>
> from_kaddr = pvfs2_kmap(from->page_array[0]);
> ret = copy_to_iter(from_kaddr, total_size, iter);
> return ret;
> }
Wrappers Are Evil: pvfs2_kmap(). It obfuscates the things for no reason
whatsoever, is actively wrong for a lot of reasons (kmap() slots are
system-wide resoure, and not too plentiful one, at that) _and_ obfuscates
the open-coding of existing primitive, badly: copy_page_to_iter()
does the same thing with less headache for caller and without a leak
(you forgot kunmap the damn thing afterwards).
> "cat filename" is a simple test that drives execution
> down the "Are we copying to User Virtual Addresses?"
> code path, and big and small files still copy
> out.
>
> I haven't found a test case that drives execution down
> the "Are we copying to Kern Virtual Addresses?" code
> path yet.
Ummm... GrepTFS? pvfs_bufmap_copy_to_kernel_iovec() called from
postcopy_buffers() when the last argument is 0, which is called from
wait_for_direct_io() in the same conditions plus the first argument being
PVFS_IO_READ. Said function has only two callers, one in do_readv_writev()
(the last argument is 1, out of consideration), another in pvfs2_inode_read().
Which does
+ ret = wait_for_direct_io(PVFS_IO_READ, inode, offset, &vec, 1,
+ count, readahead_size, 0);
which should hit pvfs_bufmap_copy_to_kernel_iovec() just fine...
Incidentally, it's misannotated -
+ssize_t pvfs2_inode_read(struct inode *inode,
+ char __user *buf,
+ size_t count,
+ loff_t *offset,
+ loff_t readahead_size)
+{
claims buf to be a userland pointer, while its only caller is passing
kmap(some page) there. This
bytes_read = pvfs2_inode_read(inode,
- page_data,
+ (char __user *) page_data,
blocksize,
&blockptr_offset,
in later commit forces sparce to STFU, but the point of __user annotations is
to be able to keep track which pointers are which, after all...
Oh, and to continue GTFS, the only caller of pvfs2_inode_read() appears
to be read_one_page(), called from pvfs2_readpage() and pvfs2_readpages(),
which are ->readpage() and ->readpages() methods in pvfs2_address_operations.
So I'd suggest trying to mmap and dereference. Or execve() of a binary
there...
BTW, this
+ /* map the pages */
+ down_write(¤t->mm->mmap_sem);
+ ret = get_user_pages(current,
+ current->mm,
+ (unsigned long)user_desc->ptr,
+ bufmap->page_count,
+ 1,
+ 0,
+ bufmap->page_array,
+ NULL);
+ up_write(¤t->mm->mmap_sem);
should almost certainly be replaced with
ret = get_user_pages_fast((unsigned long)user_desc->ptr,
bufmap->page_count, 1,bufmap->page_array);
and let it deal with ->mmap_sem.
next prev parent reply other threads:[~2015-09-06 20:20 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-01 15:42 [GIT PULL] Orangefs (text only resend) Mike Marshall
2015-09-02 23:34 ` Linus Torvalds
2015-09-03 1:13 ` Mike Marshall
2015-09-03 1:28 ` Linus Torvalds
2015-09-03 20:22 ` Linus Torvalds
2015-09-03 22:18 ` Mike Marshall
2015-09-03 22:44 ` Greg Kroah-Hartman
2015-09-06 6:35 ` Christoph Hellwig
2015-09-06 9:08 ` Al Viro
2015-09-06 14:52 ` Mike Marshall
2015-09-06 15:00 ` Mike Marshall
2015-09-06 20:20 ` Al Viro [this message]
2015-09-07 6:37 ` Al Viro
2015-09-07 21:10 ` Mike Marshall
2015-09-07 23:22 ` Al Viro
2015-09-08 0:47 ` Theodore Ts'o
2015-09-08 2:49 ` Dave Chinner
2015-09-08 14:48 ` Christoph Hellwig
2015-09-08 18:21 ` Mike Marshall
2015-09-09 15:05 ` Mike Marshall
2015-09-11 21:12 ` Mike Marshall
2015-09-11 22:24 ` Al Viro
2015-09-13 11:56 ` Mike Marshall
2015-09-11 23:20 ` Linus Torvalds
2015-09-13 11:59 ` Mike Marshall
2015-09-06 14:35 ` Mike Marshall
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=20150906202019.GJ22011@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=akpm@linux-foundation.org \
--cc=greg@kroah.com \
--cc=hch@lst.de \
--cc=hubcap@omnibond.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=ooo@electrozaur.com \
--cc=sfr@canb.auug.org.au \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.