Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: 9.99.86 HEAD



On Thu, Jul 01, 2021 at 07:54:33PM +0200, J. Hannken-Illjes wrote:
 >   lookup_fastforward -> lookup_parsepath -> VOP_PARSEPATH -> ... -> fstrans_start

Bleh. I had a feeling we were going to end up regretting that
fastforward code. :-|

 > According to vnode_if.src VOP_PARSEPATH(dvp...) should take a locked vnode
 > but here this lock is missing. So either
 > 
 > - make sure the vnode is locked so fstrans_start will no loner block.
 > 
 > or
 > 
 > - add FSTRANS=NO to vop_parsepath, file kern/vnode_if.src and allow unlocked vnodes:
 > 
 >  vop_parsepath {
 > +       FSTRANS=NO
 >         IN struct vnode *dvp;
 > 
 > David?

I thought the vnode was locked readonly in the fastforward path. Did I
misread? Or is that not good enough?

Anyway, I think it's probably ok to change vop_parsepath to not
require locked vnodes at all. The only parsepath operation that does
anything other than string ops is rumpfs's, and it takes etfs_lock to
look in some tables that etfs_lock covers. Unless that's going to
interact badly with fstrans without the vnode lock covering it (seems
unlikely, but IDK) there shouldn't be a problem.

However, except in the fastforward code the vnode will be locked. So I
think it should be "= = =" in vnode_if.src. If you also need to add
FSTRANS=NO, that should be fine too.

-- 
David A. Holland
dholland%netbsd.org@localhost


Home | Main Index | Thread Index | Old Index