#
346779 |
|
27-Apr-2019 |
rmacklem |
MFC: r346191 Add support for INET6 addresses to the kernel code that dumps open/lock state.
PR#223036 reported that INET6 callback addresses were not printed by nfsdumpstate(8). This kernel patch adds INET6 addresses to the dump structure, so that nfsdumpstate(8) can print them out, post-r346190.
|
#
338132 |
|
21-Aug-2018 |
rmacklem |
MFC: r336839 Modify the NFSv4.1 server so that it allows ReclaimComplete as done by ESXi 6.7.
I believe that a ReclaimComplete with rca_one_fs == TRUE is only to be used after a file system has been transferred to a different file server. However, RFC5661 is somewhat vague w.r.t. this and the ESXi 6.7 client does both a ReclaimComplete with rca_one_fs == TRUE and one with ReclaimComplete with rca_one_fs == FALSE. Therefore, just ignore the rca_one_fs == TRUE operation and return NFS_OK without doing anything instead of replying NFS4ERR_NOTSUPP. This allows the ESXi 6.7 NFSv4.1 client to do a mount. After discussion on the NFSv4 IETF working group mailing list, doing this along with setting a flag to note that a ReclaimComplete with rca_one_fs TRUE was an appropriate way to handle this. The flag that indicates that a ReclaimComplete with rca_one_fs == TRUE was done may be used to disable replies of NFS4ERR_GRACE for non-reclaim state operations in a future commit.
This patch along with r332790, r334492 and r336357 allow ESXi 6.7 NFSv4.1 mounts work ok. ESX 6.5 NFSv4.1 mounts do not work well, due to what I believe are violations of RFC-5661 and should not be used.
|
#
337058 |
|
01-Aug-2018 |
rmacklem |
MFC: r336357 Modify the reasons for not issuing a delegation in the NFSv4.1 server.
The ESXi NFSv4.1 client will generate warning messages when the reason for not issuing a delegation is two. Two refers to a resource limit and I do not see why it would be considered invalid. However it probably was not the best choice of reason for not issuing a delegation. This patch changes the reasons used to ones that the ESXi client doesn't complain about. This change does not affect the FreeBSD client and does not appear to affect behaviour of the Linux NFSv4.1 client. RFC5661 defines these "reasons" but does not give any guidance w.r.t. which ones are more appropriate to return to a client.
|
#
336846 |
|
28-Jul-2018 |
rmacklem |
MFC: r334492 Add the BindConnectiontoSession operation to the NFSv4.1 server.
Under some fairly unusual circumstances, the Linux NFSv4.1 client is doing a BindConnectiontoSession operation for TCP connections. It is also used by the ESXi6.5 NFSv4.1 client. This patch adds this operation to the NFSv4.1 server.
PR: 226493
|
#
336179 |
|
10-Jul-2018 |
rmacklem |
MFC: r333508 Add support for the TestStateID operation to the NFSv4.1 server.
The Linux client now uses the TestStateID operation, so this patch adds support for it to the NFSv4.1 server. The FreeBSD client never uses this operation, so it should not be affected.
|
#
334633 |
|
04-Jun-2018 |
rmacklem |
MFC: r333592 Fix the eir_server_scope reply argument for NFSv4.1 ExchangeID.
In the reply to an ExchangeID operation, the NFSv4.1 server returns a "scope" value (eir_server_scope). If this value is the same, it indicates that two servers share state, which is never the case for FreeBSD servers. As such, the value needs to be unique and it was without this patch. However, I just found out that it is not supposed to change when the server reboots and without this patch, it did change. This patch fixes eir_server_scope so that it does not change when the server is rebooted. The only affect not having this patch has is that Linux clients don't reclaim opens and locks after a server reboot, which meant they lost any byte range locks held before the server rebooted. It only affects NFSv4.1 mounts and the FreeBSD NFSv4.1 client was not affected by this bug.
|
#
325448 |
|
05-Nov-2017 |
rmacklem |
MFC: r324639 Fix the client IP address reported by nfsdumpstate for 64bit arch and NFSv4.1.
The client IP address was not being reported for some NFSv4 mounts by nfsdumpstate. Upon investigation, two problems were found for mounts using IPv4. One was that the code (originally written and tested on i386) assumed that a "u_long" was a "uint32_t" and would exactly store an IPv4 host address. Not correct for 64bit arches. Also, for NFSv4.1 mounts, the field was not being filled in. This was basically correct, because NFSv4.1 does not use a callback address. However, it meant that nfsdumpstate could not report the client IP addr. This patch should fix both of these issues. For IPv6, the address will still not be reported. The original NFSv4 RFC only specified IPv4 callback addresses. I think this has changed and, if so, a future commit to fix reporting of IPv6 addresses will be needed.
|
#
324544 |
|
11-Oct-2017 |
rmacklem |
MFC: r323978 Change a panic to an error return.
There was a panic() in the NFS server's write operation that didn't need to be a panic() and could just be an error return. This patch makes that change. Found by code inspection during development of the pNFS service.
|
#
300778 |
|
26-May-2016 |
rmacklem |
MFC: r299514 Fix use-after-free in NFS4 lock test service.
Trivial use-after-free where stp was freed too soon in the non-error path. To fix, simply move its release to the end of the routine.
|
#
284216 |
|
10-Jun-2015 |
rmacklem |
MFC: r283635 Make the size of the hash tables used by the NFSv4 server tunable. No appreciable change in performance was observed after increasing the sizes of these tables and then testing with a single client. However, there was an email that indicated high CPU overheads for a heavily loaded NFSv4 and it is hoped that increasing the sizes of the hash tables via these tunables might help. The tables remain the same size by default.
|
#
282271 |
|
30-Apr-2015 |
rmacklem |
MFC: r281628 mav@ has found that NFS servers exporting ZFS file systems can perform better when using a 128K read/write data size. This patch changes NFS_MAXDATA from 64K to 128K so that clients can use 128K for NFS mounts to allow this. The patch also renames NFS_MAXDATA to NFS_SRVMAXIO so that it is clear that it applies to the NFS server side only. It also avoids a name conflict with the NFS_MAXDATA defined in rpcsvc/nfs_prot.h, that is used for userland RPC.
|
#
276500 |
|
01-Jan-2015 |
kib |
MFC r275897: Set NOCACHE flag for CREATE namei() calls, do not specially handle MAKEENTRY in VOP_LOOKUP().
|
#
269398 |
|
01-Aug-2014 |
rmacklem |
MFC: r268115 Merge the NFSv4.1 server code in projects/nfsv4.1-server over into head. The code is not believed to have any effect on the semantics of non-NFSv4.1 server behaviour. It is a rather large merge, but I am hoping that there will not be any regressions for the NFS server.
|
#
267343 |
|
10-Jun-2014 |
rmacklem |
MFC: r267191 The new NFS server would not allow a hard link to be created to a symlink. This restriction (which was inherited from OpenBSD) is not required by the NFS RFCs. Since this is allowed by the old NFS server, it is a POLA violation to not allow it. This patch modifies the new NFS server to allow this.
|
#
264266 |
|
08-Apr-2014 |
delphij |
Fix NFS deadlock vulnerability. [SA-14:05]
Fix "Heartbleed" vulnerability and ECDSA Cache Side-channel Attack in OpenSSL. [SA-14:06]
|
#
284216 |
|
10-Jun-2015 |
rmacklem |
MFC: r283635 Make the size of the hash tables used by the NFSv4 server tunable. No appreciable change in performance was observed after increasing the sizes of these tables and then testing with a single client. However, there was an email that indicated high CPU overheads for a heavily loaded NFSv4 and it is hoped that increasing the sizes of the hash tables via these tunables might help. The tables remain the same size by default.
|
#
282271 |
|
30-Apr-2015 |
rmacklem |
MFC: r281628 mav@ has found that NFS servers exporting ZFS file systems can perform better when using a 128K read/write data size. This patch changes NFS_MAXDATA from 64K to 128K so that clients can use 128K for NFS mounts to allow this. The patch also renames NFS_MAXDATA to NFS_SRVMAXIO so that it is clear that it applies to the NFS server side only. It also avoids a name conflict with the NFS_MAXDATA defined in rpcsvc/nfs_prot.h, that is used for userland RPC.
|
#
276500 |
|
01-Jan-2015 |
kib |
MFC r275897: Set NOCACHE flag for CREATE namei() calls, do not specially handle MAKEENTRY in VOP_LOOKUP().
|
#
269398 |
|
01-Aug-2014 |
rmacklem |
MFC: r268115 Merge the NFSv4.1 server code in projects/nfsv4.1-server over into head. The code is not believed to have any effect on the semantics of non-NFSv4.1 server behaviour. It is a rather large merge, but I am hoping that there will not be any regressions for the NFS server.
|
#
267343 |
|
10-Jun-2014 |
rmacklem |
MFC: r267191 The new NFS server would not allow a hard link to be created to a symlink. This restriction (which was inherited from OpenBSD) is not required by the NFS RFCs. Since this is allowed by the old NFS server, it is a POLA violation to not allow it. This patch modifies the new NFS server to allow this.
|
#
264266 |
|
08-Apr-2014 |
delphij |
Fix NFS deadlock vulnerability. [SA-14:05]
Fix "Heartbleed" vulnerability and ECDSA Cache Side-channel Attack in OpenSSL. [SA-14:06]
|