Subject: Re: VNODEOPs & SAVESTART in cn_flags
To: Chris Jepeway <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 01/29/2002 15:32:19
On Tue, 29 Jan 2002, Chris Jepeway wrote:
> > Hmmm.. That means that fixing the problems probably won't break things.
> > :-)
> Yup. 'Course, it also means that testing a fix is hard, too.
Not necessarily, just brute force. :-) If we know all of the callers, we
can see what they are doing.
> > I agree that all f/s should behave the same. The alternative to having all
> > VOPs honor SAVESTART would be to document which do and don't.
> > Just honoring it across the board would probaby be easiest.
> That was my thought, too, but I broke my head trying
> to puzzle out how ufs_rename() wants to use it. It seems
> like ufs_rename() unconditionally steps on SAVESTART when,
> eg, calling relookup(). I guess that's to avoid VREF()ing
> the starting directory, but then there's no chance for ufs_rename()'s
> caller to use SAVESTART to hang onto cn_pnbuf. Maybe ufs_rename()
> should turn a SAVESTART into a SAVENAME?
Some of the SAVE stuff is quite crusty. I'm not 100% how it's supposed to
It used to be that ufs_rename (I think it was rename) would actually
vrele() incoming nodes, throwing away all of it's passed-in reference
counts, and then vget() them. This only worked because the caller had done
a namei() call which hung onto an extra ref, which was released after the
> Then, there's the whole thing about SAVESTART vs. SAVENAME in
> VOP calls. Those VOPs that pay attention to SAVESTART do it
> by taking it to mean "don't PNBUF_PUT() and don't let VOP_ABORTOP()
> do it, either." Should VOPs use SAVENAME to mean "PNBUF_PUT() only
> on error?" Or should they just ignore SAVENAME?
Not 100% sure. It's been a few years. :-)