2008/2/9, Yar Tikhiy <yar@comp.chem.msu.su>:
quoted text
> 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
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"