various: general adoption of SPDX licensing ID tags.Mainly focus on files that use BSD 2-Clause license, however the tool Iwas using misidentified many licenses so this was mostly a manual - error
various: general adoption of SPDX licensing ID tags.Mainly focus on files that use BSD 2-Clause license, however the tool Iwas using misidentified many licenses so this was mostly a manual - errorprone - task.The Software Package Data Exchange (SPDX) group provides a specificationto make it easier for automated tools to detect and summarize well knownopensource licenses. We are gradually adopting the specification, notingthat the tags are considered only advisory and do not, in any way,superceed or replace the license texts.No functional change intended.
show more ...
DIRDEPS_BUILD: Update dependencies.Sponsored by: Dell EMC Isilon
Fix typo when deregistering the VLAN unconfig event handlerSubmitted by: Masao Uebayashi <[email protected]>MFC after: 3 days
dirdeps.mk now sets DEP_RELDIR
Fix a lock up where we enter swapper() with interrupts disabled.In smp_rendezvous_cpus we expect to wait for all cpus to entersmp_rendezvous_action. If we call this holding a proc lock swapper may
Fix a lock up where we enter swapper() with interrupts disabled.In smp_rendezvous_cpus we expect to wait for all cpus to entersmp_rendezvous_action. If we call this holding a proc lock swapper mayattempt to also lock it, however as interrupts are disabled the cpu neverhandles the ipi. Because smp_rendezvous_action waits for all signaledcpus before contining it may get caught waiting for the cpu running swapperas the proc mutex will be unlocked after smp_rendezvous_cpus finishes.The fix is to enable interrupts in the configure stage as we should bedoing.MFC after: 1 week
Updated dependencies
Sync FreeBSD's bmake branch with Juniper's internal bmake branch.Requested by: Simon Gerraty <[email protected]>
mdoc: consistently spell our email addresses <[email protected]>Reviewed by: ru
The last big commit: let usr.sbin/ use WARNS=6 by default.
Add missing library dependency.
Add the new kernel-mode NFS Lock Manager. To use it instead of theuser-mode lock manager, build a kernel with the NFSLOCKD option andadd '-k' to 'rpc_lockd_flags' in rc.conf.Highlights include:
Add the new kernel-mode NFS Lock Manager. To use it instead of theuser-mode lock manager, build a kernel with the NFSLOCKD option andadd '-k' to 'rpc_lockd_flags' in rc.conf.Highlights include:* Thread-safe kernel RPC client - many threads can use the same RPC client handle safely with replies being de-multiplexed at the socket upcall (typically driven directly by the NIC interrupt) and handed off to whichever thread matches the reply. For UDP sockets, many RPC clients can share the same socket. This allows the use of a single privileged UDP port number to talk to an arbitrary number of remote hosts.* Single-threaded kernel RPC server. Adding support for multi-threaded server would be relatively straightforward and would follow approximately the Solaris KPI. A single thread should be sufficient for the NLM since it should rarely block in normal operation.* Kernel mode NLM server supporting cancel requests and granted callbacks. I've tested the NLM server reasonably extensively - it passes both my own tests and the NFS Connectathon locking tests running on Solaris, Mac OS X and Ubuntu Linux.* Userland NLM client supported. While the NLM server doesn't have support for the local NFS client's locking needs, it does have to field async replies and granted callbacks from remote NLMs that the local client has contacted. We relay these replies to the userland rpc.lockd over a local domain RPC socket.* Robust deadlock detection for the local lock manager. In particular it will detect deadlocks caused by a lock request that covers more than one blocking request. As required by the NLM protocol, all deadlock detection happens synchronously - a user is guaranteed that if a lock request isn't rejected immediately, the lock will eventually be granted. The old system allowed for a 'deferred deadlock' condition where a blocked lock request could wake up and find that some other deadlock-causing lock owner had beaten them to the lock.* Since both local and remote locks are managed by the same kernel locking code, local and remote processes can safely use file locks for mutual exclusion. Local processes have no fairness advantage compared to remote processes when contending to lock a region that has just been unlocked - the local lock manager enforces a strict first-come first-served model for both local and remote lockers.Sponsored by: Isilon SystemsPR: 95247 107555 115524 116679MFC after: 2 weeks