Before this change, we wouldn't re-try sending fds if the first attempt
to send them failed, meaning that some fds wouldn't arrive if there was
any error sending (e.g. because the send buffer was full, which
is more common on macOS).
This new approach ensures we don't record that we've sent the fds until
the message is marked as successful, and should avoid the macOS errors.
Depends on D145392
Differential Revision: https://phabricator.services.mozilla.com/D146621
This is made possible by part 1, which made it possible to send more messages
using IPC::Channel. A limit is still in place, however it is now substantially
higher, hopefully making it effectively unlimited for practical purposes.
Differential Revision: https://phabricator.services.mozilla.com/D145392
This is done by splitting messages with large numbers of handles into multiple
`sendmsg` calls, each of which contains less than the maximum number of
transferred handles per-message, and stitching the message back together on the
receiving side. Most of the work on the receiving side was already handled by
the IPC::Channel code, so the work required was only to ensure we could split
the handle list up when sending.
Differential Revision: https://phabricator.services.mozilla.com/D145391
In order to know if the mIsThirdPartyContextToTopWindow was set in the
loadInfo of the channel, we use maybe to hold the value. So, we can know
if it was set before.
This patch also addes two methods in LoadInfo to clear and know if the
value is set.
Differential Revision: https://phabricator.services.mozilla.com/D146491
Win32k Lockdown state must be initialized on the main thread, but currently
a process launcher may be the first thing to read it on the IPC Thread
Initializing Win32k Lockdown state also relies on the gfxPlatform being
initialized, but that also isn't explicit anywhere.
This patch ensures both things are true: Always ensure that Win32k State is
initialized before queuing a process launch to the IPC Thread, and always
ensure that gfxPlatform is initialized before attempting to read the
gfx state.
Differential Revision: https://phabricator.services.mozilla.com/D146821
Win32k Lockdown state must be initialized on the main thread, but currently
a process launcher may be the first thing to read it on the IPC Thread
Initializing Win32k Lockdown state also relies on the gfxPlatform being
initialized, but that also isn't explicit anywhere.
This patch ensures both things are true: Always ensure that Win32k State is
initialized before queuing a process launch to the IPC Thread, and always
ensure that gfxPlatform is initialized before attempting to read the
gfx state.
Differential Revision: https://phabricator.services.mozilla.com/D146821
This patch mostly turns on the features set up by the earlier patches:
allow connecting to the X server and reading various related things
(.Xauthority, GPU device info in sysfs, etc.). It also turns off Mesa's
shader cache in the RDD process; that shouldn't be needed here, and
disabling it lets us avoid dealing with a few things in the sandbox
policy that we'd rather not (e.g., `getpwuid`).
Differential Revision: https://phabricator.services.mozilla.com/D146275
Win32k Lockdown state must be initialized on the main thread, but currently
a process launcher may be the first thing to read it on the IPC Thread
Initializing Win32k Lockdown state also relies on the gfxPlatform being
initialized, but that also isn't explicit anywhere.
This patch ensures both things are true: Always ensure that Win32k State is
initialized before queuing a process launch to the IPC Thread, and always
ensure that gfxPlatform is initialized before attempting to read the
gfx state.
Differential Revision: https://phabricator.services.mozilla.com/D146821
This patch mostly turns on the features set up by the earlier patches:
allow connecting to the X server and reading various related things
(.Xauthority, GPU device info in sysfs, etc.). It also turns off Mesa's
shader cache in the RDD process; that shouldn't be needed here, and
disabling it lets us avoid dealing with a few things in the sandbox
policy that we'd rather not (e.g., `getpwuid`).
Differential Revision: https://phabricator.services.mozilla.com/D146275
As serializing IPCStream no longer requires a manager or FileDescriptor array,
the arguments are no longer necessary, and can be removed. The AutoIPCStream
helper can also be removed, as managed actors are no longer used for
serialization, so a delayed start callback is not necessary.
The delayed start parameter is also removed from nsIIPCSerializableInputStream
instances, but is still present as `aAllowLazy` on the toplevel serialization
methods.
Differential Revision: https://phabricator.services.mozilla.com/D141048
the nsIMIMEInputStream type contains extra metadata header information
which shouldn't be lost when serializing the type over IPC. This patch
changes the LazyStream serialization to take this into account and only
serialize the value within the nsMIMEInputStream when sending a lazy
stream over IPC.
This information is specifically used by HTTP channels in order to
populate POST request headers.
Differential Revision: https://phabricator.services.mozilla.com/D141043
This is a complete rewrite of RemoteLazyInputStream to run off of its own
toplevel protocol, rather than being managed by other protocols like
PBackground or PContent. This should improve performance thanks to no longer
needing to operate on a main or worker thread, and due to no longer needing the
migration step for the stream actor.
This also acts as a step towards no longer requiring a manager actor to
serialize input streams, as the type is now actor-agnostic, and should support
being sent over IPC between any pair of processes.
Differential Revision: https://phabricator.services.mozilla.com/D141040
This interface should no longer be required due to the changes in part 1
limiting the complexity of IPCStream instances and limiting the number of file
descriptors which a single stream can attach to a message.
Removing this interface is necessary to serialize nsIInputStream instances over
arbitrary toplevel protocols and non-protocol IPC in the future.
Differential Revision: https://phabricator.services.mozilla.com/D141039
This gives us various positive benefits, such as using a shared memory ring
buffer for faster communication, not having data streaming being bound to the
thread which transferred the nsIInputStream (which is often the main thread),
and the ability for some backpressure to be applied to data streaming.
After this change, the "delayed start" parameter for IPCStream serialization is
less relevant, as backpressure will serve a similar purpose. It will still be
used to determine whether or not to use RemoteLazyInputStream when serializing
from the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D141038
This will improve the efficiency of serializing large data pipes, which in bad
cases can end up serializing very small amounts of data in individual pipes
over IPC, and acts as a compliment to the existing logic for limiting
serialized message sizes. It is also necessary for the changes in bug 1754004,
which require the ability to include FileDescriptor inline in the message,
which could blow out our FileDescriptor count limits if pipe creation was
unlimited.
In some tests, this change reduces the number of pipes required to serialize a
nsIInputStream from over 5000 to 1.
Differential Revision: https://phabricator.services.mozilla.com/D141036
As serializing IPCStream no longer requires a manager or FileDescriptor array,
the arguments are no longer necessary, and can be removed. The AutoIPCStream
helper can also be removed, as managed actors are no longer used for
serialization, so a delayed start callback is not necessary.
The delayed start parameter is also removed from nsIIPCSerializableInputStream
instances, but is still present as `aAllowLazy` on the toplevel serialization
methods.
Differential Revision: https://phabricator.services.mozilla.com/D141048
the nsIMIMEInputStream type contains extra metadata header information
which shouldn't be lost when serializing the type over IPC. This patch
changes the LazyStream serialization to take this into account and only
serialize the value within the nsMIMEInputStream when sending a lazy
stream over IPC.
This information is specifically used by HTTP channels in order to
populate POST request headers.
Differential Revision: https://phabricator.services.mozilla.com/D141043
This is a complete rewrite of RemoteLazyInputStream to run off of its own
toplevel protocol, rather than being managed by other protocols like
PBackground or PContent. This should improve performance thanks to no longer
needing to operate on a main or worker thread, and due to no longer needing the
migration step for the stream actor.
This also acts as a step towards no longer requiring a manager actor to
serialize input streams, as the type is now actor-agnostic, and should support
being sent over IPC between any pair of processes.
Differential Revision: https://phabricator.services.mozilla.com/D141040
Nika Layzell
James Teh
Alexandre Lissy
Alexandre Lissy
Jan Varga
Tim Huang
Bob Owen
Chris Martin
Cristian Tuns
Marian-Vasile Laza
Jed Davis
Butkovits Atila
Andrew McCreight
Molnar Sandor
Iulian Moraru
Bogdan Szekely
Noemi Erli