msdosfs and cd9660 are the only filesystems that verify the filesystem
type in the label. This is the wrong place, sanity checks should only
rely on the inner structure of the filesystem (like signatures or
magic numbers).
msdosfs also used the device type information from the label to
deduce a filesystem parameter heuristically for the gemdos variant.
If there is no information inside the filesystem data itself, this
should be an explicit mount option.
operations. This prevents kernel memory leaks (one of which happened
every time the file system was unmounted via PUFFSOP_UNMOUNT ...
and incidentally would've been trivially caught with the old
malloc(9) interface. I wonder if the message is to use a ton of
pools instead of regression-attractive kmem interface).
reference the puffs_node before sending the request to the file
server. This diminishes the window where the inode can be reclaimed
and be invalidated before it is accessed (but does not completely
eliminate the race, as that is a caller problem which we cannot
fix here).
years ago when the kernel was modified to not alter ABI based on
DIAGNOSTIC, and now just call the respective function interfaces
(in lowercase). Plenty of mix'n match upper/lowercase has creeped
into the tree since then. Nuke the macros and convert all callsites
to lowercase.
no functional change
to initiate self destruct, i.e. unmount(MNT_FORCE). This, however,
is a semi-controlled self-destruct, since all caches are flushed
before the (possibly) violent unmount takes place.
context. This fixes a long-standing but seldomly seen deadlock,
where the kernel was holding pages busy (due to e.g. readahead
request) while waiting for the server to respond, and the server
made a callback into the kernel asking to invalidate those pages.
... or, well, theoretically fixes, since I didn't have any reliable
way of repeating the deadlock and I think I saw it only twice.
* it depended on the biglock (in a very cruel way)
* it was attached to userspace transactions rather than logical
fs operations
(If someone wants to revisit it some day, most of the stuff can be
reused from cvs history)
a valid optimization, but that's long gone and once VOP_INACTIVE is
called and the file server says that the vnode is going to be recycled,
it really is going to be recycled extra references gained or not.
based on code taken from FreeBSD.
This stops truncation of files larger than 4GB by VOP_SETATTR() which e.g.
happened when copying large files "rump_smbfs". Kudos to Antti Kantee
for diagnosing the problem in smbfs_smb_setfsize().
Change cd9660_mount, in MNT_UPDATE case, to check dev_t's for equality
instead of just vnode pointers. Fixes erroneous "Invalid argument"
errors from mount(8) with -u against cd9660 root in the presence of
mfs or tmpfs /dev prepared after initial mountroot.
Tested on QEMU running cobalt Restore CD.
operations creating a node cannot be considered outgoing operations,
since after return from userspace they modify file system state
by creating a new node. if we do not protect the file system by
holding the directory lock, a lookup operation might race us into
the kernel and create the node earlier.
* remove pnode from hashlish before sending the reclaim faf off to
userspace. also, hold pmp_lock while frobbing the list.
system generate heaps of odd allocations since the end of write request was
overwritten by the start of the second resulting in another relocation.
Also added a full flush of the file on a VOP_CLOSE(). This automatically
flushes file tails to disc.
- pcinfo = kmem_zalloc(sizeof_puffs_cacheinfo) + runsize,
+ pcinfo = kmem_zalloc(sizeof(struct puffs_cacheinfo) + runsize,
in #ifdef'ed out code, per paired kmem_free() in the same function.
Closes PR kern/41840.
complaint in the "ntfs ubc_uiomove error" (ubc_uiomove error was
not coming from ntfs but instead the "to" file system) and PR
kern/38531 (well, I assume the submitter wanted cp(1) working on
ntfs instead of mangling ntfs the way the PR title suggests). Yes,
mmap works on ntfs like it always has.
*) well, um, and in other places too ... uuuh ... no comments.
but I guess this works as long as in-kernel ntfs doesn't grow write
support.
mlelstv