Bug 240991

Summary: linprocfs: Chromium requires /proc/self/task implementation
Product: Base System Reporter: Alex S <iwtcex>
Component: kernAssignee: Edward Tomasz Napierala <trasz>
Status: Closed FIXED    
Severity: Affects Only Me CC: trasz
Priority: --- Flags: koobs: mfc-stable12+
Version: 12.0-RELEASE   
Hardware: Any   
OS: Any   
Bug Depends on:    
Bug Blocks: 247219    

Description Alex S 2019-10-02 01:01:18 UTC
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.)
Comment 1 Edward Tomasz Napierala freebsd_committer 2020-01-13 12:24:04 UTC
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.
Comment 2 Conrad Meyer freebsd_committer 2020-03-23 23:37:24 UTC
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.
Comment 3 Alex S 2020-03-24 07:21:38 UTC
(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 [1] with a couple of stubs and CEF (Chromium Embedded Framework) doesn't seem to care. The hack was tested with debug CEF builds [2], Steam's embedded browser and one Feral Interactive's game launcher ("conveniently" built into a single executable with the game).

[1]: https://github.com/shkhln/linuxulator-steam-utils/blob/3239b35d78d25cf821fd906fddd25ff34ecc84a2/src/webfix.c#L67
[2]: sample application @ http://opensource.spotify.com/cefbuilds/index.html
Comment 4 Alex S 2020-03-24 07:26:15 UTC
Wtf with this bug tracker always sending an email to some guy at @intel? Are we deliberately spamming them?
Comment 5 Alex S 2020-04-03 01:24:07 UTC
(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.
Comment 6 commit-hook freebsd_committer 2020-06-30 16:25:08 UTC
A commit references this bug:

Author: trasz
Date: Tue Jun 30 16:24:28 UTC 2020
New revision: 362806
URL: https://svnweb.freebsd.org/changeset/base/362806

  Make linprocfs(5) create the /proc/<PID>/task/ directores.
  This is to silence down some Chromium assertions.

  PR:		kern/240991
  Analyzed by:	Alex S <iwtcex@gmail.com>
  MFC after:	2 weeks
  Sponsored by:	The FreeBSD Foundation
  Differential Revision:	https://reviews.freebsd.org/D25256

Comment 7 commit-hook freebsd_committer 2020-08-13 18:54:59 UTC
A commit references this bug:

Author: trasz
Date: Thu Aug 13 18:54:02 UTC 2020
New revision: 364209
URL: https://svnweb.freebsd.org/changeset/base/364209

  MFC r362806:

  Make linprocfs(5) create the /proc/<PID>/task/ directores.
  This is to silence down some Chromium assertions.

  PR:		kern/240991
  Analyzed by:	Alex S <iwtcex@gmail.com>
  Sponsored by:	The FreeBSD Foundation

_U  stable/12/