pipe/page fault oddness.

[Dave Jones]

My fuzz tester ground to a halt, with many child processes blocked
on pipe_lock.  sysrq-t output: http://codemonkey.org.uk/junk/pipe-lock-wtf.txt

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:
[<ffffffff9181df46>] preempt_schedule+0x36/0x60
[<ffffffff9100e3d6>] ___preempt_schedule+0x56/0xb0
[<ffffffff911c3c67>] ? handle_mm_fault+0x3a7/0xcd0
[<ffffffff918239f1>] ? _raw_spin_unlock+0x31/0x50
[<ffffffff91823a05>] ? _raw_spin_unlock+0x45/0x50
[<ffffffff911c3c67>] handle_mm_fault+0x3a7/0xcd0
[<ffffffff910cb687>] ? __lock_is_held+0x57/0x80
[<ffffffff91042c84>] __do_page_fault+0x1a4/0x600
[<ffffffff910ce485>] ? mark_held_locks+0x75/0xa0
[<ffffffff910ce5bd>] ? trace_hardirqs_on_caller+0x10d/0x1d0
[<ffffffff910ce68d>] ? trace_hardirqs_on+0xd/0x10
[<ffffffff9118eda7>] ? context_tracking_user_exit+0x67/0x1b0
[<ffffffff910430fe>] do_page_fault+0x1e/0x70
[<ffffffff918264b2>] page_fault+0x22/0x30
[<ffffffff911bd7e3>] ? copy_page_to_iter+0x3b3/0x500
[<ffffffff9120eddf>] pipe_read+0xdf/0x330
[<ffffffff9120ed00>] ? pipe_write+0x490/0x490
[<ffffffff912051a0>] ? do_sync_readv_writev+0xa0/0xa0
[<ffffffff912053b8>] do_iter_readv_writev+0x78/0xc0
[<ffffffff91206bbe>] do_readv_writev+0xce/0x280
[<ffffffff9120ed00>] ? pipe_write+0x490/0x490
[<ffffffff910cbbf6>] ? lock_release_holdtime.part.29+0xe6/0x160
[<ffffffff910ac74d>] ? get_parent_ip+0xd/0x50
[<ffffffff910ac74d>] ? get_parent_ip+0xd/0x50
[<ffffffff910ac8ab>] ? preempt_count_sub+0x6b/0xf0
[<ffffffff91206da9>] vfs_readv+0x39/0x50
[<ffffffff91206e6c>] SyS_readv+0x5c/0x100
[<ffffffff918249e4>] tracesys+0xdd/0xe2

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 ?

Trinity's watchdog process has been repeatedly sending SIGKILL's to this
running pid, but we never seem to get out of this state long enough for
it to take effect.

This is 3.17-rc7 fwiw.

	Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/