Re: iov_iter_pipe warning.

[Al Viro <viro@ZenIV.linux.org.uk>]

On Tue, Apr 11, 2017 at 07:34:37PM -0400, Dave Jones wrote:
> On Wed, Apr 12, 2017 at 12:28:42AM +0100, Al Viro wrote:
>  > On Tue, Apr 11, 2017 at 06:25:02PM -0400, Dave Jones wrote:
>  > 
>  > > ffffffff812b3130 T generic_splice_sendpage
>  > > 
>  > > This one spat out all by itself.
>  > 
>  > No need to print ->f_op for that one - can be only socket_file_ops.  Now,
>  > the address family of that socket would be interesting...
> 
> Turned out to be..
> 
>  ->splice_write = ffffffff812b2b70 sd->u.file->f_op=ffffffffa02e0980
> $ grep ffffffffa02e0980 /proc/kallsyms 
> ffffffffa02e0980 r nfs4_file_operations	[nfsv4]

Lovely...  So now we get it not only on splice to socket, but on
splice to regular file on NFS as well?  That makes lying splice_read()
more likely...

>  > Interesting...  How about
>  > 	if (res > 0 && pipe == current->splice_pipe) {
>  > 		int idx = pipe->curbuf;
>  > 		int n = pipe->nrbufs;
>  > 		size_t size = 0;
>  > 		while (n--) {
>  > 			size += pipe->bufs[idx++].len;
>  > 			if (idx == pipe->buffers)
>  > 				idx = 0;
>  > 		}
>  > 		WARN_ON(len != res);
>  > 	}
>  > just before the return in default_file_splice_read()?  WARN_ON_ONCE,
>  > perhaps, to avoid cascades...
> 
> Sure, up next. Gimme an hour, it seems to be reproducing fairly quickly
> tonight.

Makes sense - now it screams on non-empty pipe in the beginning of loop
body; originally it was only for _full_ pipe (i.e. for leftovers from
several iterations filling the entire thing up), which should've been
harder to trigger...