2008/2/9, Yar Tikhiy <yar_at_comp.chem.msu.su>: > On Wed, Feb 06, 2008 at 03:57:58PM +0100, Attilio Rao wrote: > > 2008/2/6, Attilio Rao <attilio_at_freebsd.org>: > > > 2008/2/6, Yar Tikhiy <yar_at_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. EinsteinReceived on Sat Feb 09 2008 - 22:11:51 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:27 UTC