searching for reviewer(jld)
f194cdbd288a295de99a0e4c3ab14d2d503691b4: Bug 1783240 - Part 2: Automatically serialize large blocks of binary data in shared memory, r=ipc-reviewers,jld
Nika Layzell <nika@thelayzells.com> - Wed, 28 Sep 2022 19:25:12 +0000 - rev 636576
Push 40274 by apavel@mozilla.com at Thu, 29 Sep 2022 09:39:14 +0000
Bug 1783240 - Part 2: Automatically serialize large blocks of binary data in shared memory, r=ipc-reviewers,jld This changes and unifies the serialization strategy for types like `ns[C]String`, `nsTArray<T>`, `std::vector<T>` etc such that they are all serialized using a common implementation. For types which are trivial to transfer with `memcpy`, they will automatically be serialized into a shared memory region and copied out on the other side if its size exceeds 64k. Differential Revision: https://phabricator.services.mozilla.com/D153803
d20e964a3d7721de809b221f9dfeb2b9b6d38234: Bug 1784039 - Remove the `isLikelyOOM` property from ipc:content-shutdown messages r=jld
Gabriele Svelto <gsvelto@mozilla.com> - Tue, 13 Sep 2022 07:01:57 +0000 - rev 635332
Push 40232 by nfay@mozilla.com at Tue, 13 Sep 2022 15:42:21 +0000
Bug 1784039 - Remove the `isLikelyOOM` property from ipc:content-shutdown messages r=jld Differential Revision: https://phabricator.services.mozilla.com/D154226
be22852de7df3dee3c68fac2f7b110864df559c9: Bug 1781129 - Part 4: Fix issues caused by Shmem arguments no longer being visible to ipdl, r=ipc-reviewers,jld
Nika Layzell <nika@thelayzells.com> - Fri, 26 Aug 2022 16:08:06 +0000 - rev 628340
Push 40184 by imoraru@mozilla.com at Fri, 26 Aug 2022 21:48:35 +0000
Bug 1781129 - Part 4: Fix issues caused by Shmem arguments no longer being visible to ipdl, r=ipc-reviewers,jld Due to Shmem implementing ParamTraits, it is possible for a Shmem argument to not be visible to the IPDL compiler as it is only serialized within an opaque type included with `using`. If that happens, it would cause the construction of the Shmem to fail on the other side, in a hard to diagnose manner. This changes the logic to always allow any actor to manage shmems, to make it more in line with the `AllocShmem` method being directly declared on IProtocol. This specifically caused issues after this patch stack with PContent, which no longer has any shmem arguments visible to IPDL after these changes, but still is used as a manager for Shmems included in some messages. Differential Revision: https://phabricator.services.mozilla.com/D151855
37da1d18cde9c15c5f8f172c7e94efd4d9391c1e: Bug 1781129 - Part 4: Fix issues caused by Shmem arguments no longer being visible to ipdl, r=ipc-reviewers,jld
Nika Layzell <nika@thelayzells.com> - Mon, 22 Aug 2022 15:38:16 +0000 - rev 627840
Push 40169 by mlaza@mozilla.com at Tue, 23 Aug 2022 02:46:57 +0000
Bug 1781129 - Part 4: Fix issues caused by Shmem arguments no longer being visible to ipdl, r=ipc-reviewers,jld Due to Shmem implementing ParamTraits, it is possible for a Shmem argument to not be visible to the IPDL compiler as it is only serialized within an opaque type included with `using`. If that happens, it would cause the construction of the Shmem to fail on the other side, in a hard to diagnose manner. This changes the logic to always allow any actor to manage shmems, to make it more in line with the `AllocShmem` method being directly declared on IProtocol. This specifically caused issues after this patch stack with PContent, which no longer has any shmem arguments visible to IPDL after these changes, but still is used as a manager for Shmems included in some messages. Differential Revision: https://phabricator.services.mozilla.com/D151855
38595fc61412a6b8d49516d5cbc91a346aa112c0: Bug 1771712 - Make it more likely for child processes to be killed under OOM conditions compared to the parent process on Linux r=jld
Gabriele Svelto <gsvelto@mozilla.com> - Tue, 09 Aug 2022 16:05:48 +0000 - rev 626566
Push 40106 by smolnar@mozilla.com at Wed, 10 Aug 2022 04:30:40 +0000
Bug 1771712 - Make it more likely for child processes to be killed under OOM conditions compared to the parent process on Linux r=jld This patch implements hal::SetProcessPriority() on Linux and leverages it to make it more likely that the parent process and foreground tab survive an OOM situation, letting Linux' OOM killer reap preallocated processes and background tabs first when reclaiming memory. This is achieved by setting the `oom_score_adj` values of said processes such that they will be killed in this order: * Preallocated processes will be the first to go, they don't contain user data and are not visible, so they're a good candidate to free up memory * Background tabs will be killed next, we don't generate crash reports for thoes nor do we inform the user, we just reload the tab, so in most cases one being killed will only be a small annoyance * Background tabs playing video come next, but only if they're not also playing or recording audio * Finally foreground tabs will be killed as a last resort, background tabs playing audio or with an active WebRTC session are also considered to be in the foreground as the user will immediately notice if they crash Note that this patch only implements the low-level plumbing. The process priority manager has not been enabled on Linux yet so that needs to happen before this actually works. Differential Revision: https://phabricator.services.mozilla.com/D153466
8557305bcd46f05422b63c28e94835066e4ff1a0: Bug 1781129 - Part 4: Fix issues caused by Shmem arguments no longer being visible to ipdl, r=ipc-reviewers,jld
Nika Layzell <nika@thelayzells.com> - Tue, 02 Aug 2022 18:09:41 +0000 - rev 625784
Push 40074 by ccozmuta@mozilla.com at Wed, 03 Aug 2022 03:42:48 +0000
Bug 1781129 - Part 4: Fix issues caused by Shmem arguments no longer being visible to ipdl, r=ipc-reviewers,jld Due to Shmem implementing ParamTraits, it is possible for a Shmem argument to not be visible to the IPDL compiler as it is only serialized within an opaque type included with `using`. If that happens, it would cause the construction of the Shmem to fail on the other side, in a hard to diagnose manner. This changes the logic to always allow any actor to manage shmems, to make it more in line with the `AllocShmem` method being directly declared on IProtocol. This specifically caused issues after this patch stack with PContent, which no longer has any shmem arguments visible to IPDL after these changes, but still is used as a manager for Shmems included in some messages. Differential Revision: https://phabricator.services.mozilla.com/D151855
4a92d58726aa2edbd2130560caacee8c6c2df5a6: Bug 1781129 - Part 4: Fix issues caused by Shmem arguments no longer being visible to ipdl, r=ipc-reviewers,jld
Nika Layzell <nika@thelayzells.com> - Tue, 02 Aug 2022 17:15:42 +0000 - rev 625776
Push 40074 by ccozmuta@mozilla.com at Wed, 03 Aug 2022 03:42:48 +0000
Bug 1781129 - Part 4: Fix issues caused by Shmem arguments no longer being visible to ipdl, r=ipc-reviewers,jld Due to Shmem implementing ParamTraits, it is possible for a Shmem argument to not be visible to the IPDL compiler as it is only serialized within an opaque type included with `using`. If that happens, it would cause the construction of the Shmem to fail on the other side, in a hard to diagnose manner. This changes the logic to always allow any actor to manage shmems, to make it more in line with the `AllocShmem` method being directly declared on IProtocol. This specifically caused issues after this patch stack with PContent, which no longer has any shmem arguments visible to IPDL after these changes, but still is used as a manager for Shmems included in some messages. Differential Revision: https://phabricator.services.mozilla.com/D151855
c6bd9e91eb467312ceb2d0085073f5a346790dcb: Bug 1782337 - Remove unused LineWatcher. r=ipc-reviewers,jld
Chris Peterson <cpeterson@mozilla.com> - Tue, 02 Aug 2022 04:58:07 +0000 - rev 625691
Push 40070 by nfay@mozilla.com at Tue, 02 Aug 2022 09:41:16 +0000
Bug 1782337 - Remove unused LineWatcher. r=ipc-reviewers,jld Differential Revision: https://phabricator.services.mozilla.com/D153304
a8bc03d5f5230381402e1198cd95fa35b1eb92d4: Bug 1772090 - implement about:processes on OpenBSD r=glandium,jld,gerald
George Koehler <gkoehler@openbsd.org> - Thu, 28 Jul 2022 07:14:28 +0000 - rev 625357
Push 40048 by nfay@mozilla.com at Thu, 28 Jul 2022 16:09:13 +0000
Bug 1772090 - implement about:processes on OpenBSD r=glandium,jld,gerald Differential Revision: https://phabricator.services.mozilla.com/D150338
d2b1b72c06f046df4e3c51a34a4eb842c6b5b93f: Bug 1681359 - Part 2: Basic tests for BigBuffer, r=jld
Nika Layzell <nika@thelayzells.com> - Tue, 26 Jul 2022 20:51:25 +0000 - rev 625228
Push 40042 by ctuns@mozilla.com at Wed, 27 Jul 2022 09:37:31 +0000
Bug 1681359 - Part 2: Basic tests for BigBuffer, r=jld Depends on D151851 Differential Revision: https://phabricator.services.mozilla.com/D152703
1e32d22327aed7c26b95e5e9c5f7dab309f01c51: Bug 1681359 - Part 1: Introduce the BigBuffer type to IPC, r=ipc-reviewers,jld
Nika Layzell <nika@thelayzells.com> - Tue, 26 Jul 2022 20:51:25 +0000 - rev 625227
Push 40042 by ctuns@mozilla.com at Wed, 27 Jul 2022 09:37:31 +0000
Bug 1681359 - Part 1: Introduce the BigBuffer type to IPC, r=ipc-reviewers,jld 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
9f3219324df5fff930f1b8a53d48f63f1a6e1201: Bug 1777404 - Extend buildID false-positive mismatch collection r=jld
Alexandre Lissy <lissyx@lissyx.dyndns.org> - Thu, 14 Jul 2022 07:34:42 +0000 - rev 623923
Push 39984 by ccozmuta@mozilla.com at Thu, 14 Jul 2022 21:44:18 +0000
Bug 1777404 - Extend buildID false-positive mismatch collection r=jld Differential Revision: https://phabricator.services.mozilla.com/D151228
353b922a32932c65f68dd38e0c19aca755434a0f: Bug 1769593 - Part 2: Improve reporting of fatal DataPipe (de)serialization errors, r=jld
Nika Layzell <nika@thelayzells.com> - Thu, 26 May 2022 20:16:09 +0000 - rev 619009
Push 39754 by imoraru@mozilla.com at Fri, 27 May 2022 03:39:55 +0000
Bug 1769593 - Part 2: Improve reporting of fatal DataPipe (de)serialization errors, r=jld Depends on D146501 Differential Revision: https://phabricator.services.mozilla.com/D146502
16811ba730303888ea7bdad0dfab92a41a57ba6b: Bug 1769593 - Part 1: Fail when serializing file handles in excess of MAX_DESCRIPTORS_PER_MESSAGE, r=jld
Nika Layzell <nika@thelayzells.com> - Thu, 26 May 2022 20:16:09 +0000 - rev 619008
Push 39754 by imoraru@mozilla.com at Fri, 27 May 2022 03:39:55 +0000
Bug 1769593 - Part 1: Fail when serializing file handles in excess of MAX_DESCRIPTORS_PER_MESSAGE, r=jld Differential Revision: https://phabricator.services.mozilla.com/D146501
bc0432d9dd954ce2ab816e83f26297c79db98eee: Bug 1767514 - Part 3: Retry sending fds if sendmsg fails, r=ipc-reviewers,jld
Nika Layzell <nika@thelayzells.com> - Tue, 24 May 2022 14:41:11 +0000 - rev 618744
Push 39743 by mlaza@mozilla.com at Tue, 24 May 2022 21:44:48 +0000
Bug 1767514 - Part 3: Retry sending fds if sendmsg fails, r=ipc-reviewers,jld 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
f3c916fcf9fe3143c673bcd78e673a303e1f177c: Bug 1767514 - Part 2: Increase the attached handle limit for IPC Messages, r=ipc-reviewers,jld
Nika Layzell <nika@thelayzells.com> - Tue, 24 May 2022 14:41:10 +0000 - rev 618743
Push 39743 by mlaza@mozilla.com at Tue, 24 May 2022 21:44:48 +0000
Bug 1767514 - Part 2: Increase the attached handle limit for IPC Messages, r=ipc-reviewers,jld 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
344ac1cc234f9b462b4af9d250094a0dbbbe922c: Bug 1767514 - Part 1: Decouple the IPC::Message max handle count and the number of FDs supported by IPC::Channel, r=ipc-reviewers,jld
Nika Layzell <nika@thelayzells.com> - Tue, 24 May 2022 14:41:10 +0000 - rev 618742
Push 39743 by mlaza@mozilla.com at Tue, 24 May 2022 21:44:48 +0000
Bug 1767514 - Part 1: Decouple the IPC::Message max handle count and the number of FDs supported by IPC::Channel, r=ipc-reviewers,jld 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
2a8056fbf4a44736d499e48521eca7aa6502b1f8: Bug 1769616 - Error(ENOSYS) for set_mempolicy() on Content and Utility AudioDecoder r=jld
Alexandre Lissy <lissyx+mozillians@lissyx.dyndns.org> - Sat, 21 May 2022 00:01:28 +0000 - rev 618419
Push 39726 by ncsoregi@mozilla.com at Sat, 21 May 2022 09:47:23 +0000
Bug 1769616 - Error(ENOSYS) for set_mempolicy() on Content and Utility AudioDecoder r=jld Differential Revision: https://phabricator.services.mozilla.com/D146833
65c80a440f3fc3c2a711efa251b78a89c7d3a8c5: Bug 1768665 - Extend linux sandbox Utility for PGO on try with PR_GET_PDEATHSIG r=jld
Alexandre Lissy <lissyx+mozillians@lissyx.dyndns.org> - Fri, 13 May 2022 08:10:38 +0000 - rev 617169
Push 39690 by nerli@mozilla.com at Fri, 13 May 2022 16:04:00 +0000
Bug 1768665 - Extend linux sandbox Utility for PGO on try with PR_GET_PDEATHSIG r=jld Differential Revision: https://phabricator.services.mozilla.com/D146200
53ebc3f919ba28cd76e19c9440896d4deab257e2: Bug 1767514 - Part 2: Increase the attached handle limit for IPC Messages, r=ipc-reviewers,jld
Nika Layzell <nika@thelayzells.com> - Fri, 06 May 2022 20:02:37 +0000 - rev 616561
Push 39662 by nbeleuzu@mozilla.com at Sat, 07 May 2022 09:54:14 +0000
Bug 1767514 - Part 2: Increase the attached handle limit for IPC Messages, r=ipc-reviewers,jld 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. Depends on D145391 Differential Revision: https://phabricator.services.mozilla.com/D145392
62befea29e738b6d96fdeae6fcfa16b54859a0fc: Bug 1767514 - Part 1: Decouple the IPC::Message max handle count and the number of FDs supported by IPC::Channel, r=ipc-reviewers,jld
Nika Layzell <nika@thelayzells.com> - Fri, 06 May 2022 20:02:36 +0000 - rev 616560
Push 39662 by nbeleuzu@mozilla.com at Sat, 07 May 2022 09:54:14 +0000
Bug 1767514 - Part 1: Decouple the IPC::Message max handle count and the number of FDs supported by IPC::Channel, r=ipc-reviewers,jld 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
2e872bb9f766b9ff00657a5bf507a5f9c35d87b2: Bug 1766848 - Update libevent to version 2.1.12. r=jld
Ryan VanderMeulen <ryanvm@gmail.com> - Tue, 03 May 2022 01:29:13 +0000 - rev 615878
Push 39642 by ctuns@mozilla.com at Tue, 03 May 2022 09:42:08 +0000
Bug 1766848 - Update libevent to version 2.1.12. r=jld Differential Revision: https://phabricator.services.mozilla.com/D144950
0d23532d6a496bf9b48cdcb4fde4dad209941124: Bug 1757802 - Don't keep alive Shmem shared memory regions on IProtocol, r=ipc-reviewers,jld
Nika Layzell <nika@thelayzells.com> - Mon, 18 Apr 2022 19:26:15 +0000 - rev 614512
Push 39583 by imoraru@mozilla.com at Tue, 19 Apr 2022 03:41:49 +0000
Bug 1757802 - Don't keep alive Shmem shared memory regions on IProtocol, r=ipc-reviewers,jld With this new approach, Shmem instances will now have their handles transferred inline within messages as attachments, rather than being associated with their actors and sent in separate messages. This has a few advantages: * The implementation is much simpler * Releasing all references to a Shmem will automatically destroy it by RAII, rather than leaking the shared memory region until the toplevel actor is destroyed, removing the need for types like RaiiShmem. * This allows re-transmitting Shmem instances to another process, as we don't close the shared memory region handle upon receiving it. But also has a disadvantage that because we keep alive the shared memory region's handle until the shmem is destroyed, so that it can be re-transmitted, we may end up using more FDs or HANDLEs while running. This patch intentionally doesn't change or simplify callsites, removing APIs like RaiiShmem, in order to make it easier to revert if this causes issues on platforms like Linux due to FD exhaustion. If we don't run into increased resource exhaustion problems, we can make these changes in a follow-up. Differential Revision: https://phabricator.services.mozilla.com/D140211
bedcbaada2965499b6fa620c622440c155fab560: Bug 1755316 - Add Utility AudioDecoder Sandbox test r=jld,haik
Alexandre Lissy <lissyx+mozillians@lissyx.dyndns.org> - Thu, 07 Apr 2022 10:04:52 +0000 - rev 613604
Push 39531 by ccozmuta@mozilla.com at Thu, 07 Apr 2022 15:37:22 +0000
Bug 1755316 - Add Utility AudioDecoder Sandbox test r=jld,haik Differential Revision: https://phabricator.services.mozilla.com/D141471
b6a439fe6b0cdbe28a073d77b4b1fb875f042f1d: Bug 1755316 - Perform audio decoding on PUtilityAudioDecoder r=alwu,nika,jld,bobowen,haik
Alexandre Lissy <lissyx+mozillians@lissyx.dyndns.org> - Thu, 07 Apr 2022 10:04:51 +0000 - rev 613602
Push 39531 by ccozmuta@mozilla.com at Thu, 07 Apr 2022 15:37:22 +0000
Bug 1755316 - Perform audio decoding on PUtilityAudioDecoder r=alwu,nika,jld,bobowen,haik Differential Revision: https://phabricator.services.mozilla.com/D139593
c5314d76fe0112550681b8bd274151486a90050b: Bug 1761203 - Add all files in DRI device directories r=jld
Akihiko Odaki <akihiko.odaki@gmail.com> - Wed, 06 Apr 2022 01:31:50 +0000 - rev 613469
Push 39526 by ccozmuta@mozilla.com at Wed, 06 Apr 2022 09:36:46 +0000
Bug 1761203 - Add all files in DRI device directories r=jld Intel Media Driver 2021Q4 Release - 22.1.1 depends on the following files in the PCI device directory: driver, irq, and resource according to: https://github.com/intel/media-driver/blob/intel-media-22.1.1/cmrtlib/linux/hardware/drm_device.h#L548-L654 Listing such files needed by libaries is too fragile againt variations so add all files in the PCI device directory. Differential Revision: https://phabricator.services.mozilla.com/D142054
cc1c314641027743534a927645e769687d2b0a82: Bug 1753424 - Update SandboxTest code with sandboxingKind r=jld
Alexandre Lissy <lissyx+mozillians@lissyx.dyndns.org> - Sat, 26 Mar 2022 19:46:43 +0000 - rev 612262
Push 39477 by ctuns@mozilla.com at Sat, 26 Mar 2022 21:33:56 +0000
Bug 1753424 - Update SandboxTest code with sandboxingKind r=jld Differential Revision: https://phabricator.services.mozilla.com/D140744
cce723862a928e77e5c6683ae64a13fe85539e76: Bug 1753424 - Update SandboxTest code with sandboxingKind r=jld
Alexandre Lissy <lissyx+mozillians@lissyx.dyndns.org> - Sat, 26 Mar 2022 09:53:46 +0000 - rev 612255
Push 39477 by ctuns@mozilla.com at Sat, 26 Mar 2022 21:33:56 +0000
Bug 1753424 - Update SandboxTest code with sandboxingKind r=jld Differential Revision: https://phabricator.services.mozilla.com/D140744
4df499ef46477d6ccb061a7679204392d7f7a785: Bug 1753424 - Update SandboxTest code with sandboxingKind r=jld
Alexandre Lissy <lissyx+mozillians@lissyx.dyndns.org> - Sat, 26 Mar 2022 09:53:46 +0000 - rev 611983
Push 39477 by ctuns@mozilla.com at Sat, 26 Mar 2022 21:33:56 +0000
Bug 1753424 - Update SandboxTest code with sandboxingKind r=jld Differential Revision: https://phabricator.services.mozilla.com/D140744
61ce3e6f240373911f8d1bee23fe60ad427b4011: Bug 1756088 - Expose DRI configuration file in sandbox r=jld
Akihiko Odaki <akihiko.odaki@gmail.com> - Sat, 26 Mar 2022 02:58:31 +0000 - rev 611979
Push 39477 by ctuns@mozilla.com at Sat, 26 Mar 2022 21:33:56 +0000
Bug 1756088 - Expose DRI configuration file in sandbox r=jld Differential Revision: https://phabricator.services.mozilla.com/D139096
184fafcf0523a4706b3f765c3d901ba79b1b74ef: Bug 1756087 - Amend sandbox policy for libdrm r=jld
Akihiko Odaki <akihiko.odaki@gmail.com> - Wed, 23 Mar 2022 02:27:36 +0000 - rev 611562
Push 39460 by nfay@mozilla.com at Wed, 23 Mar 2022 09:49:32 +0000
Bug 1756087 - Amend sandbox policy for libdrm r=jld Before this change, it was assumed that readlink operation might be performed on /sys if the driver is AMD. However, the operation would always be performed by Mesa via libdrm if the device is PCI. In fact, blocking the operation breaks virtio_gpu. The readlink operation is part of invoking realpath("/sys/dev/char/<PCI>/device/subsystem") so the read only permissions for the file and the ancestor directories are added. The permissions for the resolved real directory and its files are already set, but the directory path is modified in libdrm when the device is virtio_gpu. The path modification is also ported to the sandbox policy. Differential Revision: https://phabricator.services.mozilla.com/D139095
13e56cc80e23221db14c0db482a565712cd2d42b: Bug 1707499 - Fix uninitialised member r=jld
Paul Bone <pbone@mozilla.com> - Tue, 15 Mar 2022 03:22:41 +0000 - rev 610597
Push 39420 by nfay@mozilla.com at Tue, 15 Mar 2022 09:13:52 +0000
Bug 1707499 - Fix uninitialised member r=jld Differential Revision: https://phabricator.services.mozilla.com/D113470
296670d89ad68a33c457a97adf51baea8f81d198: Bug 1751948 - Part 5: Ensure we don't release ActorLifecycleProxy while holding MessageChannel's Monitor, r=jld
Nika Layzell <nika@thelayzells.com> - Mon, 28 Feb 2022 21:01:48 +0000 - rev 609188
Push 39352 by nfay@mozilla.com at Tue, 01 Mar 2022 09:40:29 +0000
Bug 1751948 - Part 5: Ensure we don't release ActorLifecycleProxy while holding MessageChannel's Monitor, r=jld Releasing ActorLifecycleProxy can lead to the IToplevelProtocol being destroyed, due to the reference being the last reference. If this happens, we can deadlock due to the MessageChannel embedded in IToplevelProtocol locking mMonitor during its' destructor. This patch moves acquiring the proxy earlier in the method, so that we do not deadlock in this case any longer. Differential Revision: https://phabricator.services.mozilla.com/D137169
6198b0a5e72aadce5ed1f473d6c7e71234662567: Bug 1751948 - Part 5: Ensure we don't release ActorLifecycleProxy while holding MessageChannel's Monitor, r=jld
Nika Layzell <nika@thelayzells.com> - Sat, 19 Feb 2022 00:57:38 +0000 - rev 608235
Push 39311 by ctuns@mozilla.com at Sat, 19 Feb 2022 21:40:49 +0000
Bug 1751948 - Part 5: Ensure we don't release ActorLifecycleProxy while holding MessageChannel's Monitor, r=jld Releasing ActorLifecycleProxy can lead to the IToplevelProtocol being destroyed, due to the reference being the last reference. If this happens, we can deadlock due to the MessageChannel embedded in IToplevelProtocol locking mMonitor during its' destructor. This patch moves acquiring the proxy earlier in the method, so that we do not deadlock in this case any longer. Differential Revision: https://phabricator.services.mozilla.com/D137169
432ac2ec3202a3d7fde2c6cef265de79404aac31: Bug 1754578 - Make the pthread_create() interposer work on glibc 2.34+ r=jld
Gabriele Svelto <gsvelto@mozilla.com> - Thu, 10 Feb 2022 20:18:57 +0000 - rev 607406
Push 39270 by smolnar@mozilla.com at Fri, 11 Feb 2022 04:08:54 +0000
Bug 1754578 - Make the pthread_create() interposer work on glibc 2.34+ r=jld Differential Revision: https://phabricator.services.mozilla.com/D138355
558688086ef651df8e829d1d2a133467c80c33b4: Bug 1695556 p3: Add file tests for content process sandbox. r=handyman,ipc-reviewers,jld
Bob Owen <bobowencode@gmail.com> - Thu, 10 Feb 2022 16:56:02 +0000 - rev 607382
Push 39270 by smolnar@mozilla.com at Fri, 11 Feb 2022 04:08:54 +0000
Bug 1695556 p3: Add file tests for content process sandbox. r=handyman,ipc-reviewers,jld Depends on D135693 Differential Revision: https://phabricator.services.mozilla.com/D135694
533c3879ff8515c47fabdc7e6bb14fbf57205dfa: Bug 1738734 - Directly pass around handles rather than using TransportDescriptor, r=jld,media-playback-reviewers,alwu
Nika Layzell <nika@thelayzells.com> - Tue, 08 Feb 2022 23:53:45 +0000 - rev 607203
Push 39262 by abutkovits@mozilla.com at Wed, 09 Feb 2022 09:56:40 +0000
Bug 1738734 - Directly pass around handles rather than using TransportDescriptor, r=jld,media-playback-reviewers,alwu This simplifies the logic around descriptors significantly, which is especially useful considering how few places use the type. There is a small change required on Windows to create the NamedPipe directly and transfer around each end's handle, rather than connecting between processes after the fact. A named pipe has to be used, rather than an anonymous pipe, as bidirectional communication is required. Differential Revision: https://phabricator.services.mozilla.com/D130381
7bc4c7f965063a30e1a334976b791ef53a1063bb: Bug 1752566 - Fix warnings in the stack overflow test crasher r=jld
Gabriele Svelto <gsvelto@mozilla.com> - Fri, 04 Feb 2022 08:29:04 +0000 - rev 606480
Push 39243 by apavel@mozilla.com at Fri, 04 Feb 2022 21:41:57 +0000
Bug 1752566 - Fix warnings in the stack overflow test crasher r=jld Differential Revision: https://phabricator.services.mozilla.com/D137329
ba66242256351dcfd045aade16d150dc7e42a2e4: Bug 1738734 - Directly pass around handles rather than using TransportDescriptor, r=jld,media-playback-reviewers,alwu
Nika Layzell <nika@thelayzells.com> - Mon, 31 Jan 2022 22:26:05 +0000 - rev 606064
Push 39223 by nfay@mozilla.com at Tue, 01 Feb 2022 09:39:42 +0000
Bug 1738734 - Directly pass around handles rather than using TransportDescriptor, r=jld,media-playback-reviewers,alwu This simplifies the logic around descriptors significantly, which is especially useful considering how few places use the type. There is a small change required on Windows to create the NamedPipe directly and transfer around each end's handle, rather than connecting between processes after the fact. A named pipe has to be used, rather than an anonymous pipe, as bidirectional communication is required. Differential Revision: https://phabricator.services.mozilla.com/D130381
cf94448b84dc24e8e9ea70c5379a492a3927a71b: Bug 1678152 - Catch all stack overflows on Linux r=jld
Gabriele Svelto <gsvelto@mozilla.com> - Fri, 28 Jan 2022 07:29:26 +0000 - rev 605808
Push 39208 by ctuns@mozilla.com at Fri, 28 Jan 2022 15:50:52 +0000
Bug 1678152 - Catch all stack overflows on Linux r=jld This patch adds a library that contains an interposer function for pthread_create(). The interposer will setup an alternate signal stack to handle crashes - thus enabling us to catch stack overflows - and then call the real pthread_create() function. Since the interposer needs to appear in the linker's search order before libpthread we manually link it into firefox, plugin-container and xpcshell's executables ASAP. Differential Revision: https://phabricator.services.mozilla.com/D132736
46640f068ae46789592104c50a3af1786649e38a: Bug 1678152 - Catch all stack overflows on Linux r=jld
Gabriele Svelto <gsvelto@mozilla.com> - Tue, 25 Jan 2022 16:41:21 +0000 - rev 605464
Push 39195 by nerli@mozilla.com at Wed, 26 Jan 2022 03:47:45 +0000
Bug 1678152 - Catch all stack overflows on Linux r=jld Differential Revision: https://phabricator.services.mozilla.com/D132736
6f3c07119e594be0e16205b091affcea2c22661f: Bug 1749606 - Allow clock_gettime() for same-process r=jld,gerald
Alexandre Lissy <lissyx+mozillians@lissyx.dyndns.org> - Fri, 21 Jan 2022 23:03:26 +0000 - rev 605207
Push 39179 by mlaza@mozilla.com at Sat, 22 Jan 2022 09:51:22 +0000
Bug 1749606 - Allow clock_gettime() for same-process r=jld,gerald This is used by the new code from the profiler that is able to detect unregistered threads. Blocking it will make child-process hit sandbox violation. Differential Revision: https://phabricator.services.mozilla.com/D135648
3538e74d9d8e4b9ae29af5b72b53f2fb1f185dfb: Bug 1415595 - Remove unnecessary mode when opening ASHMEM_NAME_DEF. r=jld
Mike Hommey <mh+mozilla@glandium.org> - Wed, 15 Dec 2021 23:56:33 +0000 - rev 602213
Push 39069 by apavel@mozilla.com at Thu, 16 Dec 2021 09:41:42 +0000
Bug 1415595 - Remove unnecessary mode when opening ASHMEM_NAME_DEF. r=jld Differential Revision: https://phabricator.services.mozilla.com/D133857
3cf2b111807aec49c54bc958771177d33925aace: Bug 1678152 - Catch all stack overflows on Linux r=jld
Gabriele Svelto <gsvelto@mozilla.com> - Tue, 14 Dec 2021 21:17:12 +0000 - rev 602056
Push 39066 by ctuns@mozilla.com at Wed, 15 Dec 2021 09:11:58 +0000
Bug 1678152 - Catch all stack overflows on Linux r=jld Differential Revision: https://phabricator.services.mozilla.com/D132736
8a60ff4ab1a75f773d314a3f39ad6f2bd99b0570: Bug 1743014 - Handle unlink("") calls internally. r=jld
elfarto <elfarto@elfarto.com> - Mon, 13 Dec 2021 18:02:47 +0000 - rev 601886
Push 39062 by apavel@mozilla.com at Tue, 14 Dec 2021 04:25:24 +0000
Bug 1743014 - Handle unlink("") calls internally. r=jld unlink("") will always return -ENOENT if passed to the kernel, so just do the same thing here. We need this as empty paths can't be whitelisted. Differential Revision: https://phabricator.services.mozilla.com/D132174
28bdf3329f49dea66be1cbf305c87e784dee801f: Bug 1743225 - Return an error from AutoMemMap::initWithHandle() if MapViewOfFile() returns null. r=jld
Chris Peterson <cpeterson@mozilla.com> - Fri, 03 Dec 2021 04:04:15 +0000 - rev 600991
Push 39033 by ccozmuta@mozilla.com at Fri, 03 Dec 2021 21:38:02 +0000
Bug 1743225 - Return an error from AutoMemMap::initWithHandle() if MapViewOfFile() returns null. r=jld Differential Revision: https://phabricator.services.mozilla.com/D132323
0d6116a0dfe38433d2082931b79f0fbf88d06345: Bug 1697429 - Handle crash with the old way if the fork server is prefed out. r=jld
Thinker Li <thinker.li@gmail.com> - Thu, 14 Oct 2021 03:13:00 +0000 - rev 595747
Push 38876 by ctuns@mozilla.com at Thu, 14 Oct 2021 09:34:15 +0000
Bug 1697429 - Handle crash with the old way if the fork server is prefed out. r=jld Handle crash with the old way if the fork server is prefed out, and waitpid() for all available stat changes of children processes in the forkserver. Differential Revision: https://phabricator.services.mozilla.com/D110507
88ae7d2397ebcb0149ca014e14a75766b35457c3: Bug 1697429 - Handle crash with the old way if the fork server is prefed out. r=jld
Thinker Li <thinker.li@gmail.com> - Thu, 07 Oct 2021 23:42:22 +0000 - rev 595152
Push 38858 by malexandru@mozilla.com at Fri, 08 Oct 2021 03:38:35 +0000
Bug 1697429 - Handle crash with the old way if the fork server is prefed out. r=jld Handle crash with the old way if the fork server is prefed out, and waitpid() for all available stat changes of children processes in the forkserver. Differential Revision: https://phabricator.services.mozilla.com/D110507
f714ed6baf74cd5b193f10668b9dd12487252170: Bug 1730045 - Update expiration of buildID mismatch probe r=jld
Alexandre Lissy <lissyx+mozillians@lissyx.dyndns.org> - Mon, 20 Sep 2021 06:56:11 +0000 - rev 592437
Push 38804 by mlaza@mozilla.com at Mon, 20 Sep 2021 09:48:11 +0000
Bug 1730045 - Update expiration of buildID mismatch probe r=jld Differential Revision: https://phabricator.services.mozilla.com/D125790
64cddf423637d6816e42744657ffbe3eb9668833: Bug 1642516 - In the EHABI stack unwinder, make sure to report proper instruction addresses by masking of the bit that indicates ARM or Thumb mode. r=jld
Markus Stange <mstange.moz@gmail.com> - Sat, 07 Aug 2021 00:34:41 +0000 - rev 588128
Push 38683 by dluca@mozilla.com at Sat, 07 Aug 2021 21:48:22 +0000
Bug 1642516 - In the EHABI stack unwinder, make sure to report proper instruction addresses by masking of the bit that indicates ARM or Thumb mode. r=jld This will make it so that, for return addresses, symbolication can look up the address "returnAddress - 1" and get the correct line number (and inline stack) for the call instruction. Without the masking, returnAddress - 1 might still fall into the instruction *after* the call instruction, giving wrong line numbers / inline stacks. Differential Revision: https://phabricator.services.mozilla.com/D121930