This update fixes a bug that line breaks in printed numbers may not
match the line length set by the user. The value is printed correctly,
just not split as specified in some situations.
(cherry picked from commit 52a5ec1b178fd07651446c7e31b1512794a04dbf)
This update improves the implementation of the power function p() and
adds 3 new functions to the extended math library: min(), max(), and
i2rand().
(cherry picked from commit 0b4a06ab29a0da80f6cb5c99189054cb8e2f756c)
The modern zcat(1) is capable of handling compressed and uncompressed
text files, so we can simply use zcat command.
PR: 253168
Reviewed by: delphij
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D43357
Since fdb987bebddf it is not possible anymore to use inp_next
iterator for bound, but unconnected sockets. This applies
to TCP listening sockets. Therefore the metioned commit broke
tcpsso on listening sockets if the -i option was not used.
Fix this by iterating through all endpoints instead of only
through the bound, but unconnected ones.
Reviewed by: markj
Fixes: fdb987bebddf ("inpcb: Split PCB hash tables")
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D43353
Add _SYSCALL_BODY() macro which invokes the syscall via _SYCALL() and
calls cerror as required. Use to implement PSEUDO() and RSYSCALL().
Reviewed by: jhibbits
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D43322
Allocate 9000 bytes to match the largest requsted size. Add a check to
prevent the list of sizes and buffer size from getting out of sync
again.
Reviewed by: markj
Found with: CheriBSD
Differential Revision: https://reviews.freebsd.org/D43340
The global hw.igb.rx_process_limit knob never was adhered to by the
in-tree version of this driver but similar functionality is available
via the device-specific dev.igb.N.iflib.rx_budget.
While at it, remove the - besides initialization of tx_process_limit -
unused {r,t}x_process_limit members.
The global hw.em.rx_process_limit knob has been replaced by the device-
specific dev.IF.N.iflib.rx_budget along with the conversion to iflib(4).
While at it, remove the - besides initialization of tx_process_limit -
unused {r,t}x_process_limit members.
Work around vendors who use the same address for multiple
ReadAckRegisters in their ACPI HEST table. This
allows apei to attach cleanly on Ampere Altra servers.
Note the issue is not specific to Ampere, I've run into
it with at least one other vendor (whose server is not
yet released).
Sponsored by: Netflix
Reviewed by: jhb
Refactoring of argument list to nl_send_one() led to derefercing
wrong union member. Rename nl_send_one() to a more generic name,
isolate anew nl_send_one() as the callback only for the normal
writer and provide correct argument to nl_send() from nl_send_group().
Fixes: ff5ad900d2a0793659241eee96be53e6053b5081
This applies the fix to powerpc's pmap as was done in commit aa3bcaad51076ceb
and d0941ed9b5c39d92 for amd64 and riscv pmaps, respectively.
Reported by: Jenkins
Reviewed by: bojan.novkovic_fer.hr, markj
Fixes: e4078494f344bcba8709216bd601efa3dd05f6b3
Differential Revision: https://reviews.freebsd.org/D43339
In particular, don't reserve resources added by drivers via other
means (e.g. acpi_bus_alloc_gas which calls bus_alloc_resource
right after adding the resource).
The intention of reserved resources is to ensure that a resource range
that a bus driver knows is assigned to a device is reserved by the
system even if no driver is attached to the device. This prevents
other "wildcard" resource requests from conflicting with these
resources. For ACPI, the only resources the bus driver knows about
for unattached devices are the resources returned from _CRS. All of
these resources are already reserved now via acpi_reserve_resources
called from acpi_probe_children.
As such, remove the logic from acpi_set_resource to try to reserve
resources when they are set. This permits RF_SHAREABLE to work with
acpi_bus_alloc_gas without requiring hacks like the current one for
CPU device resources in acpi_set_resource.
Reported by: gallatin (RF_SHAREABLE not working)
Diagnosed by: jrtc27
memdesc_alloc_ext_mbufs constructs a chain of external (M_EXT or
M_EXTPG) mbufs backed by a data buffer described by a memory
descriptor.
Since memory descriptors are not an actual buffer just a description
of a buffer, the caller is required to supply a couple of helper
routines to manage allocation of the raw mbufs and associating them
with a reference to the underlying buffer.
Reviewed by: markj
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D42933
These loops already handled a NULL return from mbufq_dequeue when the
queue was empty, so remove a redundant check of mbufq_len before
dequeueing.
Reviewed by: bz
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D43336
Existing powerpc kernels include additional sections beyond .dynamic
in the PT_DYNAMIC segment. Relax the requirement for an exact size
match of the section and segment for PowerPC files as a workaround.
Reported by: jrtc27
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D43123
This allows writing setup scripts that contain lines starting with
"#!", e.g., a shebang when creating a shell script using cat:
#!/bin/sh
echo "Populate rc.local"
cat >/etc/rc.local<<EOF
#!/bin/sh
echo booted | logger -s -t 'example'
EOF
Prevent accidentally running a setup script left behind by a
previous invocation of bsdinstall.
Reviewed by: imp, jrtc27
Differential Revision: https://reviews.freebsd.org/D43350
This commit adds the zed_notify_gotify() function and hooks it
into zed_notify(). This will allow ZED to send notifications
to a self-hosted Gotify service, which can be received
on a desktop or mobile device. It is configured with ZED_GOTIFY_URL,
ZED_GOTIFY_APPTOKEN and ZED_GOTIFY_PRIORITY variables in zed.rc.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: gofaster <felix.gofaster@gmail.com>
Closes#15693
Two block pointers in livelist pointing to the same location may
be caused not only by dedup, but also by block cloning. We should
not assert D bit set in them.
Two block pointers in livelist pointing to the same location may
have different logical birth time in case of dedup or cloning. We
should assert identical physical birth time instead.
Assert identical physical block size between pointers in addition
to checksum, since that is what checksums are calculated on.
Reviewed-by: Matthew Ahrens <mahrens@delphix.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Alexander Motin <mav@FreeBSD.org>
Sponsored by: iXsystems, Inc.
Closes#15732
- Fail if source block is smaller than destination. We can only
grow blocks, not shrink them.
- Fail if we do not have full znode range lock. In that case grow
is not even called. We should improve zfs_rangelock_cb() somehow
to know when cloning needs to grow the block size unlike write.
- Fail of we tried to resize, but failed. There are many reasons
for it to fail that we can not predict at this level, so be ready
for them. Unlike write, that may proceed after growth failure,
block cloning can't and must return error.
This fixes assertion inside dmu_brt_clone() when it sees different
number of blocks held in destination than it got block pointers.
Builds without ZFS_DEBUG returned EXDEV, so are not affected much.
Reviewed-by: Pawel Jakub Dawidek <pawel@dawidek.net>
Reviewed-by: Brian Atkinson <batkinson@lanl.gov>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Alexander Motin <mav@FreeBSD.org>
Sponsored by: iXsystems, Inc.
Closes#15724Closes#15735
This function decompresses to two buffers and then compares them to
check whether the (opaque) decompression process filled the whole
buffer. Previously it began with lbuf uninitialized and lbuf2 filled
with pseudorandom data. This neither guarantees that any bytes not
written by the compressor would be different, nor seems incredibly
sound otherwise!
After these changes, instead of filling one buffer with generated
pseudorandom data we overwrite each buffer with completely different
data. This should remove the possibility of low-probability failures,
as well as make the process simpler and cheaper.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Rich Ercolani <rincebrain@gmail.com>
Signed-off-by: Kent Ross <k@mad.cash>
Closes#15733
The standard is somewhat unclear, but on the balance, I believe that the
phrase “the rest of the input line” should be interpreted to mean the
rest of the input line including the terminating newline if and only if
there is one. This means the current implementation is incorrect on two
points:
- First, it suppresses the previous line's newline in the '1' case.
- Second, it unconditionally emits a newline at the end of the output
for non-empty input, even if the input did not end with a newline.
Resolve this by rewriting the main loop. Instead of special-casing the
first line and then assuming that every line ends with a newline, we
remember how each line ends and emit that either at the beginning of
the next line or at the end of the file except in the one case ('+')
where the standard explicitly says not to.
While here, try to reduce diff to upstream a little and update their
RCS tag to reflect the fact that while we've diverged significantly
from them, we've incorporated all their changes. Remove the useless
second RCS tag.
We also update the tests to account for the change in interpretation
of the '1' case and add a test case for unterminated input.
MFC after: 1 week
Sponsored by: Klara, Inc.
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D43326
Issue data claim command after every chunk of data programmed,
so we can reuse the SVC buffer for the next chunk.
Tested on Terasic DE10 Pro.
Sponsored by: UKRI
Using calloc() instead of malloc() is useless here since the allocated
memory is to be wholly crushed by the memcpy() call that follows.
Suggested by: kib
Reviewed by: emaste, kib
Approved by: emaste (mentor)
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D43328
The change of argument for sizeof() (from a type to an object) is to be
consistent with the change done for the malloc() code just above in the
preceding commit touching this file.
Consider bit flags as integers and test whether they are set with an
explicit comparison with 0.
Use an explicit flag value (PTHREAD_SCOPE_SYSTEM) in place of a variable
that has this value at point of substitution.
All other changes are straightforward.
Suggested by: kib
Reviewed by: kib
Approved by: emaste (mentor)
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D43327
In belatedly fixing a mistake made in fbbdfa2b8a42, I noticed that igor
and mandoc -Tlint had a few more things to say.
As such, I'm reflowing a few lines and fixing a contraction.
MFC with: fbbdfa2b8a42
I forgot to do it when making the commit, so hat-tip to asomers@
Reported by: asomers@
Fixes: fbbdfa2b8a42 (nfsv4(4): mention the nfsv4_server_only..)
MFC with: fbbdfa2b8a42
CC/CXX/CPP/LD may all have arguments supplied in various circumstances,
which break the logic here. We only need to determine which of these
tools we're expecting to invoke from PATH, which just requires
examination of the first word. Limit our scope to exactly that.
Patch suggested by: jrtc27
Reviewed by: imp, jrtc27
Differential Revision: https://reviews.freebsd.org/D43372
In the case of hostbase_fd, this is infact a bug fix; we have a seek
callback that the host: filesystem may use in loader, and we really
don't have a good excuse to break it.
bootfd-derived fds will only be used with fdlopen(3) and rtld doesn't
seem to need pread / lseek at all for it today, but there's no reason to
break if it finds a good reason to later.
Suggested by: markj
This is a quick plug to fix panic with Netlink which has protocol specific
buffers. Note that PF_UNIX/SOCK_DGRAM, which also has its own buffers,
avoids the panic due to being SOCK_DGRAM. A correct but more complicated
fix that needs to be done is to merge pr_shutdown, pr_flush and dom_dispose
into one protocol method that may call sorflush for generic sockets or do
their own stuff for protocol which has own buffers.
Reviewed by: tuexen
Differential Revision: https://reviews.freebsd.org/D43367
Reported-by: syzbot+a58e1615881c01a51653@syzkaller.appspotmail.com
While picking parts from #14909 I've missed Linux tracing specific
ones, that went unnoticed in default configurations, but breaks the
build in some.
Reviewed-by: Ameer Hamza <ahamza@ixsystems.com>
Reviewed-by: Brian Atkinson <batkinson@lanl.gov>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Alexander Motin <mav@FreeBSD.org>
Sponsored by: iXsystems, Inc.
Closes#15730
This patch adds check for `kernel_neon_*` symbols on arm and arm64
platforms to address the following issues:
1. Linux 6.2+ on arm64 has exported them with `EXPORT_SYMBOL_GPL`, so
license compatibility must be checked before use.
2. On both arm and arm64, the definitions of these symbols are guarded
by `CONFIG_KERNEL_MODE_NEON`, but their declarations are still
present. Checking in configuration phase only leads to MODPOST
errors (undefined references).
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Shengqi Chen <harry-chen@outlook.com>
Closes#15711Closes#14555Closes: #15401
PRR state was not properly reset on subsequent ECN CE
events. Clean up after local transmission failures too.
Reviewed by: tuexen, cc, #transport
MFC after: 3 days
Sponsored by: NetApp, Inc.
Differential Revision: https://reviews.freebsd.org/D43170
Only try sending more data on pure ACKs when there is
more data available in the send buffer.
In the case of a retransmitted SYN not being sent due to
an internal error, the snd_una/snd_nxt accounting could
be off, leading to a panic. Pulling snd_nxt up to snd_una
prevents this from happening.
Reported by: fengdreamer@126.com
Reviewed by: cc, tuexen, #transport
MFC after: 1 week
Sponsored by: NetApp, Inc.
Differential Revision: https://reviews.freebsd.org/D43343
Previously we used a mix of perror(3) + exit(3) and err(3); standardize
on the latter instead. This does remove one free() in an error path,
because we're decidedly leaking a lot more than just the loader name
there (loader handle, vcpu, vmctx...) anyways.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D43331
