ISO9660 permits specifying a logical block size that is any power of 2
greater than or equal to 512. The geom disk layer requires requests
to be aligned on sector boundaries of the provider. With a volume
that uses a logical block size smaller than the underlying disk sector
size (e.g. a logical block size of 512 or 1024 on a CD which uses 2048
byte sectors), the current cd9660 vfs can issue requests for partial
sectors, or on non-sector boundaries.
Fixing this properly would require wrapping all of the calls to
bread*/bwrite* in cd9660 vfs to roundup requests to be on sector
boundaries which can include both the length, but also the starting
sector number (and thus requiring use of an offset relative to b_data
in the resulting buf).
These images do not seem to be common however given that no one has
fixed this in cd9660's vfs in the past few decades, so just reject
them during mount with an error. If such images are found to be used
in the wild in practice, then the larger fix can be applied.
PR: 258063
Reported by: Robert Morris <rtm@lcs.mit.edu>
Reviewed by: emaste
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D41228
- If the size is negative or if rounding it up to a multiple of
the block size overflows, fail the read request with ERANGE.
- While here, add a sanity check that the ICB length for the root
directory is at least as long as a minimum-sized file entry.
PR: 257768
Reported by: Robert Morris <rtm@lcs.mit.edu>
MFC after: 1 week
Sponsored by: FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D41220
which changes /dev/fd/N files types to symbolic link with the behavior
of symbolic links.
PR: 272127
Reported by: Peter Eriksson <pen@lysator.liu.se>
Reviewed by: dchagin
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D40969
This reverts commits 4a402dfe0b and
3bffa22623.
The fix will be implemented in somewhat different manner. The semantic
adjustment is incompatible with linuxolator expectations.
Reported and reviewed by: dchagin
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D40969
It contains arbitrary garbage, which is not cleared by vfs_bio_clrbuf()
which only zeroes invalid portions of the pages.
Reported by: Maxim Suhanov <dfirblog@gmail.com>
Discussed with: so
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Instead of using VV_READLINK vnode flag and checking it in one place,
just assign VLNK type to the Fdesc vnodes for linrdlnk mounts. Then all
places where symlinks needs to be followed, e.g. lookup(), are handled.
PR: 272127
Reported by: Peter Eriksson <pen@lysator.liu.se>
Reviewed by: markj
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D40700
pseudofs nodes store their name in a flexible array member, so the node
allocation is sized using the length of the name, including a nul
terminator. pfs_lookup() scans a directory of nodes, comparing names to
find a match. The comparison was incorrect and assumed that all node
names were at least as long as the name being looked up, which of course
isn't true.
I believe the bug is mostly harmless since it cannot result in false
positive or negative matches from the lookup, but it triggers a KASAN
check.
Reported by: pho
Reviewed by: kib, Olivier Certner <olce.freebsd@certner.fr>
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40692
The zone has been dead ever since commit
b9e2019755 ("fusefs: rewrite vop_getpages and vop_putpages")
No functional change intended.
Reviewed by: asomers
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D40143
The ext2fs does not support disks with sectorsize more 512 bytes.
The main issue is in reading/writing superblock, which is not aligned
with 4k value. Reimplement the superblock reading logic to make it
indifferent to disk logical sector size. The logical sector size
more then page size is not supported, like it is doing on Linux side.
PR: 271105
Reported by: k(at)vodka.home.kg
Reviewed by: pfg
MFC after: 2 week
Differential Revision: https://reviews.freebsd.org/D40047
The SPDX folks have obsoleted the BSD-2-Clause-NetBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.
Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix
The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.
Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix
If unionfs_domount() fails, the mount path will not call VFS_UNMOUNT()
to clean up after it. If this failure happens during upper vnode
registration, the unionfs root vnode will already be allocated.
vflush() it in order to prevent the vnode from being leaked and the
subsequent vfs_mount_destroy() call from getting stuck waiting for
the mountpoint reference count to drain.
Reviewed by: kib, markj
Tested by: pho
Differential Revision: https://reviews.freebsd.org/D39767
If upperrootvp is doomed by a concurrent unmount, unionfs_nodeget()
may return without a reference or lock on it. unionfs_domount() must
prevent the vnode from being recycled for use by a different file until
it is finished with the vnode, namely once vfs_register_upper_from_vp()
fails. Accomplish this by holding the reference returned by namei()
a bit longer.
Reviewed by: kib, markj
Tested by: pho
Differential Revision: https://reviews.freebsd.org/D39767
If either the lower or upper vnode is found to be doomed after
locking it, the newly-created unionfs node won't be associated
with it and its lock will be dropped. In that case, clear the
uppervp and lowervp locals as necessary to avoid further use
of the vnode in unionfs_nodeget(). If the upper vnode is doomed
but the lower vnode remains valid, additionally reset the unionfs
node's v_vnlock field to point to the lower vnode lock.
Reviewed by: kib, markj
Tested by: pho
Differential Revision: https://reviews.freebsd.org/D39767
If the i-node number (d_fileno) for a file on the server did
not fit in 32bits, it would be truncated to the low order 32bits
for the NFSv3 Readdir and ReaddirPlus RPC replies.
This is no longer correct, given that ino_t is now 64bits.
This patch fixes this by sending the full 64bits of d_fileno
on the wire in the NFSv3 Readdir/ReaddirPlus RPC reply.
PR: 271174
Reported by: bmueller@panasas.com
Tested by: bmueller@panasas.com
MFC after: 2 weeks
The pseudo file systems (devfs, fdescfs, procfs, etc.) report total
and available blocks and inodes despite being synthetic with no
underlying storage device to which those values could be applied.
The current code of these file systems tends to report a fixed number
of total blocks but no free blocks, and in the case of procfs,
libprocfs, linsysfs also no free inodes.
This can be irritating in e.g. the "df" output, since 100% of the
resources seem to be in use, but it can also create warnings in
monitoring tools used for capacity management.
This patch makes these file systems return the same value for the
total and free parameters, leading to 0% in use being displayed by
"df". Since there is no resource that can be exhausted, this appears
to be a sensible result.
Reviewed by: mckusick
Differential Revision: https://reviews.freebsd.org/D39442
Some combinations of FAT12 file system parameters could cause a kernel
panic due to an unmapped access if the size of the FAT was larger than
the CPU page size. The reason is that FAT12 uses 3 bytes to store
2 FAT pointers, leading to partial FAT pointers at the end of buffers
of a size that is not a multiple of 3.
With a typical page size of 4 KB, this caused the FAT entry at byte
offsets 4095 and 4096 to cross the page boundary, with only the first
page mapped. This was fixed by adjusting the mapping to always cover
both bytes of each FAT entry.
Testing revealed 2 other inconsistencies that are fixed by this commit:
1) The calculation of the size of the data area did not take into
account the fact that the first two data block numbers are reserved
and that the data area starts with block 2. This could cause a
FAT12 file system created with the maximum supported number of
blocks to be incorrectly identified as FAT16.
2) The root directory does not take up space in the data area of a
FAT12 or FAT16 file system, since it is placed into a reserved
area outside of that data area. This commits makes stat() report
the logical size of the root directory, but with 0 blocks allocated
from the data area.
PR: 270587
Reviewed by: mckusick
Differential Revision: https://reviews.freebsd.org/D39386
The underlying VOP_MKDIR() implementation may temporarily drop the
parent directory vnode's lock. If the vnode is reclaimed during that
window, the unionfs vnode will effectively become unlocked because
the its v_vnlock field will be reset. To uphold the locking
requirements of VOP_MKDIR() and to avoid triggering various VFS
assertions, explicitly re-lock the unionfs vnode before returning
in this case.
Note that there are almost certainly other cases in which we'll
similarly need to handle vnode relocking by the underlying FS; this
is the only one that's caused problems in stress testing so far.
A more general solution, such as that employed for nullfs in
null_bypass(), will likely need to be implemented.
Tested by: pho
Reviewed by: kib, markj
Differential Revision: https://reviews.freebsd.org/D39272
The implementation is racy; if the unionfs vnode is not in fact
locked, vnode private data may be concurrently altered or freed.
Instead, simply rely upon the standard implementation to query the
v_vnlock field, which is type-stable and will reflect the correct
lower/upper vnode configuration for the unionfs node.
Tested by: pho
Reviewed by: kib, markj
Differential Revision: https://reviews.freebsd.org/D39272
We hold the vnode interlock, so vnode private data cannot suddenly
become NULL.
Tested by: pho
Reviewed by: kib, markj
Differential Revision: https://reviews.freebsd.org/D39272
The LK_UPGRADE operation may have temporarily dropped the upper or
lower vnode's lock. If the unionfs vnode was reclaimed during that
window, its lock field will be reset to no longer point at the
upper/lower vnode lock, so the lock operation will use the standard
lock stored in v_lock. Remove LK_UPGRADE from the flags in this case
to avoid a lockmgr assertion, as this lock has not been previously
owned by the calling thread.
Reported by: pho
Tested by: pho
Reviewed by: kib, markj
Differential Revision: https://reviews.freebsd.org/D39272
Use it when possible, instead of separated flags.
No functional change intended.
Reviewed by: hselasky, erj
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D39466
If either of vnodes is shared locked, lock must not be recursed.
Requested by: rmacklem
Reviewed by: markj, rmacklem
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D39444
Although the NFS client does not currently perform Null RPCs,
this fix is needed if/when it might do so.
Found during testing of experimental code that uses Null RPCs
to maintain/monitor TCP connections for "nconnect" mounts.
MFC after: 3 months
Commit f4179ad46f added support for operation bitmaps for
NFSv4.1/4.2. This commit uses those to implement the SP4_MACH_CRED
case for the NFSv4.1/4.2 ExchangeID operation since the Linux
NFSv4.1/4.2 client is now using this for Kerberized mounts.
The Linux Kerberized NFSv4.1/4.2 mounts currently work without
support for this because Linux will fall back to SP4_NONE,
but there is no guarantee this fallback will work forever.
This commit only affects Kerberized NFSv4.1/4.2 mounts from
Linux at this time.
MFC after: 3 months
This will be used later in the linsysfs module to filter out VNETs.
Reviewed by: des
Differential revision: https://reviews.freebsd.org/D39382
MFC after: 1 month
Since 81167243b the size of struct pfs_node is 280 bytes, so the kernel
memory allocator takes memory from 384 bytes sized bucket. However, the
length of the node name is mostly short, e.g., for Linux emulation layer
it is up to 16 bytes. The size of struct pfs_node w/o pfs_name is 152
bytes, i.e., we have 104 bytes left to fit the node name into the 256
bytes-sized bucket.
Reviewed by: des
Differential revision: https://reviews.freebsd.org/D39381
MFC after: 1 month
NFSv4.1/4.2 uses operation bitmaps for various operations,
such as the SP4_MACH_CRED case for ExchangeID.
This patch adds support for operation bitmaps so that
support for SP4_MACH_CRED can be added to the NFSv4.1/4.2
server in a future commit.
This commit should not change any NFSv4.1/4.2 semantics.
MFC after: 3 months
