On Mon, Jul 15, 2013 at 07:32:51PM -0700, Linus Torvalds wrote:
> So the problematic op *seems* to be the splice into /proc/<pid>/attr/
> files, which causes that "pipe -> cred_guard_mutex" locking.
>
> While the *normal* ordering would be the other way around, coming from
> execve(), which has the cred_guard_mutex -> VFS locks ordering for
> reading the executable headers.
>
> Al, can we break either of those? Do we need to hold on to the cred
> mutex that long? We get it fairly early (prepare_bprm_creds) and we
> drop it very late (install_exec_creds), which means that it covers a
> lot. But that seems pretty basic. The splice into /proc/<pid>/attr/*
> seems to be the more annoying one, and maybe we just shouldn't allow
> splicing into or from /proc?
>
> Dave, is this new (it doesn't *smell* new to me), or is it just that
> trinity is doing new splice things?
I think I've seen this a long time ago from another fuzzer (iknowthis).
I thought that had gotten fixed though. But I may be mixing up a
similar callchain. The recent trinity changes shouldn't have really made
any notable difference here. Interestingly, the 'soft lockups' I was
seeing all the time on that box seem to have gone into hiding.
> Or is the XFS i_iolock required for this thing to happen at all?
> Adding Ben Myers to the cc just for luck/completeness.
It is only happening (so far) on the XFS test box, but I don't have
enough data to say that's definite yet.
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/
