hyperv/storvsc: Avoid conditional asserts in storvsc_xferbuf_prepare()
whu@ cannot reproduce the assertion failure which led to these ifdefs
being added in the first place, and since they appear wrong, i.e., the
assertions ought to apply to all platforms, let's remove them.
This reverts commits 0af5a0cd2788efce9f444f4f781357d317bb0bb1 and
6f7b1310b6fe36f9bb653d3e97bc257adced3a2b.
PR: 285681
Tested by: whu
MFC after: 2 weeks
hyperv/storvsc: Fix busdma constraints
- The BUS_DMA_KEEP_PG_OFFSET flag is needed, since
storvsc_xferbuf_prepare() assumes that only the first segment may have
a non-zero offset, and that all following segments are page-sized and
-aligned.
- storvsc_xferbuf_prepare() handles 64-bit bus addresses, so avoid
unneeded bouncing on i386.
PR: 285681
Reported by: dim
Tested by: dim, whu
MFC after: 2 weeks
jail: Add meta and env parameters
Each one is an arbitrary string associated with a jail. It can be set
upon jail creation or added/modified later:
> jail -cm ... meta="tag1=value1 tag2=value2" env="configuration"
The values are not inherited from the parent jail.
A parent jail can read both metadata parameters, while a child jail can
read only env via security.jail.env sysctl.
The maximum size of meta or env per jail is controlled by the
global security.jail.meta_maxbufsize sysctl. Decreasing it does not
alter the existing meta information.
Each metadata buffer can be handled as a set of key=value\n strings:
> jail -cm ... meta="$(echo k1=v1; echo k2=v2)" env.1=one
[10 lines not shown]
file: Add foffset_lock_pair()
This will be used in kern_copy_file_range(), which needs to lock two
offsets.
Reviewed by: kib, rmacklem
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D49440
file: Fix offset handling in kern_copy_file_range()
One can ask copy_file_range(2) to use the file offsets of the file
descriptions that it copies from and to. We were updating those offsets
without any locking, which is incorrect and can lead to unkillable loops
in the event of a race (e.g., the check for overlapping ranges in
kern_copy_file_range() is subject to a TOCTOU race with the following
loop which range-locks the input and output file).
Use foffset_lock() to serialize updates to the file descriptions, as we
do for other, similar system calls.
Reported by: syzkaller
Reviewed by: rmacklem, kib
MFC after: 2 weeks
Fixes: bbbbeca3e9a3 ("Add kernel support for a Linux compatible copy_file_range(2) syscall.")
Differential Revision: https://reviews.freebsd.org/D49440
ptrace: Do not pass a negative resid to proc_rwmem()
While here, avoid truncting uio_resid in proc_rwmem().
Reviewed by: kib
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D49479
rangelock: Fix handling of trylocks
When inserting a queue entry, i.e., locking a range, there are two
points where a trylock operation may fail, one before the new entry is
inserted, one after. In the latter case, rl_(r|w)_validate() would mark
the entry and rangelock_lock_int() would free it. However, this is of
course incorrect, since the entry is visible to other threads, which
will eventually attempt to remove it and free it again.
Factor out conflict handling in rl_(r|w)_validate() to a common function
as they are functionally the same. Then, introduce a new result which
indicates that a trylock failed but that the queue entry must not be
cleaned up.
While here, assert that a conflicting range isn't owned by the current
thread, as that would indicate a bug in the consumer.
Reviewed by: olce, kib
Reported by: syzkaller
[2 lines not shown]
socket: Handle the possibility of a protocol with no ctloutput
Add a default ctloutput handler and remove various NULL checks. This
fixes a problem wherein the generic SO_SETFIB handler did not check
whether the protocol has a ctloutput implementation before calling the
function pointer.
Reported by: syzkaller
Reviewed by: glebius
Fixes: caccbaef8e26 ("socket: Move SO_SETFIB handling to protocol layers")
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D49436
proc: Disallow re-enabling of process itimers during exit
During process exit, it's possible for the exiting thread to send a
signal to its process, via killjobc(). This happens after the itimer is
drained. If itimers are stopped, i.e., P2_ITSTOPPED is set, then
itimer_proc_continue() will resume the callout after it has been
drained.
Fix the problem by simply clearing P2_ITSTOPPED as part of the drain.
Then, a signal received after that point will not re-enable the callout.
For good measure, also make sure that we don't reset the itimer callout
in an exiting process.
Reported by: syzkaller
Reviewed by: kib
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D49529
vm_reserv: extract common gap-checking code
vm_reserv_alloc_contig and vm_reserv_alloc_page both have code to
determine whether a new reservation will fit between the predecessor
and successor. Extract this code into a separate function rather than
having it appear twice. Optimize slightly to avoid checking object
size limit when there is a successor, and to avoid checking the upper
bound at all when the size to be allocated is a multiple of
reservation size.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D49460
ptrace_test: add test for expanded reporting of syscall args
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D49430
ptrace(2): expand ability to fetch syscall parameters
Do not limit lwpinfo reporting of syscall number and args to SCE/SCX
events. When td_sa holds the values, we can report them. Clear
td_sa.code in TDA_SIG ast handler: this handler is run when the process
is traced, and it is run with the last ptracestop() points before the
return to userspace.
This allows debugger to infer the interrupted syscall immediately after
PT_ATTACH without the need to loose control to the debuggee' thread. It
should work even when the debuggee is stopped in AST.
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D49430
tcp rack: cleanup storing values for beta and beta_ecn
beta and beta_ecn were stored using a variable of type struct newreno
in struct rack_control. Later, struct newreno was extended and now
contains several more fields.
This results in a memory inefficiency and also in copying around
uninitialized memory.
This patch fixes this by storing beta and beta_ecn individually in
struct rack_control.
Please note that the newreno_flags field was only stored and never
used. Therefore, this is not stored anymore in struct rack_control.
No functional change intended.
CID: 1523796
Reviewed by: rrs
MFC after: 1 week
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D49578
sctp: fix double unlock in case adding a remote address fails
Thanks to glebius@ for pointing to the problem.
Reported by: syzbot+1d5c164f1c10de84ad8a at syzkaller.appspotmail.com
Fixes: 2d5c48eccd9f ("sctp: Tighten up locking around sctp_aloc_assoc()"
MFC after: 3 days
nvme: Fix hotplug on one of the amazon platforms
Amazon EC2 m7i cloud instances use PCI hotplug rather than ACPI
hotplug. The card is removed and detach is called to remove the drive
from the system. The hardware is no longer present at this point, but
the bridge doesn't translate the now-missing hardware reads to all ff's
leading us to conclude the hardware is there and we need to do a proper
shutdown of it. Fix this oversight by asking the bridge if the device is
still present as well. We need both tests since some systems one cane
remove the card w/o a hotplug event and we want to fail-safe in those
cases.
Convert gone to a bool while I'm here and update a comment about
shutting down the controller and why that's important.
Tested by: cperciva
Sponsored by: Netflix
(cherry picked from commit dc95228d98474aba940e3885164912b419c5579d)
sound: Fix regression in pcm/feeder_mixer.c
This call was meant to be the default case in the first place, but
somehow missed this.
Reported by: glebius
Fixes: 4021fa32d92d ("sound: Simplify pcm/feeder_mixer.c")
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
sound: Use bus_topo_lock() where appropriate
Lock around uses of devclass_*() and replace leftover
CTLFLAG_NEEDGIANTs with CTLFLAG_MPSAFE.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: imp, jhb
Differential Revision: https://reviews.freebsd.org/D46700
beep(1): Use AFMT_FLOAT
AFMT_FLOAT is supported by sound(4) as of FILLME, so use it here, since
the whole program works with floats already.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D47639
sound: Implement AFMT_FLOAT support
Even though the OSS manual [1] advises against using AFMT_FLOAT, there
are applications that expect the sound driver to support it, and might
not work properly without it.
This patch adds AFMT_F32_LE|BE (as well as AFMT_FLOAT for OSS
compatibility) in sys/soundcard.h and implements AFMT_F32_LE|BE <->
AFMT_S32_LE|BE conversion functions. As a result, applications can
write/read floats to/from sound(4), but internally, because sound(4)
works with integers, we convert floating point samples to integer ones,
before doing any processing.
The reason for encoding/decoding IEEE754s manually, instead of using
fpu_kern(9), is that fpu_kern(9) is not supported by all architectures,
and also introduces significant overhead.
The IEEE754 encoding/decoding implementation has been written by Ariff
Abdullah [2].
[9 lines not shown]
sound: Fix vchanrate and vchanformat
Make vchanrate and vchanformat reflect the primary channel's software
buffer's rate and format respectively. Fix previous inconsistencies.
Get rid of the initializations in vchan_create() and move them to
chn_init().
Without the feeder_rate_round check in sysctl_dev_pcm_vchanrate(), we
can set the software rate to anything between feeder_rate_min and
feeder_rate_max. If we keep the check, however, the rate is limited to
whatever the driver's min/max is, which can be a problem if, for
example, the driver supports only a single rate, in which case we won't
be able to set anything other than the driver rate.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D48961
