Otherwise you'll get a nice crash at the corresponding assertion checks, see https://cs.chromium.org/chromium/src/sandbox/linux/services/thread_helpers.cc?l=41&rcl=90c6c958243e775074d81e19c204f196d8e76990 and https://cs.chromium.org/chromium/src/sandbox/linux/services/thread_helpers.cc?l=44&rcl=90c6c958243e775074d81e19c204f196d8e76990. (Actually, not so nice crash, for some reason most Chromium assertion checks do not produce any error messages whatsoever.)
I've glanced at this, and it seems somewhat non-trivial. The problem here is that pseudofs(5), which is what linprocfs(5) uses underneath, does not support nested PFS_PROCDEP directories; they trigger a KASSERT, and if you remove that, you'll get a nested lock attempt.
It seems these routines are used only to implement other assertion/CHECKs (most uses are in thread_helpers_unittests.cc and the only external uses seem to be in credentials.cc and scoped_process.cc, both inside CHECK()), and since we mostly build Chrome in Release mode, we don't hit these.
A more straightforward fix for debug mode is to patch Chrome rather than procfs.
(In reply to Conrad Meyer from comment #2)
All assertions are enabled in release builds.
I should have provided a bit more context. This issue is about Linux executables running on Linuxulator. My personal use case is the Linux Steam client, but I expect this to be a bit more broadly useful. Say, for Widevine or whatever proprietary crap.
Indeed, those checks are not particularly important. To get around them I'm using an LD_PRELOADable hack  with a couple of stubs and CEF (Chromium Embedded Framework) doesn't seem to care. The hack was tested with debug CEF builds , Steam's embedded browser and one Feral Interactive's game launcher ("conveniently" built into a single executable with the game).
: sample application @ http://opensource.spotify.com/cefbuilds/index.html
Wtf with this bug tracker always sending an email to some guy at @intel? Are we deliberately spamming them?
(In reply to Alex S from comment #3)
> whatever proprietary crap
A case in point: https://lists.freebsd.org/pipermail/freebsd-emulation/2020-March/017800.html.