This update implements tallying of free directory entries during
create, delete, or rename operations on FAT12 and FAT16 file systems.
Prior to this change, the total number of root directory entries
was reported as number of inodes, but 0 as the number of free
inodes, causing system health monitoring software to warn about
a suspected disk full issue.
The FAT12 and FAT16 file systems provide a limited number of
root directory entries, e.g. 512 on typical hard disk formats.
The valid range of values is 1 to 65535, but the msdosfs code
will effectively round up "odd" values to the next multiple of 16
(e.g. 513 would allow for 528 root directory entries).
This update implements tracking of directory entries during create,
delete, or rename operations, with initial values determined by
scanning the directory when the file system is mounted.
Total and free directory entries are reported in the f_files and
f_ffree elements of struct statfs, despite differences in semantics
of these values:
- There is no limit on the number of files and directories that can
be created on a FAT file system. Only the root directory of FAT12
and FAT16 file systems is limited, any number of files can still be
created in sub-directories, even when 0 free "inodes" are reported.
- A single file can require 1 to 21 directory entries, depending on
the character set, structure, and length of the name. The DOS 8.3
style file name takes up 1 entry, and if the name does not comply
with the syntax of a DOS 8.3 file name, 1 additional entry is used
for each 13 characters of the file name. Since all these entries
have to be contiguous, it is possible that a file or directory with
a long name can not be created, despite a sufficient total number of
free directory entries.
- Renaming a file can require more directory entries than currently
allocated to store its long name, which may prevent an in-place
update of the name if more entries are needed. This may cause a
rename operation to fail if no contiguous range of free entries for
the new name can be found.
- The volume label is stored in a directory entry. An empty FAT file
system with a volume label will therefore show 1 used "inode" in
df.
- The perceentage of free inodes shown in df or monitoring tools does
only represent the state of the root directory of a FAT12 or FAT16
file system. Neither does a reported value of 0% free inodes does
prevent files from being created in sub-directories, nor does a
value of 50% free inodes guarantee that even a single file with
a "long" name can be created in the root directory (if every other
directory entry is occupied and there are no 2 contiguous entries).
The statfs(2) and df(1) man pages have been updated with a notice
regarding the possibly different semantics of values reported as
total and free inodes for non-Unix file systems.
PR: 270053
Reported by: Ben Woods <woodsb02@freebsd.org>
Approved by: mckusick
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D38987
Coverity does not like code that checks a function's
return value sometimes. Add "(void)" in front of the
function when the return value does not matter to try
and make it happy.
A recent commit deleted "(void)"s in front of nfsm_fhtom().
This commit puts them back in.
Reported by: emaste
MFC after: 3 months
We default to passing the path of the tar file to vfs_mountedfrom
so we can tell where a filesystem was mounted from.
However this can make the output of mount(8) hard to read.
Allow things like:
mount -t tarfs -o as=`basename $tar` $tar /mnt
so "as" is recorded instead of $tar
Reviewed by: des
Sponsored by: Juniper Networks
Differential Revision: https://reviews.freebsd.org/D39273
Coverity does not like code that checks a function's
return value sometimes. Add "(void)" in front of the
function when the return value does not matter to try
and make it happy.
Reported by: emaste
MFC after: 3 months
The ix number for the fdescfs root is 1, while any fd vnode has the ix
value at least 3.
Reviewed by: markj
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D39207
It is already referenced by the VOP_LOOKUP() caller, otherwise vdrop()
after vn_lock() is invalid anyway.
Reviewed by: markj
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D39207
Just owning the interlock is not enough for vget() to operate on the
vnode race-free with vgone(), the vnode should be held. Use
vget_prep()/vget_finish() to avoid vholding the vnode explicitly, and
drop LK_INTERLOCK.
Reviewed by: markj
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D39207
In fdesc_lookup(), vn_vget_ino_gen() may fail without invoking the
callback, in which case the ref on fp is leaked. This happens if the
fdescfs mount is being concurrently unmounted. Moreover, we cannot
safely drop the ref while the dvp is locked.
So:
- Use a flag variable to indicate whether the ref is dropped.
- Reorganize things to handle the leak.
Reported by: C Turt <ecturt@gmail.com>
Reviewed by: mjg, kib
Tested by: pho
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39189
The panic() will be called under ext2_dirbad()
function in case of rw mount. It cause user confusion,
like in BZ 265951.
PR: 265951
Reviewed by: pfg, mckusick
MFC after: 2 week
Differential revision: https://reviews.freebsd.org/D38503
Add check that directory entry with ino=EXT2_ROOTINO
have correct namelength and name. It is possible to
create malicious image which will cause panic if root
directory entry have incorrect name.
PR: 259068
Reported by: Robert Morris
Reviewed by: pfg
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D38502
Without this patch, a Kerberized NFSv4.1/4.2 mount must provide
a Kerberos credential for the client at mount time. This credential
is typically referred to as a "machine credential". It can be
created one of two ways:
- The user (usually root) has a valid TGT at the time the mount
is done and this becomes the machine credential.
There are two problems with this.
1 - The user doing the mount must have a valid TGT for a user
principal at mount time. As such, the mount cannot be put
in fstab(5) or similar.
2 - When the TGT expires, the mount breaks.
- The client machine has a service principal in its default keytab
file and this service principal (typically called a host-based
initiator credential) is used as the machine credential.
There are problems with this approach as well:
1 - There is a certain amount of administrative overhead creating
the service principal for the NFS client, creating a keytab
entry for this principal and then copying the keytab entry
into the client's default keytab file via some secure means.
2 - The NFS client must have a fixed, well known, DNS name, since
that FQDN is in the service principal name as the instance.
This patch uses a feature of NFSv4.1/4.2 called SP4_NONE, which
allows the state maintenance operations to be performed by any
authentication mechanism, to do these operations via AUTH_SYS
instead of RPCSEC_GSS (Kerberos). As such, neither of the above
mechanisms is needed.
It is hoped that this option will encourage adoption of Kerberized
NFS mounts using TLS, to provide a more secure NFS mount.
This new NFSv4.1/4.2 mount option, called "syskrb5" must be used
with "sec=krb5[ip]" to avoid the need for either of the above
Kerberos setups to be done by the client.
Note that all file access/modification operations still require
users on the NFS client to have a valid TGT recognized by the
NFSv4.1/4.2 server. As such, this option allows, at most, a
malicious client to do some sort of DOS attack.
Although not required, use of "tls" with this new option is
encouraged, since it provides on-the-wire encryption plus,
optionally, client identity verification via a X.509
certificate provided to the server during TLS handshake.
Alternately, "sec=krb5p" does provide on-the-wire
encryption of file data.
A mount_nfs(8) man page update will be done in a separate commit.
Discussed on: freebsd-current@
MFC after: 3 months
Building with -DMSDOSFS_DEBUG failed due to a format mismatch and
a variable that has been renamed but not updated in the printf()
parameter list.
MFC after: 1 month
The sysctls were in "struct fha_params", making it impractical
to vnet them. This patch moves the sysctls out of "struct fha_params"
and vnet's them, so that they are available in vnet prisons
running nfsd(8). It also avoids the IS_DEFAULT_VNET() macros
in the VNET_SYSINIT() function.
Reviewed by: glebius
MFC after: 3 months
Differential Revision: https://reviews.freebsd.org/D38748
The Kasan tests show the nfsrvd_cleancache() results
in a modify after free. I think this occurs because the
nfsrv_cleanup() function gets executed after nfs_cleanup()
which free's the nfsstatsv1_p.
This patch makes them use the same subsystem and sets
SI_ORDER_FIRST for nfs_cleanup(), so that it will be called
after nfsrv_cleanup() via VNET_SYSUNINIT().
The patch also sets nfsstatsv1_p NULL after free'ng it,
so that a crash will result if it is used after free'ng.
Tested by: markj
Reviewed by: markj
MFC after: 3 months
Differential Revision: https://reviews.freebsd.org/D38750
The nfsd(8) daemon generates an error message that does not
indicate that the nfsd daemon is already running when the nfssvc(2)
syscall fails for the NFSSVC_STABLERESTART. Also, the check for
running nfsd(8) in a vnet prison will return EPERM when it fails.
This patch replaces EPERM with ENXIO so that the nfsd(8) daemon
can generate more reasonable failure messages. The nfsd(8) daemon
will be patched in a future commit.
MFC after: 3 months
If there are multiple instances of mountd(8) (in different
prisons), there will be confusion if they manipulate the
exports of the same file system. This patch adds mnt_exjail
to "struct mount" so that the credentials (and, therefore,
the prison) that did the exports for that file system can
be recorded. If another prison has already exported the
file system, vfs_export() will fail with an error.
If mnt_exjail == NULL, the file system has not been exported.
mnt_exjail is checked by the NFS server, so that exports done
from within a different prison will not be used.
The patch also implements vfs_exjail_destroy(), which is
called from prison_cleanup() to release all the mnt_exjail
credential references, so that the prison can be removed.
Mainly to avoid doing a scan of the mountlist for the case
where there were no exports done from within the prison,
a count of how many file systems have been exported from
within the prison is kept in pr_exportcnt.
Reviewed by: markj
Discussed with: jamie
Differential Revision: https://reviews.freebsd.org/D38371
MFC after: 3 months
Another oopsie. The vnet initialization function in
nfs_commonport.c for initializing prison0 by testing
curthread->td_ucred->cr_prison == &prison0. This is bogus
and always true. Replace it with IS_DEFAULT_VNET(curvnet).
MFC after: 3 months
Although the nfsclient syscall is used for client side,
it does set up server side krpc for callbacks. As such,
it needs to have the vnet set. This patch does this.
Without this patch, the system would crash when the
nfscbd(8) daemon was killed.
Reported by: freebsd@walstatt-de.de
MFC after: 3 months
The previous fix was incorrect: we need to verify that the current node, if it exists, is not a directory, but we were checking the parent node instead. Address this, add more tests, and fix the test cleanup routines.
PR: 269519, 269561
Fixes: ae6cff8973
Sponsored by: Juniper Networks, Inc.
Sponsored by: Klara, Inc.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D38645
Commit ed03776ca7 enabled the vnet front end macros.
As such, for kernels built with the VIMAGE option will malloc
data and initialize locks on a per-vnet basis, typically
via a VNET_SYSINIT().
This patch adds VNET_SYSUNINIT() macros to do the frees
of the per-vnet malloc'd data and destroys of per-vnet
locks. It also removes the mtx_lock/mtx_unlock calls
from nfsrvd_cleancache(), since they are not needed.
Discussed with: bz, jamie
MFC after: 3 months
Several commits have added front end macros for the vnet
macros to the NFS server, krpc and kgssapi. These macros
are now null, but this patch changes them to front end
the vnet macros.
With this commit, many global variables in the code become
vnet'd, so that nfsd(8), nfsuserd(8), rpc.tlsservd(8) and
gssd(8) can run in a vnet prison, once enabled.
To run the NFS server in a vnet prison still requires a
couple of patches (in D37741 and D38371) that allow mountd(8)
to export file systems from within a vnet prison. Once
these are committed to main, a small patch to kern_jail.c
allowing "allow.nfsd" without VNET_NFSD defined will allow
the NFS server to run in a vnet prison.
One area that still needs to be settled is cleanup when a
prison is removed. Without this, everything should work
except there will be a leak of malloc'd data and mutex locks
when a vnet prison is removed.
MFC after: 3 months
Although it is not 100% obvious if the affinity threads
lists need to be vnet'd when nfsd runs in a prison, I
think it is necessary for the unusual case where the
same file system is exported in multiple prisons.
For this case, the affinity code might try to assign
the RPC to a svc thread that runs in a different prison.
Also, it makes sense to vnet them, since there are
separate svc threads for each prison running nfsd(8).
This patch adds the macros for vnet'ng to nfs_fha_new.c.
The macros are still null, so the only semantics change
is malloc'ng the fha_param structure.
MFC after: 3 months
Since svcpool_create() is now called from an initialization function,
the pool field of fha_params is always non-NULL, so just get
rid of it and the useless check for it being NULL.
MFC after: 3 months
Commit 9d329bbc9a converted a lot of accesses to nfsstatsv1
to use nfsstatsv1_p instead. However, the accesses in
nfs_commonkrpc.c are for client side and should not be
converted. This patch puts them back in the correct
pre-commit 9d329bbc9a form.
MFC after: 3 months
Commit 7344856e3a6d added a lot of macros that will front end
vnet macros so that nfsd(8) can run in vnet prison.
The nfsstatsv1_p variable got missed. This patch wraps all
uses of nfsstatsv1_p with the NFSD_VNET() macro.
The NFSD_VNET() macro is still a null macro.
MFC after: 3 months
VOP_ISLOCKED() does not return bool, its only reliable use it to check
that the vnode is exclusively locked by the calling thread. Almost all
asserts of this form repeated auto-generated assertions from
vnode_if.src for VOPs, in the incorrect way.
In two places where the assertions would be meaningful, convert them to
ASSERT_VOP_LOCKED() statements.
Reviewed by: markj, mjg
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D38576
Commit 7344856e3a6d added a lot of macros that will front end
vnet macros so that nfsd(8) can run in vnet prison.
This patch adds some more, to allow the nfsuserd(8) daemon to
run in vnet prison, once the macros map to vnet ones.
This is the last commit for NFSD_VNET_xxx macros, but there are
still some for KRPC_VNET_xxx and KGSS_VNET_xx to allow the
rpc.tlsservd(8) and gssd(8) daemons to run in a vnet prison.
MFC after: 3 months
fusefs would leak tickets in three cases:
* After FUSE_CREATE, if the server returned a bad inode number.
* After a FUSE_FALLOCATE operation during VOP_ALLOCATE
* After a FUSE_FALLOCATE operation during VOP_DEALLOCATE
MFC after: 3 days
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D38526
Protect the call with the node lock. We cannot lock the fvp vnode
sleepable there, because we already own other participating vnode's
locks. Taking it without sleeping require unwinding the whole locking
state in one more place.
Note that the liveness of the node is guaranteed by the lock on the
parent directory vnode.
Reported and tested by: pho
Fixes: cbac1f3464956185cf95955344b6009e2cc3ae40ESC
Reviewed by: markj, mjg
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D38557
The helper tmpfs_access_locked() requires either the vnode or node
locked for consistency of the access check, unlike the pure vnode op.
Reviewed by: markj, mjg
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D38557
Commit 7344856e3a6d added a lot of macros that will front end
vnet macros so that nfsd(8) can run in vnet prison.
This patch adds some more of them and also a lot of uses of
nfsstatsv1_p instead of nfsstatsv1. nfsstatsv1_p points to
nfsstatsv1 for prison0, but will point to a malloc'd structure
for other prisons.
It also puts nfsstatsv1_p in nfscommon.ko instead of nfsd.ko.
MFC after: 3 months
Suppose that the cluster size is larger than page size. If the buffer
at the old EOF (before extending) was partial and dirty, it cannot be
automatically neither written out nor validated by the buffer cache,
since extending buffer adds invalid pages at the end.
Correct the buffer state by calling vfs_bio_clrbuf() on it, to mark
newly added and zeroed pages as valid.
Note that UFS is immune to the problem because ffs_truncate() always
allocate the block and buffer for the last byte of the file.
PR: 269341
Reported by: asomers
In collaboration with: pho
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D38549
If extension fails, vnode pager recorded size might be left increased.
Only update vnode pager when extension is past the point of no rollback.
Reviewed by: markj
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D38549
Commit 7344856e3a6d added a lot of macros that will front end
vnet macros so that nfsd(8) can run in vnet prison.
This patch adds some more of them.
MFC after: 3 months
Oops, although the vneting macros do not do anything yet,
commit 7344856e3a6d did change where things are initialized
and one of the initialization functions was not being called
early enough. This patch moves nfsrvd_init(0) to the
function called via (VNET_)SYSINIT() to fix this.
Reported by: olivier
MFC after: 3 months
Oops, although the vneting macros do not do anything yet,
commit 7344856e3a6d enabled the prison cleanup function, that
would get called and crash the system when a jail was terminated.
This patch gets rid of nfsrv_prison_cleanup() for now.
It can go in when the vnet macros are enabled as
front ends to the vnet macros.
MFC after: 3 months
This patch defines null macros that can be used to apply
the vnet macros for global variables and SYSCTL flags.
It also applies these macros to many of the global variables
and some of the SYSCTLs. Since the macros do nothing, these
changes should not result in semantics changes, although the
changes are large in number.
The patch does change several global variables that were
arrays or structures to pointers to same. For these variables,
modified initialization and cleanup code malloc's and free's
the arrays/structures. This was done so that the vnet footprint
would be about 300bytes when the macros are defined as vnet macros,
allowing nfsd.ko to load dynamically.
I believe the comments in D37519 have been addressed, although
it has never been reviewed, due in part to the large size of the patch.
This is the first of a series of patches that will put D37519 in main.
Once everything is in main, the macros will be defined as front
end macros to the vnet ones.
MFC after: 3 months
Differential Revision: https://reviews.freebsd.org/D37519
Commit ded5f2954e defined done_namei to indicate that
nd_repstat was set after a successful nfsvno_namei(),
so that a cleanup needs to be done in nfsvno_open().
This only happens when nfsvno_namei() is done with CREATE.
This patch adds a KASSERT() to check for that.
PR: 268971
Fix rename when renamed directory not owned by user,
but when user owns the sticky parent directory.
Reviewed by: kib
MFC after: 2 week
Differential revision: https://reviews.freebsd.org/D38245
Commit ded5f2954e defined done_namei to indicate that
nd_repstat was set after a successful nfsvno_namei(),
so that a cleanup needs to be done in nfsvno_open().
However, it missed the case where a call to
nfsrv_opencheck() in nfsvno_open() sets nd_repstat non-zero.
This would cause panics due to a dangling locked vnode
when nfsrv_opencheck() set nd_repstat, such as during grace
just after a server boot.
This patch fixes the problem.
PR: 268971
* tarfs_alloc_mount(): Remove an unnecessary null check (CID 1504505) and an unused variable.
* tarfs_alloc_one(): Verify that the file size is not negative (CID 1504506). While there, also validate the mode, owner and group.
* tarfs_vget(), tarfs_zio_init(): Explicitly ignore return value from getnewvnode(), which cannot fail (CID 1504508)
* tarfs_lookup_path(): Fix a case where a specially-crafted tarball could trigger a null pointer dereference by first descending into, and then backing out of, a previously unknown directory. (CID 1504515)
* mktar: Construct a tarball that triggers the aforementioned null pointer dereference.
Reported by: Coverity
Sponsored by: Juniper Networks, Inc.
Sponsored by: Klara, Inc.
Reviewed by: imp, kib
Differential Revision: https://reviews.freebsd.org/D38463
asomers@ found a problem with the NFS client, where a write to
an NFS mounted file done via mmap(2) was lost when fspacectl(2)
was done before it. This turned out to be caused by clearing the
dirty bit on pages when the client was doing commit RPCs,
due to the second argument to vfs_busy_pages() being set to 1.
Commit RPCs tell the server to commit previously written data to
stable storage. However, Commit RPCs do not write data from the
client to the server. As such, if the dirty bit on the page has
been set by a mmap'd write to an address in the page, it should
not be cleared. Clearing it causes the mmap'd write to by lost.
This patch fixes the problem by changing the 2nd argument to
vfs_busy_pages() to 0 for this case.
I doubt this bug has affected many, since it was inherited from
the old NFS client and was in 4.3 FreeBSD twenty years ago.
Although fspacectl(2) is FreeBSD 14 specific, a write(2) would
cause the same failure.
Reviewed by: kib
Tested by: asomers
PR: 269328
MFC after: 1 week
Using done_namei instead of ni_startdir did not
fix the crashes reported in the PR. Upon looking
more closely at the code, the only case where the
code near the end of nfsvno_open() needs to be
executed is when nfsvno_namei() has succeeded,
but a subsequent error was detected.
This patch uses done_namei to indicate this case.
Also, nfsvno_relpathbuf() should only be called for
this case and not whenever nfsvno_open() is called
with nd_repstat != 0. A bug was introduced here when
the HASBUF flag was deleted.
Reviewed by: mjg
PR: 268971
Tested by: ish@amail.plala.or.jp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D38430
Some of the code in sys/fs/tarfs/tarfs_io.c is not specific to zstd, but is still only used when some form of decompression is enabled. Put it behind #ifdef TARFS_ZIO to silence warnings.
Sponsored by: Juniper Networks, Inc.
Sponsored by: Klara, Inc.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D38415
The extattrs follows semantic of ufs, mean it cannot
be set to char/block devices and fifos. The attributes
are allocated using regular malloc with M_WAITOK
allocation with the own malloc tag M_TMPFSEA. The memory
consumed by extended attributes is limited to avoid OOM
triggereing by tmpfs_mount variable tm_ea_memory_max,
which is set initialy to 16 MB. The extended attributes
entries are stored as linked list in the tmpfs node.
The mount point lock is required only under setextattr
and deleteextattr to update extended attributes
memory-inuse counter, all other operations are doing
under vnode lock.
Reviewed by: kib
MFC after: 2 week
Differential revision: https://reviews.freebsd.org/D38052
This test creates two files like file0 and file1,
then creates link to file1 and checks ctime on it.
Then renames file0 to file1. Then checks ctime on
link again. It is expected, that second ctime will
be higher then first ctime, because rename happen.
Add ctime updating for directory entry,
which will be deleted on rename.
Reviewed by: kib
MFC after: 2 week
Differential revision: https://reviews.freebsd.org/D38051
The rename call with args like:
"./dir0/dir1/.." "./dir2" will cause MPASS failure.
The tmpfs_dir_lookup() does not accept names like
'.' and '..' for lookup. Move the '.' and '..' entry
check before tmpfs_dir_lookup() call.
Reviewed by: kib
MFC after: 2 week
Differential revision: https://reviews.freebsd.org/D38051
For NFSv4.1/4.2, when the client specifies SP4_NONE for
state protection in the ExchangeID operation arguments,
the server MUST allow the state management operations for
any user credentials. (I misread the RFC and thought that
SP4_NONE meant "at the server's discression" and not MUST
be allowed.)
This means that the "sec=XXX" field of the "V4:" exports(5)
line only applies to NFSv4.0.
This patch fixes the server to always allow state management
operations for SP4_NONE, which is the only state management
option currently supported. (I have patches that add support
for SP4_MACH_CRED to the server. These will be in a future commit.)
In practice, this bug does not seem to have caused
interoperability problems.
MFC after: 2 weeks
There is no point in clearing just this flag. Flags are reset on the
struct mount re-allocation for reuse anyway.
Reviewed by: mckusick
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D37966
Commit 65127e982b removed a check for ni_startdir != NULL.
This allowed the vrele(ndp->ni_dvp) to be called with
a NULL argument.
This patch adds a new boolean argument to nfsvno_open()
that can be checked instead of ni_startdir, since mjg@ requested
that ni_startdir not be used. (Discussed in PR#268828.)
PR: 268828
Reviewed by: mjg
Differential Revision: https://reviews.freebsd.org/D38032
The usual reason for an NFSv4 server replying NFSERR_WRONGSEC
to an operation is that a Kerberos credential is required.
This patch replaces a cryptic "err=10016" with a message
suggesting that a Kerberos TGT is probably needed.
MFC after: 2 weeks
To quote from a comment above vput_final:
<quote>
* XXX Some filesystems pass in an exclusively locked vnode and strongly depend
* on the lock being held all the way until VOP_INACTIVE. This in particular
* happens with UFS which adds half-constructed vnodes to the hash, where they
* can be found by other code.
</quote>
As is there is no mechanism which allows filesystems to denote that a
vnode is fully initialized, consequently problems like the above are
only found the hard way(tm).
Add rudimentary support for state transitions, which in particular allow
to assert the vnode is not legally unlocked until its fate is decided
(either construction finishes or vgone is called to abort it).
The new field lands in a 1-byte hole, thus it does not grow the struct.
Bump __FreeBSD_version to 1400077
Reviewed by: kib (previous version)
Tested by: pho
Differential Revision: https://reviews.freebsd.org/D37759
While there, move all error checks into the common place at the start,
and eliminate the 'out' label.
PR: 268528
Analyzed and tested by: Mark Millard <marklmi@yahoo.com>
Reviewed by: mckusick
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D37866
Unlike NFSv3, the NFSv4 server follows mount points
within the file system tree below the NFSv4 root directory.
If there is a file system mounted within this subtree
that returns EOPNOTSUPP for VOP_VPTOFH(), the NFSv4 server
would return an error for the mount point entry.
This resulted in an "I/O error" report from the Linux NFSv4
client. It also put an error code in the Readdir reply
that is not defined in the NFSv4 RFCs.
For the FreeBSD NFSv4 client, the entry with the error would
be ignored, which I think is reasonable behaviour for a
mounted file system that can never be exported.
This patch changes the NFSv4 server behaviour to ignore the
mount point entry and not send it in the Readdir reply.
It also changes the behaviour of Lookup for the entry so
that it replies ENOENT for the mount point directory, so
that it is consistent with no entry in the Readdir reply.
With these two changes, the Linux client behaviour is the
same as the FreeBSD client behaviour. It also avoids
putting an unknown error on the wire to the client.
MFC after: 1 week
Since a NFSERR_NOFILEHANDLE reply from an NFSv4 server
usually means that the file system is not exported on
the server, change the console log message to indicate
that.
MFC after: 1 week
The main use-case for this is to support mounting config files and
secrets into OCI containers. My current workaround copies the files into
the container which is messy and risks secrets leaking into container
images if the cleanup fails.
This adds a VFCF flag to indicate whether the filesystem supports file
mounts and allows fspath to be either a directory or a file if the flag
is set.
Test Plan:
$ sudo mkdir -p /mnt
$ sudo touch /mnt/foo
$ sudo mount -t nullfs /COPYRIGHT /mnt/foo
Reviewed by: mjg, kib
Tested by: pho
instead of looking at SAVESTART
This is a step towards removing the flag.
Reviewed by: mckusick
Tested by: pho
Differential Revision: https://reviews.freebsd.org/D34468
Only the name is wanted which is already always provided.
Reviewed by: rmacklem
Tested by: pho, rmacklem
Differential Revision: https://reviews.freebsd.org/D34470
Torn reads are only possible for 32bit arches.
Requested by: mjg
Reviewed by: mjg, markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D37725
When the lower filesystem directory hierarchy is the same as the nullfs
mount point (admittedly not likely to be a useful situation in
practice), nullfs is subject to the exact deadlock between the busy
count drain and the covered vnode lock that VV_CROSSLOCK is intended
to address.
Reviewed by: kib
Tested by: pho
Differential Revision: https://reviews.freebsd.org/D37458
When taking the covered vnode lock during mount and unmount operations,
specify LK_CANRECURSE as the existing lock state of the covered vnode
is not guaranteed (AFAIK) either by assertion or documentation for
these code paths.
For the mount path, this is done only for completeness as the covered
vnode lock is not currently held when VFS_MOUNT() is called.
For the unmount path, the covered vnode is currently held across
VFS_UNMOUNT(), and the existing code only happens to work when unionfs
is mounted atop FFS because FFS sets LO_RECURSABLE on its vnode locks.
This of course doesn't cover a hypothetical case in which the covered
vnode may be held shared, but for the mount and unmount paths such a
scenario seems unlikely to materialize.
Reviewed by: kib
Tested by: pho
Differential Revision: https://reviews.freebsd.org/D37458
This makes tmpfs size accounting correct for the sparce files. Also
correct report st_blocks/va_bytes. Previously the reported value did not
accounted for the swapped out pages.
PR: 223015
Reviewed by: markj
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D37097
The vnode could be reclaimed and allocated again during the lifecycle of
the node, but the node cannot. Also, referencing the node would allow
to reach it and tmpfs mount data from the object, regardless of the
state of the possibly absent vnode.
Still use swp_tmpfs for back-pointer, instead of using handle. Use of
named swap objects would incur taking the sw_alloc_sx on node allocation
and deallocation.
swp_tmpfs is renamed to swp_priv to remove the last bit of tmpfs in vm/.
Reviewed by: markj
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D37097
