Linux mmap rejects mmap() on a write-only file with EACCES.
linux_mmap_common currently does a fun dance to grab the fp associated with
the passed in fd, validates it, then drops the reference and calls into
kern_mmap(). Doing so is perhaps both fragile and premature; there's still
plenty of chance for the request to get rejected with a more appropriate
error, and it's prone to a race where the file we ultimately mmap has
changed after it drops its referenced.
This change alleviates the need to do this by providing a kern_mmap variant
that allows the caller to inspect the fp just before calling into the fileop
layer. The callback takes flags, prot, and maxprot as one could imagine
scenarios where any of these, in conjunction with the file itself, may
influence a caller's decision.
The file type check in the linux compat layer has been removed; EINVAL is
seemingly not an appropriate response to the file not being a vnode or
device. The fileop layer will reject the operation with ENODEV if it's not
supported, which more closely matches the common linux description of
mmap(2) return values.
If we discover that we're allowing an mmap() on a file type that Linux
normally wouldn't, we should restrict those explicitly.
Reviewed by: kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D22977
The LSB 4.1 that I referenced omitted the varargs, and I failed to catch it.
The __vsnprintf_chk error was from just downright misreading the page. GCC6
caught all of these, but I had only tested GCC4.2.
X-MFC-With: r356356
For libssp.so, rebuild stack_protector.c with FORTIFY_SOURCE stubs that just
abort built into it.
For libssp_nonshared.a, steal stack_protector_compat.c from
^/lib/libc/secure and massage it to maintain that __stack_chk_fail_local
is a hidden symbol.
libssp is now built unconditionally regardless of {WITH,WITHOUT}_SSP in the
build environment, and the gcclibs version has been disconnected from the
build in favor of this one.
PR: 242950 (exp-run)
Reviewed by: kib, emaste, pfg, Oliver Pinter (earlier version)
Also discussed with: kan
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D22943
A future commit will rebuild this as part of libssp. The exact warnings are
fairly trivially fixed:
- No previous declaration for __stack_chk_guard
- idx is the wrong type, nitems yields a size_t
- Casting away volatile on the tmp_stack_chk_guard directly is a no-no.
Reviewed by: kib, emaste, pfg, Oliver Pinter (earlier version)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D22943
mapping to the old read-only page with a mapping to the new read-write page.
To destroy the old mapping, pmap_enter() must destroy its page table and PV
entries and invalidate its TLB entry. This change simply invalidates that
TLB entry a little earlier, specifically, on amd64 and arm64, before the PV
list lock is held.
Reviewed by: kib, markj
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D23027
UMA_MD_SMALL_ALLOC vmem has a more complicated startup sequence that
violated the new assert. Resolve this by rewriting the COLD asserts to
look at the per-cpu allocation counts for evidence of api activity.
Discussed with: rlibby
Reviewed by: markj
Reported by: lwhsu
more consistent with other NUMA features as UMA_ZONE_FIRSTTOUCH and
UMA_ZONE_ROUNDROBIN. The system will now pick a select a default depending
on kernel configuration. API users need only specify one if they want to
override the default.
Remove the UMA_XDOMAIN and UMA_FIRSTTOUCH kernel options and key only off
of NUMA. XDOMAIN is now fast enough in all cases to enable whenever NUMA
is.
Reviewed by: markj
Discussed with: rlibby
Differential Revision: https://reviews.freebsd.org/D22831
onto their respective bucket lists. This is a several order of magnitude
improvement in contention on the keg lock under heavy free traffic while
requiring only an additional bucket per-domain worth of memory.
Discussed with: markj, rlibby
Differential Revision: https://reviews.freebsd.org/D22830
accounting for each NUMA domain. Independent keg domain locks are important
with cross-domain frees. Hashed zones are non-numa and use a single keg
lock to protect the hash table.
Reviewed by: markj, rlibby
Differential Revision: https://reviews.freebsd.org/D22829
between populating buckets from the slab layer and fetching full buckets
from the zone layer. Eliminate some nonsense locking patterns where
we lock to fetch a single variable.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D22828
sleepq to serialize sleepers. This patch retains the existing sleep/wakeup
paradigm to limit 'thundering herd' wakeups. It resolves a missing wakeup
in one case but otherwise should be bug for bug compatible. In particular,
there are still various races surrounding adjusting the limit via sysctl
that are now documented.
Discussed with: markj
Reviewed by: rlibby
Differential Revision: https://reviews.freebsd.org/D22827
Use "mipsel" instead of "mips" as the 32-bit MACHINE_ARCH when
building lib32 for little-endian 64-bit MIPS targets. This fixes an
error where some objects were compiled as LE and others compiled as BE
causing a link error for rtld32.
Reviewed by: emaste
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D23028
Filesystems which want to use it in limited capacity can employ the
VOP_UNLOCK_FLAGS macro.
Reviewed by: kib (previous version)
Differential Revision: https://reviews.freebsd.org/D21427
For the most part the code was passing the LK_RELEASE flag.
The 2 cases which did not use the VOP_UNLOCK_FLAGS macro.
This fixes a panic when stacking unionfs on top of e.g., tmpfs when
debug is enabled.
Note there are latent bugs which prevent unionfs from working with debug
regardless of this change.
PR: 243064
Reported by: Mason Loring Bliss
The flags argument from VOP_UNLOCK is about to be removed and some
filesystems unlock the interlock as a convienience with it.
Add a helper to retain the behavior for the few cases it is needed.
[lld][RISCV] Use an e_flags of 0 if there are only binary input files.
Summary:
If none of the input files are ELF object files (for example, when
generating an object file from a single binary input file via "-b
binary"), use a fallback value for the ELF header flags instead of
crashing with an assertion failure.
Reviewers: MaskRay, ruiu, espindola
Reviewed By: MaskRay, ruiu
Subscribers: kevans, grimar, emaste, arichardson, asb, rbar,
johnrusso, simoncook, sabuasal, niosHD, kito-cheng, shiva0217,
zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o,
rkruppe, PkmX, jocewei, psnobl, benna, Jim, lenary, s.egerton,
pzheng, sameer.abuasal, apazos, luismarques, llvm-commits, jrtc27
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71101
This is a prerequisite for building and linking hard- and soft-float
riscv worlds with clang and lld.
Requested by: jhb
MFC after: 1 week
X-MFC-With: r353358
[RISCV] Handle fcopysign(f32, f64) and fcopysign(f64, f32)
Summary: Adds tablegen patterns to explicitly handle fcopysign where
the magnitude and sign arguments have different types, due to the
sign value casts being removed the by DAGCombiner. Support for RV32IF
follows in a separate commit. Adds tests for all relevant scenarios
except RV32IF.
Reviewers: lenary
Reviewed By: lenary
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70678
This is a prerequisite for building and linking hard- and soft-float
riscv worlds with clang and lld.
Requested by: jhb
MFC after: 1 week
X-MFC-With: r353358
[RISCV] Fix wrong CFI directives
Summary: Removes CFI CFA directives that could incorrectly propagate
beyond the basic block they were inteded for. Specifically it removes
the epilogue CFI directives. See the branch_and_tail_call test for an
example of the issue. Should fix the stack unwinding issues caused by
the incorrect directives.
Reviewers: asb, lenary, shiva0217
Reviewed By: lenary
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D69723
This is a prerequisite for building and linking hard- and soft-float
riscv worlds with clang and lld.
Requested by: jhb
MFC after: 1 week
X-MFC-With: r353358
[RISCV] Don't force Local Exec TLS for non-PIC
Summary:
Forcing Local Exec TLS requires the use of copy relocations. Copy
relocations need special handling in the runtime linker when being
used against TLS symbols, which is present in glibc, but not in
FreeBSD nor musl, and so cannot be relied upon. Moreover, copy
relocations are a hack that embed the size of an object in the ABI
when it otherwise wouldn't be, and break protected symbols (which are
expected to be DSO local), whilst also wasting space, thus they
should be avoided whenever possible. As discussed in D70398, RISC-V
should move away from forcing Local Exec, and instead use Initial
Exec like other targets, with possible linker relaxation to follow.
The RISC-V GCC maintainers also intend to adopt this
more-conventional behaviour (see
https://github.com/riscv/riscv-elf-psabi-doc/issues/122).
Reviewers: asb, MaskRay
Reviewed By: MaskRay
Subscribers: emaste, krytarowski, hiraditya, rbar, johnrusso,
simoncook, sabuasal, niosHD, kito-cheng, shiva0217, zzheng,
edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe,
PkmX, jocewei, psnobl, benna, Jim, lenary, s.egerton, pzheng,
sameer.abuasal, apazos, llvm-commits, bsdjhb
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70649
This is a prerequisite for building and linking hard- and soft-float
riscv worlds with clang and lld.
Requested by: jhb
MFC after: 1 week
X-MFC-With: r353358
[RISCV] Fix evaluation of %pcrel_lo
The following testcase
function:
.Lpcrel_label1:
auipc a0, %pcrel_hi(other_function)
addi a1, a0, %pcrel_lo(.Lpcrel_label1)
.p2align 2 # Causes a new fragment to be emitted
.type other_function,@function
other_function:
ret
exposes an odd behaviour in which only the %pcrel_hi relocation is
evaluated but not the %pcrel_lo.
$ llvm-mc -triple riscv64 -filetype obj t.s | llvm-objdump -d -r -
<stdin>: file format ELF64-riscv
Disassembly of section .text:
0000000000000000 function:
0: 17 05 00 00 auipc a0, 0
4: 93 05 05 00 mv a1, a0
0000000000000004: R_RISCV_PCREL_LO12_I other_function+4
0000000000000008 other_function:
8: 67 80 00 00 ret
The reason seems to be that in RISCVAsmBackend::shouldForceRelocation
we only consider the fragment but in RISCVMCExpr::evaluatePCRelLo we
consider the section. This usually works but there are cases where
the section may still be the same but the fragment may be another
one. In that case we end forcing a %pcrel_lo relocation without any
%pcrel_hi.
This patch makes RISCVAsmBackend::shouldForceRelocation use the
section, if any, to determine if the relocation must be forced or
not.
Differential Revision: https://reviews.llvm.org/D60657
This is a prerequisite for building and linking hard- and soft-float
riscv worlds with clang and lld.
Requested by: jhb
MFC after: 1 week
X-MFC-With: r353358
GCC issues the warning, but with LLVM it is fatal- no matching .cprestore
with .cpload. Reserve some place on the stack and and add the proper
.cprestore to pair it with.
nop added in the !o32 branch to fill out delay slot instruction, just in
case.
Reviewed by: arichardson
Differential Revision: https://reviews.freebsd.org/D21697
r356147 removed a vm_page_activate() call, but this is required to
ensure that pages end up in the page queues in the first place.
Restore the pre-r356157 logic. Now, without the page lock, the
vm_page_active() check is racy, but this race is harmless.
Reviewed by: alc, kib
Reported and tested by: pho
Differential Revision: https://reviews.freebsd.org/D23024
More MACHINE_CPUARCH/MACHINE_ARCH cases enable these options than
disable them, and several of them have work in progress to switch over.
Thus, invert the sense of the test and list cases not using LLD as the
exceptions.
There were a few special cases for arm v5, such as disabling LLDB due to
the lack of 64-bit atomic operations. Now that arm has been retired (as
of r356263) we can simplify the options logic somewhat.
After increasing WARNS, building WITHOUT_TCP_WRAPPERS failed because of
some unused variables.
Reported by: Cirrus-CI (against my WIP branch)
MFC with: r356248
Sponsored by: The FreeBSD Foundation
This is a re-apply r356249 with changes to make GCC happy.
This utility was initially written for FAT12/16, which were inherently
small. When FAT32 support was added, the old data structure and
algorithms remain used with minimal changes.
With growing size of FAT32 media, the current data structure that
requires 4 32-bit variables per each FAT32 table entry would consume up
to 4 GiB of RAM, which can be too big for systems with limited RAM
available.
Address this by taking a different approach of validating the FAT.
The FAT is essentially a set of linked lists of chains that was
referenced by directory entries, and the checker needs to make sure that
the linked chains of clusters do not have cross-linked chains, and every
chain were referenced by one and only one directory entry. Instead of
keeping track of the chain's 'head' cluster number, the size of the
chain, the used status of the chain and the "next" pointer which is
content of the FAT table, we create accessors for the FAT table data
for the "next" pointer, and keep only one bit to indicate if the
current cluster is a 'head' node of a cluster chain, in a bitmap.
We further overhaul the FAT checker to find out the possible head nodes
by excluding ones that are not (in other words, nodes that have some
other nodes claiming them as the next node) instead of marking the head
nodes for each node on the chain. This approach greatly reduced the
complexiety of computation from O(N^2) worst case, to an O(N) scan for
worst case. The file (cluster chain) length is not useful for the FAT
checker, so don't bother to calculate them in the FAT checker and
instead leave the task to the directory structure check, at which point
we would have non-crossed cluster chains, and we are guaranteed that
each cluster will be visited for at most one time.
When checking the directory structures, we use the head node indicator
to as the visited (used) flag: every cluster chain can only be
referenced by one directory entry, so we clear them when calculating
the length of the chain, and we can immediately tell if there are
anomalies in the directory entry.
As a result, the required RAM size is now 1 bit per each entry of
the FAT table, plus memory needed to hold the FAT table in memory,
instead of 16 bytes (=128 bits) per each entry. For FAT12 and FAT16,
we will load the whole FAT table into memory as they are smaller than
128KiB, and for FAT32, we first attempt to mmap() it into memory, and
when that fails, we would fall back to a simple LRU cache of 4 MiB of
RAM.
sbin/fsck_msdosfs/boot.c:
- Added additional sanity checks for valid FAT32/FAT16/FAT12 cluster
number.
- FAT32: check if root directory starts with a valid cluster number,
moved from dir.c. There is no point to proceed if the filesystem
is already damaged beyond repair.
sbin/fsck_msdosfs/check.c:
- Combine phase 1 and phase 2, now that the readfat() is able to
detect cross chains.
sbin/fsck_msdosfs/dir.c:
- Refactor code to use FAT accessor instead of accessing the internal
representation of FAT table.
- Make use of the cluster chain head bitmap.
- Clarify and simplify directory entry check, remove unnecessary
checks that are would be done at a later time (for example, whether
the directory's second cluster is a valid one, which is examined
more throughly in a later checkchain() and does not prevent us
from proceeding further).
sbin/fsck_msdosfs/dosfs.h:
- Remove internal representation of FAT table, which is replaced by
the head bitmap that is opaque to other code.
- Added a special CLUST_DEAD cluster type to indicate errors.
sbin/fsck_msdosfs/ext.h:
- Added a flag that overrides mmap(2) setting. The corresponding
command line option, -M is intentionally undocumented as we do not
expect users to need it.
- Added accessors for FAT table and convert existing interface to use
it.
sbin/fsck_msdosfs/fat.c:
- Added head bitmap to represent whether a cluster is a head cluster.
- Converted FAT internal representation to accessors.
- Implemented a LRU cache for FAT32 when mmap(2) should not or can not
be used.
- _readfat: Attempt a mmap(2) and fall back to regular read for
non-FAT32 file systems; use the LRU cache for FAT32 and prepopulate
the cache with the first 4MiB of the entries.
- readfat: Added support of head bitmap and use the population scan to
detect bogus chains.
- clusterdiff: removed, FATs are copied from the checked copy via
writefat()/copyfat().
- checkchain: calculates the length of a cluster chain and make sure
that it ends with a valid EOF marker.
- clearchain: follow and clear a chain and maintain the free cluster
count.
- checklost: convert to use head bitmap. At the end of all other scans,
the remaining 'head' nodes are leaders of lost cluster chains.
sbin/fsck_msdosfs/fat.c:
- Added a new -M option which is intentionally undocumented, to disable
the use of mmap().
Reviewed by: kevlo
MFC after: 1 month
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D22965
While changing link state in iflib_link_state_change(), queues are
marked as IFLIB_QUEUE_IDLE to disable watchdog. Currently, iflib_timer()
watchdog does not check for previous queue status before marking it as
IFLIB_QUEUE_HUNG.
This patch adds check of queue status before marking it as hung.
Signed-off-by: Piotr Pietruszewski <piotr.pietruszewski@intel.com>
PR: 239240
Submitted by: Piotr Pietruszewski <piotr.pietruszewski@intel.com>
Reported by: ultima@
Reviewed by: gallatin@, erj@
MFC after: 3 days
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D21712
Add a privilege check to the ixl_handle_nvmupd_cmd function, ensuring
that only privileged users are allowed to access the NVM update
interface.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Submitted by: Jacob Keller <jacob.e.keller@intel.com>
Reported by: markj@
Reviewed by: markj@, erj@, jeffrey.e.pieper@intel.com
MFC after: 3 days
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D22870
This is a lock-based emulation of 64-bit atomics for kernel use, split off
from an earlier patch by jhibbits.
This is needed to unblock future improvements that reduce the need for
locking on 64-bit platforms by using atomic updates.
The implementation allows for future integration with userland atomic64,
but as that implies going through sysarch for every use, the current
status quo of userland doing its own locking may be for the best.
Submitted by: jhibbits (original patch), kevans (mips bits)
Reviewed by: jhibbits, jeff, kevans
Differential Revision: https://reviews.freebsd.org/D22976
The goal here is to make it so applications can take the rights one would
normally get by calling caph_limit_stream() on a descriptor and build on
them as needed.
The tentatively planned use-case is an application that takes a socket and
hooks it up to std{err,out,in} for a fork()d child. It may be feasible to
apply limitations to such descriptors as long as it's a superset of those
normally applied to stdio.
Reviewed by: markj, oshobo (prior version; sans manpage addition)
Differential Revision: https://reviews.freebsd.org/D22993
The fdt attachment for this heavily relies on extres for clk work. This
unbreaks the build for mips XLPN32/XLP, which have pci/fdt but no need for
this fdt attachment.
This will soon be a dependency for machine/atomic.h on mips with the
introduction of 64-bit atomics; the scope here is pretty narrow, so throw it
here in the header just before systm.h, which includes machine/atomic.h
When activated in direct exec mode, kernel-provided AT_EXECPATH points
to the interpreter. We need to recalculate auxv to point to the
string with the path to the executable which is actually executed.
The somewhat problematic case is when the executable path is relative
and either $PATH use is not enabled or it contains '/' so $PATH search
is not performed. In this case resulting AT_EXECPATH is relative, I
might fix this later.
Reported and reviewed by: rstone
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D22894
