In r357324 most of the use of gi_irq was moved to gi_lpi. Complete this
with the last few places we need the IRQ value and create gi_id for the
per-device value we need.
MFC after: 2 weeks
Sponsored by: DARPA, AFRL
The code was using a hand-rolled fcmpset loop, while in other places the same
count is manipulated with the refcount API.
This transferred from a stylistic issue into a bug after the API got extended
to support flags. As a result the hand-rolled loop could bump the count high
enough to set the bit flag. Another bump + refcount_release would then free
the file prematurely.
The bug is only present in -CURRENT.
When there are multiple GICv3 ITS devices we don't know which vmem is for
which device. Use device_get_nameunit to get a per-device name.
MFC after: 2 weeks
Sponsored by: DARPA, AFRL
This uses UMA to allocate space. It causes issues when there are multiple
ITS devices in the system where interrupts are not allocated from a low
address on some interrupt controllers. Disabling the quantum cache fixes
this on the Neoverse N1 SDP.
MFC after: 2 weeks
Sponsored by: DARPA, AFRL
CD boot is broken for some systems since bioscd and biosdisk merge. The issue is that we can not use anything else than int 13 ah=0x4b to query cd information.
The patch does restore the same probe as was originally used in bioscd.c. Additionally extra buffer padding is used to avoid memory corruption caused by some systems.
PR: 234031
Reported by: ultramage and others
MFC after: 1 day
fonts. As a workaround, remove the static. vt is default on powerpc, but there's
a few old macs that still fail with vt. sc is used as a work arouond for those
machines, and the kernel fails to build w/o it.
Among the same justification as the other stdio _unlocked; in addition to an
inline version in <stdio.h>, we must provide a function in libc as well for
the functionality. This fixes the lang/gcc* builds, which want to use the
symbol from libc.
PR: 243810
Reported by: antoine, swills, Michael <michael.adm gmail com>
X-MFC-With: r357284
In r355656, endianness handling of the floating point environment was fixed
in the PowerPC code to work as intended.
However, one bit got missed, causing feholdexcept() to mis-save the fenv.
Submitted by: Renato Riolino <renato.riolino@eldorado.org.br>
Differential Revision: https://reviews.freebsd.org/D23382
O_SEARCH is defined by POSIX [0] to open a directory for searching, skipping
permissions checks on the directory itself after the initial open(). This is
close to the semantics we've historically applied for O_EXEC on a directory,
which is UB according to POSIX. Conveniently, O_SEARCH on a file is also
explicitly undefined behavior according to POSIX, so O_EXEC would be a fine
choice. The spec goes on to state that O_SEARCH and O_EXEC need not be
distinct values, but they're not defined to be the same value.
This was pointed out as an incompatibility with other systems that had made
its way into libarchive, which had assumed that O_EXEC was an alias for
O_SEARCH.
This defines compatibility O_SEARCH/FSEARCH (equivalent to O_EXEC and FEXEC
respectively) and expands our UB for O_EXEC on a directory. O_EXEC on a
directory is checked in vn_open_vnode already, so for completeness we add a
NOEXECCHECK when O_SEARCH has been specified on the top-level fd and do not
re-check that when descending in namei.
[0] https://pubs.opengroup.org/onlinepubs/9699919799/
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D23247
If we come from VOP_CACHEDLOOKUP, we must skip the VEXEC check as it will
have been done in the caller (vfs_cache_lookup). This is a part of D23247,
which may skip the earlier VEXEC check as well if the root fd was opened
with O_SEARCH.
This one required slightly more work as zfs_lookup may also be called
indirectly as VOP_LOOKUP or a couple of other places where we must do the
check.
The sparc64 architecture is being removed from FreeBSD 13, starting
now. This removes it from the top level only. It is the only
architecture that didn't see substantial work after the call to get
things working with the external toolchain.
clang inlines fget -> _fget into kern_fstat and eliminates several checkes,
but prior to this change it would assume fget_unlocked was likely to fail
and consequently avoidable jumps got generated.
Use ${SRCTOP} instead of /usr/share.
Prefer to depend on option sc_dflt_fnt instead of sc.
gc the 4 otherwise identical instances in the tree.
Platforms that don't need this won't included it.
Fix the old-style build by using ${SRCTOP} instead of a weird
construct that only works for new-style build.
Simplify the building of keymap files by using macros
Move atkbdmap.h in files.x86
This has been broken since r296899 which removed the implicit
dependency on /usr/share.
Now that armv5 is gone, we no longer need multiple LINT files. Kill
the odd-ball support here. From now on, we just have LINT built from
notes like all the other platforms. Keep the removal of LINT-V5/7
to remove stale files for a while still..
The Parallel Port SCSI adapter was interesting for 100MB ZIP drives, but is no
longer used or maintained. Remove it from the tree.
The Parallel Port microsequencer (microseq.9) is now mostly unused in the tree,
but remains. PPI still refrences it, but doesn't use its full functionality.
Relnotes: Yes
Reviewed by: rgrimes@, Ihor Antonov
Discussed on: arch@
Differential Revision: https://reviews.freebsd.org/D23389
This driver has seen no real changes for almost 20 years. It's for
hardware that's 25 years old. It has no reports of active use, nor
has it been seen in the NYCBug dmesg database at all. Schedule
its removal for 13.0.
Reviewed by: rgrimes@ (earlier version)
Relnote: Yes
MFC After: 3 days
Differential Revision: https://reviews.freebsd.org/D23403
In dmar_gas_uppermatch, skip searching a subtree if all its gaps-between-alloctions are too small.
Reviewed by: kib
Tested by: pho
Differential Revision: https://reviews.freebsd.org/D23391
As Ian Lepore noted, writing ~1 to a register might have a completely
different effect than doing a regular read-modify-write operation.
Follow the TCG_PC_Client_Platform_TPM_Profile_PTP_2.0_r1.03_v22
datasheet instead, and use the actual values mentioned there:
(uint32_t)1 to cancel the command, (uint32_t)0 to clear the field.
MFC after: 3 days
tpmtis_go_ready() read the value of the TPM_STS register, ORed
TPM_STS_CMD_READY with it, and wrote it back. However, the TPM Profile
(PTP) specification states that only one bit in the write request value may
be set to 1, or else the entire write request is ignored.
Fix by just writing TPM_STS_CMD_READY.
Similarly, remove the call which clears the TPM_STS_CMD_READY flag in the
same function. It was being ignored for the same reason.
Submitted by: Darrick Lew <darrick.freebsd AT gmail.com>
Reviewed by: vangyzen, myself
MFC after: if you care about stable, you might want to do so
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D23081
rand(3)'s standard C API is extremely limiting, but we can do better
than the historical 32-bit state Park-Miller LCG we've shipped since
2001: r73156.
The justification provided at the time for not using random(3) was that
rand_r(3) could not be made to use the same algorithm. That is still
true. However, the irrelevance of rand_r(3) is increasingly obvious.
Since that time, POSIX has marked the interface obsolescent. rand_r(3)
never became part of the standard C library. If not for API
compatibility reasons, I would just remove rand_r(3) entirely.
So, I do not believe it is a problem for rand_r(3) and rand(3) to
diverge.
The 12 ABI is maintained with compatibility definitions, but this
revision does subtly change the API of rand(3). The sequences of
pseudorandom numbers produced in programs built against new versions of
libc will differ from programs built against prior versions of libc.
Reviewed by: kevans, markm
MFC after: no
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D23290
