geneve creates a generic network virtualization tunnel interface
for Tentant Systems over an L3 (IP/UDP) underlay network that provides
a Layer 2 (ethernet) or Layer 3 service using the geneve protocol.
This implementation is based on RFC8926.
Reviewed by: glebius, adrian
Discussed with: zlei, kp
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D54172
Implement Linux I2C ioctl translation in the Linux compatibility layer
and wire iicbus cdevs up for in-kernel rdwr handling.
Support common i2c-dev requests including SLAVE, FUNCS, and RDWR,
while rejecting unsupported 10-bit and SMBus operations.
Signed-off-by: YAO, Xin <mr.yaoxin@outlook.com>
Reviewed by: imp, adrian, pouria
Differential Revision: https://reviews.freebsd.org/D56251
The change e133271fc1 introduced ifnet_detach_sxlock, and change
6d2a10d96f 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
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
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: 868bf82153 if: avoid interface destroy race
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D56288
The size broke when upages was converted from array to double pointer.
Reported by: gcc -Wsizeof-pointer-div
Reviewed by: imp
Fixes: 82ff1c334b ("nvme: Allow larger user request sizes")
Differential Revision: https://reviews.freebsd.org/D56368
The SOCK_RAW socket is a multiple receiver socket by its definition. An
incoming packet may be copied to multiple sockets. Thus, incoming packet
handling is expensive. Systems with many thousands of raw sockets usually
have them connect(2)-ed to different destinations. This allows for some
improvement of the input handling, which was introduced by 9ed324c9a5
back in 2008. This optimization was made specifically for L2TP/PPTP VPN
concentrators based on ports/net/mpd5.
This change generalizes the idea of 9ed324c9a5, so that it potentially
can be used with IPv6 raw sockets. This also eliminates last use of the
pcbinfo hash lock outside of in_pcb.c.
While here make a speculative design decision: put into the hash table
sockets that did only connect(2). Previously, we were indexing only
sockets that were protocol bound, did bind(2) and did connect(2). My
speculation is that only the remote IP provides some real entropy into the
hash and local address and proto are expected to be the same for majority
of the sockets. My other speculation is that VPN concentrators other than
mpd5 may not bind(2) their sockets, thus not getting any use of the hash.
Differential Revision: https://reviews.freebsd.org/D56172
The logic of clearing local address at the protocol level makes sense. It
is feature of UDP, not of any protocol, that local address is cleared on
disconnect. This code can be tracked down to pre-FreeBSD times.
For example, for TCP we want a disconnected socket to return previously
used local address with getsockname(2). The TCP has successfully evaded
that by not calling in_pcbdisconnect() and calling in_pcbdetach() in the
very old code and in_pcbdrop() later. After D55661 TCP again has this
potential bug masked. Better make it right than rely on such
unintentional evasions.
The raw IP sockets don't use in_pcbdisconnect(), but they are going to in
the near future. If in_pcbdisconnect() clears local address for them,
that would be a larger bug than just getsockname(). A raw socket may be
bound with bind(2) and then connect(2)ed, and then disconnected, e.g.
connect(INADDR_ANY). And when we run raw IP socket through
in_pcbdisconnect() we don't want to lose local address.
This reverts D38362.
This reverts commit 2589ec0f36.
Reviewed by: rrs, markj
Differential Revision: https://reviews.freebsd.org/D56170
The inpcb flag INP_DROPPED served two purposes.
It was used by TCP and subsystems running on top of TCP as a flag that
marks a connection that is now in TCPS_CLOSED, but was in some other state
before (not a new-born connection). Create a new TCP flag TF_DISCONNECTED
for this purpose.
The in_pcbdrop() was a TCP's version of in_pcbdisconnect() that also sets
INP_DROPPED. Use in_pcbdisconnect() instead.
Second purpose of INP_DROPPED was a negative lookup mask in
inp_smr_lock(), as SMR-protected lookup may see inpcbs that had been
removed from the hash. We already have had INP_INHASHLIST that marks
inpcb that is in hash. Convert it into INP_UNCONNECTED with the opposite
meaning. This allows to combine it with INP_FREED for the negative lookup
mask.
The Chelsio/ToE and kTLS changes are done with some style refactoring,
like moving inp/tp assignments up and using macros for that. However, no
deep thinking was taken to check if those checks are really needed, it
could be that some are not.
Reviewed by: rrs
Differential Revision: https://reviews.freebsd.org/D56186
The INP_DROPPED is going to become an internal flag for inpcb. As of now
it means a TCP pcb that is in TCPS_CLOSED. There is nothing wrong with
calling setsockopt(2) on such socket, although has no practical use.
This deletes a piece of code from 56713d16a0 / D16201. There is no
description of the panic fixed, but I will speculate that the panic was
about in6p->in6p_outputopts being NULL as the inpcb already went through
in_pcbfree_deferred(). This also can be related to compressed TIME-WAIT,
that is also gone now.
With current locking this shouldn't be possible. An inpcb goes through
in_pcbfree() only with pr_detach method, which is called from sofree(),
and the latter is called on losing the very last socket reference. So, at
the point when in_pcbfree() is called, the socket has lost its file
descriptor reference and there can not be any running setsockopt() on it.
Leave the call to ip6_pcbopt() still embraced with INP_WLOCK(), since we
are modifying inpcb contents.
NB: the IPv6 setsockopt(2) definitely has room for improvement. Several
memory allocations should be moved out of lock and made M_WAITOK.
Covering large piece of setsockopt(2) code with epoch(9) just because
ip6_setpktopts() calls ifnet_byindex() isn't correct either.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D56169
The iteration over all pcbs is possible without the global list. The
newborn inpcbs are put on a global list of unconnected inpcbs, then after
connect(2) or bind(2) they move to respective hash slot list.
This adds a bit of complexity to inp_next(), but the storage scheme is
actually simplified.
One potential problem before this change was that a couple of pcbs fall
into the same hash slot and are linked A->B there, but they also sit next
to each other in the global list, linked as B->A. This can deadlock of
course. The problem was never observed in the wild, but I was able to
instrument it with lots of effort: just few pcbs in the system, hash size
reduced down to 2 and a lot of repetitive calls into two kinds of
iterators.
However the main motivation is not the above problem, but make a step
towards splitting the big hash lock into per-slot locks.
Differential Revision: https://reviews.freebsd.org/D55967
With the SMR locking of inpcbs the use of this lock reduced down to the
global list and generation number. It was used only on an inpcb creation
and destruction. Use the inpcbinfo hash lock for this purpose.
Reviewed by: pouria, rrs, markj
Differential Revision: https://reviews.freebsd.org/D55966
The protocols marked with PR_CONNREQUIRED can never go through pr_connect
after being disconnected. This is a tiny improvement of fdb987bebd.
While here push clearing of the addresses under the same condition.
Although this clearing originates from pre-FreeBSD times, it actually
makes sense only for protocols that can reconnect.
Reviewed by: pouria, markj
Differential Revision: https://reviews.freebsd.org/D55661
Before this change evdev interface sent only copy of data sent through
the sysmouse interface. It worked as /dev/wsp0 device node was
automatcaly opened by devd(8) with starting of moused(8).
Starting with 15.0 moused(8) does not open sysmouse interface by default
thus making wsp(4) device dysfunctional.
Fix it with adding extra checks of interfaces state.
MFC after: 1 week
These devices appeared to stop sending reports via mouse USB interface
after switching to RAW mode. Fix it with changing Usage of Top Level
Collection to one found in HID report descriptor of proper interface.
MFC after: 1 week
According to "HID Usage Tables FOR Universal Serial Bus (USB)"
Usage Page ID range 0x93-0xF1CF is "Reserved" and Usage Page ID range
0xFF00-0xFFFF is "Vendor-defined".
MFC after: 1 week
rather than on VID/PID. Later is not reliable for some types.
VID/PID identification can be restored by specifying of -p option.
Tested by: arrowd, wulf
PR: 290639
MFC after: 1 week
Functional change is that on destruction INVARIANTS checks will run. Also
the mask is no longer hardcoded, so makes it easier to make hash size a
tunable.
Reviewed by: ae
Differential Revision: https://reviews.freebsd.org/D56176
While here, slightly restyle ip_vnet_init() and use sparse initializer for
pfil_head_args. There is no functional change wrt to pfil(9) hook
registration.
Differential Revision: https://reviews.freebsd.org/D56175
While here remove ipi_lbgrouphashmask, as it is always has the same value
as ipi_porthashmask.
Differential Revision: https://reviews.freebsd.org/D56174
This is a more extendable version than traditional hashinit(9). It allows
different kinds of slot headers with optional locks.
Implement traditional hashinit()/hashdestroy() on top of it.
Reviewed by: pouria, gallatin
Differential Revision: https://reviews.freebsd.org/D55904
Focus on the MRQE field of the MRQC register, which is 4 bits wide,
and we use these 3 types of values.
- IXGBE_MRQC_RSSEN 0x1 (non VF mode)
- IXGBE_MRQC_VMDQRSS32EN 0xA (less than 33 VFs)
- IXGBE_MRQC_VMDQRSS64EN 0xB (less than 65 VFs)
If we always take a bitwise OR with IXGBE_MRQC_RSSEN,
IXGBE_MRQC_VMDQRSS32EN will never be chosen.
Select these 3 types of values for the proper case.
Signed-off-by: Yuichiro NAITO <naito.yuichiro@gmail.com>
MFC after: 1 week
Pull Request: https://github.com/freebsd/freebsd-src/pull/2132
Commit 8b9775912c added support for an NFSv4 mounted
root file system. This patch documents how to set this
up. It also includes some minor updates and fixes
some formatting.
This is a content change.
Reviewed by: kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D56317
Fixes: 8b9775912c ("nfs_diskless: Add support for an NFSv4 root fs")
While here, remove a bogus const which has been there for years.
MFC after: 1 week
Reported by: ivy@
Fixes: 1b83e8a3f8 ("Constify string pointers.")
Fixes: 8244dd3262 ("tunefs: Better fix for arm64 alignment issues")
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D56343
Improve mfi_pd_inq_string() by
* Reusing buffer sizes from cam/cam.h according to SCSI specification + NULL byte
* Don't truncate vendor-specific information by escaping into a too small buffer
* Use cam_strvis() from libcam instead of old, outdated local copy
* Recaculate size of inq_string based on the reused buffer sizes and
format statements
PR: 294354
Reviewed by: imp
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D56328
Both (U)EFI and BIOS are completely different things, be precise and don't use
them together.
Reviewed by: imp
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D56329
Added support for the f{maximum,minimum}_{mag,num} families, the new
C23 standard functions for maximum magnitude and number-preferring
maximum. This includes modifying fmax.3, on top of D56230, to
recommend the use of fmaximum_num and fminimum_num.
Reviewed by: fuz, kargl
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D56236
zstd's tracing API (zstd_trace.h) declares ZSTD_trace_compress_begin()
and friends as __attribute__((weak)) externals, gated on the
ZSTD_HAVE_WEAK_SYMBOLS compile-time probe. That probe has covered
x86_64 and i386 since at least zstd 1.5.6, and was extended to aarch64
and riscv in 1.5.7.
In a static kernel image there is no dynamic linker to patch the PLT GOT
entries at runtime. On amd64 the undefined weak symbols resolve directly
to NULL, so the "!= NULL" guard in the zstd source correctly suppresses
every call through the stubs. On aarch64 and riscv the ABI requires
GOT-based indirection for external calls: the PLT stub address is
non-NULL, the guard passes, and the call lands in an uninitialized GOT
slot. Because this happens before exception handlers are in place the
machine resets silently, making the kernel unbootable after the zstd
1.5.7 import.
The upstream-supported suppression is ZSTD_NO_TRACE (zstd_internal.h),
which skips inclusion of zstd_trace.h entirely and forces ZSTD_TRACE=0.
Add it to ZSTD_C alongside the existing ZSTD_* defines, and while here
group all three -DZSTD_* flags onto a single line in alphabetical order
with ${.IMPSRC} on its own line.
Reported by: many
Tested by: lwhsu
X-MFC-with: c0d9a07101
Linux /proc/partitions reports the major/minor pair, the device size in
1K blocks, and the device name. linprocfs still printed obsolete
statistics columns and reported the size in bytes.
Update linprocfs_dopartitions() to emit the Linux-style header and
report provider sizes in 1K blocks.
Signed-off-by: Shunchao Hu <ankohuu@gmail.com>
Reviewed by: des
MFC after: 2 weeks
Pull Request: https://github.com/freebsd/freebsd-src/pull/2126
Closes: https://github.com/freebsd/freebsd-src/pull/2126
* migrate the MSM8916 (snapdragon 410) support to qcom_gcc
* add the full qcom_gcc / qcom_clk list to files.arm64, replacing
the MSM8916 stub in sys/arm64/qualcomm .
Differential Revision: https://reviews.freebsd.org/D49706
The draft-ietf-6man-ipv6only-flag has been obsoleted by RFC 8925.
Remove the EXPERIMENTAL compile option from the kernel and remove
DRAFT_IETF_6MAN_IPV6ONLY_FLAG from userland.
This compile option was not enabled by default.
Also regenerate src.conf.5.
Reviewed by: bz
Differential Revision: https://reviews.freebsd.org/D56228
Pouria Mousavizadeh Tehrani