On Mon, Sep 29, 2014 at 09:27:09PM -0700, Linus Torvalds wrote:
> On Mon, Sep 29, 2014 at 8:33 PM, Dave Jones <da...@redhat.com> wrote:
> >
> > Looking at the dump, there's only one running trinity child,
> > with all the others blocking on it.
> >
> > trinity-c49 R running task 12856 19464 7633 0x00000004
> > ffff8800a09bf960 0000000000000002 ffff8800a09bf9f8 ffff880219650000
> > 00000000001d4080 0000000000000000 ffff8800a09bffd8 00000000001d4080
> > ffff88023f755bc0 ffff880219650000 ffff8800a09bffd8 ffff88010b017e00
> > Call Trace:
> > [<ffffffff911c3c67>] handle_mm_fault+0x3a7/0xcd0
> > [<ffffffff91042c84>] __do_page_fault+0x1a4/0x600
> > [<ffffffff910430fe>] do_page_fault+0x1e/0x70
> > [<ffffffff918264b2>] page_fault+0x22/0x30
> > [<ffffffff911bd7e3>] ? copy_page_to_iter+0x3b3/0x500
> > [<ffffffff9120eddf>] pipe_read+0xdf/0x330
> >
> > Running the function tracer on that pid shows it spinning forever..
> > http://codemonkey.org.uk/junk/pipe-trace.txt
> >
> > Kernel bug (missing EFAULT check somewhere perhaps?), or is this a
> > case where the fuzzer asked the kernel to do something stupid, and it
> > obliged ?
>
> Hmm. It looks like copy_page_to_iter_iovec() is broken and keeps not
> making any progress while just faulting.
>
> I don't see how that could happen, though. All the loops there are
> conditional on the user copies *not* failing (ie "!left"), and they
> seem to properly update "iov".
>
> Mind sending a disassembly of your "copy_page_to_iter" function, in
> particular around that whole "0x3b3/0x500" area which is where the
> page fault seems to happen?
Whole file is at http://codemonkey.org.uk/junk/iov_iter.txt
gcc is 4.8.3 btw
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
