> On 15. Jan 2020, at 18:44, Andrew Doran <ad%netbsd.org@localhost> wrote: > > I don't understand why we do this. I don't think it's needed at all because > if the file really is deleted and the inode is getting cleaned out, then it > shouldn't be getting new refs in any of the usual ways and we don't need to > worry about it. And in any case the vnode lock prevents anyone from messing > with the inode during VOP_INACTIVE(). > > I want to change this because it causes nasty problems on MP. For example I > see threads very regulary thrown out of the namecache by vcache_vtryget(), > and when they finally get the vnode ref'd and locked they do it by digging > through the file system metadata (when everything is already in cache). > > http://www.netbsd.org/~ad/inactive.diff > > What am I missing here? Is there a buggy file system or something like > that? We also come here with a full vnode cache cleaning vnodes to keep the cache size below its max calling vrecycle() on un-deleted vnodes. I suppose the "vp->v_usecount == 1" assert in vrecycle() may fire with this change as we drop the interlock before taking the lock. -- J. Hannken-Illjes - hannken%eis.cs.tu-bs.de@localhost - TU Braunschweig
Attachment:
signature.asc
Description: Message signed with OpenPGP