On 07/10/2014 03:06 PM, Hugh Dickins wrote: > On Thu, 10 Jul 2014, Sasha Levin wrote: >> > On 07/10/2014 02:52 PM, Hugh Dickins wrote: >>> > > On Thu, 10 Jul 2014, Sasha Levin wrote: >>>>> > >> > 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. >>> > > You and Vlastimil enlightened me yesterday that lockdep shows tasks as >>> > > holding i_mmap_mutex when they are actually waiting to get i_mmap_mutex. >>> > > Hundreds of those in yesterday's log, hundreds of them in today's. >> > >> > What if we move lockdep's acquisition point to after it actually got the >> > lock? >> > >> > We'd miss deadlocks, but we don't care about them right now. Anyways, doesn't >> > lockdep have anything built in to allow us to separate between locks which >> > we attempt to acquire and locks that are actually acquired? >> > >> > (cc PeterZ) >> > >> > We can treat locks that are in the process of being acquired the same as >> > acquired locks to avoid races, but when we print something out it would >> > be nice to have annotation of the read state of the lock. > I certainly hope someone can work on improving that. I imagine it would > be easy, and well worth doing. But won't be looking into it myself. I'd be happy to work on that, just want Peter to confirm that there's no reason that this is missing right now. Thanks, Sasha -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>