Date: Sun, 10 Feb 2008 00:11:47 +0100 From: "Attilio Rao" <attilio@freebsd.org> To: "Yar Tikhiy" <yar@comp.chem.msu.su> Cc: yar@freebsd.org, Scot Hetzel <swhetzel@gmail.com>, Doug Barton <dougb@freebsd.org>, freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: panic: System call lstat returning with 1 locks held Message-ID: <3bbf2fe10802091511p201ee404g76a835f49d9291ac@mail.gmail.com> In-Reply-To: <20080209203317.GB62234@comp.chem.msu.su> References: <790a9fff0801312241s346068b6s40fcae71ebbf546@mail.gmail.com> <3bbf2fe10802011041t28e419c9n5f0f6f34d6450184@mail.gmail.com> <20080205162217.GA56373@comp.chem.msu.su> <3bbf2fe10802051156p1cc6ea67t7938a60e306323ce@mail.gmail.com> <20080206112930.GD7592@comp.chem.msu.su> <3bbf2fe10802060549u66b1067cy4bb9d4232ccef05d@mail.gmail.com> <20080206144802.GH7592@comp.chem.msu.su> <3bbf2fe10802060652y3782d023k9c5299168a81093d@mail.gmail.com> <3bbf2fe10802060657h1dbc93e2lf3fd1b0c6843f674@mail.gmail.com> <20080209203317.GB62234@comp.chem.msu.su>
next in thread | previous in thread | raw e-mail | index | archive | help
2008/2/9, Yar Tikhiy <yar@comp.chem.msu.su>: > On Wed, Feb 06, 2008 at 03:57:58PM +0100, Attilio Rao wrote: > > 2008/2/6, Attilio Rao <attilio@freebsd.org>: > > > 2008/2/6, Yar Tikhiy <yar@comp.chem.msu.su>: > > > > > > > On Wed, Feb 06, 2008 at 02:49:49PM +0100, Attilio Rao wrote: > > > > [...] > > > > > > > > > Want to see if this bt has been helpful? :) > > > > > Can you try the attached patch and see if kernel rings a bell?: > > > > > http://www.freebsd.org/~attilio/ntfs_debug.diff > > > > > > > > > > > > The kernel just panics. :-) > > > > > > > > > This is the new I wanted to know! :) > > > With better checks in lockmgr code, we would have caught more > > > informations about it. > > > > > > Can you please now add DDB support and once it breaks in DDB do a > > > 'show alllocks' and maybe other small investigations? > > > This should shade a light for us. > > > > Could you please enable NTFS_DEBUG too and maybe see, when the kernel > > panics, what is the value of i_usecount for the specified ip? > > I want to exclude refcount leaking. > > > i_usecount is just zero for the faulty ip: > With the determinant yar's help, I think I found how the lock leak happens. Basically, in ntfs_ntput() the inode refcount (ip->i_usecount) is decreased and after checked. When check its i_usecount == 0, it means that initially i_usecount == 1 which also means the lockmgr() was held. For the i_usecount == 0 logic, however, no lockmgr release operation is previewed. This patch should fix the NTFS problems even with stricter assertions I plan to commit rather soon: http://www.freebsd.org/~attilio/ntfs.diff This patch was initially provided by yar as a workaround, but it moved me in analyzing refcount handling and finding this bug. Please test and report if it solves problems for you. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3bbf2fe10802091511p201ee404g76a835f49d9291ac>