that are needed by the new dtrace. these don't do anything yet,
but dtrace doesn't mind. I'll do a full resync to the latest FreeBSD
libproc / librtld_db later.
New tests:
- ucontext_sp
- ucontext_fp
- ucontext_pc
- ucontext_intrv
They test respectively:
- _UC_MACHINE_SP
- _UC_MACHINE_FP
- _UC_MACHINE_PC
- _UC_MACHINE_INTRV
These tests attempt to access and print the values from ucontext, without
interpreting the values.
This is a follow up of the _UC_MACHINE_FP() introduction.
These tests use PRIxREGISTER, and require to be built with -D_KERNTYPES.
Sponsored by <The NetBSD Foundation>
during page faults (T_PAGEFLT), so here we're reading a value that comes
from a previous page fault.
That's a real problem; if you launch an unprivileged process, set up a
signal handler, make it sleep 10 seconds, and trigger a T_ALIGNFLT fault,
you get in si_addr the address of another LWP's page - and perhaps this
can be used to defeat userland ASLR.
This bug has been there since 2003.
is changed also in the non-SVS case.
I've put a documentation in amd64_trap.S. Basically, the problem with SVS
is that if iret faults, we already have a full trapframe pushed on the
stack and the CPU will push another frame on this stack (nested), but it
hits the redzone below the stack since it is still running with the user
page table loaded.
To fix that, we pop a good part of the trapframe earlier in intrfastexit.
If iret faults, the current %rsp has enough room for an iret frame, and
the CPU can push that without problem. We then switch back to the outer
iret frame (the frame the CPU was trying to pop by executing iret, but that
it didn't pop for real because iret faulted), call INTRENTRY, and handle
the trap as if it had been received from userland directly.
puts the code in the .text section, so the effect of TEXT_USER_BEGIN was
overwritten, and check_swapgs was not put in the .text.user section.
As a result kernels running SVS would crash when jumping here - because we
execute this place with the user page table loaded, and in this page table
only .text.user is mapped.
While here, rename check_swapgs -> kernuser_reenter, because we do more
things than just SWAPGS.
This does not exist in HEAD.
It looks like accidentally committed in:
Add new modules (for i386 and amd64 only) for the imcsmb SMBus driver.
src/sys/modules/Makefile r1.200
SMBus controllers which are part of the integrated memory controllers
on certain modern Intel CPUs. These SMBus are attached only to the
memory DIMMs, so we provide only a minimum amount of functionality.
Deliberately not included in GENERIC, as on some motherboards there
can be conflicting access between the driver and the motherboard. The
motherboards generally will provide a mechanism to synchronize access,
but the methods are likely proprietary; the driver provides a place
for inserting user-provided synchronization.
* In setusergs. Here we can't fault. So we don't need to handle this
case.
* In intrfastexit for 32bit processes. This case needs to be handled,
and we already have a label.
So use the label instead of disassembling %rip.
Enable awacs(4), skipping MAMBO config as it is for an emulator.
From <macallan>
"that warning about the awacs driver making some
machines lock up can probably go. It's ancient and I've never seen it
actually happen, I have several oldish macs with different awacs
variants and it's enabled in all my configs. In fact it predates my
macppc interrupt cleanup ( I think I did that in 2005 or so ) and I
strongly suspect that fixed the problem.
( the ancient code didn't properly distinguish between edge and level
triggered interrupts on grand central / heathrow type hardware, IIRC it
always just checked the level register(s) which resulted in edge
triggered interrupts being missed or misdetected. Most of the mac-io
goop from that time uses edge triggered interrupts, which includes
awacs )
If this actually happens to anyone I'd like to know about it"
SVS. In SVS we use %rax instead of %r15 because the following instructions
cannot be encoded:
movq %r15,SVS_UTLS+UTLS_SCRATCH
movq SVS_UTLS+UTLS_RSP0,%r15
When we see dp->dad_ifa == NULL, it means that the ifa is being deleted and also
the callout is scheduled again by someone. We shouldn't rely on a result of
callout_pending to know if the callout is scheduled because it returns false if
the subsequent callout handler is already on the fly.
We have to always delegate the destruction of dp to the subsequent handler
unconditionally if dp->dad_ifa == NULL. Otherwise, the first handler destroys
the dp and the second handler tries to handle destroyed dp.
A deadlock occurs because there is a violation of the rule of lock ordering;
softnet_lock is held with hodling IFNET_LOCK, which violates the rule.
To avoid the deadlock, replace softnet_lock in in_control and in6_control
with KERNEL_LOCK.
We also need to add some KERNEL_LOCKs to protect the network stack surely.
This is required, for example, for PR kern/51356.
Fix PR kern/53043
chs