We do an MGETHDR)() for each mbuf "packet" of the input chain, to hold
the socket address prepended to that "packet". If those MGETHDR()s
ever failed, we would leak all the successfully-allocated mbuf
headers. Leak noted by Yamamoto-san (yamt@NetBSD.org); thanks for catching it!
Add socketbuf invariant-checking macros to sbappendaddrchain(), and
replace a stray bcopy() with memcpy(), also as suggested by Yamamoto-san.
to ``registered'' sockets -- be treated ``specially'', as suggested
by RFC-2367.
The "special" treatment sys/netipsec now gives such messages is that
we use sbappendaddrchain() to deliver the (single) kernel-generated
message to each registered PF_KEY socket, with an sbprio argument of
SB_PRIO_BESTEFFORT, thus by-passing
For now, we check for registered messages, set a local `sbprio'
argument, and call sbappendaddrchain() (as opposed to sbappendaddr())
if and only if sbprio is non-NULL. As noted, we can rework
key_sendup_mbuf(), and all its callers, to pass the sbprio argument;
pending consensus (and hopeful KAME buy-back).
because the sysctl() code wasn't setting the requestor-pid field in dump
responses, the reworked unicast dump wasn't setting the requestor pid, either.
More exaclty, the pid field was set to 0.
No problem for setkey(8), but racoon reportedly ignores SADB dump-responses
with any pid (including 0) which doesn't match its own pid. A private bug
report says the 0-valued pid field broke racoon code which attempts to recover
from death of a prior racoon process, by dumping the SADB at startup.
Fix by revising sys/netipsec, so that both the new unicast PF_KEY dump
responses and the sysctl code set the requestor pid field in all
response mesages to DUMP requests.
obliteration to RESTORE_{KERN,USER}_SRS, respectively; have oea_init()
patch these sequences to be skipped on non-MPC601s. The code sequence
matching heuristic isn't as pretty as the one for VRSAVE and MQ but works
well enough with the current structure of the trap code, and can be easily
updated when necessary.
Note: the default behavior is changed. Now we don't disable the ACPI
subsystem on power off (halt -p) by default.
'options ACPI_DISABLE_ON_POWEROFF' in a kernel config file makes the kernel
behave the way we used to be.
petrov