On 07/10/2014 01:55 PM, Hugh Dickins wrote: >> And finally, (not) holding the i_mmap_mutex: > I don't understand what prompts you to show this particular task. > I imagine the dump shows lots of other tasks which are waiting to get an > i_mmap_mutex, and quite a lot of other tasks which are neither waiting > for nor holding an i_mmap_mutex. > > Why are you showing this one in particular? Because it looks like the > one you fingered yesterday? But I didn't see a good reason to finger > that one either. There are a few more tasks like this one, my criteria was tasks that lockdep claims were holding i_mmap_mutex, but are actually not. One new thing that I did notice is that since trinity spins a lot of new children to test out things like execve() which would kill said children, there tends to be a rather large amount of new tasks created and killed constantly. So if you look at the bottom of the new log (attached), you'll see that there are quite a few "trinity-subchild" processes trying to die, unsuccessfully. Thanks, Sasha
Attachment:
log.gz
Description: application/gzip