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.
[6 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)
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)
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)
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)
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
[5 lines not shown]
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)
ifnet: Add some sanity checks
To be more robust since the checking is now performed where the
interface is referenced.
While here, remove a redundant check from if_vmove_loan().
Reviewed by: kp, glebius, pouria
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D55875
(cherry picked from commit 00d96da231d007673a1672452748d8ea4f6788ae)
dev/ichsmb: disable block buffer if supported
In order to improve the efficiency of block read/write calls, Intel has
introduced a block buffer. Instead of generating an interrupt after
receiving/sending a single byte, the data is buffered in the block buffer. It
allows the SMBus controller to generate a single interrupt for the whole
transfer. At the moment, we don't support that and don't expect the SMBus
controller to behave in that way. Unfortunately, BIOS code can also access the
SMBus controller and may enable the block buffer. Poorly written BIOS code may
also keep the block buffer enabled breaking our driver. Therefore, we should
check if the device supports a block buffer and disable it for every request
because we don't know if some BIOS code has reconfigured the SMBus controller
in between.
Reviewed by: emaste
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Pull Request: https://github.com/freebsd/freebsd-src/pull/2161
bhyve: allow read/write to full CRB buffer
For some reason, we've incorrectly calculated the size of the CRB data buffer
register. There's no need to divide the CRB data buffer size by 4. We should
allow access to the whole buffer instead.
Reviewed by: markj
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Pull Request: https://github.com/freebsd/freebsd-src/pull/2169
net-mgmt/netbox: Update to 4.5.9
Changelog:
Enhancements:
* Add profile filter support for modules
* Enable optional config template selection when rendering device
configuration via a URL query parameter
* Support filtering by multiple object-type custom fields simultaneously
in filter forms
* Include the PostgreSQL database schema in system details
* Allow dict subclasses for the API_TOKEN_PEPPERS configuration
parameter
Performance Improvements:
* Optimize queryset prefetching for CSV bulk export
Bug Fixes:
* Fix incorrect contact count for contact groups with contacts assigned
[25 lines not shown]
ahci(4): Add another device ID for Marvell 9128 SATA controller: 0x91a3
This was encountered on a Gigabyte GA-P55A-UD4 motherboard identifying itself
as:
ahci0 at pci0:2:0:0: class=0x01018f rev=0x11 hdr=0x00 vendor=0x1b4b device=0x91a3 subvendor=0x1458 subdevice=0xb000
vendor = 'Marvell Technology Group Ltd.'
class = mass storage
subclass = ATA
The physical chip has "88SE9128-NAA2" printed on it.
Similar code has been in Linux for a long time:
https://github.com/torvalds/linux/commit/50be5e3657cd2851a297dc0b3fd459f25829d29b
Co-authored-by: Michael Osipov <michaelo at FreeBSD.org>
PR: 288526
Reviewed by: jhb
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D56464
[2 lines not shown]
