Due to the ordering of the powerpc64 linker script, we were discarding
all notes before emitting .note.gnu.build-id. This had the effect of
generating an empty build id section and breaking the kern.build_id
sysctl added in r348611.
powerpc and powerpcspe are uneffected.
PR: 246430
MFC after: 3 days
Sponsored by: Tag1 Consulting, Inc.
vfs_export requires security flavors be explicitly listed when
exporting as of r360900.
Use the default AUTH_SYS flavor when converting old export args to
ensure compatibility with the legacy mount syscall.
Reported by: rmacklem
Reviewed by: rmacklem
Approved by: mav (mentor)
MFC after: 3 days
Sponsored by: iXsystems, Inc.
Differential Revision: https://reviews.freebsd.org/D25045
netmap assumes the one "slot" is left unused to distinguish
the empty ring and full ring conditions. This assumption was
violated by vtnet_netmap_rxq_populate().
MFC after: 1 week
The functionality contained in this function is duplicated,
as it is already available in vtnet_txq_free_mbufs()
and vtnet_rxq_free_mbufs().
MFC after: 1 week
The vtnet_netmap_rxq_populate() function erroneously assumed
that kring->nr_hwcur = 0, i.e. the kring was in the initial
state. However, this is not always the case: for example,
when a vtnet reinit is triggered by some changes in the
interface flags or capenable.
This patch changes the behaviour of vtnet_netmap_kring_refill()
so that it always starts publishing the netmap buffers starting
from the current value of kring->nr_hwcur.
MFC after: 1 week
The field was added in r141137 in 2005 and is unused.
It avoidably grows a struct which is NOFREE and easily gets hundreds of
thousands of instances.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D25036
This is something I added a few years ago to handle resyncing the beacon if
we miss a beacon or need to sync after association/reassociation/powersave.
However, if we're doing STA+AP mode (eg DWDS) then we don't want
to reprogram the beacons here; this may upset normal AP operation.
I missed checking for the sc->sc_swbmiss flag so I was reinitialising
the beacon timers after every beacon miss / TSFOOR option, and
that isn't likely good.
This plus ensuring that STA's are created with "-beacon" to disable
BMISS/TSFOOR processing will hopefully quieten some of the issues
I've seen with missed beacons / TSFOOR (out of range) interrupts
coming in when operating in STA mode.
Tested:
* AR9380/AR9580, STA+AP modes
The trampoline code used for loading gzipped a.out kernels on arm was
removed in r350436. A portion of this code allowed for DDB to find the
symbol tables when booting without loader(8), and some of this was
untouched in the removal. Remove it now.
Differential Revision: https://reviews.freebsd.org/D24950
The ICMPv6 echo reply is constructed with the IPv6 header too close to
the beginning of a packet for an Ethernet header to be prepended, so we
end up with an mbuf containing just the Ethernet header. The GENET
controller doesn't seem to handle this, with or without transmit checksum
offload. At least until we have chip documentation, do a pullup to
satisfy the chip. Hopefully this can be fixed properly in the future.
Fix problem with ICMP echo replies: check only deferred data checksum
flags, and not the received checksum status bits, when checking whether
a packet has a deferred checksum; otherwise echo replies are corrupted
because the received checksum status bits are still present.
Fix some unhandled cases in packet shuffling for checksum offload.
null. In the first case, RB_REMOVE_COLOR just changes the child to
black and returns. With this change, RB_REMOVE handles that case, and
drops the child argument to RB_REMOVE_COLOR, since that value is
always null.
RB_REMOVE_COLOR is changed to remove a couple of unneeded tests, and
to eliminate some deep indentation.
RB_ISRED is defined to combine a null check with a test for redness,
to replace that combination in several places.
Reviewed by: markj
Tested by: pho
Differential Revision: https://reviews.freebsd.org/D25032
Honoring the kernel-supplied opt_ipsec.h in r361632 causes builds of
ipsec modules to fail if the kernel doesn't include IPSEC_SUPPORT.
However, the module can never be loaded into such a kernel, so only
build the modules if the kernel includes IPSEC_SUPPORT.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D25059
This allows partitions to create additional aliases of their own. The
default method implementations preserve the existing behavior.
No functional change.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D24938
This fixes ipsec.ko to include all of IPSEC_DEBUG.
Reviewed by: imp
MFC after: 2 weeks
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D25046
To make this simpler, set the default contents of opt_ipsec.h
for standalone modules in sys/conf/config.mk.
Reviewed by: imp
MFC after: 2 weeks
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D25046
cs_cmdsn can be incremented with single atomic. expcmdsn/maxcmdsn set in
cfiscsi_pdu_prepare() based on cs_cmdsn are not required to be updated
synchronously, only monotonically, that is achieved with lock there.
MFC after: 2 weeks
Sponsored by: iXsystems, Inc.
* Enable self-generated 11n frames
* add MCS rates for 1-stream and 2-stream rates; will do 3-stream
once the rest of this tests out OK with other people.
* Hard-code 1 stream for now
* Add A-MPDU RX mbuf tagging
* RTS/CTS if doing RTSCTS in HT protmode as well as legacy; they're
separate configuration flags
* Update the amrr rate index stuff - walk the rates array like others
to find the right one - this now works for MCS and CCK/OFDM rates
* Add support for atheros fast frames/AMSDU support as we can generate
those in net80211.
TODO:
* HT40 isn't enabled yet
* No A-MPDU support just yet; that requires some more firmware research
and maybe porting some ath(4) A-MPDU support/tracking into net80211
* Short preamble flags aren't set yet for MCS; need to check the linux
driver and see what's going on there
* Add 3x3 rates and set tx/rx stream configuration appropriately
* More 5GHz testing; I have a 3x3 dual band USB NIC coming soon that'll
let me test this.
* Figure out why the RX path isn't performing as fast as it could -
there's only a single buffer loaded at a time for the receive path
in the USB bulk handler and this may not be super useful.
Tested:
* RT5390 usb, 1x1, RF5370 (2GHz radio), STA mode - A-MSDU TX, A-MPDU RX
Submitted by: Ashish Gupta <ashishgu@andrew.cmu.edu>
Differential Revision: https://reviews.freebsd.org/D22840
PCI bus driver restores most but not all of a child PCI-PCI bridge
configuration. The bridge's I/O windows are restored by pcib driver and
that happens later in time. This can be problematic because the Command
register is restored before the windows are restored. If the firmware
programs the windows incorrectly or even does not program them at all,
then the bridge can start claiming I/O cycles that are not intended for
it. This will continue until the correct windows are restored.
I have observed this problem with a buggy BIOS where after resuming from
S3 an I/O port window of a PCI-PCI bridge was configured with zero base
and limit causing the bridge to claim 0x0 - 0xFFF port range. That
interfered with ACPI port access including ACPI PM Timer at port 0x808,
thus wreaking havoc in the time keeping.
The solution is to restore the Command register of PCI-PCI bridges after
the windows are restored in pcib driver. While here, I decided that for
other PCI device types (normal and cardbus) it's better to restore the
Command register after their BARs are restored.
To do: per jhb's suggestion, move the window handling to pci driver.
Reviewed by: imp, jhb, kib
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D25028
Consider this scenario:
- kern.corefile=/var/coredumps/%N.%U.%I.core
- multiple processes with the same name crash at the same time
It's possible that one process selects existing file N as oldvp while it
keeps looking for an unused file number. Another process scans through
files and stumbles upon N. That process would be blocked on the vnode
lock while holding the directory vnode exclusively locked. The first
process would, thus, get blocked on the directory's vnode lock.
More generally, holding a file's vnode lock (oldvp) while trying to lock
its directory (for the next lookup) is a violation of the vnode locking
order.
I have observed this deadlock in the wild.
So, the change to keep oldvp "opened" but unlocked and to lock it again
only if it's to be returned as the result.
As kib noted, an alternative would be to keep the directory locked and
to use VOP_LOOKUP directly for scanning through existing core files.
Reviewed by: kib
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D25027
When a crypto_cursor_copyback() request spanned multiple mbufs or
iovecs, the pointer into the mbuf/iovec was incremented instead of the
pointer into the source buffer being copied from.
PR: 246737
Reported by: Jenkins, ZFS test suite
Sponsored by: Netflix
We any way have per-I/O space in CTL_PRIV_FRONTEND, while for PDU private
fields I have better use ideas. Plus to me such use of PDU fields looked
a layering violation.
MFC after: 2 weeks
Sponsored by: iXsystems, Inc.
HTM is on the chopping block, doesn't work on FreeBSD, and has only token
support in PowerISA 3.1 and POWER10. Don't advertise something we'll never
support.
I noticed that unaligned accesses were returning garbage values.
Give test data like this:
char testdata[] = { 0x12, 0x34, 0x56, 0x78, 0x9a, 0xbc, 0xde, 0xf1, 0x23, 0x45, 0x67, 0x89, 0xab, 0xcd, 0xef, 0x5a };
Iterating through uint32_t space 1 byte at a time should
look like this:
freebsd-carambola2:/mnt# ./test
Hello, world!
offset 0 pointer 0x410b00 value 0x12345678 0x12345678
offset 1 pointer 0x410b01 value 0x3456789a 0x3456789a
offset 2 pointer 0x410b02 value 0x56789abc 0x56789abc
offset 3 pointer 0x410b03 value 0x789abcde 0x789abcde
offset 4 pointer 0x410b04 value 0x9abcdef1 0x9abcdef1
offset 5 pointer 0x410b05 value 0xbcdef123 0xbcdef123
offset 6 pointer 0x410b06 value 0xdef12345 0xdef12345
offset 7 pointer 0x410b07 value 0xf1234567 0xf1234567
.. but to begin with it looked like this:
offset 0 value 0x12345678
offset 1 value 0x00410a9a
offset 2 value 0x00419abc
offset 3 value 0x009abcde
offset 4 value 0x9abcdef1
offset 5 value 0x00410a23
offset 6 value 0x00412345
offset 7 value 0x00234567
The amusing reason? The compiler is generating the lwr/lwl incorrectly.
Here's an example after I tried to replace the two macros with a single
invocation and offset, rather than having the compiler compile in addiu
to s3 - but the bug is the same:
1044: 8a620003 lwl v0,0(s3)
1048: 9a730000 lwr s3,3(s3)
.. which is just totally trashy and wrong.
This explicitly tells the compiler to treat the output as being read
and written to, which is what lwl/lwr does with the destination
register.
I think a subsequent commit should unify these macros to skip an addiu,
but that can be a later commit.
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D25040
I don't see a point to copy io->scsiio.kern_total_len into the request
PDU private field. The io is going to stay with us till the end, and
kern_total_len field is not changed after being first initialized.
MFC after: 2 weeks
Sponsored by: iXsystems, Inc.
Extract scrollback buffer initialization into a common routine, used both
during vt(4) init and in handling the CONS_CLRHIST ioctl.
PR: 224436
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D24815
The nfs-over-tls daemons need a system call to perform operations such as
associate a file descriptor with a krpc socket.
The daemons will not be in head for some time, but it will make it
easier for testers of nfs-over-tls to do testing if the system call
is in head (basically the stub for libc which will be commited soon).
Reviewed by: brooks
Differential Revision: https://reviews.freebsd.org/D24949
- Add vm_phys_early_add_seg(), complementing vm_phys_early_alloc(), to
ensure that segments registered during hammer_time() are placed in the
right domain. Otherwise, since the SRAT is not parsed at that point,
we just add them to domain 0, which may be incorrect and results in a
domain with only several MB worth of memory.
- Fix uma_startup1() to try allocating memory for zones from any domain.
If domain 0 is unpopulated, the allocation will simply fail, resulting
in a page fault slightly later during boot.
- Change _vm_phys_domain() to return -1 for addresses not covered by the
affinity table, and change vm_phys_early_alloc() to handle wildcard
domains. This is necessary on amd64, where the page array is dense
and pmap_page_array_startup() may allocate page table pages for
non-existent page frames.
Reported and tested by: Rafael Kitover <rkitover@gmail.com>
Reviewed by: cem (earlier version), kib
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D25001
This is in preparation for booting via loader(8). Lift these macros from arm64
so we don't need to worry about the size when inserting new elements. This
could have been done in r359673, but I didn't think I would be returning to
this function so soon.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D24910
r359374 introduced crypto_apply function which takes as argument a function pointer
that is expected to return an int, however aesni hash update functions
return void.
Because of that the function pointer passed was simply cast with
its return value changed.
This resulted in undefined behavior, in particular when mbuf is used, (ipsec)
m_apply checks return value of function pointer passed to it
and in our case bogusly fails after calculating hash of the first mbuf
in chain.
Fix it by changing signatures of sha update routines in aesni and
dropping the casts.
Submitted by: Kornel Duleba
Reviewed by: jhb, cem
Obtained from: Semihalf
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D25030
