Date: Tue, 10 Jan 2017 00:15:38 +0000 From: Anindya Mukherjee <anindya49@hotmail.com> To: Benjamin Kaduk <kaduk@mit.edu>, Anindya Mukherjee <anindya49@hotmail.com> Cc: "freebsd-current@freebsd.org" <freebsd-current@freebsd.org> Subject: RE: New Lock Order Reversal in 12.0? Message-ID: <BN6PR22MB080260EC2F09C691580561CBB6670@BN6PR22MB0802.namprd22.prod.outlook.com> In-Reply-To: <20170109215342.GI8460@kduck.kaduk.org> References: <BN6PR22MB0802636EB33644849ED4E151B6640@BN6PR22MB0802.namprd22.prod.outlook.com> <20170109004717.GE8460@kduck.kaduk.org> <BN6PR22MB08029DEFE472EAC32C9788B3B6640@BN6PR22MB0802.namprd22.prod.outlook.com>, <20170109215342.GI8460@kduck.kaduk.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Good, that makes me feel better :) The system is running fine, so I think y= ou're right and it's nothing to worry about. Thanks again for your response= s. Best, Anindya ________________________________________ From: Benjamin Kaduk [kaduk@mit.edu] Sent: January 9, 2017 1:53 PM To: Anindya Mukherjee Cc: freebsd-current@freebsd.org 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 p= oint 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 + in= ode probably) in #238, and then a sync is being attempted, which causes loc= ks to activate in the softdep code. I've read a bit about this from McCusic= k's book but the details are still fuzzy. > > Perhaps you are trying to tell me that it's benign? I know that WITNESS h= as 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 thi= s 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. -Ben
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BN6PR22MB080260EC2F09C691580561CBB6670>