From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1753276AbdDKXem (ORCPT <rfc822;w@1wt.eu>);
        Tue, 11 Apr 2017 19:34:42 -0400
Received: from scorn.kernelslacker.org ([45.56.101.199]:39700 "EHLO
        scorn.kernelslacker.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752327AbdDKXek (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 11 Apr 2017 19:34:40 -0400
Date: Tue, 11 Apr 2017 19:34:37 -0400
From: Dave Jones <davej@codemonkey.org.uk>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: iov_iter_pipe warning.
Message-ID: <20170411233437.jmkghan72fb4fclg@codemonkey.org.uk>
Mail-Followup-To: Dave Jones <davej@codemonkey.org.uk>,
        Al Viro <viro@ZenIV.linux.org.uk>,
        Linux Kernel <linux-kernel@vger.kernel.org>
References: <20170410194206.loesu5licstif7or@codemonkey.org.uk>
 <20170410195711.GD29622@ZenIV.linux.org.uk>
 <20170410234830.tmqdhpjtfdveor3c@codemonkey.org.uk>
 <20170411002215.GE29622@ZenIV.linux.org.uk>
 <20170411030532.vcam25fz6224ny2h@codemonkey.org.uk>
 <20170411032839.GF29622@ZenIV.linux.org.uk>
 <20170411205336.uyz5vfw52twhh6ob@codemonkey.org.uk>
 <20170411211216.GH29622@ZenIV.linux.org.uk>
 <20170411222502.ldgahltwvrrxdbbw@codemonkey.org.uk>
 <20170411232842.GI29622@ZenIV.linux.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170411232842.GI29622@ZenIV.linux.org.uk>
User-Agent: NeoMutt/20170306 (1.8.0)
X-Spam-Note: SpamAssassin invocation failed
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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]

dir test is running from is /home on nfs, so that makes sense.

 > How about adding to that printk (under if (WARN_ON()) something like
 > 	file = sd->u.file;
 > 	if (file->f_op->splice_write == generic_splice_sendpage) {
 > 		struct socket *sock = file->private_data;
 > 		printk(KERN_ERR "socket [%d, %p]\n", sock->type, sock->ops);
 > 	}
 > 	printk(KERN_ERR "in->f_op = %p\n", in->f_op);

Ack.

 > 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.

	Dave.