On Thu, Jun 25, 2009 at 07:50:59AM +0100, David Laight wrote: > On Wed, Jun 24, 2009 at 09:24:57PM -0700, Bill Stouder-Studenmund wrote: > > > > > > > > The fact that the caller has a reference to the vnode at all should > > > > really be enough, surely?? > > > > > > do you mean vref? > > > it doesn't prevent revoke(2). > > > thus a filesystem can't access v_data safely. > > If revoke works by changing fields of the vnode (like v_data) then > it is always going to cause grief - since v_data can then disappear > during the entry of any VOP call. > > In a single-threaded, non-smp, kernel the data areas can probably be > changed in a consistent manner. With SMP you have to do things > differently. So if revoke is making the vnode reference some other > (dummy) fs and then releasing all references to the original fs, it > just isn't going to work. Please don't hand-wave. Other OSs and file systems have delt with this. And for any interesting OS we care to look at, we can go see what their track record with this is. How often do their kernels crash because of revoke()? > > How does Solaris do this? My understanding is you _don't_ have to lock > > nodes any where near as often as we do (or did last I looked, which was > > admittedly a while ago). > > FWIW SYSV handled controlling terminal 'revoke' by disallowing access > to the major/minor in the specfs code. So even if you did another open() > you couldn't access the device that had been your ctty. (Which was rather > fun when the ctty was a clone device from the network stack, and the > program was a network daemon.) Well, sounds like clone devices weren't implemented so well. ;-) I know in Mac OS, requested-reclaims happen when you go down to 0 references. So in the sequence of 'lookup, splash the vnode, release vnode', the actual vnode destruction happens in the release of the vnode. Take care, Bill
Attachment:
pgp4tg6E7itDD.pgp
Description: PGP signature