Revert "libusb: change callback register handler to int"
This reverts commit ce9ced951a0b9d004a3b007d4ac6e9087a1301a2.
We should handle backward compatibility before introducing this patch as
people may rely on old ABI.
libusb: fix incorrect status type when completion on cancel the events
Reviewed by: lwhsu, markj
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D51736
libusb: change callback register handler to int
libusb upstream uses int for register handler. This causes some library
user (like pyusb) to assume that we have int in all implementations and
therefore provides a 4 byte storage only. This causes Segmentation
fault as we will right the pointer.
Reviewed by: adrian
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D54211
init: allow to specify a custom path for rc(8)
This is useful for testing alternative service managers
without modifying /etc/rc
MFC After: 1 weeks
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D56828
pfsync: reject invalid SCTP states
SCTP states should always have a src scrub object associated with them.
Crafted pfsync packets might not have this, leading to us derferencing a
NULL pointer on cleanup.
Validate the pfsync state insertion packet to make sure this is correct.
PR: 294989
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")
pf: improve ASCONF chunk validation
When processing an ASCONF chunk we failed to verify that the chunk
length was at least 8 bytes. As a result we might end up passing a
negative length to pf_multihome_scan(). Fortunately this merely meant
the function did nothing, but we should discard such invalid packets, so
explicitly check for this.
MFC after: 1 week
Reported by: Mark Johnston
Sponsored by: Orange Business Services
(cherry picked from commit bea1c2fcd7839fd90a8ce96d6dc6a033779bc3c2)
pf: improve ASCONF chunk validation
When processing an ASCONF chunk we failed to verify that the chunk
length was at least 8 bytes. As a result we might end up passing a
negative length to pf_multihome_scan(). Fortunately this merely meant
the function did nothing, but we should discard such invalid packets, so
explicitly check for this.
MFC after: 1 week
Reported by: Mark Johnston
Sponsored by: Orange Business Services
(cherry picked from commit bea1c2fcd7839fd90a8ce96d6dc6a033779bc3c2)
nfs_pub: move from vfs_subr.c to vfs_export.c
nfs_pub is used only in vfs_export.c.
Reviewed by: kib, rmacklem
Differential Revision: https://reviews.freebsd.org/D56777
bsdinstall: Always use pkg.FreeBSD.org
The FreeBSD-base bits are accessible via pkg.FreeBSD.org, even for
releases, so there is no need to point at pkgbase.FreeBSD.org.
MFC after: 3 days
packages: Make create-sets.sh more robust during release
Commit d1c176fedfc9 made create-sets.sh exit when it encounters an
error, instead of creating an empty repository. However, this turns
out to cause some issues:
1. A package not having any sets is considered an error, but during
the release build, we stuff a 'pkg' package into the repository
which doesn't have any sets, which causes a failure. Avoid this
by simply ignoring the pkg package.
2. No error was printed in this case, which made the problem hard
to diagnose. Add an explicit error message.
3. A similar problem occurred running on a repository which already
contained sets, which is not usually done during the build, but
is not necessarly an inappropriate thing to do. Fix this one by
ignoring set packages when looking for sets.
[11 lines not shown]
nfs_nfsdserv.c: Clip number of callback slots
The client tells the server how many callback slots
it can handle in the callback session. However, the
NFSv4.1/4.2 server can only handle a maximum of
NFSV4_SLOTS slots. This patch clips the client's
value to that, to avoid using too high a slot#
for a callback.
Fortunately, I do not know of an extant client that
specifies a value greater than NFSV4_SLOTS, so this
patch is not really needed, as yet. Also, the client
rarely uses a slot# above 0 when doing callbacks.
MFC after: 2 weeks
Import smart revision 1.0.2
The smart command allows the user to monitor the various information
reported by Self-Monitoring, Analysis and Reporting Technology (SMART)
present on most ATA, SCSI, and NVMe storage media.
linuxkpi: Implement `module_*()` APIs as static functions
This fixes an "unused variable" warning when building DRM drivers.
Reviewed by: emaste
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D56780
execve: Add guard pages around execve KVA buffers
This helps ensure that overflows will trigger a panic instead of
silently corrupting adjacent buffers, as happened in SA-26:13.exec.
Extend kmap_alloc_wait() to support allocation of guard pages on both
sides of a KVA allocation. Modify the exec_map setup accordingly. Add
the "vm.exec_map_guard_pages" tunable to provide control over the guard
page allocations.
Reviewed by: kib
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D56711
ifnet: if_detach(): Fix races with vmove operations
The rationality is that the driver private data holds a strong reference
to the interface, and the detach operation shall never fail. Given the
vmove operation, if_vmove_loan(), if_vmove_reclaim() or vnet_if_return()
is not atomic and spans multiple steps, acquire ifnet_detach_sxlock only
for if_detach_internal() and if_vmove() is not sufficient. It is possible
that the thread running if_detach() sees stale vnet, or the vmoving is
in progress, then if_unlink_ifnet() will fail.
Fix that by extending coverage of ifnet_detach_sxlock a bit to also
cover if_unlink_ifnet(), so that the entire detach and vmove operation
is serialized.
Given it is an error when the if_unlink_ifnet() fails, and if_detach()
is a public KPI, prefer panic() over assertion on failure, to indicate
explicitly that bad thing happens. That shall also prevent potential
corrupted status of the interface, which is a bit hard to diagnose.
[7 lines not shown]
tests/net/if_clone_test: Add a test for races between if_detach() and if_vmove_reclaim()
Ideally we shall have tests for all possible races. It is races between
if_detach(), if_vmove_loan(), if_vmove_reclaim() and vnet_if_return().
Well that requires too many tests and it appears to be less valuable to
have them all. So focus on potential in future regressions related to
recent fixes [1] and [2] only.
[1] ee9456ce3753 ifnet: Fix races in if_vmove_reclaim()
[2] ba7f47d47dc1 ifnet: if_detach(): Fix races with vmove operations
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D56606
(cherry picked from commit f4be16983dea4904f85ac20e921ad2a8c18a0f79)
(cherry picked from commit 696d1590697e9d4c0f07ce0a8d76a62bc77bdfd5)
if_clone: Make ifnet_detach_sxlock opaque to consumers
The change e133271fc1b5e introduced ifnet_detach_sxlock, and change
6d2a10d96fb5 widened its coverage, but there are still consumers,
net80211 and tuntap e.g., want it. Instead of sprinkling it everywhere,
make it opaque to consumers.
Out of tree drivers shall also benefit from this change.
Reviewed by: kp
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D56298
(cherry picked from commit e9fc0c538264355bd3fd9120c650078281c2a290)
(cherry picked from commit c624e04a0bd0ab147ec64c17e3e53f5ebc769dcf)
ifnet: Move SIOCSIFVNET from ifhwioctl() to ifioctl()
SIOCSIFVNET is not a hardware ioctl. Move it to where it belongs.
Where here, rewrite the logic of checking whether we are moving the
interface from and to the same vnet or not, since it is obviously not
stable to access the interface's vnet, given the current thread may
race with other threads those running if_vmove().
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D55880
(cherry picked from commit 38bd7ef62f318f791e232e217855307a9d75efa0)
(cherry picked from commit 477c3ba3673152e88ec5c50d8f45db24102bdf07)
ifnet: vnet_if_return(): Avoid unnecessary recursive acquisition of ifnet_detach_sxlock
vnet_if_return() will be invocked by vnet_sysuninit() on vnet destructing,
while the lock ifnet_detach_sxlock has been acquired in vnet_destroy()
already.
With this change the order of locking is more clear. There should be no
functional change.
Reviewed by: pouria
Fixes: 868bf82153e8 if: avoid interface destroy race
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D56288
(cherry picked from commit f1fae67afbb13a41d488d0e0ec66b1805925019c)
(cherry picked from commit ccfc2d91304e88aafc0ca0e13e0f8b5a156d2a01)
ifnet: Remove unreachable code
The ioctls SIOCSIFVNET and SIOCSIFRVNET are for userland only. For
SIOCSIFVNET, if_vmove_loan(), the interface is obtained from current
VNET. For SIOCSIFRVNET, if_vmove_reclaim(), a valid child prison is
held before getting the interface. In both cases the VNET of the
obtained interfaces is stable, so there's no need to check it.
No functional change intended.
Reviewed by: glebius, jamie (for #jails)
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D55828
(cherry picked from commit e0731059af912a27d0f842959218946b1daaa7d1)
(cherry picked from commit a989b0fbc965b453d97e3d032efb4f9c7592734a)
ifnet: Fix races in if_vmove_reclaim()
The thread running if_vmove_reclaim() may race with other threads those
running if_detach(), if_vmove_loan() or if_vmove_reclaim(). In case the
current thread loses race, two issues arise,
1. It is unstable and unsafe to access ifp->if_vnet,
2. The interface is removed from "active" list, hence if_unlink_ifnet()
can fail.
For the first case, check against source prison's vnet instead, given
the interface is obtained from that vnet.
For the second one, return ENODEV to indicate the interface was on the
list but the current thread loses race, to distinguish from ENXIO, which
means the interface or child prison is not found. This is the same with
if_vmove_loan().
Reviewed by: kp, pouria
[6 lines not shown]
