improperly doing the equivalent of (m = (function() == NULL)) instead
of ((m = function()) == NULL).
This fixes a NULL pointer dereference panic with runt arp packets.
timeout closer to the 1-second value that AMI use in their Linux
driver, and mark the mailbox structures as volatile so that gcc
doesn't over-optimise access to them.
This should fix the "controller wedged" bug.
Submitted by: Brian Dean <brdean@unx.sas.com>
Rename and (where appropriate) re-order sections:
NOTES -> IMPLEMENTATION NOTES
AUTHOR -> AUTHORS
Put something useful in the BUGS section.
Only the first gammar fix in the file comes was given in the
attributed PR.
PR: 17545
Submitted by: Yoshihiro Ota <hiro@mail.advok.com>
The fix submitted in the attributed PR is identical to the one
adopted by OpenBSD.
PR: 17027
Submitted by: David Malone <dwmalone@maths.tcd.ie>
Obtained from: OpenBSD
don't bother to re-initialise the NCPs. Instead wait for
bundle_LinkClosed() to be called - IFF it actually is called.
By initialising the NCPs at this point, ppp was recursing
back into the fsm_Down() routing for the link, and losing
track of the reason that the link was being brought down.
The end result was that ``set reconnect'' would never do
anything.
Patiently pointed out by: ru
if the childs exec() has succeeded or failed by taking advantage
of the fact that both processes share the same memory.
FWIW:
I tried to implement this by doing a pipe(), setting the
write desciptors close-on-exec flag in the child and writing
errno to the descriptor if the exec() fails. The parent can
then ``if (read()) got errno else exec worked''.
This didn't work though - the child could write() to fd[1] on
exec failure, but the parent got 0 trying to read() from fd[0] !
Is this a bug in execve() ?
dropping out of background/foreground/direct mode.
This avoids either having to wait for the redial timer before
exiting or jaming up in select() waiting for something that'll
never happen.
Remove a bogus (redundant, just weird, etc.) key_freeso(so).
There are no consumers of it now, nor does it seem there
ever will be.
in6?_pcb.c:
Add an if (inp->in6?p_sp != NULL) before the call to
ipsec[46]_delete_pcbpolicy(inp). In low-memory conditions
this can cause a crash because in6?_sp can be NULL...
