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.
