On Feb 27, 2014, at 7:01 PM, Mindaugas Rasiukevicius <rm...@netbsd.org> wrote:
> "J. Hannken-Illjes" <hann...@eis.cs.tu-bs.de> wrote: >>> I have not had time to follow your VFS changes, but can you explain why >>> did you remove VOP_LOCK/VOP_UNLOCK in tmpfs_reclaim()? It was added to >>> prevent from the racy access of tn_links. >> >> Hopefully a vnode lock is needed to access tn_links -- otherwise the >> VOP_LOCK/UNLOCK in tmpfs_reclaim() didn't protect it ... > > Yes, tn_links is modified with the vnode lock held. Unlocked access in > VOP_RECLAIM() racing with the release of the last last reference, used to > cause crashes due to premature reclamation attempts. Given that VOP_LOCK() > acquires the vnode node, can you explain why this "didn't protect it"? As stated above I hoped tn_links is modified only with the lock held. >> As this commit prevents other threads from obtaining a lock while >> VOP_RECLAIM() is running the protection should be the same as before. > > You mean VOP_RECLAIM() is now called with the vnode lock held? Can you > please add an assert in tmpfs_reclaim() which demonstrates that? No -- while VOP_RECLAIM() is called no thread may get the lock which is the same as if it were held here. -- J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
