Summary: | linprocfs: Chromium requires /proc/self/task implementation | ||
---|---|---|---|
Product: | Base System | Reporter: | Alex S <iwtcex> |
Component: | kern | Assignee: | 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
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 [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 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. 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 Log: 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 Changes: head/sys/compat/linprocfs/linprocfs.c 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 Log: 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 Changes: _U stable/12/ stable/12/sys/compat/linprocfs/linprocfs.c |