The syntax for the new construct looks like the following, and re-uses the
refcounted keyword from refcounted using statements:
async refcounted protocol PFoo { ... }
Differential Revision: https://phabricator.services.mozilla.com/D39501
--HG--
extra : moz-landing-system : lando
The previous behaviour of failing unconditionally was performed as, during
shutdown, the channel could become unable to send without worker threads having
a chance to react. This change keeps that behaviour, isolating async message
senders from impending IPC shutdown, while performing expected actor teardown if
the manager actor has already been destroyed, and should no longer send messages.
An alternate behaviour here could be to crash if !Manager()->CanSend(). That
behaviour may be preferable if a sufficient number of callsites don't check the
return value of the `SendPFooConstructor()` method.
Differential Revision: https://phabricator.services.mozilla.com/D39534
--HG--
extra : moz-landing-system : lando
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
Until now we asserted that EnsureMTA was being called from the main thread
unless the current thread was already in the MTA.
This patch makes MTA thread initialization thread-safe by using a C++11
"magic static," thus allowing EnsureMTA to be safely invoked from any thread.
Differential Revision: https://phabricator.services.mozilla.com/D38422
--HG--
extra : moz-landing-system : lando
At the moment, this shouldn't make any difference because we only ever
launch one child process on android.
Differential Revision: https://phabricator.services.mozilla.com/D38244
--HG--
extra : moz-landing-system : lando
Now that UniqueFileHandle can be used more widely, and with
ipc::FileDescriptor being essentially a copyable UniqueFileHandle, it
makes sense to add a move constructor and a "forget"-like method to
convert between them when needed.
Depends on D26737
Differential Revision: https://phabricator.services.mozilla.com/D26738
--HG--
extra : moz-landing-system : lando
I'm not convinced the current comment about being race-free is accurate
in context of the launcher pool. It probably _is_ correct under this
patch, because ProcessLaunchers should only be constructed on a single
thread, but it's easy enough just to make it atomic.
Hopefully moving the timestamp doesn't perturb telemetry too much.
Differential Revision: https://phabricator.services.mozilla.com/D37305
--HG--
extra : moz-landing-system : lando
This is intended to facilitate future work to break up
PerformAsyncLaunch into asynchronous pieces. It also aims to fix some
raciness around access to state in the GeckoChildProcessHost instance.
There appears to be at least one data race in the existing code, in which
OpenPrivilegedHandle are run on both the launcher thread and the IO
thread without synchronization.
Differential Revision: https://phabricator.services.mozilla.com/D36539
--HG--
extra : moz-landing-system : lando
Having to namespace these into GeckoChildProcessHost is annoying. The
|using| declarations help to some extent, but it's easier to just put
them in mozilla::ipc.
Differential Revision: https://phabricator.services.mozilla.com/D36538
--HG--
extra : moz-landing-system : lando
Adds GeckoChildProcessHost::GetAll() and use it in ChromeUtils::GetProcInfo()
Differential Revision: https://phabricator.services.mozilla.com/D33920
--HG--
extra : moz-landing-system : lando
Also refactor SharedMemoryBasic::SystemProtect to allow testing cases
that are expected to fail.
Depends on D26748
Differential Revision: https://phabricator.services.mozilla.com/D26749
--HG--
rename : ipc/moz.build => ipc/gtest/moz.build
extra : moz-landing-system : lando
If mmap failed, we'd leave the memory_ member variable set to MAP_FAILED,
but everything else in this file checks for nullptr (and only nullptr) to
test if the pointer is valid.
Also, this removes the debug assertion that the mmap succeeded, to allow
writing unit tests where we expect it to fail (e.g., for insufficient
permissions).
Depends on D26747
Differential Revision: https://phabricator.services.mozilla.com/D26748
--HG--
extra : moz-landing-system : lando
This allows writing to shared memory and then making it read-only before
sharing it to other processes, such that a malicious sandboxed process
cannot regain write access. This is currently available only in the
low-level base::SharedMemory interface.
The freeze operation exposes the common subset of read-only shared
memory that we can implement on all supported OSes: with some APIs
(POSIX shm_open) we can't revoke writeability from existing capabilies,
while for others (Android ashmem) we *must* revoke it. Thus, we require
that the writeable capability not have been duplicated or shared to
another process, and consume it as part of freezing. Also, because in
some backends need special handling at creation time, freezeability must
be explicitly requested.
In particular, this doesn't allow giving an untrusted process read-only
access to memory that the original process can write.
Note that on MacOS before 10.12 this will use temporary files in order to
avoid an OS security bug that allows regaining write access; those OS
versions are no longer supported by Apple (but are supported by Firefox).
Depends on D26742
Differential Revision: https://phabricator.services.mozilla.com/D26743
--HG--
extra : moz-landing-system : lando
This uses RAII to handle error-case cleanup in the POSIX backend for
SharedMemory::Create, to simplify the complexity that will be added to
support freezing.
Depends on D26741
Differential Revision: https://phabricator.services.mozilla.com/D26742
--HG--
extra : moz-landing-system : lando
The Unix backend for shared memory needs to keep the mapped size to pass
to munmap, while the Windows backend doesn't. Currently it's reusing the
max_size field, and then zeroing it when it's unmapped, which breaks the
freezing use case. This patch uses a dedicated field for that.
Depends on D26740
Differential Revision: https://phabricator.services.mozilla.com/D26741
--HG--
extra : moz-landing-system : lando
Despite the comment saying not to use the "handle" except as an opaque
identifier, it is being used to pass the handle to other OS APIs. Direct
access to the handle needs to be controlled to make sure freezing is
safe, so this patch replaces that with interfaces that are more explicit
about ownership and lifetime.
Depends on D26739
Differential Revision: https://phabricator.services.mozilla.com/D26740
--HG--
extra : moz-landing-system : lando
FreeBSD's SHM_ANON is useful for the usual case of shared memory, but it
doesn't support freezing. It could be re-added later, but for now it's
simplest to remove it (and use named shm instead) while refactoring.
Depends on D26738
Differential Revision: https://phabricator.services.mozilla.com/D26739
--HG--
extra : moz-landing-system : lando
Now that UniqueFileHandle can be used more widely, and with
ipc::FileDescriptor being essentially a copyable UniqueFileHandle, it
makes sense to add a move constructor and a "forget"-like method to
convert between them when needed.
Depends on D26737
Differential Revision: https://phabricator.services.mozilla.com/D26738
--HG--
extra : moz-landing-system : lando
