FreeBSD's version of the config(8) utility is based on 4.3BSD not
4.4BSD. So correct the mentioned paper in the SEE ALSO section.
Reported by: imp
Reviewed by: imp
X-MFC-with: 2b59392cb0
Differential Revision: https://reviews.freebsd.org/D29701
The manual page currently doesn't show an example how to print
the routing table, so add one and .Xr netstat while here.
PR: 231579
Reported by: Pekka Järvinen <pekka dot jarvinen at gmail dot com>
Reviewed by: debdrup
MFC after: 5 days
Differential Revision: https://reviews.freebsd.org/D29702
A doomed VI does not have a valid ifnet.
Reported by: Jithesh Arakkan @ Chelsio
Reviewed by: np
MFC after: 1 week
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D29662
There haven't been any non-obscure drivers that supported this
functionality and it has been impossible to test to ensure that it
still works. The only known consumer of this interface was the engine
in OpenSSL < 1.1. Modern OpenSSL versions do not include support for
this interface as it was not well-documented.
Reviewed by: cem
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D29736
iscsid can be sleeping in iscsi_ioctl() causing the destroy_dev() to
sleep forever if iscsi.ko is unloaded while iscsid is running.
Reported by: Jithesh Arakkan @ Chelsio
Reviewed by: mav
MFC after: 1 week
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D29688
Use .o files directly. Replace the .o.uu files that we uudecode with .o files.
Adjust the kernel and module build to cope.
Suggestions by: markj@, emaste@
Sposnored by: Netflix, Inc
Differential Revision: https://reviews.freebsd.org/D29636
uudecode the .o.uu files and commit directly to the tree. Adjust the build
infrastructure to cope with the new location, both for the kernel and modules.
Sposnored by: Netflix, Inc
Differential Revision: https://reviews.freebsd.org/D29635
Store the .o files directly in the tree. We no longer need to play uuencode
games like we did in the CVS days. Adjust the build infrastructure to match.
Reviewed by: markj@
Sposnored by: Netflix, Inc
Differential Revision: https://reviews.freebsd.org/D29634
We no longer need to use uuencode to uuencode files in our tree. Store the .o
file directly instead. Adjust the build to cope with the new arrangement.
Suggestions by: emaste, bz, donner
Reviewed by: markm
Sposnored by: Netflix, Inc
Differential Revision: https://reviews.freebsd.org/D29632
The check needs to be in the public routine (gdb_cpu_suspend()), not
in the internal routine called from various places
(_gdb_cpu_suspend()). All the other callers of _gdb_cpu_suspend()
already check gdb_active, and this breaks the use of snapshots when
the debug server is not enabled since gdb_cpu_suspend() tries to lock
an uninitialized mutex.
Reported by: Darius Mihai, Elena Mihailescu
Reviewed by: elenamihailescu22_gmail.com
Fixes: 621b509048
Differential Revision: https://reviews.freebsd.org/D29538
Introduce pfctl_pool to be able to extend the pool part of the pf rule
without breaking the ABI.
Reviewed by: kp
MFC after: 4 weeks
Differential Revision: https://reviews.freebsd.org/D29721
When packet is a SYN packet, we don't need to modify any existing PCB.
Normally SYN arrives on a listening socket, we either create a syncache
entry or generate syncookie, but we don't modify anything with the
listening socket or associated PCB. Thus create a new PCB lookup
mode - rlock if listening. This removes the primary contention point
under SYN flood - the listening socket PCB.
Sidenote: when SYN arrives on a synchronized connection, we still
don't need write access to PCB to send a challenge ACK or just to
drop. There is only one exclusion - tcptw recycling. However,
existing entanglement of tcp_input + stacks doesn't allow to make
this change small. Consider this patch as first approach to the problem.
Reviewed by: rrs
Differential revision: https://reviews.freebsd.org/D29576
Add the System Management BIOS Baseboard (or Module) Information
a.k.a. Type 2 structure to the SMBIOS emulation.
Reviewed by: rgrimes, bcran, grehan
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D29657
Allows for duplicate locks to be acquired without witness complaining.
Similar flags exists already for rwlock(9) and sx(9).
Reviewed by: markj
MFC after: 3 days
Sponsored by: NetApp, Inc.
Sponsored by: Klara, Inc.
NetApp PR: 52
Differential Revision: https://reviews.freebsd.org/D29683n
This improves consistency; the NETWORKING script provides both,
so there should be no functional change.
Differential Revision: https://reviews.freebsd.org/D29587
It was unused since 405c3050f1, which removed iBCS support.
This also moves the 'linux' rc script slightly earlier, which
might help in some setups. The original version of this patch
moved it even more, before 'mountcritlocal', which would fixe
mount(8) errors due to missing /dev/shm in setups with entries
for /path/to/chroot/dev/shm without the "late" flag; however,
in the end 'kldxref' turned out to depend on 'mountcritlocal'
anyway.
Reported By: pstef
Reviewed By: dchagin
Sponsored By: EPSRC
Differential Revision: https://reviews.freebsd.org/D29590
types.h defines device_t as a typedef of struct device *. struct device
is defined in subr_bus.c and almost all of the kernel uses device_t.
The LinuxKPI also defines a struct device, so type confusion can occur.
This causes bugs and ambiguity for debugging tools. Rename the FreeBSD
struct device to struct _device.
Reviewed by: gbe (man pages)
Reviewed by: rpokala, imp, jhb
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D29676
We were passing a LinuxKPI struct device * to a pci(4) function that
expects a device_t.
Reviewed by: manu, hselasky, bz
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D29675
The driver needs to provide a LinuxKPI device structure to register
itself with the IB subsystem. It was erroneously using a copy of its
FreeBSD device structure for this purpose.
Use linux_pci_attach_device() instead, following the example of the
Chelsio iwarp driver. Also ensure that we don't leak the faked device
during detach.
Reviewed by: hselasky
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D29595
Once a kif is passed to pfi_kkif_attach() we must ensure we never re-use
it for anything else.
Set the kif to NULL afterwards to guarantee this.
Reported-by: syzbot+be5d4f4a7a4c295e659a@syzkaller.appspotmail.com
MFC after: 4 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
It was used for testing armv6 under QEMU, however since then we added
support for the QEMU virt platform.
Reviewed by: imp, manu
Differential Revision: https://reviews.freebsd.org/D29707
This is intended to be used with memory mapped IO, e.g. from
bus_space_map with no flags, or pmap_mapdev.
Use this new memory type in the map request configured by
resource_init_map_request, and in pciconf.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D29692
The mbuf allocated could be a chain and must be freed with m_freem.
Reviewed by: jhb@
MFC after: 1 week
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D29579
Recent testing of network partitioning a FreeBSD NFSv4.1
server from a Linux NFSv4.1 client identified problems
with both the FreeBSD server and Linux client.
Sometimes, after some Linux NFSv4.1/4.2 clients establish
a new TCP connection, they will advance the sequence number
for a session slot by 2 instead of 1.
RFC5661 specifies that a server should reply
NFS4ERR_SEQ_MISORDERED for this case.
This might result in a system call error in the client and
seems to disable future use of the slot by the client.
Since advancing the sequence number by 2 seems harmless,
allow this case if vfs.nfs.linuxseqsesshack is non-zero.
Note that, if the order of RPCs is actually reversed,
a subsequent RPC with a smaller sequence number value
for the slot will be received. This will result in
a NFS4ERR_SEQ_MISORDERED reply.
This has not been observed during testing.
Setting vfs.nfs.linuxseqsesshack to 0 will provide
RFC5661 compliant behaviour.
This fix affects the fairly rare case where a NFSv4
Linux client does a TCP reconnect and then apparently
erroneously increments the sequence number for the
session slot twice during the reconnect cycle.
PR: 254816
MFC after: 2 weeks
That fixes disabled keyboard input after Xorg server has been stopped.
Reviewed by: whu
MFC after: 1 month
Differential revision: https://reviews.freebsd.org/D28171
Trim leading spaces in variable names when the list is e.g.
pretty-formatted in /etc/login.conf or ~/.login_conf.
PR: 247947
Reviewed by: allanjude
Differential Revision: https://reviews.freebsd.org/D25649
This seems to have been lost during updates from upstream, and
was reported (on IRC) as a nice feature to have (again).
Reviewed by: bapt
Differential Revision: https://reviews.freebsd.org/D28689
During a recent testing event, it was reported that the NFSv4.1/4.2
server erroneously bound the back channel to a new TCP connection.
RFC5661 specifies that the fore channel is implicitly bound to a
new TCP connection when an RPC with Sequence (almost any of them)
is done on it. For the back channel to be bound to the new TCP
connection, an explicit BindConnectionToSession must be done as
the first RPC on the new connection.
Since new TCP connections are created by the "reconnect" layer
(sys/rpc/clnt_rc.c) of the krpc, this patch adds an optional
upcall done by the krpc whenever a new connection is created.
The patch also adds the specific upcall function that does a
BindConnectionToSession and configures the krpc to call it
when required.
This is necessary for correct interoperability with NFSv4.1/NFSv4.2
servers when the nfscbd daemon is running.
If doing NFSv4.1/NFSv4.2 mounts without this patch, it is
recommended that the nfscbd daemon not be running and that
the "pnfs" mount option not be specified.
PR: 254840
Comments by: asomers
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D29475
Such type cannot be used in code that is in common between
FreeBSD and Linux. Use the FreeBSD type instead.
MFC after: 3 days
Reported by: markj
Differential Revision: https://reviews.freebsd.org/D29677
I had added entries that depended on some build option to this file
and have been informed, that those go into a different file in another
directory.
Mentioning /usr/src/tools/build/mk/OptionalObsoleteFiles.inc in this
file should help other committers (and me) to not repeat that mistake.
MFC after: 1 week
similarly to the Linux driver, by a tunable read only sysctl.
Submitted by: Oleg Sidorkin <osidorkin@gmail.com>
PR: 254884
MFC after: 1 week
Sponsored by: Mellanox Technologies // NVIDIA Networking
