Re: splice vs execve lockdep trace.

[Dave Jones <davej@redhat.com>]

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