From: Al Viro <viro@ZenIV.linux.org.uk> To: Miklos Szeredi <miklos@szeredi.hu> Cc: Linus Torvalds <torvalds@linux-foundation.org>, Dave Chinner <david@fromorbit.com>, CAI Qian <caiqian@redhat.com>, linux-xfs <linux-xfs@vger.kernel.org>, xfs@oss.sgi.com, Jens Axboe <axboe@kernel.dk>, Nick Piggin <npiggin@gmail.com>, linux-fsdevel <linux-fsdevel@vger.kernel.org> Subject: Re: [PATCH 10/12] new iov_iter flavour: pipe-backed Date: Thu, 29 Sep 2016 23:50:03 +0100 [thread overview] Message-ID: <20160929225003.GQ19539@ZenIV.linux.org.uk> (raw) In-Reply-To: <CAELBmZDpm635PcTPQfnpLGs2P4bfT6JU+DEuFu9pBut=uzOLHw@mail.gmail.com> On Thu, Sep 29, 2016 at 10:53:55PM +0200, Miklos Szeredi wrote: > The EFAULT logic seems to be missing across the board. And callers > don't expect a zero return value. Most will loop indefinitely. Nope. copy_page_to_iter() *never* returns -EFAULT. Including the iovec one - check copy_page_to_iter_iovec(). Any caller that does not expect a zero return value from that primitive is a bug, triggerable as soon as you feed it an iovec with NULL ->iov_base. > Again, unexpected zero return if this is the first page. Should > return -ENOMEM? Some callers only expect -EFAULT, though. For copy_to_iter() and zero_iter() it's definitely "return zero". For get_pages... Hell knows; those probably ought to return -EFAULT, but I'll need to look some more at the callers. It should end up triggering a short read as the end result (or, as usual, EFAULT on zero-length read). > > + /* take it relative to the beginning of buffer */ > > + size += off - pipe->bufs[idx].offset; > > + while (1) { > > + buf = &pipe->bufs[idx]; > > + if (size > buf->len) { > > + size -= buf->len; > > + idx = next_idx(idx, pipe); > > + off = 0; > > off is unused and reassigned before breaking out of the loop. True. > [...] > > > + if (unlikely(i->type & ITER_PIPE)) { > > + struct pipe_inode_info *pipe = i->pipe; > > + size_t off; > > + int idx; > > + > > + if (!sanity(i)) > > + return 0; > > + > > + data_start(i, &idx, &off); > > + /* some of this one + all after this one */ > > + npages = ((pipe->curbuf - idx - 1) & (pipe->buffers - 1)) + 1; > > It's supposed to take i->count into account, no? And that calculation > will result in really funny things if the pipe is full. And we can't > return -EFAULT here, since that's not expected by callers... It should look at i->count, in principle. OTOH, overestimating the amount is not really a problem for possible users of such iov_iter. I'll look into that.
WARNING: multiple messages have this Message-ID (diff)
From: Al Viro <viro@ZenIV.linux.org.uk> To: Miklos Szeredi <miklos@szeredi.hu> Cc: Jens Axboe <axboe@kernel.dk>, CAI Qian <caiqian@redhat.com>, Nick Piggin <npiggin@gmail.com>, xfs@oss.sgi.com, linux-xfs <linux-xfs@vger.kernel.org>, linux-fsdevel <linux-fsdevel@vger.kernel.org>, Linus Torvalds <torvalds@linux-foundation.org> Subject: Re: [PATCH 10/12] new iov_iter flavour: pipe-backed Date: Thu, 29 Sep 2016 23:50:03 +0100 [thread overview] Message-ID: <20160929225003.GQ19539@ZenIV.linux.org.uk> (raw) In-Reply-To: <CAELBmZDpm635PcTPQfnpLGs2P4bfT6JU+DEuFu9pBut=uzOLHw@mail.gmail.com> On Thu, Sep 29, 2016 at 10:53:55PM +0200, Miklos Szeredi wrote: > The EFAULT logic seems to be missing across the board. And callers > don't expect a zero return value. Most will loop indefinitely. Nope. copy_page_to_iter() *never* returns -EFAULT. Including the iovec one - check copy_page_to_iter_iovec(). Any caller that does not expect a zero return value from that primitive is a bug, triggerable as soon as you feed it an iovec with NULL ->iov_base. > Again, unexpected zero return if this is the first page. Should > return -ENOMEM? Some callers only expect -EFAULT, though. For copy_to_iter() and zero_iter() it's definitely "return zero". For get_pages... Hell knows; those probably ought to return -EFAULT, but I'll need to look some more at the callers. It should end up triggering a short read as the end result (or, as usual, EFAULT on zero-length read). > > + /* take it relative to the beginning of buffer */ > > + size += off - pipe->bufs[idx].offset; > > + while (1) { > > + buf = &pipe->bufs[idx]; > > + if (size > buf->len) { > > + size -= buf->len; > > + idx = next_idx(idx, pipe); > > + off = 0; > > off is unused and reassigned before breaking out of the loop. True. > [...] > > > + if (unlikely(i->type & ITER_PIPE)) { > > + struct pipe_inode_info *pipe = i->pipe; > > + size_t off; > > + int idx; > > + > > + if (!sanity(i)) > > + return 0; > > + > > + data_start(i, &idx, &off); > > + /* some of this one + all after this one */ > > + npages = ((pipe->curbuf - idx - 1) & (pipe->buffers - 1)) + 1; > > It's supposed to take i->count into account, no? And that calculation > will result in really funny things if the pipe is full. And we can't > return -EFAULT here, since that's not expected by callers... It should look at i->count, in principle. OTOH, overestimating the amount is not really a problem for possible users of such iov_iter. I'll look into that. _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2016-09-29 22:50 UTC|newest] Thread overview: 152+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <723420070.1340881.1472835555274.JavaMail.zimbra@redhat.com> [not found] ` <1832555471.1341372.1472835736236.JavaMail.zimbra@redhat.com> 2016-09-03 0:39 ` xfs_file_splice_read: possible circular locking dependency detected Dave Chinner 2016-09-03 0:57 ` Linus Torvalds 2016-09-03 1:45 ` Al Viro 2016-09-06 23:59 ` Dave Chinner 2016-09-08 20:35 ` Al Viro 2016-09-06 21:53 ` CAI Qian 2016-09-06 23:34 ` Dave Chinner 2016-09-08 15:29 ` CAI Qian 2016-09-08 17:56 ` Al Viro 2016-09-08 18:12 ` Linus Torvalds 2016-09-08 18:18 ` Linus Torvalds 2016-09-08 20:44 ` Al Viro 2016-09-08 20:57 ` Al Viro 2016-09-08 21:23 ` Al Viro 2016-09-08 21:38 ` Dave Chinner 2016-09-08 23:55 ` Al Viro 2016-09-09 1:53 ` Dave Chinner 2016-09-09 2:22 ` Linus Torvalds 2016-09-09 2:26 ` Linus Torvalds 2016-09-09 2:34 ` Al Viro 2016-09-09 2:50 ` Linus Torvalds 2016-09-09 22:19 ` Al Viro 2016-09-10 2:06 ` Linus Torvalds 2016-09-14 3:16 ` Al Viro 2016-09-14 3:39 ` Nicholas Piggin 2016-09-14 4:01 ` Linus Torvalds 2016-09-18 5:33 ` Al Viro 2016-09-19 3:08 ` Nicholas Piggin 2016-09-19 6:11 ` Al Viro 2016-09-19 7:26 ` Nicholas Piggin 2016-09-14 3:49 ` Linus Torvalds 2016-09-14 4:26 ` Al Viro 2016-09-17 8:20 ` Al Viro 2016-09-17 19:00 ` Al Viro 2016-09-17 20:15 ` Linus Torvalds 2016-09-18 19:31 ` skb_splice_bits() and large chunks in pipe (was " Al Viro 2016-09-18 20:12 ` Linus Torvalds 2016-09-18 22:31 ` Al Viro 2016-09-19 0:18 ` Linus Torvalds 2016-09-19 0:22 ` Al Viro 2016-09-19 0:22 ` Al Viro 2016-09-20 9:51 ` Herbert Xu 2016-09-23 19:00 ` [RFC][CFT] splice_read reworked Al Viro 2016-09-23 19:01 ` [PATCH 01/11] fix memory leaks in tracing_buffers_splice_read() Al Viro 2016-09-23 19:02 ` [PATCH 02/11] splice_to_pipe(): don't open-code wakeup_pipe_readers() Al Viro 2016-09-23 19:02 ` [PATCH 03/11] splice: switch get_iovec_page_array() to iov_iter Al Viro 2016-09-23 19:02 ` Al Viro 2016-09-23 19:03 ` [PATCH 04/11] splice: lift pipe_lock out of splice_to_pipe() Al Viro 2016-09-23 19:45 ` Linus Torvalds 2016-09-23 20:10 ` Al Viro 2016-09-23 20:36 ` Linus Torvalds 2016-09-24 3:59 ` Al Viro 2016-09-24 17:29 ` Al Viro 2016-09-27 15:38 ` Nicholas Piggin 2016-09-27 15:53 ` Chuck Lever 2016-09-27 15:53 ` Chuck Lever 2016-09-24 3:59 ` [PATCH 04/12] " Al Viro 2016-09-26 13:35 ` Miklos Szeredi 2016-09-26 13:35 ` Miklos Szeredi 2016-09-27 4:14 ` Al Viro 2016-09-27 4:14 ` Al Viro 2016-12-17 19:54 ` Andreas Schwab 2016-12-18 19:28 ` Linus Torvalds 2016-12-18 19:57 ` Andreas Schwab 2016-12-18 20:12 ` Al Viro 2016-12-18 20:30 ` Al Viro 2016-12-18 22:10 ` Linus Torvalds 2016-12-18 22:18 ` Al Viro 2016-12-18 22:22 ` Linus Torvalds 2016-12-18 22:49 ` Andreas Schwab 2016-12-21 18:56 ` Andreas Schwab 2016-12-21 19:12 ` Linus Torvalds 2016-09-24 4:00 ` [PATCH 06/12] new helper: add_to_pipe() Al Viro 2016-09-26 13:49 ` Miklos Szeredi 2016-09-24 4:01 ` [PATCH 10/12] new iov_iter flavour: pipe-backed Al Viro 2016-09-29 20:53 ` Miklos Szeredi 2016-09-29 22:50 ` Al Viro [this message] 2016-09-29 22:50 ` Al Viro 2016-09-30 7:30 ` Miklos Szeredi 2016-10-03 3:34 ` [RFC] O_DIRECT vs EFAULT (was Re: [PATCH 10/12] new iov_iter flavour: pipe-backed) Al Viro 2016-10-03 17:07 ` Linus Torvalds 2016-10-03 18:54 ` Al Viro 2016-09-24 4:01 ` [PATCH 11/12] switch generic_file_splice_read() to use of ->read_iter() Al Viro 2016-09-24 4:02 ` [PATCH 12/12] switch default_file_splice_read() to use of pipe-backed iov_iter Al Viro 2016-09-23 19:03 ` [PATCH 05/11] skb_splice_bits(): get rid of callback Al Viro 2016-09-23 19:03 ` Al Viro 2016-09-23 19:04 ` [PATCH 06/11] new helper: add_to_pipe() Al Viro 2016-09-23 19:04 ` [PATCH 07/11] fuse_dev_splice_read(): switch to add_to_pipe() Al Viro 2016-09-23 19:06 ` [PATCH 08/11] cifs: don't use memcpy() to copy struct iov_iter Al Viro 2016-09-23 19:08 ` [PATCH 09/11] fuse_ioctl_copy_user(): don't open-code copy_page_{to,from}_iter() Al Viro 2016-09-26 9:31 ` Miklos Szeredi 2016-09-23 19:09 ` [PATCH 10/11] new iov_iter flavour: pipe-backed Al Viro 2016-09-23 19:10 ` [PATCH 11/11] switch generic_file_splice_read() to use of ->read_iter() Al Viro 2016-09-30 13:32 ` [RFC][CFT] splice_read reworked CAI Qian 2016-09-30 17:42 ` CAI Qian 2016-09-30 18:33 ` CAI Qian 2016-09-30 18:33 ` CAI Qian 2016-10-03 1:37 ` Al Viro 2016-10-03 17:49 ` CAI Qian 2016-10-04 17:39 ` local DoS - systemd hang or timeout (WAS: Re: [RFC][CFT] splice_read reworked) CAI Qian 2016-10-04 21:42 ` tj 2016-10-05 14:09 ` CAI Qian 2016-10-05 15:30 ` tj 2016-10-05 15:54 ` CAI Qian 2016-10-05 18:57 ` CAI Qian 2016-10-05 20:05 ` Al Viro 2016-10-06 12:20 ` CAI Qian 2016-10-06 12:25 ` CAI Qian 2016-10-06 16:11 ` CAI Qian 2016-10-06 17:00 ` Linus Torvalds 2016-10-06 18:12 ` CAI Qian 2016-10-07 9:57 ` Dave Chinner 2016-10-07 15:25 ` Linus Torvalds 2016-10-07 7:08 ` Jan Kara 2016-10-07 14:43 ` CAI Qian 2016-10-07 15:27 ` CAI Qian 2016-10-07 18:56 ` CAI Qian 2016-10-09 21:54 ` Dave Chinner 2016-10-10 14:10 ` CAI Qian 2016-10-10 20:14 ` CAI Qian 2016-10-10 21:57 ` Dave Chinner 2016-10-12 19:50 ` [bisected] " CAI Qian 2016-10-12 20:59 ` Dave Chinner 2016-10-13 16:25 ` CAI Qian 2016-10-13 20:49 ` Dave Chinner 2016-10-13 20:56 ` CAI Qian 2016-10-09 21:51 ` Dave Chinner 2016-10-21 15:38 ` [4.9-rc1+] overlayfs lockdep CAI Qian 2016-10-24 12:57 ` Miklos Szeredi 2016-10-07 9:27 ` local DoS - systemd hang or timeout (WAS: Re: [RFC][CFT] splice_read reworked) Dave Chinner 2016-10-27 12:52 ` local DoS - systemd hang or timeout with cgroup traces CAI Qian 2016-10-03 1:42 ` [RFC][CFT] splice_read reworked Al Viro 2016-10-03 14:06 ` CAI Qian 2016-10-03 15:20 ` CAI Qian 2016-10-03 21:12 ` Dave Chinner 2016-10-04 13:57 ` CAI Qian 2016-10-03 20:32 ` CAI Qian 2016-10-03 20:35 ` Al Viro 2016-10-04 13:29 ` CAI Qian 2016-10-04 14:28 ` Al Viro 2016-10-04 16:21 ` CAI Qian 2016-10-04 20:12 ` Al Viro 2016-10-05 14:30 ` CAI Qian 2016-10-05 16:07 ` Al Viro 2016-09-09 2:31 ` xfs_file_splice_read: possible circular locking dependency detected Al Viro 2016-09-09 2:39 ` Linus Torvalds 2016-09-09 2:26 ` Al Viro 2016-09-09 2:19 ` Al Viro 2016-09-08 18:01 ` Linus Torvalds 2016-09-08 20:39 ` CAI Qian 2016-09-08 21:19 ` Dave Chinner 2016-09-08 21:30 ` 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=20160929225003.GQ19539@ZenIV.linux.org.uk \ --to=viro@zeniv.linux.org.uk \ --cc=axboe@kernel.dk \ --cc=caiqian@redhat.com \ --cc=david@fromorbit.com \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-xfs@vger.kernel.org \ --cc=miklos@szeredi.hu \ --cc=npiggin@gmail.com \ --cc=torvalds@linux-foundation.org \ --cc=xfs@oss.sgi.com \ /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: linkBe 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.