tech-kern archive

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

Re: VOP_STRATEGY for devices and pipes



On Thu, Jul 15, 2021 at 06:26:55PM +0200, Rhialto wrote:
 > > Seems to me the best/safest thing to do for now would be to prohibit
 > > the extended-attr on devices and fifos.
 > 
 > If I have a normal file system, and in a directory is an entry with an
 > inode for a fifo (or a device), and I set an extended attribute on that
 > inode, then surely it will get stored in the file system, and not in the
 > fifo (or device)?
 > 
 > So if the fifo (or device) code gets involved in this, then the bug is
 > there, I'd think?

Well... yes, in theory.

The way it actually works right now is that device and fifo vnodes
belong half to the filesystem and half not -- every filesystem on
which devices and fifos can be created (which is not all of them) has
two additional vnode ops tables for device and fifo vnodes
respectively, which redirect most but not all of the ops to the code
in miscfs/specfs and miscfs/fifofs. So things like chmod (VOP_SETATTR)
go through the filesystem code and things like read and write go to
the device or fifo.

Buffers associated with a file are hung on that file's vnode. This is
overloaded for devices such that buffers for the _device_ are hung on
the device vnode... it works that way because the buffer cache is
indexed by vnode and offset. (The buffer cache is both virtually and
physically indexed: you can have buffers for an offset in a file, and
buffers for a raw disk address, and the latter use the disk device's
vnode as part of the key.)

We've had assorted problems in the past caused by this overloading; if
you remember when wapbl was rolled out there were assorted problems
when wapbl was enabled on the root fs; this was caused by calling the
root fs's operations for device buffers that came from some other
filesystem, which then tried to do wapbl operations where no wapbl
goop existed and croaked.

We think those issues have pretty much all been found and fixed, but
I'm wary of adding new ones.

One of the goals of the device plumbing changes I proposed a couple
months ago is to get rid of this overloading by making operating
device vnodes separate from the on-disk special file vnodes. But
that's a big invasive change and not happening in the near future.

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


Home | Main Index | Thread Index | Old Index