sound: Start each channel individually
Unlock all members before starting any of them. Holding multiple channel
locks while calling chn_start() on a virtual channel can trigger the
parent, which acquires PCM_LOCK() while other virtual channels are still
locked -- a lock order reversal.
Reviewed by: christos
Differential Revision: https://reviews.freebsd.org/D57399
(cherry picked from commit 47ae0a869c7db693ffb1ac058d63dcb79c4e68a8)
ipfilter(4): Fix a couple of typos in the manual pages
- s/heirarchical/hierarchical/
- s/itnerface/interface/
- s/conjuction/conjunction/
(cherry picked from commit 0223ae33ad6dd29215bbb6efd041aa5b6c67dc1f)
ps(1): Fix a few typos in the manual page
- s/occurence/occurrence/
- s/occurences/occurrences/
- s/ouput/output/
(cherry picked from commit dd2127b54f97fd7445bb4f4187a148e979c9c944)
ipfilter(4): Fix a couple of typos in the manual pages
- s/heirarchical/hierarchical/
- s/itnerface/interface/
- s/conjuction/conjunction/
(cherry picked from commit 0223ae33ad6dd29215bbb6efd041aa5b6c67dc1f)
ps(1): Fix a few typos in the manual page
- s/occurence/occurrence/
- s/occurences/occurrences/
- s/ouput/output/
(cherry picked from commit dd2127b54f97fd7445bb4f4187a148e979c9c944)
posix_spawn(3): create a guard page below the stack for rfork_thread on x86
Reviewed by: kevans
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D57955
rtld: add spinlock around the crt malloc calls
Right now, the rtld malloc is called under the write-locked rtld bind
lock. A future change adds places where only read-locked rtld bind lock
is held, and then the spinlock protects the malloc structures from the
parallel updates.
Reviewed by: kevans
Tested by: Marek Zarychta <zarychtam at plan-b.pwste.edu.pl>
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D57908
rtld: stop using unbound alloca()
For DoneList allocations, its size depends on the number of loaded DSOs.
Small images could be served by alloca(), but large donelists need to
go into heap.
For map_object(), alloca size is the number of segments in the object.
In both cases, over-grown situations would cause a stack overflow.
PR: 295991
Noted and reviewed by: kevans
Tested by: Marek Zarychta <zarychtam at plan-b.pwste.edu.pl>
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D57908
netinet6: cleanse safeguards against IFT_PFLOG
This "interface" type is no more. Leave the constant in if_types.h, we
probably need an exp-run before removing it.
MAC/do: Add consistency tests
Test that:
1. Concurrent changes to different parameters on the same jail are
independent/atomic.
2. Inheritance works.
3. Relaxing only parent jail rules does not leak to a subjail thanks to
sequential consistency.
4. Sysctl knobs and jail parameters stay consistent.
Some of these tests may be extended in the future with several layers of
jails (there is only a single subjail currently).
Reviewed by: bapt
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/38
(cherry picked from commit 851499046d25fbe5841a55fb7bfcc879522f59a8)
MAC/do: Tests: Add support for exec paths, jail parameters, subjails
And also allow configuration of the mdo(1) executable path.
This commit only contains new or modified infrastructure. No functional
change intended at this point.
Reviewed by: bapt
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/38
(cherry picked from commit a95ff5ef7d1ffcb701913028253a4700cd9a1459)
mac_do.4: Document executable paths, default jail values and consistency
While here, fix the bug of mentioning 'enable' as a possible value for
the 'mac.do' jail parameter whereas it is 'new' instead.
Reviewed by: bapt
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/38
(cherry picked from commit 39818654ae879788807d3a87c2d75cc700cc7113)
MAC/do: Fix double-free on parse error after "executable paths" feature
parse_rules() has been calling toast_rules() in case of a parse error in
order to deallocate the 'struct rule' objects it has constructed up to
that point.
toast_rules() would take a pointer to a full 'struct rules' object, and
besides freeing all 'struct rule' referenced by it, would also free the
holding 'struct rules' itself.
With the introduction of the "executable paths" feature, and the
embedding of 'struct rules' into 'struct conf', meaning that the
lifecycle for 'struct rules' was no longer independent, toast_rules()
was changed not to free the passed 'struct rules' (as it was a field of
a 'struct conf' object). Unfortunately, this change was not completed
with a reinitialization of the rules list head, so the 'struct conf'
object would continue to reference just-freed rules, which then would be
freed a second time on destruction of that container.
[18 lines not shown]
MAC/do: Update copyright
Update years for the Foundation.
While here, remove the initial '/*-' which has been useless for a long
time.
While here, add a missing space on bapt@'s copyright line (approved by
him).
Reviewed by: bapt
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/38
(cherry picked from commit fcb0018634c77fe32ed99bca00f856af18ed240b)
MAC/do: Do not skip blanks when parsing executable paths
The kind of tolerance we apply to parsing rules, whose format we have
defined, cannot be applied to paths since blank characters are allowed
there.
There is still the limitation that no escape character is currently
supported, and so it is not possible to configure a path having a ':'
character.
Reviewed by: bapt
Fixes: 9818224174c4 ("MAC/do: Executable paths feature (GSoC 2025's final state)")
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/38
(cherry picked from commit 1fa1e3f3950fc0593ab73ea075c24c9bfbe8afd6)
MAC/do: Serialize installing/modifying some jail's configuration
See the immediately preceding commit for explanations on what this is
fixing.
When setting 'mac.do' to 'inherit' on a jail with 'mac.do.rules' and
'mac.do.exec_paths' also specified in the same call, ensure that the
check that these passed parameters are the same as those to be inherited
is atomic with respect to enabling the inheritance (i.e., removing the
jail's 'struct conf' object). (See previous commit "MAC/do: Fix the
recent logic to set jail parameters, make it more tolerant" as for why
this check exists.)
Because we currently only modify a single configuration object per
transaction, we introduce the parse_and_commit_conf() wrapper around
parse_and_set_conf() to remove duplicated code that would ensue from
calling the latter directly, namely, releasing the 'mac_do_rwl' lock and
freeing the old configuration object (if any).
[11 lines not shown]
MAC/do: Support for atomically modifying configurations
As mentioned in previous commits "MAC/do: parse_and_set_conf(): Require
the model configuration" and "MAC/do: Sequential consistency for
configuration retrieval", the introduction of the "executable path"
feature, more fundamentally, the fact that there is now more than one
per-jail parameter and that parameters can be independently modified or
copied, causes an atomicity problem in case of concurrent accesses to of
a jail's applicable configuration.
Partially modifying a configuration is indeed akin to
a read-modify-write operation, where the read is either to the current
or an inherited configuration. More precisely, once pointed to by
a jail, a configuration object is immutable, and changing the jail's
configuration means making the jail point to another configuration
object. To change a jail's configuration, a new configuration object is
thus built, and if only some parameters have been explicitly specified,
those that have not been are set by copying the corresponding values
from an existing configuration object (in case of partial modification
[36 lines not shown]
MAC/do: Sequential consistency for configuration retrieval
Since the inception of mac_do(4), find_conf(), used to retrieve the
applicable configuration, has been weakly consistent with respect to
concurrent modifications to configuration inheritance that influence its
result (and it has been sequentially consistent with respect to other
configuration modifications, which the initial executable paths feature
and introduction of implicit parameters broke and which will be fixed in
a subsequent commit).
Indeed, find_conf() climbs the jail tree to find an applicable
configuration, which is not an atomic operation. It examines the
current jail's configuration pointer for each browsed jail, which does
not prevent concurrent modifications of the configuration pointer for
jails below or above it. Modifications above the current jail are not
a problem, since if climbing needs to continue (i.e., the current jail
inherits), these modifications will be seen if performed before that
check (and may or may not be seen if performed after that check).
However, modifications below the current jail impair sequential
[50 lines not shown]
