The public bus_map/unmap_resource() API still accepts both forms, but
the internal kobj methods no longer pass the argument.
Implementations which need the type now use rman_get_type() to fetch
the value from the allocated resource.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D44129
The public bus_adjust_resource() API still accepts both forms, but the
internal kobj method no longer passes the argument. Implementations
which need the type now use rman_get_type() to fetch the value from
the allocated resource.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D44128
Remove the 'type' and 'rid' arguments from the wrapper bus API
functions (e.g. bus_release_resource) that accept a struct resource.
The "new" versions extract the 'type' and/or 'rid' from the passed in
resource object via rman_get_type and rman_get_rid.
This commit adds the new API as functions with a _new suffix. Wrapper
macros choose between the old and new functions based on the number of
arguments provided to the macro. This commit does not change the ABI
but can be safely MFCd to older branches so long as older kernels use
rman_set_type when allocating resources.
Future commits will push the removal of these extraneous arguments
through the bus implementation.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D44124
Use rman_set_type to set the type of allocated resources everywhere
rman_set_rid is currently called.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D44123
This permits associating a resource type (e.g. SYS_RES_MEMORY) with a
struct resource.
I considered adding a new field to struct rman to store the type and
only providing rman_get_type as an accessor. However, changing
'struct rman' is an ABI breakage. I might revisit this in main, but
the current approach is MFC'able.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D44122
Doing a deep copy of the keys early allows users of the
tls_enable structure to assume kernel memory.
This enables the socket options to be set by kernel threads.
Reviewed By: #transport, tuexen, jhb, rrs
Sponsored by: NetApp, Inc.
X-NetApp-PR: #79
Differential Revision: https://reviews.freebsd.org/D44250
Remove attempts to use NetBSD __weak_alias macros to export _-prefixed
versions of various fp[sg]et* symbols under softfloat. __weak_alias
isn't defined so we didn't export them and thus the Symbol.map entries
were wrong.
Reviewed by: jhibbits
Differential Revision: https://reviews.freebsd.org/D44327
With recent fixes to the ACPI and pcib drivers to translate mapping
requests of child resources into mappings of sub-ranges of parent
resources these assertions should now be true.
This reverts commit ed88eef140.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D43691
These provide standard APIs, but are implemented using another system
call (e.g., pipe implemented in terms of pipe2) or are interposed by the
threading library to support cancelation.
After discussion with kib (see D44111), I've concluded that it is
better to keep most public interfaces in libc with as little
as possible in libsys.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D44241
Access __libsys_interposing with __libc_interposing_slot() in all
cases to support a move of these wrappers back to libc.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D44239
Long ago (e129c18a83) __sys_sigwait was wrapped to prevent sigwait()
from returning with EINTR. Through a series of changes this wrapper
become __libc_sigwait which was internal to libc and used solely in the
interposing table. To support a move of sigwait back to libc, move this
wrapper into libsys and rename it with an __libsys_ prefix.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D44238
In case of LKPI_80211_HW_CRYPTO we convert from LinuxKPI cipher_suites
to net80211 ic_cryptocaps fields. For WLAN_CIPHER_SUITE_CCMP we
accidentally returned the bit number instead of the shifted value
which leads to ieee80211_crypto_newkey() setting IEEE80211_KEY_SWCRYPT,
which in turned lead to us trying to decode the frame again despite
HW had already done it. This was found out of a discussion in D43634.
MFC after: 3 days
Reviewed by: cc, adrian
Differential Revision: https://reviews.freebsd.org/D44208
Summary:
In ar9300_eeprom_read_word() also allow JUPITER cards read the eeprom
instead of returning an error. While this will not help all the
9462, 9485, 9565 OEM cards to work, it will make debugging of the
next steps a lot easier.
While here fix a typo in the error message if we do not get CAL.
PR: 255337
Tested by: John Nielsen (john jnielsen net)
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D44328
The function was renamed to _thr_cond_timedwait in commit 0ab1bfc7b2
and for some reason did not get the same __weak_reference treatment as
other _pthread_cond symbols.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D44244
A missing else caused the correct resolver hint (AF_INET) to be
overwritten with AF_UNSPEC when the kernel supports IPv4 but not
IPv6.
MFC after: 3 days
PR: 277592
Sponsored by: NetApp, Inc.
Sponsored by: Klara, Inc.
Reviewed by: allanjude
Differential Revision: https://reviews.freebsd.org/D44304
mkimg may make severe load only to fail in the end
if output is non-seekable pipe, socket or FIFO
unless output format is raw disk image.
Check it out and fail early. Make it clear in the manual.
MFC after: 1 week
The last example in the manpage md5(1) wants to demonstrate
GNU mode (md5sum), but uses BSD mode (md5) instead.
In GNU mode, the -c option does not compare against a hash string
passed as parameter. Instead, it expects a digest file,
as created under the name digest for /boot/loader.conf in
the example above.
PR: 276560
Reviewed by: mhorne, des
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D44098
This brings the rack stack up to the current level used at NF. Many fixes
and improvements have been added. I also add in a fix to BBR to deal with
the changes that have been in hpts for a while i.e. only one call no matter
if mbuf queue or tcp_output.
It basically does little except BBlogs and is a placemark for future work on
doing path capacity measurements.
With a bit of a struggle with git I finally got rack_pcm.c into place (apologies
for not noticing this error). The LINT kernel is running on my box now .. sigh.
Reviewed by: tuexen, glebius
Sponsored by: Netflix Inc.
Differential Revision:https://reviews.freebsd.org/D43986
When a physical disk(PD) [belonging to a RAID1 Virtual disk(VD)] is
removed, driver may still use the reference to the removed PD while submitting
IO to the controller. Controller firmware faults upon receipt of such IO.
This patch fixes this issue by not using any reference to the removed PD.
Reviewed by: imp
Approved by: imp
Sponsored by: Broadcom Inc
Differential Revision: https://reviews.freebsd.org/D44282
The old timezone(3) function has long since been obsolete and has a
fatally flawed interface. Retain this function for compatibility
purposes, but shift to providing the offset from UTC in the timezone
variable, whether or not the timezone observes summer time in the
'daylight' variable. Document the tzname variable that's already been
set. Also make _tztab() static. It's not used in libc (or anywhere in
the tree) and it's not exported as a public dynamic symbol.
Sponsored by: Netflix
Reviewed by: brooks, kib
Differential Revision: https://reviews.freebsd.org/D44281
If we are able to open /sys/firmware/fdt, but aren't able to read it,
fall back to /proc/device-tree. Remove comment that's not really true,
it turns out.
Sponsored by: Netflix
If we can read the UEFI memory map, go ahead and print the memory map.
While the kernel prints this with bootverbose, having it at this stage
is useful for debugging other problems.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D44287
The host_* syscalls are all raw Linux system calls, not the POSIX
wrappers that glibc / musl create. So we have to ranage change the
return value of host_llseek correctly to use the negative value hack
that all Linux system calls use.
This fixes a false positive error detection when we do something like
lseek(fd, 0xf1234567, ...); This returns 0xf1234567, which is a negative
value which used to trigger the error path. Instead, we check using the
is_linux_error() and store the return value in a long. Translate that
errno to a host errno and set the global errno to that and return
-1. lseek can't otherwise return a negative number, since it's the
offset after seeking into the file, which by definition is positive.
This kept the 'read the UEFI memory map out of physical memory' from
working on aarch64 (whose boot loader falls back to reading it since
there are restrictive kernel options that can also prevent it), since
the physical address the memory map was at on my platform was like
0xfa008018.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D44286
offset is signed. Copy it to the unsigned res before shifting. This
avoids any possible undefined behavior for right shifting signed
numbers. No functional change intended (and the code generated is the
nearly same for aarch64).
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D44285
Linux has the convention of returning -ERRNO to flag errors from its
system calls. Sometimes other negative values are returned that are
success... However, only values -1 to -4096 (inclusive) are really
errors. The rest are either truncated values that only look negative (so
use long instead of int), or are things like addresses or legal unsigned
file offsets or similar that are successful returns. Filter out the
latter.
Sponsored by: Netflix
Although these particular constants aren't supported, the incorrect
values break bird 2.15 operation.
PR: 277618
Reported by: Ondrej Zajicek <santiago@crfreenet.org>
All callers do it right. Don't be overprotective against a stupid
caller and thus don't look like a code that leaks a resource.
Reported by: Coverity Scan
CID: 1539210
This brings the rack stack up to the current level used at NF. Many fixes
and improvements have been added. I also add in a fix to BBR to deal with
the changes that have been in hpts for a while i.e. only one call no matter
if mbuf queue or tcp_output.
Note there is a new file that I can't figure out how to get in rack_pcm.c
It basically does little except BBlogs and is a placemark for future work on
doing path capacity measurements.
Reviewed by: tuexen, glebius
Sponsored by: Netflix Inc.
Differential Revision:https://reviews.freebsd.org/D43986
Since non-doomed unionfs vnodes always share their primary lock with
either the lower or upper vnode, any forwarded call to the base FS
which transiently drops that upper or lower vnode lock may result in
the unionfs vnode becoming completely unlocked during that transient
window. The unionfs vnode may then become doomed by a concurrent
forced unmount, which can lead to either or both of the following:
--Complete loss of the unionfs lock: in the process of being
doomed, the unionfs vnode switches back to the default vnode lock,
so even if the base FS VOP reacquires the upper/lower vnode lock,
that no longer translates into the unionfs vnode being relocked.
This will then violate that caller's locking assumptions as well
as various assertions that are enabled with DEBUG_VFS_LOCKS.
--Complete less of reference on the upper/lower vnode: the caller
normally holds a reference on the unionfs vnode, while the unionfs
vnode in turn holds references on the upper/lower vnodes. But in
the course of being doomed, the unionfs vnode will drop the latter
set of references, which can effectively lead to the base FS VOP
executing with no references at all on its vnode, violating the
assumption that vnodes can't be recycled during these calls and
(if lucky) violating various assertions in the base FS.
Fix this by adding two new functions, unionfs_forward_vop_start_pair()
and unionfs_forward_vop_finish_pair(), which are intended to bookend
any forwarded VOP which may transiently unlock the relevant vnode(s).
These functions are currently only applied to VOPs that modify file
state (and require vnode reference and lock state to be identical at
call entry and exit), as the common reason for transiently dropping
locks is to update filesystem metadata.
Reviewed by: olce
Tested by: pho
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D44076
When calling VOP_CREATE(), uipc_bindat() reuses the componentname
object from the preceding lookup operation, which is likely to specify
LK_SHARED. Furthermore, the VOP_CREATE() interface technically only
requires the newly-created vnode to be returned with a shared lock.
However, the socket layer requires the new vnode to be locked exclusive
and asserts to that effect.
In most cases, this is not a practical concern because most if not
all base-layer filesystems (certainly FFS, ZFS, and msdosfs at least)
always return the vnode locked exclusive regardless of the lock flags.
However, it is an issue for unionfs which uses cn_lkflags to determine
how the new unionfs wrapper vnode should be locked. While it would
be easy enough to work around this issue within unionfs itself, it
seems better for the socket layer to be explicit about its locking
requirements when issuing VOP_CREATE().
Reviewed by: kib, olce
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D44047
It's a bit strange to require the caller to pass contrived lock flags
if the corresponding vnode is NULL, simply to appease the assertion
that exactly one of LK_SHARED or LK_EXCLUSIVE must be set. On the
other hand, we still want to catch cases in which completely bogus
or corrupt flags are passed even if the corresponding vnode is NULL.
Therefore, specifically allow empty flags for lkflags1/lkflags2 iff
the respective vp1/vp2 param is NULL.
Reviewed by: kib, olce
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D44046
crunchgen generates a foo.lo for each binary it will end up crunching
into the final product. While they have a dependency on the libs that
are used to link them, nothing will force relinking if the set of libs
needed to link them is changed. Because of this, incremental builds may
not be possible if one builds a version of, e.g., rescue/ with a broken
set of libs specified for a project -- a subsequent fix won't be rolled
in cleanly, it will require purging the rescue/ objdir.
This is a bit crude, but the foo.mk we generate doesn't actually get
regenerated all that often in practice, so a spurious relink for the
vast majority of crunched objects won't actually happen all that often.
Reviewed by: bapt, emaste, imp
Differential Revision: https://reviews.freebsd.org/D43869
