We accidentally had two ioctls use the same base number
(DIOCKEEPCOUNTERS and DIOCGIFSPEEDV{0,1}). We get away with that on most
platforms because the size of the argument structures is different.
This does break CHERI, and is generally a bad idea anyway.
Renumber to avoid this collision.
Reported by: jhb
Add ofwbus, iicbus and spibus to pnpautoload so modules under those
buses will be loaded.
On my rockpro64 now :
OK pnpautoload -v
Autoloading modules for simplebus
Using DTB provided by EFI at 0x8100000.
Autoloading modules for ofwbus
/boot/kernel/rk_spi.ko text=0x14b2 text=0xd4c data=0x4d0+0x8 syms=[0x8+0xa98+0x8+0x807]
/boot/kernel/dwwdt.ko text=0x12e2 text=0x78c data=0x4c8+0x10 syms=[0x8+0x990+0x8+0x6e1]
Autoloading modules for iicbus
Autoloading modules for spibus
/boot/kernel/mx25l.ko text=0x1613 text=0x114c data=0x6e8+0x8 syms=[0x8+0xa08+0x8+0x665]
loading required module 'fdt_slicer'
/boot/kernel/fdt_slicer.ko text=0x95e text=0x340 data=0x290 syms=[0x8+0x6c0+0x8+0x4a0]
This adds a new ng_device command, NGM_DEVICE_ETHERALIGN, which has no
associated args. After the command arrives, the device begins adjusting all
packets sent out its hook to have ETHER_ALIGN bytes of padding at the
beginning of the packet. The ETHER_ALIGN padding is added only when
running on an architecture that requires strict alignment of IP headers
(based on the __NO_STRICT_ALIGNMENT macro, which is only #define'd on
x86 as of this writing).
This also adds ascii <-> binary command translation to ng_device, both for
the existing NGM_DEVICE_GET_DEVNAME and the new ETHERALIGN command.
This also gives a name to every ng_device node when it is constructed, using
the cdev device name (ngd0, ngd1, etc). This makes it easier to address
command msgs to the device using ngctl(8).
Reviewed by: donner, ray, adrian
Differential Revision: https://reviews.freebsd.org/D32905
MFC after: 1 week
This make the base driver cleaner and the subclassed driver only have
related code.
Kernel config wise this is still only handled by rk805.
No functional changes intended.
Even if for now all the RTC-related register are at the same offset don't
use some hardcoded values for them but set them based on the PMIC type.
No functional changes intended.
Since the upstream merge we end up with the compiler generating calls to
memcpy (and it appears upstream LLVM does too, so this will probably
also be a problem upstream when the LLVM 13 import is finished). Like
the kernel we should just compile this file with -ffreestanding to avoid
such surprises.
Note that elf_trampoline.c does actually provide a memcpy, but it's
static. That's a bit weird, and means by the time the memcpy calls are
generated by the compiler the explicit ones have already been inlined
and the function itself GC'ed, but since using -ffreestanding is the
right thing to do for this kind of code anyway, that doesn't actually
matter.
Obtained from: https://github.com/CTSRD-CHERI/cheribsd/commit/219ddb6293c
Merge commit e27a6db5298f from llvm git (by Jameson Nash):
Bad SLPVectorization shufflevector replacement, resulting in write to wrong memory location
We see that it might otherwise do:
%10 = getelementptr {}**, <2 x {}***> %9, <2 x i32> <i32 10, i32 4>
%11 = bitcast <2 x {}***> %10 to <2 x i64*>
...
%27 = extractelement <2 x i64*> %11, i32 0
%28 = bitcast i64* %27 to <2 x i64>*
store <2 x i64> %22, <2 x i64>* %28, align 4, !tbaa !2
Which is an out-of-bounds store (the extractelement got offset 10
instead of offset 4 as intended). With the fix, we correctly generate
extractelement for i32 1 and generate correct code.
Differential Revision: https://reviews.llvm.org/D106613
Merge commit 029f1a534489 from llvm git (by Arthur Eubanks):
[LazyCallGraph] Skip blockaddresses
blockaddresses do not participate in the call graph since the only
instructions that use them must all return to someplace within the
current function. And passes cannot retrieve a function address from a
blockaddress.
This was suggested by efriedma in D58260.
Fixes PR50881.
Reviewed By: nickdesaulniers
Differential Revision: https://reviews.llvm.org/D112178
Merge commit f5755c0849a5 from llvm git (by Jessica Clarke):
[Mips] Add glue between CopyFromReg, CopyToReg and RDHWR nodes for TLS
The MIPS ABI requires the thread pointer be accessed via rdhwr $3, $r29.
This is currently represented by (CopyToReg $3, (RDHWR $29)) followed by
a (CopyFromReg $3). However, there is no glue between these, meaning
scheduling can break those apart. In particular, PR51691 is a report
where PseudoSELECT_I was moved to between the CopyToReg and CopyFromReg,
and since its expansion uses branches, it split the def and use of the
physical register between two basic blocks, resulting in the def being
eliminated and the use having no def. It also seems possible that a
similar situation could arise splitting up the CopyToReg from the RDHWR,
causing the RDHWR to use a destination register other than $3, violating
the ABI requirement.
Thus, add glue between all three nodes to ensure they aren't split up
during instruction selection. No regression test is added since any test
would be implictly relying on specific scheduling behaviour, so whilst
it might be testing that glue is preventing reordering today, changes to
scheduling behaviour could result in the test no longer being able to
catch a regression here, as the reordering might no longer happen for
other unrelated reasons.
Fixes PR51691.
Reviewed By: atanasyan, dim
Differential Revision: https://reviews.llvm.org/D111967
Merge commit c9539f957f57 from llvm git (by Nemanja Ivanovic):
[PowerPC] Define XL-compatible macros only for AIX and Linux
Since XLC only ever shipped on PowerPC AIX and Linux, it is not
reasonable to provide the compatibility macros on any target other
than those two. This patch restricts those macros to AIX/Linux.
Differential revision: https://reviews.llvm.org/D110213
PR: 258209
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-13-init-16847-g88e66fa60ae5, the last commit before
the upstream release/13.x branch was created.
PR: 258209
MFC after: 2 weeks
Instead of only hiding cpu_set_t compat typedef itself.
Too many software packages assume that sched_getaffinity() presence
implies full source compatibility with glibc. We can (and should)
handle missing CPU_* macros, but then there are incompatible BIT_* uses
which cannot be fixed in src/.
So hide everything under _WITH_CPU_SET_T, in particular, do not expose
sched_getcpu(), sched_get/setaffinity(), as well as CPU_* and BIT_*
macros. Consumers that want sched* functions must opt-in.
Reported by: portmgr (antoine)
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
The code was probably useful during the problem being chased down,
but for brevity makes sense just to return to the original KASSERT.
Reviewed by: rrs
Differential revision: https://reviews.freebsd.org/D32968
All timers keep inpcb locked through their execution. We need to
check these flags only once. Checking for INP_TIMEWAIT earlier is
is also safer, since such inpcbs point into tcptw rather than tcpcb,
and any dereferences of inp_ppcb as tcpcb are erroneous.
Reviewed by: rrs, hselasky
Differential revision: https://reviews.freebsd.org/D32967
Currently, if the linux service is run twice, mount(8) fails with:
mount: linprocfs: Device busy
mount: linsysfs: Device busy
mount: devfs: Device busy
mount: fdescfs: Device busy
mount: tmpfs: Device busy
It is a bit more user-friendly if before running mount(8) the service
checks if there are any file systems left to be mounted. This patch
implements this behavior.
Also, while here, create mount points directories (as suggested by
otis).
Reviewed by: trasz
Approved by: trasz (src)
Differential Revision: https://reviews.freebsd.org/D32463
Drop some unnecessary includes from Linuxulator ptrace
and coredump code. No functional changes.
Sponsored By: EPSRC
Differential Revision: https://reviews.freebsd.org/D32925
On-board devices should be configured via the FDT and overlays.
Hints are primarily useful for external and temporarily attached devices.
Adding hints is much easier and faster than writing and compiling
an overlay.
MFC after: 2 weeks
On-board devices should be configured via the FDT and overlays.
Hints are primarily useful for external and temporarily attached devices.
Adding hints is much easier and faster than writing and compiling
an overlay.
MFC after: 2 weeks
For pNFS, Layouts are issued by the server to indicate
where a file's data resides on the DS(s). This patch
adds counters for how many layouts are allocated to
the nfsstatsv1 structure, using two reserved fields.
MFC after: 2 weeks
We do not require devvp vnode locked for metadata io. It is typically
not needed indeed, since correctness of the file system using
corresponding block device ensures that there is no incorrect or racy
manipulations.
But right now DEBUG_VFS_LOCKS option excludes both character device
vnodes and completely destroyed (VBAD) vnodes from asserts. This is not
too bad since WITNESS still ensures that we do not leak locks. On the
other hand, asserts do not mean what they should, to the reader, and
reliance on them being enforced might result in wrong code.
Note that ASSERT_VOP_LOCKED() still silently accepts NULLVP, I think it
is worth fixing as well, in the next round.
In collaboration with: pho
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D32761
For devfs vnodes, it is fine to not lock vnodes for VOP_FSYNC().
Otherwise vnode must be locked exclusively, except for MNT_SHARED_WRITES()
where the shared lock is enough.
Reported and tested by: pho
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D32761
It is not, and the lock is not needed there
Reported and tested by: pho
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D32761
Require devvp locked for mntfs_freevp(), to have it locked around
vgone(). Make that true for ffs, which is the only consumer of
the interface.
Reported and tested by: pho
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D32761
