asomers [Mon, 1 Oct 2018 16:07:32 +0000 (16:07 +0000)]
MFC r336587:
tftpd(8): when completing an WRQ, flush the file before acknowleding receipt
tftpd(8) should flush a newly written file to disk before ACKing the final DATA
packet. Otherwise there is a narrow race window when a subsequent read may not
see the file. This is somewhat related to r330710, but the race window is much
smaller. Hopefully this will fix the intermittent tests in Jenkins.
Describe the role of tags and mapping objects as abstractions.
Describe static vs dynamic transaction types and give a brief overview
of the set of functions and object life cycles used for static vs
dynamic.
While here, fix a few other typos and expand a bit on parent tags.
gordon [Thu, 27 Sep 2018 18:48:50 +0000 (18:48 +0000)]
There are various cases where we modify the inp_vflag and inp_inc.inc_flags
fields during a syscall, but don't restore those fields if the operation
fails. This can leave the inp structure in an inconsistent state and cause
various problems.
Restore the inp_vflag and inp_inc.inc_flags fields when the underlying
operation fails and the inp could be in an inconsistent state.
This is a direct commit to the branch as the code is different enough in
the other branches to make it difficult to resolve a merge.
Submitted by: jtl@
Reported by: Jakub Jirasek, Secunia Research at Flexera
Reviewed by: jhb@
Approved by: so
Security: FreeBSD-EN-18:11.listen
Security: CVE-2018-6925
MFC r338754:
Update the pkg-stage.sh script used to populate packages on the
dvd1.iso installation medium from including KDE4 to KDE5, as the
KDE4-based ports have been marked as deprecated in the Ports
Collection.
mm [Wed, 19 Sep 2018 09:41:44 +0000 (09:41 +0000)]
MFC r338600:
Update libarchive to 3.3.3
As all important changes have already been merged from libarchive git
this is just a version number bump, documentation update and some
polishing for cpio tests. Other source code changes are not relevant to
FreeBSD.
MFC r338679:
Improve LibUSB debugging by simultaneously allowing both function
and transfer prints. Make sure the debug level comes from the
correct USB context.
MFC r338616:
Fix issues about cancelling USB transfers in LibUSB when the USB device has
been detached. When a USB device has been detached the kernel file handle
stops responding to commands. USB applications which continue to run after
the USB device has been detached, depend on LibUSB generated events to tear
down its pending USB transfers. Add code to handle the needed cleanup when
processing the USB transfer(s) fails and prevent new USB transfer(s) from
being submitted.
dim [Tue, 18 Sep 2018 20:46:55 +0000 (20:46 +0000)]
MFC r309748 (by glebius):
Treat R_X86_64_PLT32 relocs as R_X86_64_PC32.
If we load a binary that is designed to be a library, it produces
relocatable code via assembler directives in the assembly itself
(rather than compiler options). This emits R_X86_64_PLT32 relocations,
which are not handled by the kernel linker.
marius [Thu, 13 Sep 2018 10:18:50 +0000 (10:18 +0000)]
MFC: r333614, r333647, r338275, r338280, r338513
- Let mmcsd_ioctl() ensure appropriate privileges via priv_check(9).
- If present, take advantage of the R/W cache of eMMC revision 1.5 and
later devices. These caches work akin to the ones found in HDDs/SSDs
that ada(4)/da(4) also enable if existent, but likewise increase the
likelihood of data loss in case of a sudden power outage etc. On the
other hand, write performance is up to twice as high for e. g. 1 GiB
files depending on the actual chip and transfer mode employed.
For maximum data integrity, the usage of eMMC caches can be disabled
via the hw.mmcsd.cache tunable.
- Get rid of the NOP mmcsd_open().
- Obtain the bus mode (MMC or SD) from the directly superordinated
bus rather than reaching up to the bridge and use the cached mode
in mmcsd_delete(), too.
- Use le32dec(9) for decoding EXT_CSD values where it makes sense. [1]
- Locally cache some instance variable values in mmc_discover_cards()
in order to improve the code readability a bit.
marius [Thu, 13 Sep 2018 09:26:16 +0000 (09:26 +0000)]
MFC: r333613
The broken DDR52 support of Intel Bay Trail eMMC controllers rumored
in the commit log of r321385 has been confirmed via the public VLI54
erratum. Thus, stop advertising DDR52 for these controllers.
Note that this change should hardly make a difference in practice as
eMMC chips from the same era as these SoCs most likely support HS200
at least, probably even up to HS400ES.
marius [Thu, 13 Sep 2018 09:20:07 +0000 (09:20 +0000)]
MFC: r338261, r338512
- According to section 2.2.5 of the SDHCI specification version 4.20,
SDHCI_TRNS_ACMD12 is to be set only for multiple-block read/write
commands without data length information, so don't unconditionally
set this bit. The result matches what e. g. Linux does.
- Section 2.2.19 of the SDHCI specification version 4.20 states that
SDHCI_ACMD12_ERR should be only valid if SDHCI_INT_ACMD12ERR is set
and hardware may clear SDHCI_ACMD12_ERR when SDHCI_INT_ACMD12ERR is
cleared (differing silicon behavior is specifically allowed, though).
Thus, read SDHCI_ACMD12_ERR before clearing SDHCI_INT_ACMD12ERR.
While at it, use the 16-bit accessor rather than the 32-bit one for
reading the 16-bit SDHCI_ACMD12_ERR.
- SDHCI_INT_TUNEERR isn't one of the ROC bits in SDHCI_INT_STATUS so
clear it explicitly.
- Add missing prototypes and sort them.
- Explicitly compare a pointer to NULL. The __builtin_expect() of clang
3.4.1 otherwise isn't able to cope with the expression.
MFC r338492:
Add support for receive side scaling stride, RSSS, in mlx5en(4).
The receive side scaling stride parameter is a value which define the interval
between active receive side queues. The traffic for the inactive queues is
redirected to the nearest active queue by use of modulus. The default value
of this parameter is one, which means all receive side queues are used.
The point of this feature is to redirect more traffic to fewer receive side
queues in order to take more advantage of sorted large receive offload,
sorted LRO. The sorted LRO works better when more packets are accumulated
per service interval.
marius [Wed, 5 Sep 2018 20:47:51 +0000 (20:47 +0000)]
MFC: r338304
The read accessors generated by __BUS_ACCESSOR() have the problem that
they don't check the result of BUS_READ_IVAR(9) and silently return stack
garbage on failure in case a bus doesn't implement a particular instance
variable for example. With MMC bridges not providing MMCBR_IVAR_RETUNE_REQ,
yet, this in turn can cause mmc(4) to get into a state in which re-tuning
seems to be necessary but is inappropriate, causing mmc_wait_for_request()
to fail. Thus, don't use __BUS_ACCESSOR() for mmcbr_get_retune_req() and
instead provide a version of the latter which returns retune_req_none if
reading MMCBR_IVAR_RETUNE_REQ fails.
Avoid printing extraneous function names when searching man page
database (apropos, man -k). This commit Replaces .SS with .SH,
similar to the man page provided by original heimdal (as in port).
Teach the EC2 AMI upload code to:
* Mark EBS snapshots as public,
* Announce new AMIs to an SNS topic, and
* Place the SVN branch and revision into the AMI "description".
eugen [Sat, 25 Aug 2018 10:42:44 +0000 (10:42 +0000)]
MFC 338013: bsnmpd(8): fix and optimize interface description processing
* correctly prepare a buffer to obtain interface description from a kernel
and truncate long description instead of dropping it altogether and
spamming logs;
* skip calling strlen() for each description and each SNMP request
for MIB-II/ifXTable's ifAlias.
* teach bsnmpd to allocate memory dynamically for interface descriptions
to decrease memory usage for common case and not to break
if long description occurs;
PR: 217763
Reviewed by: harti and others
Differential Revision: https://reviews.freebsd.org/D16459
rmacklem [Fri, 24 Aug 2018 22:48:19 +0000 (22:48 +0000)]
MFC: r337438
Allow newnfs_request() to retry all callback RPCs with an NFSERR_DELAY reply.
The code in newnfs_request() retries RPCs that get a reply of NFSERR_DELAY,
but exempts certain NFSv4 operations. However, for callback RPCs, there
should not be any exemptions at this time. The code would have erroneously
exempted the CBRECALL callback, since it has the same operation number as
the CLOSE operation.
This patch fixes this by checking for a callback RPC (indicated by clp != NULL)
and not checking for exempt operations for callbacks.
This would have only affected the NFSv4 server when delegations are enabled
(they are not enabled by default) and the client replies to CBRECALL with
NFSERR_DELAY. This may never actually happen.
Spotted during code inspection.
For use with things like BOOT_TAG=\"\" -- there are valid reasons to allow
empty strings, especially as these are usually being passed through as
options. The same argument could perhaps be made for the unquoted
variant in things like MODULES_OVERRIDE="", but it's not immediately clear
that this is an issue so I've left it untouched.
pfg [Wed, 22 Aug 2018 04:21:25 +0000 (04:21 +0000)]
MFC r337456:
msdosfs: fixes for Undefined Behavior.
These were found by the Undefined Behaviour GsoC project at NetBSD:
Do not change signedness bit with left shift.
While there avoid signed integer overflow.
Address both issues with using unsigned type.
msdosfs_fat.c:512:42, left shift of 1 by 31 places cannot be represented
in type 'int'
msdosfs_fat.c:521:44, left shift of 1 by 31 places cannot be represented
in type 'int'
msdosfs_fat.c:744:14, left shift of 1 by 31 places cannot be represented
in type 'int'
msdosfs_fat.c:744:24, signed integer overflow: -2147483648 - 1 cannot be
represented in type 'int [20]'
msdosfs_fat.c:840:13, left shift of 1 by 31 places cannot be represented
in type 'int'
msdosfs_fat.c:840:36, signed integer overflow: -2147483648 - 1 cannot be
represented in type 'int [20]'
cy [Wed, 22 Aug 2018 01:43:11 +0000 (01:43 +0000)]
MFC r338047:
The bucket index is subtracted by one at lines 2304 and 2314. When 0 it
becomes -1, except these are unsigned integers, so they become very large
numbers. Thus are always larger than the maximum bucket; the hash table
insertion fails causing NAT to fail.
This commit ensures that if the index is already zero it is not reduced
prior to insertion into the hash table.
cy [Wed, 22 Aug 2018 01:23:11 +0000 (01:23 +0000)]
MFC r338046:
Add handy DTrace probes useful in diagnosing NAT issues. DTrace probes
are situated next to error counters and/or in one instance prior to the
-1 return from various functions. This was useful in diagnosis of
PR/208566 and will be handy in the future diagnosing NAT failures.
cy [Wed, 22 Aug 2018 01:04:52 +0000 (01:04 +0000)]
MFC r338045:
Expose np (nat_t - an entry in the nat table structure) in the DTrace
probe when nat fails (label badnat). This is useful in diagnosing
failed NAT issues and was used in PR/208566.
rmacklem [Tue, 21 Aug 2018 11:17:25 +0000 (11:17 +0000)]
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.
cy [Tue, 21 Aug 2018 00:37:48 +0000 (00:37 +0000)]
MFC r337410:
Remove redundant and incorrect default definition of AF_INET6. AF_INET6
is defined in sys/socket.h where it's defined as 28.
A bit of trivia: On NetBSD AF_INET6 is defined as 24. On Solaris it is
defined as 26. This is probably why Darren defaulted to 26, because
ipfilter was originally written for SunOS 4 and Solaris many moons ago.
kp [Mon, 20 Aug 2018 15:43:08 +0000 (15:43 +0000)]
MFC r337969:
pf: Limit the maximum number of fragments per packet
Similar to the network stack issue fixed in r337782 pf did not limit the number
of fragments per packet, which could be exploited to generate high CPU loads
with a crafted series of packets.
Limit each packet to no more than 64 fragments. This should be sufficient on
typical networks to allow maximum-sized IP frames.
This addresses the issue for both IPv4 and IPv6.
Security: CVE-2018-5391
Sponsored by: Klara Systems
dim [Fri, 17 Aug 2018 06:31:30 +0000 (06:31 +0000)]
MFC r337322:
Fix build of hyperv with base gcc on i386
Summary:
Base gcc fails to compile `sys/dev/hyperv/pcib/vmbus_pcib.c` for i386,
with the following -Werror warnings:
cc1: warnings being treated as errors
/usr/src/sys/dev/hyperv/pcib/vmbus_pcib.c: In function 'new_pcichild_device':
/usr/src/sys/dev/hyperv/pcib/vmbus_pcib.c:567: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
/usr/src/sys/dev/hyperv/pcib/vmbus_pcib.c: In function 'vmbus_pcib_on_channel_callback':
/usr/src/sys/dev/hyperv/pcib/vmbus_pcib.c:940: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
/usr/src/sys/dev/hyperv/pcib/vmbus_pcib.c: In function 'hv_pci_protocol_negotiation':
/usr/src/sys/dev/hyperv/pcib/vmbus_pcib.c:1012: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
/usr/src/sys/dev/hyperv/pcib/vmbus_pcib.c: In function 'hv_pci_enter_d0':
/usr/src/sys/dev/hyperv/pcib/vmbus_pcib.c:1073: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
/usr/src/sys/dev/hyperv/pcib/vmbus_pcib.c: In function 'hv_send_resources_allocated':
/usr/src/sys/dev/hyperv/pcib/vmbus_pcib.c:1125: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
/usr/src/sys/dev/hyperv/pcib/vmbus_pcib.c: In function 'vmbus_pcib_map_msi':
/usr/src/sys/dev/hyperv/pcib/vmbus_pcib.c:1730: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
This is because on i386, several casts from `uint64_t` to a pointer
reduce the value from 64 bit to 32 bit.
For gcc, this can be fixed by an intermediate cast to uintptr_t. Note
that I am assuming the incoming values will always fit into 32 bit!
cy [Fri, 17 Aug 2018 02:46:36 +0000 (02:46 +0000)]
MFC r337558, r337560
r337558:
Identify the return value (rval) that led to the IPv4 NAT failure
in ipf_nat_checkout() and report it in the frb_natv4out and frb_natv4in
dtrace probes.
This is currently being used to diagnose NAT failures in PR/208566. It's
rather handy so this commit makes it available for future diagnosis and
debugging efforts.
PR: 208566
r337560:
Correct a comment. Should have been detected by ipf_nat_in() not
ipf_nat_out().
gjb [Thu, 16 Aug 2018 15:17:22 +0000 (15:17 +0000)]
MFC r337717, r337718:
r337717:
Add lang/python2, lang/python3, and lang/python to GCE images
to help avoid hard-coding 'python<MAJOR>.<MINOR>' in several
scripts in the client-side scripts. [1]
r337718:
Add a space between a variable and escaped new line.
PR: 230248 [1]
Sponsored by: The FreeBSD Foundation
brooks [Tue, 14 Aug 2018 16:25:09 +0000 (16:25 +0000)]
MFC r337508:
Terminate filter_create_ext() args with NULL, not 0.
filter_create_ext() is documented to take a NULL terminated set of
arguments. 0 is promoted to an int so this would fail on 64-bit
systems if the value was not passed in a register. On all currently
supported 64-bit architectures it is.
hselasky [Tue, 14 Aug 2018 11:44:11 +0000 (11:44 +0000)]
MFC r330657:
Use vport rather than physical-port MTU in mlx5en(4).
Set and report vport MTU rather than physical MTU,
The driver will set both vport and physical port mtu
and will rely on the query of vport mtu.
SRIOV VFs have to report their MTU to their vport manager (PF),
and this will allow them to work with any MTU they need
without failing the request.
Also for some cases where the PF is not a port owner, PF can
work with MTU less than the physical port mtu if set physical
port mtu didn't take effect.
hselasky [Tue, 14 Aug 2018 11:19:04 +0000 (11:19 +0000)]
MFC r336450:
Do not inline transmit headers and use HW VLAN tagging if supported by mlx5en(4).
Query the minimal inline mode supported by the card.
When creating a send queue, cache the queried mode and optimize the transmit
if no inlining is required. In this case, we can avoid touching the headers
cache line and avoid dirtying several more lines by copying headers into
the send WQEs. Also, if no inline headers are used, hardware assists in
the VLAN tag framing.
davidcs [Thu, 9 Aug 2018 01:39:47 +0000 (01:39 +0000)]
MFC r336695
Remove support for QLNX_RCV_IN_TASKQ - i.e., Rx only in TaskQ.
Added support for LLDP passthru
Upgrade ECORE to version 8.33.5.0
Upgrade STORMFW to version 8.33.7.0
davidcs [Thu, 9 Aug 2018 00:48:55 +0000 (00:48 +0000)]
MFC r336438
Fixes for the following issues:
1. Fix taskqueues drain/free to fix panic seen when interface is being
bought down and in parallel asynchronous link events happening.
2. Fix bxe_ifmedia_status()
Submitted by:Vaishali.Kulkarni@cavium.com and Anand.Khoje@cavium.com
jtl [Mon, 6 Aug 2018 17:46:28 +0000 (17:46 +0000)]
MFC r337384:
Address concerns about CPU usage while doing TCP reassembly.
Currently, the per-queue limit is a function of the receive buffer
size and the MSS. In certain cases (such as connections with large
receive buffers), the per-queue segment limit can be quite large.
Because we process segments as a linked list, large queues may not
perform acceptably.
The better long-term solution is to make the queue more efficient.
But, in the short-term, we can provide a way for a system
administrator to set the maximum queue size.
We set the default queue limit to 100. This is an effort to balance
performance with a sane resource limit. Depending on their
environment, goals, etc., an administrator may choose to modify this
limit in either direction.
Approved by: so
Security: FreeBSD-SA-18:08.tcp
Sponsored by: CVE-2018-6922
Relevant vendor changes:
Fix issue #948: out-of-bounds read in lha_read_data_none()
MFH r336854:
Sync libarchive with vendor.
Important vendor changes:
PR #993: Chdir to -C directory for metalog processing
OSS-Fuzz #4969: Check size of the extended time field in zip archives
PR #973: Record informational compression level in gzip header
asomers [Fri, 3 Aug 2018 14:45:53 +0000 (14:45 +0000)]
MFC r336205:
Don't acquire evclass_lock with a spinlock held
When the "pc" audit class is enabled and auditd is running, witness will
panic during thread exit because au_event_class tries to lock an rwlock
while holding a spinlock acquired upstack by thread_exit.
To fix this, move AUDIT_SYSCALL_EXIT futher upstack, before the spinlock is
acquired. Of thread_exit's 16 callers, it's only necessary to call
AUDIT_SYSCALL_EXIT from two, exit1 (for exiting processes) and kern_thr_exit
(for exiting threads). The other callers are all kernel threads, which
needen't call AUDIT_SYSCALL_EXIT because since they can't make syscalls
there will be nothing to audit. And exit1 already does call
AUDIT_SYSCALL_EXIT, making the second call in thread_exit redundant for that
case.
asomers [Fri, 3 Aug 2018 14:37:23 +0000 (14:37 +0000)]
MFC r335899:
auditd(8): register signal handlers interrutibly
auditd_wait_for_events() relies on read(2) being interrupted by signals,
but it registers signal handlers with signal(3), which sets SA_RESTART.
That breaks asynchronous signal handling. It means that signals don't
actually get handled until after an audit(8) trigger is received.
Symptoms include:
* Sending SIGTERM to auditd doesn't kill it right away; you must send
SIGTERM and then send a trigger with auditon(2).
* Same with SIGHUP
* Zombie child processes don't get reaped until auditd receives a trigger
sent by auditon. This includes children created by expiring audit trails
at auditd startup.
asomers [Fri, 3 Aug 2018 14:22:16 +0000 (14:22 +0000)]
MFC r334296:
Fix "Bad tailq" panic when auditing auditon(A_SETCLASS, ...)
Due to an oversight in r195280, auditon(A_SETCLASS, ...) would cause a tailq
element to get added to the tailq twice, resulting in a circular tailq. This
panics when INVARIANTS are on.
asomers [Fri, 3 Aug 2018 14:19:56 +0000 (14:19 +0000)]
MFC r330720:
tftpd: reject unknown opcodes
If tftpd receives a command with an unknown opcode, it simply exits 1. It
doesn't send an ERROR packet, and the client will hang waiting for one. Fix
it.
asomers [Fri, 3 Aug 2018 14:19:09 +0000 (14:19 +0000)]
MFC r330719:
tftpd: Abort on an WRQ access violation
On a WRQ (write request) tftpd checks whether the client has access
permission for the file in question. If not, then the write is prevented.
However, tftpd doesn't reply with an ERROR packet, nor does it abort.
Instead, it tries to receive the packet anyway.
The symptom is slightly different depending on the nature of the error. If
the target file is nonexistent and tftpd lacks permission to create it, then
tftpd will willingly receive the file, but not write it anywhere. If the
file exists but is not writable, then tftpd will fail to ACK to WRQ.
asomers [Fri, 3 Aug 2018 14:18:02 +0000 (14:18 +0000)]
MFC r330718:
tftpd: Verify world-writability for WRQ when using relative paths
tftpd(8) says that files may only be written if they already exist and are
publicly writable. tftpd.c verifies that a file is publicly writable if it
uses an absolute pathname. However, if the pathname is relative, that check
is skipped. Fix it.
Note that this is not a security vulnerability, because the transfer
ultimately doesn't work unless the file already exists and is owned by user
nobody. Also, this bug does not affect the default configuration, because
the default uses the "-s" option which makes all pathnames absolute.
asomers [Fri, 3 Aug 2018 14:17:11 +0000 (14:17 +0000)]
MFC r330710:
tftpd: Flush files as soon as they are fully received
On an RRQ, tftpd doesn't exit as soon as it's finished receiving a file.
Instead, it waits five seconds just in case the client didn't receive the
server's last ACK and decides to resend the final DATA packet.
Unfortunately, this created a 5 second delay from when the client thinks
it's done sending the file, and when the file is available for other
processes.
Fix this bug by closing the file as soon as receipt is finished.
PR: 157700
Reported by: Barry Mishler <barry_mishler@yahoo.com>
asomers [Fri, 3 Aug 2018 14:13:15 +0000 (14:13 +0000)]
MFC r330696, r330709, r330742, r331358
r330696:
Add some functional tests for tftpd(8)
tftpd(8) is difficult to test in isolation due to its relationship with
inetd. Create a test program that mimics the behavior of tftp(1) and
inetd(8) and verifies tftpd's response in several different scenarios.
These test cases cover all of the basic TFTP protocol, but not the optional
parts.
kib [Fri, 3 Aug 2018 14:12:37 +0000 (14:12 +0000)]
MFC r336683:
Extend ranges of the critical sections to ensure that context switch
code never sees FPU pcb flags not consistent with the hardware state.
asomers [Fri, 3 Aug 2018 14:08:39 +0000 (14:08 +0000)]
MFC r328266:
mlock(2): correct documentation for error conditions.
The man page is years out of date regarding errors. Our implementation _does_
allow unaligned addresses, and it _does_not_ check for negative lengths,
because the length is unsigned. It checks for overflow instead.
rmacklem [Wed, 1 Aug 2018 19:25:12 +0000 (19:25 +0000)]
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.
hselasky [Wed, 1 Aug 2018 11:08:52 +0000 (11:08 +0000)]
MFC r321686 and r330361:
Add inline functions to convert between sbintime_t and decimal time units.
Use them in some existing code that is vulnerable to roundoff errors.
hselasky [Wed, 1 Aug 2018 10:34:53 +0000 (10:34 +0000)]
MFC r330349 and r330362:
Allow pause_sbt() to catch signals during sleep by passing C_CATCH flag.
Define pause_sig() function macro helper similarly to other kernel functions
which catch signals. Update outdated function description.
Document pause_sig(9) and update prototypes for existing pause(9) and
pause_sbt(9) functions.
MFC: r336215
Ignore the cookie verifier for NFSv4.1 when the cookie is 0.
RFC5661 states that the cookie verifier should be 0 when the cookie is 0.
However, the wording is somewhat unclear and a recent discussion on the
nfsv4@ietf.org mailing list indicated that the NFSv4 server should ignore
the cookie verifier's value when the dirctory offset cookie is 0.
This patch deletes the check for this that would return NFSERR_BAD_COOKIE
when the verifier was not 0.
This was found during testing of the ESXi client against the NFSv4.1 server.
MFC: r335866
Fix the server side krpc so that the kernel nfsd threads terminate.
Occationally the kernel nfsd threads would not terminate when a SIGKILL
was posted for the kernel process (called nfsd (slave)). When this occurred,
the thread associated with the process (called "ismaster") had returned from
svc_run_internal() and was sleeping waiting for the other threads to terminate.
The other threads (created by kthread_start()) were still in svc_run_internal()
handling NFS RPCs.
The only way this could occur is for the "ismaster" thread to return from
svc_run_internal() without having called svc_exit().
There was only one place in the code where this could happen and this patch
stops that from happening.
Since the problem is intermittent, I cannot be sure if this has fixed the
problem, but I have not seen an occurrence of the problem with this patch
applied.
projects / FreeBSD / stable / 10.git / log