Good, that makes me feel better :) The system is running fine, so I think 
you're right and it's nothing to worry about. Thanks again for your responses.

From: Benjamin Kaduk []
Sent: January 9, 2017 1:53 PM
To: Anindya Mukherjee
Subject: Re: New Lock Order Reversal in 12.0?

On Mon, Jan 09, 2017 at 02:31:39AM +0000, Anindya Mukherjee wrote:
> Hi Ben,
> Thanks for your reply, and yes, I did notice #238. I should say at this point 
> that I'm a newbie when it comes to kernel code and am trying to learn about 
> it (hence current).

Understood.  It's good that you are ready to try!

> The entry you refer to does look a bit like the one I've got, but I'm not 
> totally sure if the same code path is being followed to arrive at this LOR. 
> An inode is being created in my case, vs a directory creation (entry + inode 
> probably) in #238, and then a sync is being attempted, which causes locks to 
> activate in the softdep code. I've read a bit about this from McCusick's book 
> but the details are still fuzzy.
> Perhaps you are trying to tell me that it's benign? I know that WITNESS has 
> false positives, an example being #236 where due to shared vs exclusive vnode 
> locks required on the two ways to lock bufwait and dirhash a deadlock never 
> happens.

Well, it's hard to say for certain, but there are a few ufs/bufwait/ufs
LORs that are very commonly reported as WITNESS output but have never (IIRC)
been identified as causing a deadlock.  So, it seems pretty likely that this
one is similarly benign -- I, for one, do not plan to put in time trying
to analyze it until there is a hang or deadlock associated with it.

_______________________________________________ mailing list
To unsubscribe, send any mail to ""

Reply via email to