With GATEWAY (fastforward), the whole forwarding processing runs in
hardware interrupt context. So we cannot use rwlock for lltable and
llentry in that case.
This change replaces rwlock with mutex(IPL_NET) for lltable and llentry
when GATEWAY is enabled. We need to tweak locking only around rtree
in lltable_free. Other than that, what we need to do is to change macros
for locks.
I hope fastforward runs in softint some day in the future...
and for 82573 (unknown). Set GCR_L1_ACT_WITHOUT_L0S_RX bit. The NVM Image
version 2.1.4 and newer have this workaround.
- Print the NVM image version on 82583, too.
Pointed out by joerg@.
UNLOCKED and LOCKED are done inside mutex_exit and mutex_enter respectively
so we don't need to do them outside mutex_exit and mutex_enter.
Reviewed by pooka@
unitchan entry to make lba_read() work in all cases.
The libsa-printf() does not seem to support 64-bit output, so cast the
block number to unsigned when printing an error message.
* Typo's, thanks to Herbert Parentes Fortes Neto
* Clarify that private_interfaces="*" will not forward the root zone
* ensure that domain-insecure always appears in a server clause for
the unbound subscriber
The previous code took locks the following order:
- LLE_WLOCKs
- mutex_enter(softnet_lock)
- LLE_WUNLOCKs
- mutex_exit(softnet_lock)
This fix moves mutex_enter(softnet_lock) before LLE_WLOCKs.
We actually have a big problem: the fileassocs are never deleted.
Therefore, if a user generates a lot of buggy binaries and launches them
all, the kernel will allocate memory again again and again for all these
entries and will never free them (unless the files are deleted from the
disk). Which means that a user can too easily put the kernel under memory
pressure.
months ago, but no one reviewed it - probably because it's not a trivial
change.
This change fixes the following bug: when loading a PaX'ed binary, the
kernel updates the PaX flag of the calling process before it makes sure
the new process is actually launched. If the kernel fails to launch the
new process, it does not restore the PaX flag of the calling process,
leaving it in an inconsistent state.
Actually, simply restoring it would be horrible as well, since in the
meantime another thread may have used the flag.
The solution is therefore: modify all the functions used by PaX so that
they take as argument the exec package instead of the lwp, and set the PaX
flag in the process *right before* launching the new process - it cannot
fail in the meantime.
