Allow ugetrlimit() whenever we allow getrlimit() as the calls are pretty

Allow ugetrlimit() whenever we allow getrlimit() as the calls are pretty
much identical.

BUG=226965
R=jln@chromium.org

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=202979

[jln (very slow on Chromium), 2013-05-29 03:36:40]

I think the #ifdef you changed were correct.

If you modify this to just add ugetrlimit to the renderer process (on arm in
i386): lgtm

https://codereview.chromium.org/16019017/diff/1/content/common/sandbox_seccom...
File content/common/sandbox_seccomp_bpf_linux.cc (left):

https://codereview.chromium.org/16019017/diff/1/content/common/sandbox_seccom...
content/common/sandbox_seccomp_bpf_linux.cc:876: #if defined(__i386__) ||
defined(__x86_64__)
There is no getrlimit on arm. I think this #ifdef was correct?

https://codereview.chromium.org/16019017/diff/1/content/common/sandbox_seccom...
content/common/sandbox_seccomp_bpf_linux.cc:1557: #if defined(__i386__) ||
defined(__x86_64__)
Ditto.

[Chris Evans, 2013-05-29 07:58:48]

On 2013/05/29 03:36:40, Julien Tinnes wrote:
> I think the #ifdef you changed were correct.
> 
> If you modify this to just add ugetrlimit to the renderer process (on arm in
> i386): lgtm
> 
>
https://codereview.chromium.org/16019017/diff/1/content/common/sandbox_seccom...
> File content/common/sandbox_seccomp_bpf_linux.cc (left):
> 
>
https://codereview.chromium.org/16019017/diff/1/content/common/sandbox_seccom...
> content/common/sandbox_seccomp_bpf_linux.cc:876: #if defined(__i386__) ||
> defined(__x86_64__)
> There is no getrlimit on arm. I think this #ifdef was correct?

I made the change after having read the __NR_* defines from all the plaforms
involved (i386, x86_64 and arm).
And my intent is to confirm my reading with the try bots.

As can be seen, I've got a very green try run, including compile on Android and
iOS (arm).

PTAL?

> 
>
https://codereview.chromium.org/16019017/diff/1/content/common/sandbox_seccom...
> content/common/sandbox_seccomp_bpf_linux.cc:1557: #if defined(__i386__) ||
> defined(__x86_64__)
> Ditto.

[jln (very slow on Chromium), 2013-05-29 19:03:31]

On 2013/05/29 07:58:48, Chris Evans wrote:

> And my intent is to confirm my reading with the try bots.
> 
> As can be seen, I've got a very green try run, including compile on Android
and
> iOS (arm).

(Note: this file doesn't even get compiled on Android or IOS)

I confirm: in the Linux kernel, look at include/uapi/asm/unistd.h, around line
440:

/*
 * The following syscalls are obsolete and no longer available for EABI.
 */
#if !defined(__KERNEL__)
#if defined(__ARM_EABI__)
[...]
#undef __NR_getrlimit

The process of finding out what exists and doesn't is quite involved. We've done
that once, look at src/sandbox/linux/services/linux_syscalls.h, which is now the
authoritative source.

[Chris Evans, 2013-05-29 20:02:01]

On 2013/05/29 19:03:31, Julien Tinnes wrote:
> On 2013/05/29 07:58:48, Chris Evans wrote:
> 
> > And my intent is to confirm my reading with the try bots.
> > 
> > As can be seen, I've got a very green try run, including compile on Android
> and
> > iOS (arm).
> 
> (Note: this file doesn't even get compiled on Android or IOS)
> 
> I confirm: in the Linux kernel, look at include/uapi/asm/unistd.h, around line
> 440:
> 
> /*
>  * The following syscalls are obsolete and no longer available for EABI.
>  */
> #if !defined(__KERNEL__)
> #if defined(__ARM_EABI__)
> [...]
> #undef __NR_getrlimit
> 
> The process of finding out what exists and doesn't is quite involved. We've
done
> that once, look at src/sandbox/linux/services/linux_syscalls.h, which is now
the
> authoritative source.

You are of course correct, @jln, sorry for doubting you ;-)
I confirmed on the cros_daisy trybot that it compile fails. It'd be nice to at
least compile this file on one of the ARM targets that are in default try runs.

[Chris Evans, 2013-05-29 21:34:06]

Committed patchset #2 manually as r202979 (presubmit successful).