rename the source to gsb_crc32.c.
This is a prerequisite of unifying kernel zlib instances.
PR: 229763
Submitted by: Yoshihiro Ota <ota at j.email.ne.jp>
Differential Revision: https://reviews.freebsd.org/D20193
This is for an upcoming change that fixes .depend handling in here.
It will cause some duplicate sources which need to be trimmed out.
MFC after: 2 weeks
Sponsored by: DellEMC
The man page claims that with O_FSYNC (aka O_SYNC) the kernel will not cache
written data. However, that's not true. Nor does POSIX require it.
Perhaps it was true when that section of the man page was written in r69336
(I haven't checked). But it's not true now. Now the effect is simply that
writes are sent to disk immediately and synchronously, but they're still
cached.
See also: https://pubs.opengroup.org/onlinepubs/9699919799/
See also: ffs_write in sys/ufs/ffs/ffs_vnops.c
Reviewed by: cem
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D20641
libunwind and openmp to the upstream release_80 branch r363030
(effectively, 8.0.1 rc2). The 8.0.1 release should follow this within a
week or so.
MFC after: 2 weeks
Sync libarchive with vendor.
Relevant vendor changes:
- check_symlinks_fsobj() without chdir() and fchdir()
- bsdtar.1 manpage fixes
- patches from OpenBSD to libarchive_fe/passphrase.c
- version bumped to 3.4.0
MFC after: 2 weeks
configuration descriptor reads early on to avoid issues with devices
that don't check for a valid USB configuration read request.
Submitted by: takahiro.kurosawa@gmail.com
PR: 238412
MFC after: 3 days
port number, properly access them by their IPv6 names.
This will make it easier to slice up and compile out address families
in the future.
No functional change intended.
MFC after: 6 weeks
To facilitate experimentation with LTO we require an ar that supports
LLVM IR, and to a lesser degree also an nm. As a first step always
install llvm-ar and llvm-nm.
Sponsored by: The FreeBSD Foundation
As depicted in the comment: jid 0 always exists, but the lookup will fail as
it does not appear in the kernel's alljails list being a special jail. Some
callers will expect/rely on this, and we have no reason to lie because it
does always exist.
Reported by: Stefan Hegnauer <stefan.hegnauer gmx ch>
MFC after: soon (regression, breaks inspecting jail host bits, partial
revert)
ASAN reports become a lot more useful with llvm-symbolizer in $PATH, and the
build is not much more time-consuming. The added benefit is that the
resulting reports will actually include symbol information; without, thread
trace information includes a bunch of addresses that immediately resolve to
an inline function in
^/contrib/compiler-rt/lib/sanitizer_common/sanitizer_common.h and take a
little more effort to examine.
Reviewed by: emaste
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D20484
Ensure the expected result is stored first in a volatile variable with
the desired type. This makes all the tests succeed.
Slightly changed from the original pull request, but functionally the
same.
Obtained from: https://github.com/freebsd/freebsd/pull/401
Submitted by: Moritz Buhl <gh@moritzbuhl.de>
PR: 191676
MFC after: 3 days
lib/atf/libatf-c/tests/Makefile added the -Wno-duplicate-decl-specifier
due to an issue with an old version of ATF. ATF has long since been
updated to a version with the fix so the workaround is no longer
necessary.
Found during review for PR 236889.
PR: 236889
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Currently, if jail_getid(3) is passed in a numeric string, it assumes that
this is a jid string and passes it back converted to an int without checking
that it's a valid/existing jid. This breaks consumers that might use
jail_getid(3) to see if it can trivially grab a jid from a name if that name
happens to be numeric but not actually the name/jid of the jail. Instead of
returning -1 for the jail not existing, it'll return the int version of the
input and the consumer will not fallback to trying other methods.
Pass the numeric input to jail_get(2) as the jid for validation, rather than
the name. This works well- the kernel enforces that jid=name if name is
numeric, so doing the safe thing and checking numeric input as a jid will
still DTRT based on the description of jail_getid.
Reported by: Wes Maag
Reviewed by: jamie, Wes Maag
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D20388
- Triple DES has been formally deprecated in Kerberos (RFC 8429)
and is soon to be deprecated in IPsec (RFC 8221).
- Blowfish is deprecated. FreeBSD doesn't support its successor
(Twofish).
- MD5 is generally considered a weak digest that has known attacks.
geli refuses to create new volumes using these algorithms via 'geli
init'. It also warns when attaching to existing volumes or creating
temporary volumes via 'geli onetime' . The plan is to fully remove
support for these algorithms in FreeBSD 13.
Note that none of these algorithms have ever been the default
algorithm used by geli(8). Users would have had to explicitly select
these algorithms when creating volumes in the past.
Reviewed by: cem, delphij
MFC after: 3 days
Relnotes: yes
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D20344
Use the .PATH mechanism instead so keep installing them from lib/libc/gen
While here revert 347961 and 347893 which are no longer needed
Discussed with: manu
Tested by: manu
ok manu@
The .init and .fini epilogues from crtn should be placed immediately
after any instructions in .init and .fini sections from the linked
objects. Using 16-byte alignment for the epilogues on MIPS was a bug,
but it did not cause any issue with GNU ld as GNU ld (2.17.50) fills the
padding with NOPs.
Current versions of LLD fill any padding between different object files
with trap instructions. Inserting trap padding prior to the .init/.fini
epilogue is undesriable as the resulting binary will crash at runtime.
The .init and .fini sections in object files linked between crti and
crtn must already be a multiple of the instruction size and so no
alignment directive is required in crtn. Indeed, other architectures
(except sparc64) do not specify alignment in their crtn implementations.
Reported by: arichardson
Reviewed by: andrew
Event: Waterloo Hackathon 2019
Differential Revision: https://reviews.freebsd.org/D18291
Sync libarchive with vendor.
Relevant vendor changes:
Issue #795: XAR - do not try to add xattrs without an allocated name
PR #812: non-recursive option for extract and list
PR #958: support reading metadata from compressed files
PR #999: add --exclude-vcs option to bsdtar
Issue #1062: treat empty archives with a GNU volume header as valid
PR #1074: Handle ZIP files with trailing 0s in the extra fields
(Android APK archives)
PR #1109: Ignore padding in Zip extra field data (Android APK archives)
PR #1167: fix problems related to unreadable directories
Issue #1168: fix handling of strtol() and strtoul()
PR #1172: RAR5 - fix invalid window buffer read in E8E9 filter
PR #1174: ZIP reader - fix of MSZIP signature parsing
PR #1175: gzip filter - fix reading files larger than 4GB from memory
PR #1177: gzip filter - fix memory leak with repeated header reads
PR #1180: ZIP reader - add support for Info-ZIP Unicode Path Extra Field
PR #1181: RAR5 - fix merge_block() recursion
(OSS-Fuzz 12999, 13029, 13144, 13478, 13490)
PR #1183: fix memory leak when decompressing ZIP files with LZMA
PR #1184: fix RAR5 OSS-Fuzz issues 12466, 14490, 14491, 12817
OSS-Fuzz 12466: RAR5 - fix buffer overflow when parsing huffman tables
OSS-Fuzz 14490, 14491: RAR5 - fix bad shift-left operations
OSS-Fuzz 12817: RAR5 - handle a case with truncated huffman tables
PR #1186: RAR5 - fix invalid type used for dictionary size mask
(OSS-Fuzz 14537)
PR #1187: RAR5 - fix integer overflow (OSS-Fuzz 14555)
PR #1190: RAR5 - RAR5 don't try to unpack entries marked as directories
(OSS-Fuzz 14574)
PR #1196: RAR5 - fix a potential SIGSEGV on 32-bit builds
OSS-Fuzz 2582: RAR - fix use after free if there is an invalid entry
OSS-Fuzz 14331: RAR5 - fix maximum owner name length
OSS-Fuzz 13965: RAR5 - use unsigned int for volume number + range check
Additional RAR5 reader changes:
- support symlinks, hardlinks, file owner, file group, versioned files
- change ARCHIVE_FORMAT_RAR_V5 to 0x100000
- set correct mode for readonly directories
- support readonly, hidden and system Windows file attributes
MFC after: 2 weeks
During boot we only want to measure things which *must*
be verified - this should provide more deterministic ordering.
Reviewed by: stevek
MFC after: 1 week
Sponsored by: Juniper Networks
Differential Revision: https://reviews.freebsd.org/D20297
does not ship a -lomp symlink. Also update OptionalObsoleteFiles for
this, and add 32-bit variants while here.
Submitted by: jbeich
PR: 237975
MFC after: 3 days
In all practical situations, the resolver visibility is static.
Requested by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Approved by: so (emaste)
Differential revision: https://reviews.freebsd.org/D20281
These datasets will generally be canmount=noauto,mountpoint=none (e.g.
zroot/var) but have children that may need to be mounted. Instead of
skipping that segment for no good reason, descend.
Submitted by: Wes Maag
Reported by: Wes Maag
MFC after: 3 days
libc was picked as the destination location for these because of the syscalls
that use these files as the lowest level place they are referenced.
Approved by: will (mentor), rgrimes, manu
Differential Revision: https://reviews.freebsd.org/D16728
- Add some coverage for cap_sysctl(3).
- Add a test for the case where the caller wishes to find the sysctl
output length without specifying an output buffer.
Reviewed by: oshogbo
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D17856
These complement cap_sysctlbyname(3) to provide a drop-in
replacement for the corresponding libc functions.
Also revise the libcap_sysctl limit interface to provide access
to sysctls by MIB, and to avoid direct manipulation of nvlists
by the caller.
Reviewed by: oshogbo
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D17854
Historically we have not distinguished between kernel wirings and user
wirings for accounting purposes. User wirings (via mlock(2)) were
subject to a global limit on the number of wired pages, so if large
swaths of physical memory were wired by the kernel, as happens with
the ZFS ARC among other things, the limit could be exceeded, causing
user wirings to fail.
The change adds a new counter, v_user_wire_count, which counts the
number of virtual pages wired by user processes via mlock(2) and
mlockall(2). Only user-wired pages are subject to the system-wide
limit which helps provide some safety against deadlocks. In
particular, while sources of kernel wirings typically support some
backpressure mechanism, there is no way to reclaim user-wired pages
shorting of killing the wiring process. The limit is exported as
vm.max_user_wired, renamed from vm.max_wired, and changed from u_int
to u_long.
The choice to count virtual user-wired pages rather than physical
pages was done for simplicity. There are mechanisms that can cause
user-wired mappings to be destroyed while maintaining a wiring of
the backing physical page; these make it difficult to accurately
track user wirings at the physical page layer.
The change also closes some holes which allowed user wirings to succeed
even when they would cause the system limit to be exceeded. For
instance, mmap() may now fail with ENOMEM in a process that has called
mlockall(MCL_FUTURE) if the new mapping would cause the user wiring
limit to be exceeded.
Note that bhyve -S is subject to the user wiring limit, which defaults
to 1/3 of physical RAM. Users that wish to exceed the limit must tune
vm.max_user_wired.
Reviewed by: kib, ngie (mlock() test changes)
Tested by: pho (earlier version)
MFC after: 45 days
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D19908
The rewrite of strcmp in assembly uses an instruction added in PowerISA
2.05, making it SIGILL on CPUs older than the POWER6, such as the PPC970 in
the PowerMac G5. Revert this until we get clang+lld, or retire the in-tree
binutils in favor of newer binutils with IFUNC support, whichever comes
first.
Otherwise concurrently running threads may inadvertently use the same
token for different messages.
Preserve the behaviour of disallowing negative message tokens, but allow
a message token value of zero since this simplifies the code a bit and
tokens are documented to be non-negative.
PR: 234442
Reported and tested by: eugen
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
This is a prerequisite of unifying kernel zlib instances.
Submitted by: Yoshihiro Ota <ota at j.email.ne.jp>
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D20191
