[lkml]   [2013]   [Jul]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: splice vs execve lockdep trace.
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.


 \ /
  Last update: 2013-07-16 05:21    [W:0.071 / U:3.844 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site