I browsed the Kernel Source and there is only one mark_inode_dirty in pipe_write (in fs/pipe.c). So we know where it is hanging... And in __mark_inode_dirty (in fs/inode.c) there is one spin_lock(&inode_lock) call, and I guess that is where the whole thing is hanging. So something is holding that lock... how do I find out who is doing that? Apparently the handling of inode_lock is confined to inode.c. I'll keep reading. Maybe the pipe in question is one of the pipes that jack uses for ipc?