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 [ka...@mit.edu]
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
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.
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"