options even though they look like primaries. (This is already documented
in the options themselves, but is sufficiently astonishing that I think it
deserves a BUGS entry as well.)
section.
Move the HISTORY section to place it before BUGS rather than after BUGS,
in order to minimize the chance of this error being reproduced in the
future. (Both mdoc(7) and 63% of manual pages have these sections listed
in this order.)
using linker_load_module(). This works OK if NGM_MKPEER message came
from userland and we have process associated with thread. But when
NGM_MKPEER was queued because target node was busy, linker_load_module()
is called from netisr thread leading to panic.
To workaround that we do not load modules by framework, instead ng_socket
loads module (if this is required) before sending NGM_MKPEER.
However, the race condition between return from NgSendMsg() and actual
creation of node still exist and needs to be solved.
PR: kern/62789
Approved by: julian
clients simultaneously. When node is client its mode is configured
with a control message.
sysctl net.graph.nonstandard_pppoe is deprecated but kept for
backward compatibility for some time.
Approved by: julian
dereference curthread. It is called only from critical_{enter,exit}(),
which already dereferences curthread. This doesn't seem to affect SMP
performance in my benchmarks, but improves MySQL transaction throughput
by about 1% on UP on my Xeon.
Head nodding: jhb, bmilekic
(i.e. with the foreign address being not wildcard) when checking
for possible port theft since such connections cannot be stolen.
The port theft check is FreeBSD-specific and isn't in the KAME tree.
PR: bin/65928 (in the audit trail)
Reviewed by: -net, -hackers (silence)
Tested by: Nick Leuta <skynick at mail.sc.ru>
MFC after: 1 month
an adaptive fashion when adaptive mutexes are enabled. The theory
behind non-adaptive Giant is that Giant will be held for long periods
of time, and therefore spinning waiting on it is wasteful. However,
in MySQL benchmarks which are relatively Giant-free, running Giant
adaptive makes an observable difference on SMP (5% transaction rate
improvement). As such, make adaptive behavior on Giant an option so
it can be more widely benchmarked.
These convert plain ASCII characters in-line, making them only slightly
slower than the single-byte ("NONE" encoding) version when processing
ASCII strings.
o s/TARGET_XFER_DIRTY/NATIVE_XFER_DIRTY/g to be conformant,
o Handle TARGET_OBJECT_DIRTY for core files. Required on Linux,
o Replace ia64_fbsd_supply_fpregs() and ia64_fbsd_supply_gregs()
with supply_fpregset() and supply_gregset() resp. Needed to
support libthread_db.
o For target_read_partial(), pass the address of bspstore as the
annex instead of bspstore itself. This fixes crossbuilds. The
annex is a pointer, while bspstore is a ULONGEST.
o In ia64_frame_prev_register(), handle dirty stacked registers.
- Push down Giant into shmexit(). (Giant is acquired only if the vmspace
contains shm segments.)
- Eliminate the acquisition of Giant from proc_rwmem().
- Reduce the scope of Giant in exit1(), uncovering the destruction of the
address space.
switch in fork_exit() to before anything else is done (but keep
schedlock for the deadthread check). This means one less
nasty bug if ever in the future whatever might have been called
before the update played with schedlock or critical sections.
Discussed with: tjr
from mutex profiling... This takes cnt_* and divides it by count, so
lower is better...
Sample command:
sh mtxpercent.sh | sort -rn +7 -8
SEE ALSO
MUTEX_PROFILING(9)
when inpcb is NULL, this is no longer invalid since jlemon added the
tcp_twstart function... this prevents close "failing" w/ EINVAL when it
really was successful...
Reviewed by: jeremy (NetBSD)
Now it is user-controlled through ifconfig(8).
The former ``automagic'' way of operation created more
trouble than good. First, VLAN_MTU consumers other than
vlan(4) had appeared, e.g., ng_vlan(4). Second, there was
no way to disable VLAN_MTU manually if it were causing
trouble, e.g., data corruption.
Dropping the ``automagic'' should be completely invisible
to the user since
a) all the drivers supporting VLAN_MTU
have it enabled by default, and in the first place
b) there is only one driver that can really toggle VLAN_MTU
in the hardware under its control (it's fxp(4), to which
I added VLAN_MTU controls to illustrate the principle.)
