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
When a lookup operation crosses into a new mountpoint, the mountpoint
must first be busied before the root vnode can be locked. When a
filesystem is unmounted, the vnode covered by the mountpoint must
first be locked, and then the busy count for the mountpoint drained.
Ordinarily, these two operations work fine if executed concurrently,
but with a stacked filesystem the root vnode may in fact use the
same lock as the covered vnode. By design, this will always be
the case for unionfs (with either the upper or lower root vnode
depending on mount options), and can also be the case for nullfs
if the target and mount point are the same (which admittedly is
very unlikely in practice).
In this case, we have LOR. The lookup path holds the mountpoint
busy while waiting on what is effectively the covered vnode lock,
while a concurrent unmount holds the covered vnode lock and waits
for the mountpoint's busy count to drain.
Attempt to resolve this LOR by allowing the stacked filesystem
to specify a new flag, VV_CROSSLOCK, on a covered vnode as necessary.
Upon observing this flag, the vfs_lookup() will leave the covered
vnode lock held while crossing into the mountpoint. Employ this flag
for unionfs with the caveat that it can't be used for '-o below' mounts
until other unionfs locking issues are resolved.
Reported by: pho
Tested by: pho
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D35054
providing the support for lseek(2) SEEK_DATA and SEEK_HOLE.
Reviewed by: markj
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D37024
When the user specifies SEEK_END, unlike SEEK_CUR, VOP_ADVLOCK must
adjust lock offsets itself.
Sort-of related to bug 266886.
MFC after: 2 weeks
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D37040
When the NFS server does the Setxattr or Rmxattr operation,
the Change attribute (va_filerev) needs to be updated.
Without this patch, that was not happening for the
pNFS server configuration. This patch does a Setattr
against the DS file to make the Change attribute
change.
This bug was discovered during a recent IETF NFSv4 testing
event, where the Change attribute wasn't changed in the
operation reply.
MFC after: 1 month
When the NFS server does Setxattr or Removexattr, the
operations must be done IO_SYNC. If a server
crashes/reboots immediately after replying it must
have the extended attribute changes.
Since UFS does extended attributes asynchronously
by default and there is no "ioflag" argument in
the VOP calls, follow the VOP calls with VOP_FSYNC(),
to ensure the operation has been done synchronously.
This was found by inspection while investigating a
bug discovered during a recent IETF NFSv4 testing
event, where the Change attribute wasn't changed
in the operation reply.
This bug will take further work for ZFS and the
pNFS server configuration, but is now fixed for
a non-pNFS UFS exported file system.
MFC after: 1 month
Commit efe58855f3 modifies IN_LOOPBACK() so that it uses a VNET
variable. Without this patch, nfscl_getmyip() uses IN_LOOPBACK()
when the VNET is not set and crashes the system.
nfscl_getmyip() is only called when a NFSv4.0 (not NFSv4.1/4.2)
mount is done.
This patch re-organizes nfscl_getmyip() so that IN_LOOPBACK()
is before the CURVENT_RESTORE() macro, to avoid the crashes.
Reviewed by: karels, zlei.huang_gmail.com
Differential Revision: https://reviews.freebsd.org/D37008
When doing small reads and writes use an intermediate buffer to store the
data to save locking the remote process to access data.
Reviewed by: imp @
Differential Revision: https://reviews.freebsd.org/D36633
MFC after: 1 week
Sponsored by: NVIDIA Networking
Commit ab17854f97 fixed access to v_mount when the
vnode is unlocked for nfs_copy_file_range().
This patch does the same for nfs_advlockasync().
MFC after: 1 week
Commit ab17854f97 fixed access to v_mount when the
vnode is unlocked for nfs_copy_file_range().
This patch does the same for nfs_ioctl().
Reviewed by: kib, markj
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D36846
and we checked that it is not reclaimed.
Reviewed by: markj, rmacklem
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D36722
