This patch rewrites the Unix backend of ProcessWatcher for two reasons:
1. To remove the use of libevent's signal handling, which has concurrency
bugs that can't be easily fixed upstream (see Bugzilla for details)
2. To simplify the code in general; in particular, the new version has one
place where the process and its exit status are consumed from the OS
The new implementation uses the same pipe-to-self technique as libevent
(and which we use elsewhere) to deal with async signal safety. Unlike
the previous version, there is a single object which manages all
monitored child processes rather than one each. (Previously, this
multiplexing was done inside libevent.)
Differential Revision: https://phabricator.services.mozilla.com/D141309
This won't be used for any security or routing purposes, but can be useful for
debugging. It will be used in the future by the profiler to correlate sent and
received message events across processes.
Differential Revision: https://phabricator.services.mozilla.com/D153621
These constructors are unnecessary and can be defined with a `using` statement,
making it easier to change all constructors simultaneously.
Differential Revision: https://phabricator.services.mozilla.com/D153620
This improves consistency with the child process case, and will make it easier
to attach additional state without needing to thread it through every child
process callsite manually.
Differential Revision: https://phabricator.services.mozilla.com/D153619
This type is also used in other places to start non-initial actors, and will
allow us to attach additional state more easily without needing to thread it
through every child process callsite manually.
Differential Revision: https://phabricator.services.mozilla.com/D153618
Previously this code read the atomic rather than the cached value (which
was unused). This is inherently racy as the atomic is updated on a
different thread than the read happened on.
Differential Revision: https://phabricator.services.mozilla.com/D153617
We want to signal content processes to cancel content JS unconditionally on shutdown.
In the case of parent shutdown this has to happen as early as "quit-application-granted", given that both extensions and session storage shutdown rely on the possibility to interact with content processes (which is not possible when they are inside long running JS).
In addition in the case of a normal child shutdown we cancel content JS execution, too.
For now we put this behind the pref "dom.abort_script_on_child_shutdown" which remains default off.
Depends on D150539
Differential Revision: https://phabricator.services.mozilla.com/D150598
We want to signal content processes to cancel content JS unconditionally on shutdown.
In the case of parent shutdown this has to happen as early as "quit-application-granted", given that both extensions and session storage shutdown rely on the possibility to interact with content processes (which is not possible when they are inside long running JS).
In addition in the case of a normal child shutdown we cancel content JS execution, too.
For now we put this behind the pref "dom.abort_script_on_child_shutdown" which remains default off.
Depends on D150539
Differential Revision: https://phabricator.services.mozilla.com/D150598
We were already turning off Mesa's shader cache in the RDD process,
because it's not useful given that we're only using video codec
acceleration and moving images around, and it does a few things related
to trying to access the cache that the sandbox would have to accomodate.
This patch does the equivalent thing for the nvidia proprietary driver;
we don't support it for media codec acceleration, but it can still be
loaded in that process (e.g., on multi-GPU systems) and it's trying to
call `statfs` on startup which may be related.
Differential Revision: https://phabricator.services.mozilla.com/D152932
Instead of using the public member type `PrivateIPDLCaller` to
restrict access to certain `Shmem` member functions, make them
`private`, and designated `IProtocol` and `ITopLevelProtocol` as
friends of `Shmem`.
Differential Revision: https://phabricator.services.mozilla.com/D151952
This type is inspired by the Chromium BigBuffer type, and acts as a type which
intelligently either allocates a shared memory region or in-memory buffer based
on the size of the payload. The current threshold is 64k bytes, and it can be
somewhat cheaply transferred over IPC.
This is intended to be used in places where we currently create a basic `Shmem`
to transfer a potentially large block of bytes over IPC.
Differential Revision: https://phabricator.services.mozilla.com/D151851
This prevents copies and avoids the hack we have to avoid this, which
right now is using nsDependent{C,}String.
Non-virtual actors can still use `nsString` if they need to on the
receiving end.
Differential Revision: https://phabricator.services.mozilla.com/D152519
We want to signal content processes to cancel content JS unconditionally on shutdown.
In the case of parent shutdown this has to happen as early as "quit-application-granted", given that both extensions and session storage shutdown rely on the possibility to interact with content processes (which is not possible when they are inside long running JS).
In addition in the case of a normal child shutdown we cancel content JS execution, too.
For now we put this behind the pref "dom.abort_script_on_child_shutdown" which remains default off.
Depends on D150539
Differential Revision: https://phabricator.services.mozilla.com/D150598
Mesa 22.1.0 changed the env var name MESA_GLSL_CACHE_DISABLE to
MESA_SHADER_CACHE_DISABLE; it still accepts the old name, but prints a
deprecation warning. If we set both env vars, then we can support both
old and new Mesas correctly (the warning won't be printed if the new env
var is also set).
Differential Revision: https://phabricator.services.mozilla.com/D151094
These changes are partially copied from D148179 (created by jesup). We need to
be able to create correct origin directories from the very beginning.
Differential Revision: https://phabricator.services.mozilla.com/D149259
Spec: https://html.spec.whatwg.org/multipage/#coep:coep-credentialless
Credentialless is a new cross-origin embedder policy which allows us
to not enforcing CORP when loading cross-origin resources while
providing SharedArrayBuffer.
There are two main things involved here:
1. Fetching cross-origin no-CORS resources omits credentials
- This is done by applying `LOAD_ANONYMOUS` flag to the request
2. Other requests sent with credentials require the server's explicit
permission through the CORS protocol or the CORS header
- This is done by expanding `ProcessCrossOriginResourcePolicyHeader`
function to apply the necessary checks.
Differential Revision: https://phabricator.services.mozilla.com/D147802
Spec: https://html.spec.whatwg.org/multipage/#coep:coep-credentialless
Credentialless is a new cross-origin embedder policy which allows us
to not enforcing CORP when loading cross-origin resources while
providing SharedArrayBuffer.
There are two main things involved here:
1. Fetching cross-origin no-CORS resources omits credentials
- This is done by applying `LOAD_ANONYMOUS` flag to the request
2. Other requests sent with credentials require the server's explicit
permission through the CORS protocol or the CORS header
- This is done by expanding `ProcessCrossOriginResourcePolicyHeader`
function to apply the necessary checks.
Differential Revision: https://phabricator.services.mozilla.com/D147802
Norisz Fay
Jed Davis
Nika Layzell
Fabrice Desré
Andreea Pavel
Christian Holler
Jens Stutte
Sandor Molnar
Sean Feng
Jim Blandy
Marian-Vasile Laza
Emilio Cobos Álvarez
az
Harveer Singh
Cristian Tuns
Andi-Bogdan Postelnicu
Paul Bone
Randell Jesup
Butkovits Atila
Dana Keeler
Jan Varga
Jari Jalkanen
serge-sans-paille
Iulian Moraru