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 dholl...@netbsd.org