vm_page_t's.
- Add a KTR_TRAP tracepoint to trap() on the alpha that displays the
contents of a0, a1, and a2 to make debugging of nested traps that
panic before displaying any useful output easier.
may need the clock lock for nanotime().
- Add KTR trace events for lock list manipulations and other witness
operations.
- Use a temporary variable instead of setting the lock list head directly
and then setting up the links to add a new lock list entry to the lock
list. This small race could result in witness "forgetting" about all
the locks held by this process temporarily during an interrupt.
- Close a more fatal race condition when removing a lock from a list.
Removing a lock from the list entails both decrementing the count of
items in this bucket as well as shuffling items in the current bucket up
a notch to replace the gap left by the removed item. Wrap these
operations in a critical section.
class to trace witness events.
- Make the ktr_cpu field of ktr_entry be a standard field rather than one
present only in the KTR_EXTEND case.
- Move the default definition of KTR_ENTRIES from sys/ktr.h to
kern/kern_ktr.c. It has not been needed in the header file since KTR
was un-inlined.
- Minor include cleanup in kern/kern_ktr.c.
- Fiddle with the ktr_cpumask in ktr_tracepoint() to disable KTR events
on the current CPU while we are processing an event.
- Set the current CPU inside of the critical section to ensure we don't
migrate CPU's after the critical section but before we set the CPU.
switch. Count the context switch when preempting the current thread to let
a higher priority thread blocked on a mutex we just released run as an
involuntary context switch.
Reported by: bde
signal. Fix it by adding an explicit call to summary() in terminate()
(it was previously called implicitly by exit() because summary() was
registered with atexit()). summary() is supposed to be signal-safe--
it handles SIGINFO almost exclusively--so this should be safe.
Submitted by: bde
rejecting INTR_FAST interrupts. Since they can't be shared anyway,
this just short circuits a failure case that should work but is panic
fodder now.
This bug is that if the interrut condiation is active when you activate
the interrupt, then the interrupt routine will be called. jhb had
a patch that may or may not work to fix it, but I've lost it.
This may be due to the sio probe doing something odd too.
one to see what files would be removed *if* an 'lpc clean' is done. 'tclean'
will remove no files, and is therefore not a privileged command. Also, both
'lpc clean' and 'lpc tclean' will now look for 'core' files in spool directories
(but not remove them). They also print out an extra line of info when a
datafile to be removed is a symlink (from 'lpr -s'), saying what file it is
a symlink to.
The 'lpc clean' commands also now print out a summary line saying how many
queues were checked, how many files were removed (or "would be" removed, for
tclean), and how much disk space is involved. For the benefit of those who
have many print queues, 'lpc clean all' will only print out the names of print
queues where some "interesting" files were found, instead of printing out a
header-line for every queue in your printcap file.
Reviewed by: freebsd-print@bostonradio.orgfreebsd-audit@FreeBSD.org
MFC after: 2 weeks
while -w allows connection from non-reserved ports. Also improves the
helpfulness of various connection-error messages.
The changes for IPv6 added back in the reserved-port check which was mistakenly
dropped from lpd in 1997 (copying a change from openbsd). It is best to have
that check in place, but the check breaks lpr's from some implementations of
lpr/lpd for Windows. The -w option is for those admins who need to accept
jobs from non-reserved ports, the -c option is for admins who would like a
print-server machine to log all failed connection-attempts to syslog.
Reviewed by: freebsd-audit@FreeBSD.orgfreebsd-print@bostonradio.org
MFC after: 2 weeks
NO_SENDMAIL flag if set. The whole NO_FOO mechanism in /usr/src
is pretty bogus and needs to be re-examined in the context of a
larger argument about modularity, but that's something for another
time.
Submitted by: Peter Pentchev <roam@orbitel.bg>
