I think it's coming from base/process/process_metrics_posix.cc:

size_t GetMaxFds() {
  rlim_t max_fds;
  struct rlimit nofile;
  if (getrlimit(RLIMIT_NOFILE, &nofile)) {
    // getrlimit failed. Take a best guess.
    max_fds = kSystemDefaultMaxFds;
    RAW_LOG(ERROR, "getrlimit(RLIMIT_NOFILE) failed");
  } else {
    max_fds = nofile.rlim_cur;
  }

  if (max_fds > INT_MAX)
    max_fds = INT_MAX;

  return static_cast<size_t>(max_fds);
}

That code hasn't changed since 2013, so I assume there's something different on the platform where it's running.

The getrlimit syscall is probably blocked in some processes. If I disable seccomp filter in chrome_dev.conf with "--disable-seccomp-filter-sandbox" the errors are gone. The kSystemDefaultMaxFds is 8192 on OS_LINUX which is more than sufficient in most cases so I believe we're fine: https://cs.chromium.org/chromium/src/base/process/process_metrics_posix.cc?rcl=0&l=29

I do not see these messages on R54-8561.0.0, or R54-8743.83.0 so something has changed.

I do see these messages on peach_pi @ R55-8872.42.0, so it is not elm specific.

I saw same issue, a lot of getrlimit(RLIMIT_NOFILE) failed
in kevin-tpm2.
Chrome Version: 56.0.2897.0
Chrome OS Version: 8921.0.0
Chrome OS Platform: kevin-tpm2

I bisected the issue to the range R55-8790.0.0 - R55-8791.0.0.

There are not a lot of changes:

src/platform2
044603c8	384011	56550	Fri Sep 09 21:05:13 2016	dtor@chromium.org	init: cgroups.conf - prepare cpusets for Chrome

src/third_party/adhd
8041030f	366964		Thu Aug 04 03:02:39 2016	muirj@google.com	CRAS: Rename PeriodFrames to DmaPeriodMicrosecs.
6babffc0	366962		Wed Aug 03 03:55:58 2016	muirj@google.com	CRAS: Add UCM flag to enable use of ALSA htimestamp.
fa4cd976	366961		Sun Jul 31 21:57:44 2016	muirj@google.com	CRAS: Use the hardware timestamp with available/used frames.

src/third_party/chromiumos-overlay
8b348f8d	383881		Sat Sep 10 02:43:01 2016	dnojiri@chromium.org	chromeos-bmpblk: Ignore missing output files

src/third_party/kernel/v3.18
be11b67b	380438	56410	Fri Sep 02 02:15:44 2016	kkunduru@chromium.org	CHROMIUM: net: export nf_ct_tcp_no_window_check to support SFE
0ed4cd18	380430	56410	Fri Sep 02 18:16:47 2016	kkunduru@chromium.org	CHROMIUM: drivers: sfe: Add flag to enable/disable acceleration

There is a Chrome bump, though:
R55-8790.0.0 - 55.0.2852.0
R55-8791.0.0 - 55.0.2857.0

Definitely a Chrome regression.  
R55-8791.0.0 + 55.0.2852.0 is ok.
Bisecting between 55.0.2852.0 & 55.0.2857.0.
 

So hacking with process_metrics_posix.cc gives me this:

"""
getrlimit(RLIMIT_NOFILE) failed: pid=1 name=CrRendererMain type=renderer
"""

The getrlimit() call was blocked on the main renderer process. As first glance the default bpf policy for renderer allows getrlimit:

https://cs.chromium.org/chromium/src/content/common/sandbox_linux/bpf_renderer_policy_linux.cc?rcl=1478435172&l=74

After some digging I realized that the actual syscall that was blocked is prlimit(), as glibc uses prlimit() when it's available to achieve the same behavior as getrlimit() on linux systems:

https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/getrlimit64.c;h=d055a7f83923aabb696456b3ac3e6d25dbb8a77f;hb=HEAD

The error goes away after I hacked the renderer bpf policy to allow __NR_prlimit64. The code that denies prlimit64 was there since Aug. 2014, so I don't know why this error has recently shown up. Probably some modification to the logging pipeline surfaced this error?

git bisect points to:

aa5c49175702f57438c939a7e4796ff19de4b681 is the first bad commit
commit aa5c49175702f57438c939a7e4796ff19de4b681
Author: danakj <danakj@chromium.org>
Date:   Fri Sep 9 17:28:23 2016 -0700

    cc: Remove SetMemoryPolicy from OutputSurface and Display.
    
    This method is plumbed through the Display but nothing ever actually
    goes there. The only usage of this is:
    1) WebView changes the policy based on SyncCompositorMsg_SetMemoryPolicy
    but it does so from SynchronousCompositorOutputSurface by calling the
    OutputSurfaceClient (LayerTreeHostImpl) directly.
    2) CompositorOutputSurface sets a limit when using software compositing.
    
    Instead of 2, pass both gpu and software limits in the LayerTreeSettings,
    and have LayerTreeHostImpl use the software limits directly when given
    a software output surface. And remove the plumbing through Display and
    replace it with a NOTREACHED.
    
    This means we don't have to support the method at all on the
    "OutputSurfaceClient" that Display uses, only the one that
    LayerTreeHostImpl uses.
    
    Left a comment on OutputSurfaceClient::SetMemoryPolicy() that it is
    only used by WebView now. crbug.com/499004 suggests that the WebView
    usage could also be replaced with something else. WebView seems to
    only be changing the bytes part of the limit, so probably the method
    only needs to take that, and I feel like the implementation in
    LayerTreeHostImpl could probably be cleaned up some more yet also.
    
    R=enne
    TBR=wez
    BUG=499004, 606056 
    CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
    
    Review-Url: https://codereview.chromium.org/2321883002
    Cr-Commit-Position: refs/heads/master@{#417778}

Previously, there was no explicit "software" memory policy.
Rather, the "no-gpu-context" memory policy would only be set if there was no "context provider" during CompositorOutputSurface::BindToClient().

[content/renderer/gpu/compositor_output_surface.cc]:

-   if (!context_provider()) {
-     // Without a GPU context, the memory policy otherwise wouldn't be set.
-    client->SetMemoryPolicy(cc::ManagedMemoryPolicy(
-        128 * 1024 * 1024,
-        gpu::MemoryAllocation::CUTOFF_ALLOW_NICE_TO_HAVE,
-        base::SharedMemory::GetHandleLimit() / 3));
-   }

The patch in #10, however, now always creates an explicit "software" memory policy during RenderWidgetCompositor::GenerateLayerTreeSettings(), which does:

[content/renderer/gpu/render_widget_compositor.cc]:

+  settings.software_memory_policy.num_resources_limit =
+      base::SharedMemory::GetHandleLimit() / 3;

It is this new unconditional call to "GetHandleLimit()" (ie, even when using a gpu context), that generates the error messages.

rickyz, jorgelo,

One solution here is to enable Chrome to call prlimit64.
Chrome already allows getrlimit, and getrlimit is implemented using prlimit() on Linux glibc for the reasons outlined below.

WDYT?

http://man7.org/linux/man-pages/man2/getrlimit.2.html

   prlimit()
       The Linux-specific prlimit() system call combines and extends the
       functionality of setrlimit() and getrlimit().  It can be used to both
       set and get the resource limits of an arbitrary process.

       The resource argument has the same meaning as for setrlimit() and
       getrlimit().

       If the new_limit argument is a not NULL, then the rlimit structure to
       which it points is used to set new values for the soft and hard
       limits for resource.  If the old_limit argument is a not NULL, then a
       successful call to prlimit() places the previous soft and hard limits
       for resource in the rlimit structure pointed to by old_limit.

       The pid argument specifies the ID of the process on which the call is
       to operate.  If pid is 0, then the call applies to the calling
       process.  To set or get the resources of a process other than itself,
       the caller must have the CAP_SYS_RESOURCE capability in the user
       namespace of the process whose resource limits are being changed, or
       the real, effective, and saved set user IDs of the target process
       must match the real user ID of the caller and the real, effective,
       and saved set group IDs of the target process must match the real
       group ID of the caller.

   C library/ kernel ABI differences
       Since version 2.13, the glibc getrlimit() and setrlimit() wrapper
       functions no longer invoke the corresponding system calls, but
       instead employ prlimit(), for the reasons described in BUGS.

       The name of the glibc wrapper function is prlimit(); the underlying
       system call is prlimit64().


   Representation of "large" resource limit values on 32-bit platforms
       The glibc getrlimit() and setrlimit() wrapper functions use a 64-bit
       rlim_t data type, even on 32-bit platforms.  However, the rlim_t data
       type used in the getrlimit() and setrlimit() system calls is a
       (32-bit) unsigned long.  Furthermore, in Linux versions before
       2.6.36, the kernel represents resource limits on 32-bit platforms as
       unsigned long.  However, a 32-bit data type is not wide enough.  The
       most pertinent limit here is RLIMIT_FSIZE, which specifies the
       maximum size to which a file can grow: to be useful, this limit must
       be represented using a type that is as wide as the type used to
       represent file offsets—that is, as wide as a 64-bit off_t (assuming a
       program compiled with _FILE_OFFSET_BITS=64).

       To work around this kernel limitation, if a program tried to set a
       resource limit to a value larger than can be represented in a 32-bit
       unsigned long, then the glibc setrlimit() wrapper function silently
       converted the limit value to RLIM_INFINITY.  In other words, the
       requested resource limit setting was silently ignored.

       This problem was addressed in Linux 2.6.36 with two principal
       changes:

       *  the addition of a new kernel representation of resource limits
          that uses 64 bits, even on 32-bit platforms;

       *  the addition of the prlimit() system call, which employs 64-bit
          values for its resource limit arguments.

       Since version 2.13, glibc works around the limitations of the
       getrlimit() and setrlimit() system calls by implementing setrlimit()
       and getrlimit() as wrapper functions that call prlimit().

Or... at least allow prlimit64() on pid 0.
This is in fact the policy already used in components/nacl/loader/sandbox_linux/nacl_bpf_sandbox_linux.cc, as implemented by:
   sandbox::RestrictPrlimit64

See: https://codereview.chromium.org/2484393004

Can we allow only on pid 0 and |new_limit == NULL|? That way we can guarantee limits are not changed, and that prlimit can only "behave" like getrlimit.

i see no problem with allowing prlimit/prlimit64 when new_limit==NULL.  i'm not sure we need to check pid, but if we want to be paranoid, requiring pid==0 should be fine to start with.

@#14 - any idea how to implement that?  The BPF? code in RestrictPrlimit64 looks a little obscure.


BTW - this is still assigned to danakj, because I am hoping someone will take a look at removing all of the unnecessary getrlimit calls introduced by the patch in #10.

sorry, i have no experience with the sandbox or bpf code on the chromium side :/

https://codereview.chromium.org/2484393004/ is now updated to allow prlimit64 when new_limit==NULL

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/517401168417632e8c0ab54d4d99d39f2c1eaa47

commit 517401168417632e8c0ab54d4d99d39f2c1eaa47
Author: Daniel Kurtz <djkurtz@chromium.org>
Date: Tue Nov 22 10:41:51 2016

CHROMIUM: config: Disable CONFIG_SECURITY_SELINUX_DEVELOP

Disable by default, the development support option of NSA SELinux.
This option allows starting the kernel in permissive mode (log everything,
deny nothing), if enforcing=1 was not specify on the kernel command line.

It also allows interactively toggling the kernel between enforcing mode
and permissive mode (if permitted by the policy) via /selinux/enforce
(aka "setenforce Permissive").

In fact, this CONFIG option is already set via the cros-kernel2.eclass,
so there is no need to enable it here in base.config.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

BUG= chromium:662450 
TEST=USE="-android_test" emerge-${B} -pvq chromeos-kernel-3_18
 Check: /build/${B}/var/cache/portage/sys-kernel/chromeos-kernel-3_18/.config
 =>
  # CONFIG_SECURITY_SELINUX_DEVELOP is not set

Change-Id: Id5db65d1beb7c2d30d7b4377fad419090392390c
Reviewed-on: https://chromium-review.googlesource.com/412625
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>

[modify] https://crrev.com/517401168417632e8c0ab54d4d99d39f2c1eaa47/chromeos/config/base.config

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/602ea28e42eac46af59ba2109a334b059d44dc3b

commit 602ea28e42eac46af59ba2109a334b059d44dc3b
Author: Daniel Kurtz <djkurtz@chromium.org>
Date: Tue Nov 22 10:47:24 2016

cros-kernel2: Move CONFIG_SECURITY_SELINUX_DEVELOP to its own USE flag

CONFIG_SECURITY_SELINUX_DEVELOP allows changing SELinux enforcing mode at
runtime to "Permissive".  This is a useful developer feature for testing
SELinux policies, but is not something that need be set on shipping
images, so disable it by default.

If a SELinux policy developer wishes to experiment with SELinux policies,
they can easily rebuilding their own kernel with USE="selinux_develop".

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

BUG= chromium:662450 
TEST=emerge-${B} chromeos-kernel-3_18 && update_kernel.sh
TEST=On DUT:
  getenforce
  => Enforcing
  setenforce Permissive
  => setenforce:  setenforce() failed
TEST=USE="selinux_develop" emerge-${B} chromeos-kernel-3_18 && update_kernel.sh
TEST=On DUT:
  getenforce
  => Enforcing
  setenforce Permissive
  getenforce
  => Permissive

Change-Id: Ib82efb2d38309152cf1b3ba6dfd282d518e6c228
Reviewed-on: https://chromium-review.googlesource.com/413167
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Jorge Lucangeli Obes <jorgelo@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>

[modify] https://crrev.com/602ea28e42eac46af59ba2109a334b059d44dc3b/eclass/cros-kernel2.eclass

Repurposing this issue for just the rlimit messages.

I've created  issue 668409  to track reverting / removing the new getrlimit calls in the gpu policy case.

(please ignore the patches in #20 & #21.  They are actually for  issue 653575 )

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5ce3b357d4cb9906b57f5758ef271cb69dbb664b

commit 5ce3b357d4cb9906b57f5758ef271cb69dbb664b
Author: djkurtz <djkurtz@chromium.org>
Date: Tue Nov 29 03:38:53 2016

From http://man7.org/linux/man-pages/man2/getrlimit.2.html:

The Linux-specific prlimit() system call combines and extends the
functionality of setrlimit() and getrlimit().  It can be used to both
set and get the resource limits of an arbitrary process.

Since version 2.13, the glibc getrlimit() and setrlimit() wrapper
functions no longer invoke the corresponding system calls, but
instead employ prlimit(), for the reasons described in BUGS.

If new_limit is not NULL, then the rlimit structure to which it points is
used to set new values.  If it is NULL, then prlimit() acts as getrlimit().

So, allow prlimit() with new_limit=NULL, and pid is the current process
(or 0), so the glib implementation of getrlimit can succeed.

BUG= chromium:662450 
TEST=boot on ChromeOS w/ sandbox enabled
 No messages like:
   getrlimit(RLIMIT_NOFILE) failed

R=rickyz,jcliang,vapier

Review-Url: https://codereview.chromium.org/2484393004
Cr-Commit-Position: refs/heads/master@{#434872}

[modify] https://crrev.com/5ce3b357d4cb9906b57f5758ef271cb69dbb664b/content/common/sandbox_linux/bpf_renderer_policy_linux.cc
[modify] https://crrev.com/5ce3b357d4cb9906b57f5758ef271cb69dbb664b/sandbox/linux/seccomp-bpf-helpers/syscall_parameters_restrictions.cc
[modify] https://crrev.com/5ce3b357d4cb9906b57f5758ef271cb69dbb664b/sandbox/linux/seccomp-bpf-helpers/syscall_parameters_restrictions.h

For R56: https://codereview.chromium.org/2536103002

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/085095e8e9dd05aecc5ebe84060a9fd6a5aea5a6

commit 085095e8e9dd05aecc5ebe84060a9fd6a5aea5a6
Author: Daniel Kurtz <djkurtz@chromium.org>
Date: Tue Nov 22 10:47:24 2016

cros-kernel2: Move CONFIG_SECURITY_SELINUX_DEVELOP to its own USE flag

CONFIG_SECURITY_SELINUX_DEVELOP allows changing SELinux enforcing mode at
runtime to "Permissive".  This is a useful developer feature for testing
SELinux policies, but is not something that need be set on shipping
images, so disable it by default.

If a SELinux policy developer wishes to experiment with SELinux policies,
they can easily rebuilding their own kernel with USE="selinux_develop".

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

BUG= chromium:662450 
TEST=emerge-${B} chromeos-kernel-3_18 && update_kernel.sh
TEST=On DUT:
  getenforce
  => Enforcing
  setenforce Permissive
  => setenforce:  setenforce() failed
TEST=USE="selinux_develop" emerge-${B} chromeos-kernel-3_18 && update_kernel.sh
TEST=On DUT:
  getenforce
  => Enforcing
  setenforce Permissive
  getenforce
  => Permissive

Change-Id: Ib82efb2d38309152cf1b3ba6dfd282d518e6c228
Previous-Reviewed-on: https://chromium-review.googlesource.com/413167
(cherry picked from commit 86c518b6efb87247e1cdc3ef0364b0177e392957)
Reviewed-on: https://chromium-review.googlesource.com/414714
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Commit-Queue: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Trybot-Ready: Daniel Kurtz <djkurtz@chromium.org>

[modify] https://crrev.com/085095e8e9dd05aecc5ebe84060a9fd6a5aea5a6/eclass/cros-kernel2.eclass

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/12f7cc4a68a2d85c070d86397da3e4587d228e13

commit 12f7cc4a68a2d85c070d86397da3e4587d228e13
Author: Daniel Kurtz <djkurtz@chromium.org>
Date: Tue Nov 22 10:41:51 2016

CHROMIUM: config: Disable CONFIG_SECURITY_SELINUX_DEVELOP

Disable by default, the development support option of NSA SELinux.
This option allows starting the kernel in permissive mode (log everything,
deny nothing), if enforcing=1 was not specify on the kernel command line.

It also allows interactively toggling the kernel between enforcing mode
and permissive mode (if permitted by the policy) via /selinux/enforce
(aka "setenforce Permissive").

In fact, this CONFIG option is already set via the cros-kernel2.eclass,
so there is no need to enable it here in base.config.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

BUG= chromium:662450 
TEST=USE="-android_test" emerge-${B} -pvq chromeos-kernel-3_18
 Check: /build/${B}/var/cache/portage/sys-kernel/chromeos-kernel-3_18/.config
 =>
  # CONFIG_SECURITY_SELINUX_DEVELOP is not set

Change-Id: Id5db65d1beb7c2d30d7b4377fad419090392390c
Previous-Reviewed-on: https://chromium-review.googlesource.com/412625
(cherry picked from commit 816b7f36e9a7c5fc94d430b061bb1c501f12ed44)
Reviewed-on: https://chromium-review.googlesource.com/414772
Commit-Queue: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Trybot-Ready: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>

[modify] https://crrev.com/12f7cc4a68a2d85c070d86397da3e4587d228e13/chromeos/config/base.config

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/514748a8b987d608ede240ff941b15cd43661d50

commit 514748a8b987d608ede240ff941b15cd43661d50
Author: Daniel Kurtz <djkurtz@chromium.org>
Date: Tue Nov 22 10:41:51 2016

CHROMIUM: config: Disable CONFIG_SECURITY_SELINUX_DEVELOP

Disable by default, the development support option of NSA SELinux.
This option allows starting the kernel in permissive mode (log everything,
deny nothing), if enforcing=1 was not specify on the kernel command line.

It also allows interactively toggling the kernel between enforcing mode
and permissive mode (if permitted by the policy) via /selinux/enforce
(aka "setenforce Permissive").

In fact, this CONFIG option is already set via the cros-kernel2.eclass,
so there is no need to enable it here in base.config.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

BUG= chromium:662450 
TEST=USE="-android_test" emerge-${B} -pvq chromeos-kernel-3_18
 Check: /build/${B}/var/cache/portage/sys-kernel/chromeos-kernel-3_18/.config
 =>
  # CONFIG_SECURITY_SELINUX_DEVELOP is not set

Change-Id: Id5db65d1beb7c2d30d7b4377fad419090392390c
Reviewed-on: https://chromium-review.googlesource.com/412625
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
(cherry picked from commit 517401168417632e8c0ab54d4d99d39f2c1eaa47)
Reviewed-on: https://chromium-review.googlesource.com/414803
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>

[modify] https://crrev.com/514748a8b987d608ede240ff941b15cd43661d50/chromeos/config/base.config

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/c87d0030167a703c895a68a548bdda5e552ea998

commit c87d0030167a703c895a68a548bdda5e552ea998
Author: Daniel Kurtz <djkurtz@chromium.org>
Date: Tue Nov 22 10:41:51 2016

CHROMIUM: config: Disable CONFIG_SECURITY_SELINUX_DEVELOP

Disable by default, the development support option of NSA SELinux.
This option allows starting the kernel in permissive mode (log everything,
deny nothing), if enforcing=1 was not specify on the kernel command line.

It also allows interactively toggling the kernel between enforcing mode
and permissive mode (if permitted by the policy) via /selinux/enforce
(aka "setenforce Permissive").

In fact, this CONFIG option is already set via the cros-kernel2.eclass,
so there is no need to enable it here in base.config.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>

BUG= chromium:662450 
TEST=USE="-android_test" emerge-${B} -pvq chromeos-kernel-3_18
 Check: /build/${B}/var/cache/portage/sys-kernel/chromeos-kernel-3_18/.config
 =>
  # CONFIG_SECURITY_SELINUX_DEVELOP is not set

Change-Id: Id5db65d1beb7c2d30d7b4377fad419090392390c
Previous-Reviewed-on: https://chromium-review.googlesource.com/412625
(cherry picked from commit 517401168417632e8c0ab54d4d99d39f2c1eaa47)
Previous-Reviewed-on: https://chromium-review.googlesource.com/414803
(cherry picked from commit fd07d55b646c7c122be4be7c62bda23aefd15bf5)
Reviewed-on: https://chromium-review.googlesource.com/415008
Reviewed-by: Brian Norris <briannorris@chromium.org>
Commit-Queue: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Trybot-Ready: Daniel Kurtz <djkurtz@chromium.org>

[modify] https://crrev.com/c87d0030167a703c895a68a548bdda5e552ea998/chromeos/config/base.config

Sorry for the noise;
We are still Merge-Requesting this Chromium patch for R56: https://codereview.chromium.org/2536103002

[Automated comment] There appears to be on-going work (i.e. bugroid changes), needs manual review.

[Automated comment] There appears to be on-going work (i.e. bugroid changes), needs manual review.

Is this something we really need on 55 at this point?

We are going stable imminently, and it is not clear if this is something we would want to block on such that it would be worth merging. 

56 should be ok at this point though.

This cleans up quite a bit of log-spam.  It would be useful on 55, but definitely not critical.  We definitely want this for 56.

We are still waiting on Merge-Approval for this Chromium patch for R56: https://codereview.chromium.org/2536103002

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7a5581bb1936509a457b55e6ba9cf178efa5c524

commit 7a5581bb1936509a457b55e6ba9cf178efa5c524
Author: djkurtz <djkurtz@chromium.org>
Date: Thu Dec 08 17:35:27 2016

Linux Sandbox: Whitelist prlimit64 when used as getrlimit

From http://man7.org/linux/man-pages/man2/getrlimit.2.html:

The Linux-specific prlimit() system call combines and extends the
functionality of setrlimit() and getrlimit().  It can be used to both
set and get the resource limits of an arbitrary process.

Since version 2.13, the glibc getrlimit() and setrlimit() wrapper
functions no longer invoke the corresponding system calls, but
instead employ prlimit(), for the reasons described in BUGS.

If new_limit is not NULL, then the rlimit structure to which it points is
used to set new values.  If it is NULL, then prlimit() acts as getrlimit().

So, allow prlimit() with new_limit=NULL, and pid is the current process
(or 0), so the glib implementation of getrlimit can succeed.

BUG= chromium:662450 
TEST=boot on ChromeOS w/ sandbox enabled
 No messages like:
   getrlimit(RLIMIT_NOFILE) failed

NOTRY=true
NOPRESUBMIT=true

Review-Url: https://codereview.chromium.org/2484393004
Cr-Commit-Position: refs/heads/master@{#434872}
(cherry picked from commit 5ce3b357d4cb9906b57f5758ef271cb69dbb664b)

Review-Url: https://codereview.chromium.org/2536103002
Cr-Commit-Position: refs/branch-heads/2924@{#407}
Cr-Branched-From: 3a87aecc31cd1ffe751dd72c04e5a96a1fc8108a-refs/heads/master@{#433059}

[modify] https://crrev.com/7a5581bb1936509a457b55e6ba9cf178efa5c524/content/common/sandbox_linux/bpf_renderer_policy_linux.cc
[modify] https://crrev.com/7a5581bb1936509a457b55e6ba9cf178efa5c524/sandbox/linux/seccomp-bpf-helpers/syscall_parameters_restrictions.cc
[modify] https://crrev.com/7a5581bb1936509a457b55e6ba9cf178efa5c524/sandbox/linux/seccomp-bpf-helpers/syscall_parameters_restrictions.h

gkihumba - you already approved this one for 56 yesterday.  Thanks! :-)