> > * We hack a fix to deal with the mmap/write case. > > A permanent vnode locking fix is many months away because core > decided to ask Kirk to fix it, which was news to me at the time. > However, I agree with the idea of having Kirk fix VNode locking. > > But since this sort of permanent fix is months away, we really need > an interim solution to the mmap/write deadlock case. > > The easiest interim solution is to break write atomicy. That is, > unlock the vnode if the backing store of the uio being written is > (A) vnode-pager-backed and (B) not all in-core. > > This will generally fix all known deadlock situations but at the > cost of write atomicy in certain cases. We can use the same hack > that pipe code uses and only guarentee write atomicy for small > block sizes. We would do this by wiring ( and faulting, if > necessary ) the first N pages of the uio prior to locking the vnode. > > We cannot wire all the pages of the uio since the user may specify > a very large buffer - megabytes or gigabytes. > > * Stage 3: Permanent fix is committed by generally fixing vnode locks > and VFS layering. > > ... which may be 6 months if Kirk agrees to do a complete rewrite > of the vnode locking algorithms. > Regarding atomicy:
Remember that you cannot assume that the mappings stay the same during almost any I/O mechanism anymore. The issue of wiring pages and assuming constant mapping has to be resolved. A careful definition of whether or not one is doing I/O to an address or I/O to a specific piece of memory. I know that this is an end condition, but it has consequences as to the effects on the design. (I suspect that a punt to do I/O to a virtual address is correct, but those change, and also disappear.) John To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
