Messages in this thread | | | Date | Fri, 7 Jul 2006 15:14:04 +0200 | From | Jens Axboe <> | Subject | Re: splice/tee bugs? |
| |
On Fri, Jul 07 2006, Jens Axboe wrote: > On Fri, Jul 07 2006, Jens Axboe wrote: > > On Fri, Jul 07 2006, Michael Kerrisk wrote: > > > Jens Axboe wrote: > > > > > > > > > > > In this case I can't kill it with ^C or ^\. This is a > > > > > > > > hard-to-reproduce behaviour on my (x86) system, but I have > > > > > > > > seen it several times by now. > > > > > > > > > > > > > > aka local DoS. Please capture sysrq-T output next time. > > > [...] > > > > > I'll see about reproducing locally. > > > > > > > > With your modified ktee, I can reproduce it here. Here's the ktee and wc > > > > output: > > > > > > Good; thanks. > > > > > > By the way, what about points a) and b) in my original mail > > > in this thread? > > > > I'll look at them after this. > > I _think_ it was due to a bad check for ipipe->nrbufs, can you see if > this works for you? It also changes some other things: > > - instead of returning EAGAIN on nothing tee'd because of the possible > deadlock problem, release/regrab the ipipe/opipe mutex if we have to. > This makes sys_tee block for that case if SPLICE_F_NONBLOCK isn't set. > > - Check that ipipe and opipe differ to avoid possible deadlock if user > gives the same pipe. > > You can still see 0 results without SPLICE_F_NONBLOCK set, if we have no > writers for instance. This is expected, not much we can do about that as > we cannot block for that condition.
BTW, I'm seeing an odd lockdep message on the first invocation of the test:
============================================= [ INFO: possible recursive locking detected ] --------------------------------------------- ktee2/6208 is trying to acquire lock: (&inode->i_mutex){--..}, at: [<c03922c6>] mutex_lock+0x1c/0x1f
but task is already holding lock: (&inode->i_mutex){--..}, at: [<c03922c6>] mutex_lock+0x1c/0x1f
other info that might help us debug this: 1 lock held by ktee2/6208: #0: (&inode->i_mutex){--..}, at: [<c03922c6>] mutex_lock+0x1c/0x1f
stack backtrace: [<c01041ab>] show_trace+0x12/0x14 [<c0104874>] dump_stack+0x19/0x1b [<c01399b6>] __lock_acquire+0x645/0xc77 [<c013a32a>] lock_acquire+0x5d/0x79 [<c0392082>] __mutex_lock_slowpath+0x6e/0x296 [<c03922c6>] mutex_lock+0x1c/0x1f [<c018d37f>] sys_tee+0x292/0x4a4 [<c0103075>] sysenter_past_esp+0x56/0x8d
I cannot see where this could be happening, Ingo is this valid?
-- Jens Axboe
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |