Gordon Bergling [Wed, 12 Aug 2020 07:00:06 +0000 (07:00 +0000)]
MFC r363907: environ(7): Update the description and include some more environment variables
- Add a better introduction to the DESCRIPTION section
- Add a description for MANPATH and POSIXLY_CORRECT
- Asorted improvements for the usage of some macros
Eugene Grosbein [Tue, 11 Aug 2020 11:32:44 +0000 (11:32 +0000)]
MFC r363064,363067,363081,363136: optimize install(1) a bit.
Currently, "install -s -S" behaviour is inefficient for upgrade.
First it finds that destination file already exists and copies
source file to temporary file. Then it calls strip(1)
with name of temporary file as single agrument and our strip(1) creates
another temporary file in the /tmp (or TMPDIR) making another copy
that is finally copied to DESTDIR third time.
Meantime, strip(1) has an option "-o dst" to specify destination
so install(1) is allowed to skip initial copying from obj to DESTDIR.
This change makes it do so.
This optimization descreases total amount of data sent to
both of /tmp and DESTDIR during "make installworld" by 32% or so.
See the differential for details.
Gordon Bergling [Tue, 11 Aug 2020 10:56:44 +0000 (10:56 +0000)]
MFC r363829: directory(3): Add an ERRORS section
- Add an ERRORS section for opendir(3) and closedir(3)
- Document also the errors of readdir(3), readdir_r(3) and telldir(3)
- Convert the code sample into an EXAMPLES section
Rick Macklem [Tue, 11 Aug 2020 05:10:01 +0000 (05:10 +0000)]
MFC: r363210
Fix the pNFS flexible file layout client for servers with small write size.
The code in nfscl_dofflayout() loops when a flexible file layout server
provides a small write data limit (no extant server is known to do this).
If/when it looped, it erroneously reused the "drpc" argument for the
mirror worker thread, corrupting it.
This patch fixes the problem by only using the calling thread after the
first loop iteration.
Found during testing by simulating a server with a small write size.
Since no extant pNFS server is known to provide a small write size,
this fix it not needed in practice at this time.
Alexander Motin [Tue, 11 Aug 2020 00:41:48 +0000 (00:41 +0000)]
MFC r363852: Remove extra memset() left after r342388.
This memset() wiped MPI2_FUNCTION_SCSI_TASK_MGMT set by mprsas_alloc_tm(),
that broke target reset on device removal, making later re-insertion into
the same slot impossible, since firmware was still waiting for the driver
to finish with the removed device.
iflib: initialize netmap with the correct number of descriptors
In case the network device has a RX or TX control queue, the correct
number of TX/RX descriptors is contained in the second entry of the
isc_ntxd (or isc_nrxd) array, rather than in the first entry.
This case is correctly handled by iflib_device_register() and
iflib_pseudo_register(), but not by iflib_netmap_attach().
If the first entry is larger than the second, this can result in a
panic. This change fixes the bug by introducing two helper functions
that also lead to some code simplification.
Dimitry Andric [Mon, 10 Aug 2020 17:35:58 +0000 (17:35 +0000)]
MFC r363988:
Fix clang 11 -Wformat warnings in yp_mkdb:
usr.sbin/yp_mkdb/yp_mkdb.c:91:40: error: format specifies type 'char *' but the argument has type 'void *' [-Werror,-Wformat]
printf("%.*s %.*s\n", (int)key.size, key.data, (int)data.size,
~~~~ ^~~~~~~~
usr.sbin/yp_mkdb/yp_mkdb.c:92:7: error: format specifies type 'char *' but the argument has type 'void *' [-Werror,-Wformat]
data.data);
^~~~~~~~~
Import new 2-clause BSD licenced implementation of the bc and dc commands
These implementations of the bc and dc programs offer a number of advantages
compared to the current implementations in the FreeBSD base system:
- They do not depend on external large number functions (i.e. no dependency
on OpenSSL or any other large-number library)
- They implements all features found in GNU bc/dc (with the exception of
the forking of sub-processes in dc, which the author of this version
considers a security issue).
- They are significantly faster than the current code in base (more than
2 orders of magnitude in some of my tests, e.g. for 12345^100000).
- They should be fully compatible with all features and the behavior of the
current implementations in FreeBSD (not formally verified).
- They support POSIX message catalogs and come with localized messages in
Chinese, Dutch, English, French, German, Japanese, Polish, Portuguese,
and Russian.
- They offer very detailed man-pages that provide far more information than
the current ones.
This code is not built and installed in FreeBSD-12, unless WITH_GH_BC=yes
is set (e.g. in src.conf) during builworld and installworld. It has been
imported and made the default in FreeBSD-CURRENT, and all improvements and
changes requested for the version in -CURRENT are included in this initial
import into a stable branch.
The only thing this tunable enables now is reporting to ACPI _OSC that
Active State Power Management and Clock Power Management Capability are
"supported" by the OS.
I've found that at least some Supermicro server boards do not allow OS
to support native PCIe hot-plug unless it reports those capabilities.
After spending significant time in PCIe specs I have found very little
motivation for that, and none of it applies to those motherboards, not
enabling ASPM themselves. So unless OS explicitly wants to save power,
I see nothing for it to do there actually.
I guess it may get sense to support ASPM when we get Thunderbolt support.
Otherwise I have no system with PCIe hot-plug where power saving matters.
It would be nice to enable this by default, but I worry that it affect
power saving of some laptops, even though I haven't noticed that myself.
Gordon Bergling [Fri, 7 Aug 2020 15:03:20 +0000 (15:03 +0000)]
MFC r363291: devstat(9): Update the man page to reflect the current implementation
- Rename devstat_add_entry to devstat_new_entry
- Update the description of devstat_trans_flags
- Add manpage aliases for devstat_start_transaction_bio and devstat_end_transaction_bio
Alexander Motin [Fri, 7 Aug 2020 01:05:10 +0000 (01:05 +0000)]
MFC r363624: Add initial driver for ACPI Platform Error Interfaces.
APEI allows platform to report different kinds of errors to OS in several
ways. We've found that Supermicro X10/X11 motherboards report PCIe errors
appearing on hot-unplug via this interface using NMI. Without respective
driver it ended up in kernel panic without any additional information.
This driver introduces support for the APEI Generic Hardware Error Source
reporting via NMI, SCI or polling. It decodes the reported errors and
either pass them to pci(4) for processing or just logs otherwise. Errors
marked as fatal still end up in kernel panic, but some more informative.
When somebody get to native PCIe AER support implementation both of the
reporting mechanisms should get common error recovery code. Since in our
case errors happen when the device is already gone, there is nothing to
recover, so the code just clears the error statuses, practically ignoring
the otherwise destructive NMIs in nicer way.
Alexander Motin [Fri, 7 Aug 2020 00:56:20 +0000 (00:56 +0000)]
MFC r360328 (by vangyzen):
Fix handling of NMIs from unknown sources (BMC, hypervisor)
Release kernels have no KDB backends enabled, so they discard an NMI
if it is not due to a hardware failure. This includes NMIs from
IPMI BMCs and hypervisors.
Furthermore, the interaction of panic_on_nmi, kdb_on_nmi, and
debugger_on_panic is confusing.
Respond to all NMIs according to panic_on_nmi and debugger_on_panic.
Remove kdb_on_nmi. Expand the meaning of panic_on_nmi by making
it a bitfield. There are currently two bits: one for NMIs due to
hardware failure, and one for all others. Leave room for more.
If panic_on_nmi and debugger_on_panic are both true, don't actually panic,
but directly enter the debugger, to allow someone to leave the debugger
and [hopefully] resume normal execution.
Relnotes: yes: machdep.kdb_on_nmi is gone; machdep.panic_on_nmi changed
Alexander Motin [Fri, 7 Aug 2020 00:40:28 +0000 (00:40 +0000)]
MFC r363527: Allow swi_sched() to be called from NMI context.
For purposes of handling hardware error reported via NMIs I need a way to
escape NMI context, being too restrictive to do something significant.
To do it this change introduces new swi_sched() flag SWI_FROMNMI, making
it careful about used KPIs. On platforms allowing IPI sending from NMI
context (x86 for now) it immediately wakes clk_intr_event via new IPI_SWI,
otherwise it works just like SWI_DELAY.
Alexander Motin [Fri, 7 Aug 2020 00:26:16 +0000 (00:26 +0000)]
MFC r363490: Make lapic_ipi_vectored(APIC_IPI_DEST_SELF) NMI safe.
Sending IPI to self or all CPUs does not require write into upper part of
the ICR, prone to races. Previously the code disabled interrupts, but it
was not enough for NMIs. Instead of that when possible write only lower
part of the register, or use special SELF IPI register in x2APIC mode.
This also removes ICR reads used to preserve reserved bits on write.
It was there from the beginning, but I failed to find explanation why,
neither I see Linux doing it. Specification even tells that ICR content
may be lost in deep C-states, so if hardware does not bother to preserve
it, why should we?
Kyle Evans [Thu, 6 Aug 2020 18:17:19 +0000 (18:17 +0000)]
MFC r363692: diff: fix side_by_side
It's currently unclear to me how this could have worked previously; \n here
is not a literal newline but actual '\' 'n', and was getting passed to the
underlying regex engine as such. regex(3) does not translate this to a
newline, and this became an error because we don't really allow escaping
of arbitrary ordinary characters anymore.
Run the pattern strings through printf to make sure we're dealing with real
newlines before passing them through to atf_check, which ultimately feeds
them directly to regcomp(3).
This fix is different than that will be needed for sed, in that this is the
proper way to inject newlines into search strings as long as regex(3)
won't combine \ + n as folks might expect.
When WITHOUT_SENDMAIL is set, we end up with two different mailer.conf that
conflict, and hilarity ensues. There's currently three different places that
we might install mailer.conf:
- ^/etc/Makefile (package=runtime, contingent on MK_MAIL != no)
- ^/libexec/dma/dmagent/Makefile (package=dma, contingent on MK_SENDMAIL !=
no)
- ^/usr.sbin/mailwrapper/Makefile (package=utilities, contingent on
not-installed)
The mailwrapper installation will effectively never happen because the ^/etc
one will first.
This patch simplifies the whole situation; remove the ^/etc/Makefile version
and install it primarily in mailwrapper if MK_MAILWRAPPER != "no". The
scenarios covered in mailwrapper are:
- sendmail(8) is installed, dma(8) may or may not be installed
- neither sendmail(8) nor dma(8) is installed
In the first scenario, sendmail(8) is dominant so we can go ahead and
install the version in ^/etc/mail. In the unlisted scenario, sendmail(8) is
not installed but dma(8) is, we'll let ^/libexec/dma/dmagent do the
installation. In the second listed scenario, we still want to install an
example mailer.conf so just install the base sendmail(8) version.
r362787:
mailwrapper: switch mailer.conf to CONFS
This matches what was already being done in dma(8), and should again make
this merge with etcupdate/mergemaster.
Andriy Gapon [Thu, 6 Aug 2020 08:06:07 +0000 (08:06 +0000)]
MFC r362042: iicbb: rebuild the bit-banging algorithms using different primitives
I2C_SET was quite inflexible, it used too long delays as well as some
unnecessary delays. The new building blocks are iicbb_clockin and
iicbb_clockout. The former sets SDA and starts the high period of SCL,
the latter executes the low period of SCL. What happens during the high
phase depends on the operation. For writes we just hold both lines, for
reads we poll SDA. S, Sr and P change SDA in the middle of the high
period.
Also, the calculation of udelay has been updated, so that the resulting
period more closely corresponds the requested bus frequency. There is a
new knob, io_delay, that allows to further adjust udelay based on the
estimated latency of pin toggling operations.
Finally, I slightly changed debug tracing and added error indicators to
it. The debug prints are compiled in but disabled by default. This can
be of use if there is any fallout from this change.
Kyle Evans [Thu, 6 Aug 2020 04:54:59 +0000 (04:54 +0000)]
MFC r363409: libbe: annotate lbh as __unused in be_is_auto_snapshot_name
lbh is included for consistency with other functions and in case
future work needs to use it, but it is currently unused. Mark it,
and a post-OpenZFS-import world will be able to raise WARNS of
libbe to the default (pending some minor changes to openzfs libzfs).
Kyle Evans [Thu, 6 Aug 2020 04:52:30 +0000 (04:52 +0000)]
MFC r363421: pkg-bootstrap: complain on improper `pkg bootstrap` usage
Right now, the bootstrap will gloss over things like pkg bootstrap -x or
pkg bootstrap -f pkg. Make it more clear that this is incorrect, and hint
at the correct formatting.
Kyle Evans [Wed, 5 Aug 2020 14:42:45 +0000 (14:42 +0000)]
MFC r362564: stand: remove redundant declarations
These are picked out by the amd64-gcc6 build; time() is declared in <time.h>
and delay() is declared in <bootstrap.h>. These are the correct places for
these in stand/, so remove the duplicate declarations and make sure the
delay() consumer in libefi that depended on the extra delay() declaration
includes <bootstrap.h>.
Kyle Evans [Wed, 5 Aug 2020 14:40:09 +0000 (14:40 +0000)]
MFC r361257: bsdinstall: do a `certctl rehash` upon installation of config
If certctl is installed on the system we're configuring, do a certctl
rehash.
Note that certctl may not be present if the world we've installed was built
either WITHOUT_OPENSSL or WITHOUT_CAROOT. In this scenario, we don't
currently see if the host has a certctl as this may be an indication that
the system *shouldn't* have certs installed into /etc/ssl.
This commit diverges from our usual procedure of committing generated files
separately because the original commit, r359836, conflated userland use (in
tests) with the implementation.
__FreeBSD_version was already bumped ~15 hours prior to this MFC, 1201522
marks the introduction of close_range.
CPython will use this syscall for some pretty sizable performance gains.
r359836:
Implement a close_range(2) syscall
close_range(min, max, flags) allows for a range of descriptors to be
closed. The Python folk have indicated that they would much prefer this
interface to closefrom(2), as the case may be that they/someone have special
fds dup'd to higher in the range and they can't necessarily closefrom(min)
because they don't want to hit the upper range, but relocating them to lower
isn't necessarily feasible.
sys_closefrom has been rewritten to use kern_close_range() using ~0U to
indicate closing to the end of the range. This was chosen rather than
requiring callers of kern_close_range() to hold FILEDESC_SLOCK across the
call to kern_close_range for simplicity.
The flags argument of close_range(2) is currently unused, so any flags set
is currently EINVAL. It was added to the interface in Linux so that future
flags could be added for, e.g., "halt on first error" and things of this
nature.
This patch is based on a syscall of the same design that is expected to be
merged into Linux.
r359837:
sysent: re-roll after introduction of close_range in r359836
r359891:
close_range/closefrom: fix regression from close_range introduction
close_range will clamp the range between [0, fdp->fd_lastfile], but failed
to take into account that fdp->fd_lastfile can become -1 if all fds are
closed. =-( In this scenario, just return because there's nothing further we
can do at the moment.
Add a test case for this, fork() and simply closefrom(0) twice in the child;
on the second invocation, fdp->fd_lastfile == -1 and will trigger a panic
before this change.
r360236:
close_range(2): use newly assigned AUE_CLOSERANGE
r360237:
sysent: re-roll after 360236 (AUE_CLOSERANGE used)
Pawel Biernacki [Tue, 4 Aug 2020 12:42:55 +0000 (12:42 +0000)]
MFC kernel part of r351729
Add sysctlbyname system call
The two syscalls that exists in head but not in stable/12 are marked as
UNIMPL to keep the __sysctlbyname syscall number the same (570).
Userland part to be commited in about a week time.
Ryan Moeller [Tue, 4 Aug 2020 12:04:47 +0000 (12:04 +0000)]
MFC r363630:
libpmc: Use known pmc_cpuid buffer size
Use the existing PMC_CPUID_LEN to size pmc_cpuid in the kernel and various
buffers for reading it in libpmc. This avoids some extra syscalls and
malloc/frees.
While in here, use strlcpy to copy a user-provided cpuid string instead of
memcpy, to make sure we terminate the buffer.
Reviewed by: mav
Sponsored by: iXsystems, Inc.
Differential Revision: https://reviews.freebsd.org/D25679
Alexander Motin [Tue, 4 Aug 2020 02:31:52 +0000 (02:31 +0000)]
MFC r363656: When modifying LUN pass "special" options too.
Before switching to nvlists CTL merged previous and new options, so
any options not passed just kept previous value. Now CTL completely
replaces them, so we must pass everything still relevant.
MFC r363078:
Implement the bitmap_subset() function in the LinuxKPI. This function
checks if the bitmap pointed to by the first argument is a subset of
the bitmap pointed to by the second argument. The function returns one
on success and zero on failure.
MFC r363077:
Implement the array_size() function in the LinuxKPI. This function
basically multiplies its two arguments and returns SIZE_MAX if the
result overflows the size_t type. Else the product of the two
arguments is returned.
Bump the FreeBSD_version to mitigate issues with existing
implementation of array_size() in drm-devel-kmod.
Only add check_add_overflow and check_mul_overflow as those are the only
two needed function by DRM v5.3.
Both gcc and clang have builtin to do this check so use them directly
but throw an error if the compiler/code checker doesn't support this builtin.
Sponsored-by: The FreeBSD Foundation
Reviewed by: hselsasky
Differential Revision: https://reviews.freebsd.org/D25015
Gordon Bergling [Sat, 1 Aug 2020 14:22:05 +0000 (14:22 +0000)]
MFC r359547, r359629 (by imp): Note some functions that appeared in First Edition Unix
These functions first appeared in the First Edition of Unix (or earlier in the
pdp-7 version). Just claim 1st Edition for all this. The pdp-7 code is too
fragmented at this point to extend history that far back.
Document that force_depend() supports only /etc/rc.d scripts
Currently, force_depend() from rc.subr(8) does not support depending on
scripts outside of /etc/rc.d (like /usr/local/etc/rc.d). The /etc/rc.d path
is hard-coded into force_depend().
MFC r363383: dtrace/fbt: fix return probe arguments on arm
arg0 should be an offset of the return point within the function, arg1
should be the return value. Previously the return probe had arguments as
if for the entry probe.
Tested on armv7.
andrew noted that the same problem seems to be present on arm64, mips,
and riscv.
I am not sure if I will get around to fixing those. So, platform users
or anyone looking to make a contribution please be aware of this
opportunity.
MFC r362530: teach ena driver about RSS kernel option
Networking is broken if the driver configures its (virtual) hardware to
use a hash algorithm (or a key) different from the one that the network
stack (software RSS) uses. This can be seen with connections initiated
from the host. The PCB will be placed into the hash table based on the
hash value calculated by the software. The hardware-calculated hash
value in reponse packets will be different, so the PCB won't be found.
Tested with a kernel compiled with 'options RSS' on an instance with ena
driver.
MFC r362294,r362647: hdac_intr_handler: keep working until global interrupt status clears
It is plausible that the hardware interrupts a host only when GIS goes
from zero to one. GIS is formed by OR-ing multiple hardware statuses,
so it's possible that a previously cleared status gets set again while
another status has not been cleared yet. Thus, there will be no new
interrupt as GIS always stayed set. If we don't re-examine GIS then we
can leave it set and never get another interrupt again.
Without this change I frequently saw a problem where snd_hda would stop
working. Setting dev.hdac.1.polling=1 would bring it back to life and
afterwards I could set polling back to zero. Sometimes the problem
started right after a boot, sometimes it happened after resuming from
S3, frequently it would occur when sound output and input are active
concurrently (such as during conferencing). I looked at HDAC_INTSTS
while the sound was not working and I saw that both HDAC_INTSTS_GIS and
HDAC_INTSTS_CIS were set, but there were no interrupts.
Brooks Davis [Wed, 29 Jul 2020 20:30:15 +0000 (20:30 +0000)]
MFC r363435:
Avoid reading one byte before the path buffer.
This happens when there's only one component (e.g. "/foo"). This
(mostly-harmless) bug has been present since June 1990 when it was
commited to mountd.c SCCS version 5.9.
Note: the bug is on the second changed line, the first line is changed
for visual consistency.
Don Lewis [Wed, 29 Jul 2020 04:36:45 +0000 (04:36 +0000)]
Make lex a bootstrap tool when cross-building on recent 13-CURRENT if
binutils/ld is going to be built. The latter is no longer true by default.
The import of flex 2.6.4 into -CURRENT changed the type of yy_n_chars
in the lex skeleton from yy_size_t to int, which breaks the build of
binutils/ld when using the host copy of lex.
ldlex.c:3216:3: error: incompatible pointer types passing 'int *' to parameter
of type 'yy_size_t *' (aka 'unsigned long *')
[-Werror,-Wincompatible-pointer-types]
...YY_INPUT( (&YY_CURRENT_BUFFER_LVALUE->yy_ch_buf[number_to_move]),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This is a direct commit to stable/12 since binutils/ld has been removed
from -CURRENT, and it would require a different fix there since the
bootstrap tool version of lex would also cause breakage. This is similar
to the stable/11 change in r363653, but in stable/12 we only need to
build lex as a bootstrap tool if binutils/ld is going to be built.
projects / FreeBSD / FreeBSD.git / log