Should fix PR #45829: "writing to vnd on sparse file blocks on pager_map"
where the pager_map gets exhausted by requests enqueued on a vnd
device and the device worker thread blocks on putpages() needing the map.
While here always sync the underlying vnode before calling biodone().
XXX: vnd should be converted to mutex/condvar.
- Make the strategy decision a device flag and set VNF_USE_VN_RDWR for
files known to be sparse.
- Change handle_with_rdwr() to use POSIX_FADV_NOREUSE advise to disable
read ahead and keep the size of mapped pages below 1 MByte.
No objections on tech-kern@.
- Reorganize locking in UVM and provide extra serialisation for pmap(9).
New lock order: [vmpage-owner-lock] -> pmap-lock.
- Simplify locking in some pmap(9) modules by removing P->V locking.
- Use lock object on vmobjlock (and thus vnode_t::v_interlock) to share
the locks amongst UVM objects where necessary (tmpfs, layerfs, unionfs).
- Rewrite and optimise x86 TLB shootdown code, make it simpler and cleaner.
Add TLBSTATS option for x86 to collect statistics about TLB shootdowns.
- Unify /dev/mem et al in MI code and provide required locking (removes
kernel-lock on some ports). Also, avoid cache-aliasing issues.
Thanks to Andrew Doran and Joerg Sonnenberger, as their initial patches
formed the core changes of this branch.
copyright. Confirmed by Mike Hibler, mike at cs.utah.edu - thanks!
Also, merge UCB and Utah copyright texts back into one, as they
originally were.
Extra verification by snj@.
and the metadata required to interpret it. Callers of namei must now
create a pathbuf and pass it to NDINIT (instead of a string and a
uio_seg), then destroy the pathbuf after the namei session is
complete.
Update all namei call sites accordingly. Add a pathbuf(9) man page and
update namei(9).
The pathbuf interface also now appears in a couple of related
additional places that were passing string/uio_seg pairs that were
later fed into NDINIT. Update other call sites accordingly.
64 bit integers (eg, sparc). the problem was that the new 64 bit
element on the end was used for the offsetof() (aka size) for the old
structure, but this includes the padding required, thus the ioctl number
was set wrongly.
move all the supporting code for this inside COMPAT_50, with some renaming
to suit, and kill all the external definitions related to it.
tested on i386, amd64 and sparc.
which grew since netbsd 5.0 (hi christos!)
fix a few issues/problems:
- the COMPAT_30 code wasn't used since opt_compat_netbsd.h wasn't included
- move 'struct vnd_ouser' (for COMPAT_30) into vnd.c itself, and call it
'struct vnd_user30'
- same for VNDIOOCGET -> VNDIOCGET30
now 'vnconfig -l' works on -current with a netbsd-5 binary, using i386.
XXX: there is still a potential problem with the old VNDIOOCSET and
VNDIOOCCLR macros on some platforms like sparc. there is padding
between the old vnd_osize member and the new vnd_size member on
platforms that want 64 bit values 64 bit aligned, but are 32 bit
otherwise (like sparc.) 64 bit systems already end up with this
member 64 bit aligned, and should be fine.
this most likely results in the old ioctl numbers being wrong and
the code won't match/run ever (ENOTTY.)
Make sure non-MPsafe iodone callbacks raise the SPL as appropriate.
Fix buffer corruption issue I noticed in dk(4), and probable similar
issues in vnd(4) and cgd(4).
compatibility. Both fields are now unsigned.
Add compatibility for the old ioctl size.
Detect and error files which are definitely sparse (va_bytes < va_size).
Part of fix for PR/41873.
Test if VOP_BMAP actually works before using bmap/strategy.
When you create an image with
dd if=/dev/zero of=./netbsd.img bs=1m count=1 seek=1000
then the current check actually determines the "file system"
in the image supports VOP_BMAP and VOP_STRATEGY, but VOP_BMAP can't
translate any logical block numbers which results in EIO failures.
When you try to access the image in a Xen DomU you see all disk operations
failing. Therefore test if VOP_BMAP actually works and fall back to
VOP_READ/VOP_WRITE if it doesn't.
This makes a Xen DomU installation working. When you boot your fresh
installed Xen DomU with a valid disklabel and file system in the image,
VOP_BMAP actually works and is used.
This allows you to create an image with dd as above on the Dom0 and
run a DomU installation or to quickly create another virtual disk for
an existing DomU without having to create a disklabel and file system
by hand.
