Timezone data changes in this import:
- Add America/St_Barthelemy (BL) and America/Marigot (MF)
- Venezuela will move to -4:30 on 9 December 2007 instead of 31 December 2007
MFCs will be done after the code freezes have stopped.
no per-thread name is available or the name is identical to the
process name, display "-" instead. Very slightly shrink the COMM
entry to make a bit more room, although this doesn't help with
stack traces much.
Suggested by: thompsa
attached. Otherwise, the snp->snp_tty would be overwritten, while the
tty line discipline still set to the snpdisc. Then snplwrite() causes
panic because ttytosnp() cannot find the snp.
MFC after: 1 week
- Print a warning if the version number recorded in the log is not what the
tool expects.
- Print a tidier error message when an unrecognized event is encountered
in the log.
- Don't print a spurious 'Unknown error: 0' when exiting after a parse
error.
The problem was, isc_atomic_cmpxchg() is almost like our
atomic_cmpset_32(), except it expects the old value to be
returned, whereas our atomic_cmpset_32 returns 1 on success,
or 0 on failure. So I re-implemented something suitable.
Submitted by: cognet
Reviewed by: bsdimp
of the missing functionality from procfs(4) and new functionality for
monitoring and debugging specific processes. procstat(1) operates in
the following modes:
-b Display binary information for the process.
-c Display command line arguments for the process.
-f Display file descriptor information for the process.
-k Display the stacks of kernel threads in the process.
-s Display security credential information for the process.
-t Display thread information for the process.
-v Display virtual memory mappings for the process.
Further revision and modes are expected.
Testing, ideas, etc: cognet, sam, Skip Ford <skip at menantico dot com>
Wesley Shields <wxs at atarininja dot org>
support its -k argument:
kern.proc.kstack - dump the kernel stack of a process, if debugging
is permitted.
This sysctl is present if either "options DDB" or "options STACK" is
compiled into the kernel. Having support for tracing the kernel
stacks of processes from user space makes it much easier to debug
(or understand) specific wmesg's while avoiding the need to enter
DDB in order to determine the path by which a process came to be
blocked on a particular wait channel or lock.
- Introduce per-architecture stack_machdep.c to hold stack_save(9).
- Introduce per-architecture machine/stack.h to capture any common
definitions required between db_trace.c and stack_machdep.c.
- Add new kernel option "options STACK"; we will build in stack(9) if it is
defined, or also if "options DDB" is defined to provide compatibility
with existing users of stack(9).
Add new stack_save_td(9) function, which allows the capture of a stacktrace
of another thread rather than the current thread, which the existing
stack_save(9) was limited to. It requires that the thread be neither
swapped out nor running, which is the responsibility of the consumer to
enforce.
Update stack(9) man page.
Build tested: amd64, arm, i386, ia64, powerpc, sparc64, sun4v
Runtime tested: amd64 (rwatson), arm (cognet), i386 (rwatson)
We used to allocate the domains 0-14 for userland, and leave the domain 15
for the kernel. Now supersections requires the use of domain 0, so we
switched the kernel domain to 0, and use 1-15 for userland.
How it's done currently, the kernel domain could be allocated for a
userland process.
So switch back to the previous way we did things, set the first available
domain to 0, and just add 1 to get the real domain number in the struct pmap.
Reported by: Mark Tinguely <tinguely AT casselton DOT net>
MFC After: 3 days
1. A packet comes in that is to be forwarded
2. The destination of the packet is rewritten by some firewall code
3. The next link's MTU is too small
4. The packet has the DF bit set
Then the current code is such that instead of setting the next
link's MTU in the ICMP error, ip_next_mtu() is called and a guess
is sent as to which MTU is supposed to be tried next. This is because
in this case ip_forward() is called with srcrt set to 1. In that
case the ia pointer remains NULL but it is needed to get the MTU
of the interface the packet is to be sent out from.
Thus, we always set ia to the outgoing interface.
MFC after: 2 weeks
The RAS implementation would set the end address, then the start
address. These were used by the kernel to restart a RAS sequence if
it was interrupted. When the thread switching code ran, it would
check these values and adjust the PC and clear them if it did.
However, there's a small flaw in this scheme. Thread T1, sets the end
address and gets preempted. Thread T2 runs and also does a RAS
operation. This resets end to zero. Thread T1 now runs again and
sets start and then begins the RAS sequence, but is preempted before
the RAS sequence executes its last instruction. The kernel code that
would ordinarily restart the RAS sequence doesn't because the PC isn't
between start and 0, so the PC isn't set to the start of the sequence.
So when T1 is resumed again, it is at the wrong location for RAS to
produce the correct results. This causes the wrong results for the
atomic sequence.
The window for the first race is 3 instructions. The window for the
second race is 5-10 instructions depending on the atomic operation.
This makes this failure fairly rare and hard to reproduce.
Mutexs are implemented in libthr using atomic operations. When the
above race would occur, a lock could get stuck locked, causing many
downstream problems, as you might expect.
Also, make sure to reset the start and end address when doing a syscall, or
a malicious process could set them before doing a syscall.
Reviewed by: imp, ups (thanks guys)
Pointy hat to: cognet
MFC After: 3 days
its -f and -v arguments:
kern.proc.filedesc - dump file descriptor information for a process, if
debugging is permitted, including socket addresses, open flags, file
offsets, file paths, etc.
kern.proc.vmmap - dump virtual memory mapping information for a process,
if debugging is permitted, including layout and information on
underlying objects, such as the type of object and path.
These provide a superset of the information historically available
through the now-deprecated procfs(4), and are intended to be exported
in an ABI-robust form.
