On Tue, Apr 11, 2017 at 04:28:39AM +0100, Al Viro wrote:
> On Mon, Apr 10, 2017 at 11:05:32PM -0400, Dave Jones wrote:
> > On Tue, Apr 11, 2017 at 01:22:15AM +0100, Al Viro wrote:
> >
> > > * in do_splice_to(): WARN_ON(pipe->nrbufs == pipe->buffers)
> >
> > Hit this one.
>
> But not WARN_ON(pipe->nrbufs) in its caller *or* WARN_ON(!pipe->buffers)
> in do_splice_to() itself?
>
> How the devil can that be possible?
>
> Again, to make sure we are on the same page: in
> if (WARN_ON(pipe->nrbufs)) {
> printk(KERN_ERR "->splice_write = %p",
> sd->u.file->f_op->splice_write);
> }
> while (len) {
> size_t read_len;
> loff_t pos = sd->pos, prev_pos = pos;
>
> ret = do_splice_to(in, &pos, pipe, len, flags);
> ...
> ... (not a single continue in sight)
> ...
> if (WARN_ON(pipe->nrbufs)) {
> printk(KERN_ERR "->splice_write = %p",
> sd->u.file->f_op->splice_write);
> }
> }
Ah, missed adding this 2nd WARN_ON.
> neither of those WARN_ON() triggers. In do_splice_to()
> WARN_ON(pipe->nrbufs == pipe->buffers);
> does trigger, but
> WARN_ON(!pipe->buffers);
> does not. And pipe is equal to current->splice_pipe, so nobody else could
> see it, let alone be messing with it.
>
> How can that be possible? Non-triggering WARN_ON() in caller of
> do_splice_to()
> mean that pipe->nrbufs is zero. Triggering WARN_ON() in do_splice_to() means
> that it's equal to pipe->buffers, but WARN_ON(!pipe->buffers) manages to
> avoid
> being triggered? Can you confirm all that?
asides from above, yeah, same.
> Because if that's the case,
> the next possibility is random memory corruption and/or pipe_info dangling
> pointers/use-after-free/etc.
I've been tied up with other stuff today, so while I was preoccupied, I
did a run with KASAN to see if anything fell out. That seems to slow
things down enough that I don't trigger anything. Been running all day
without incident.
I'll turn it back off, and retry with the missing WARN from above added.
Dave
