libc/resolv: Refactor the configuration parser
This was previously all a single loop in res_init(), apart from option
parsing which we cleaned up in a previous commit. Break it out into
separate functions for reading the configuration line by line, setting
the default domain, setting the search list, and adding a nameserver
to the nameserver list. Sprinkle bounds checks and code comments all
around.
The sortlist code, which has been disabled for the past 20 years, will
be dealt with in a separate commit.
MFC after: 1 week
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D57924
(cherry picked from commit ffeb56905ed6a7ac759367096d6dc0596e82e03f)
libc/resolv: Reimplement the sortlist parser
When we switched from the BIND4 resolver to the BIND9 resolver, the
sortlist parser was inadvertently disabled due to a missing #define, and
nobody seemed to notice. The sorting code remained enabled in the
resolver, but there was no way to set a sort order.
Reimplement the sortlist parser, but correctly, and update the manual
accordingly. The new parser accepts IPv4 and IPv6 addresses with or
without a mask or prefix length, just like the old one, except IPv6
support was a bit wonky in the original code.
Fixes: 5342d17f09a8 ("Update the resolver in libc to BIND9's one.")
Relnotes: yes
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D57925
(cherry picked from commit fbe0257b5613f457af42f82efb2e3bc9395d0557)
resolver(5): Overhaul
* Modernize the markup
* Describe the comment syntax
* Drop obsolete advice
* Capitalize sentences
* Improve the language
* Replace no_tld_query with no-tld-query; both are supported, but all the
other multi-word options use hyphens rather than underscores.
* Add missing ENVIRONMENT section
* Redo the example
[5 lines not shown]
resolver.5: document six previously undocumented options
Document the edns0, inet6, insecure1, insecure2, no-check-names,
and rotate options which are parsed by res_init(3) but were not
described in the resolver(5) man page.
MFC after: 1 week
Signed-off-by: Christos Longros <chris.longros at gmail.com>
Reviewed by: des
Differential Revision: https://reviews.freebsd.org/D55864
(cherry picked from commit 462a1f6197fa3de63e0eca2835b1d5b0bc6a3bbb)
libc/resolv: Refactor the option parser
Start the loop by finding the end of the option name, the name-value
separator (if any), and the end of the option. Use those pointers to
simplify matching the option name and parsing the option value, and
validate option names and values more strictly. This means that:
* We no longer accept trailing garbage in an option name or value. For
instance, we would previously interpret “edns0123” as “edns0” and
“timeout:3xyz” as “timeout:3”. This was actually quite lucky because
we also failed to recognize the newline at the end of the option line
as a whitespace character.
* For options that take a numerical argument, we would previously accept
negative values and treat non-numerical arguments as 0, while large
numerical arguments would be capped to the option's maximum permitted
value. Now, any failure to parse the argument, including overflow,
results in the option being left unchanged.
[6 lines not shown]
libc/resolv: Reimplement the sortlist parser
When we switched from the BIND4 resolver to the BIND9 resolver, the
sortlist parser was inadvertently disabled due to a missing #define, and
nobody seemed to notice. The sorting code remained enabled in the
resolver, but there was no way to set a sort order.
Reimplement the sortlist parser, but correctly, and update the manual
accordingly. The new parser accepts IPv4 and IPv6 addresses with or
without a mask or prefix length, just like the old one, except IPv6
support was a bit wonky in the original code.
Fixes: 5342d17f09a8 ("Update the resolver in libc to BIND9's one.")
Relnotes: yes
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D57925
(cherry picked from commit fbe0257b5613f457af42f82efb2e3bc9395d0557)
libc/resolv: Refactor the configuration parser
This was previously all a single loop in res_init(), apart from option
parsing which we cleaned up in a previous commit. Break it out into
separate functions for reading the configuration line by line, setting
the default domain, setting the search list, and adding a nameserver
to the nameserver list. Sprinkle bounds checks and code comments all
around.
The sortlist code, which has been disabled for the past 20 years, will
be dealt with in a separate commit.
MFC after: 1 week
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D57924
(cherry picked from commit ffeb56905ed6a7ac759367096d6dc0596e82e03f)
libc/resolv: Refactor the option parser
Start the loop by finding the end of the option name, the name-value
separator (if any), and the end of the option. Use those pointers to
simplify matching the option name and parsing the option value, and
validate option names and values more strictly. This means that:
* We no longer accept trailing garbage in an option name or value. For
instance, we would previously interpret “edns0123” as “edns0” and
“timeout:3xyz” as “timeout:3”. This was actually quite lucky because
we also failed to recognize the newline at the end of the option line
as a whitespace character.
* For options that take a numerical argument, we would previously accept
negative values and treat non-numerical arguments as 0, while large
numerical arguments would be capped to the option's maximum permitted
value. Now, any failure to parse the argument, including overflow,
results in the option being left unchanged.
[6 lines not shown]
resolver(5): Overhaul
* Modernize the markup
* Describe the comment syntax
* Drop obsolete advice
* Capitalize sentences
* Improve the language
* Replace no_tld_query with no-tld-query; both are supported, but all the
other multi-word options use hyphens rather than underscores.
* Add missing ENVIRONMENT section
* Redo the example
[5 lines not shown]
bhyve: check upper bounds for value from qsz
The max_qentries in pci_nvme_softc is uint16_t and
too large int may get truncated to invalid value.
While there, use local declarations for val.
Suggested by: Bill Sommerfeld
Reviewed by: chuck
Differential Revision: https://reviews.freebsd.org/D58293
ena: Put taskqueues into correct domain if !RSS
When compiled without 'options RSS', the ena driver created taskqueues
using taskqueue_start_threads_cpuset passing a mask value of NULL,
both in the ena_setup_tx_resources path (for enqueues) and in the
ena_create_io_queues path (for the completion-processing).
In the default configuration, on most EC2 instances, this results in
taskqueues running in the right NUMA domain, but only by accident; in
non-default configurations (e.g. with with multiple EBS volumes
attached and associated NVMe taskqueues) the taskqueues may land in
the wrong NUMA domain even on instance types where the one-EBS-one-ENA
case produces the desired results.
Set (struct ena_que)->domain and use that to inform the choice of CPU
sets. On a c8gn.48xlarge EC2 instance this doubles throughput on a
32-TCP-stream benchmark.
Reviewed by: akiyano
[5 lines not shown]
ena: Put taskqueues into correct domain if !RSS
When compiled without 'options RSS', the ena driver created taskqueues
using taskqueue_start_threads_cpuset passing a mask value of NULL,
both in the ena_setup_tx_resources path (for enqueues) and in the
ena_create_io_queues path (for the completion-processing).
In the default configuration, on most EC2 instances, this results in
taskqueues running in the right NUMA domain, but only by accident; in
non-default configurations (e.g. with with multiple EBS volumes
attached and associated NVMe taskqueues) the taskqueues may land in
the wrong NUMA domain even on instance types where the one-EBS-one-ENA
case produces the desired results.
Set (struct ena_que)->domain and use that to inform the choice of CPU
sets. On a c8gn.48xlarge EC2 instance this doubles throughput on a
32-TCP-stream benchmark.
Reviewed by: akiyano
[5 lines not shown]
kern/sys_ptrace: do not skip P2_PTRACEREQ wait for PT_CLEARSTEP/PT_GET_CHILDREN
Reported and reviewed by: markj
Fixes: d3b7bbee9275 ("ptrace(2): add PT_GET_CHILDREN")
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D58364
sched_4bsd: Allocate runqueues only for present CPUs
4BSD has been allocating an array of MAXCPU runqueues, runq_pcpu[],
instead of one runqueue per actually present CPU. On amd64, MAXCPU is
1024 and 'struct runq' is 4128 bytes, causing runq_pcpu[] to take more
than 4 MiB of memory. On the vast majority of current systems, which
have at most 32 cores with SMT, this is a waste of memory.
Besides providing per-CPU runqueues, runq_pcpu[] has also been used to
determine the CPU ID of a given thread's associated runqueue through
pointer arithmetic.
Since per-CPU structures are only allocated for present CPUs, in order
to save space, move the runqueues to per-CPU fields and, for each thread
('struct ts_sched'), replace its runqueue pointer by the CPU ID of the
runqueue it is in (new 'ts_rqcpu' field). Set the thread's CPU ID to
the special NOCPU value when it is running on the global runqueue.
Drop the SKE_RUNQ_PCPU() macro as it is now simply equivalent to
[11 lines not shown]
sched_4bsd: Rename the global runqueue
In an upcoming change whose purpose is to stop having 4BSD always
allocate MAXCPU runqueues, wasting space on most machines, 'struct
td_sched' will store the CPU ID to which a thread is bound/pinned
instead of a pointer to the corresponding runqueue. As a consequence,
existing functions manipulating a thread's runqueue will need to point
to the inferred runqueue through a local variable. The name 'runq' is
the ideal one for these local variables, but before this change it
designated the global runqueue, also causing unnecessary ambiguity.
Thus, rename the global runqueue to the more explicit 'runq_global'.
Arguably, this should have been performed as part of commit e17c57b14ba9
("- Implement cpu pinning and binding. (...)").
No functional change (intended).
[olce: Massaged the commit message. Tested with source builds.]
[5 lines not shown]
sched_4bsd: Remove obsolete SMP scaling for ticks per priority level
The INVERSE_ESTCPU_WEIGHT scaling had been introduced by commit
b698380f33ef ("Quick fix for scaling of statclock ticks in the SMP
case. ...") to leave more discrimination room for multiple CPUs possibly
adding their ticks to the same 'struct ksegrp' (but also slightly
changing how CPU hogs are penalized).
Then, commit 8460a577a4b4 ("Make KSE a kernel option, ...") introduced
the current thread-based code, where tick accounting is only done on the
current thread, which renders this trick obsolete on !KSE.
Finally, when KSE was removed, the trick became generally obsolete.
The trick is actually even harmful because it changes the intended
behavior of priorizing more the CPUs that use the less ticks (and so,
impairs boosting "interactive" processes).
Remove it now. Clamping of 'ts_estcpu' and its relation to the
[6 lines not shown]
sched_4bsd: Fix conflating priority of differently-niced CPU-bound threads
We introduced (PRI_MAX_TIMESHARE - PRI_MIN_TIMESHARE) as part of
ESTCPULIM() in commit eebc148f25c3 ("sched_4bsd: ESTCPULIM(): Allow any
value in the timeshare range") in order to use more than a fixed number
(40) of all the available priority levels in the timeshare range (136
before the 256-queue runqueue work, 224 now) to take into account the
number of ticks a thread has run ('ts_estcpu').
In the computation of a new thread's priority (resetpriority()), in
addition to the "ticks running" contribution, the final priority also
includes a "nice" value contribution. The final value is clamped into
the [PRI_MIN_TIMESHARE; PRI_MAX_TRIMESHARE] range.
Problem is that the new "ticks running" contribution now can lead to
a computed priority value that exceeds PRI_MAX_TRIMESHARE, and is thus
finally clamped to PRI_MAX_TIMESHARE, which becomes an alias for all
out-of-bound values. In particular, this can conflate CPU-hungry
threads. With at least two of them competing on the same CPU, with an
[20 lines not shown]
nfsd: Optionally enable use of M_EXTPG mbufs for read replies
A test site determined that, for a Mellanox NIC which can handle
M_EXTPG mbufs, an improvement of 5-15% for read rate could be
achieved if the read reply was in M_EXTPG mbufs.
A patch that tried to determine if the outbound NIC supported
M_EXTPG mbufs (IFCAP_MEXTPG) did not pass review.
However, it does appear that this can be useful for NFS-over-RDMA.
(Which just happen to use NICs that do support M_EXTPG mbufs.)
As such, this patch enables them is xp_extpg is set to true,
which is never for now, but might be set true for RDMA or
when vfs.nfsd.enable_mextpg is set non-zero. (It is 0 by
default, so this is never enabled by default at this time.)
(cherry picked from commit d516e52373e1768ea84bf1ca220671a44f413abe)
