Add SeccompSupportDetector for Android.

Add SeccompSupportDetector for Android.

This class will report to UMA the Android kernel version and the level of kernel
support for seccomp-bpf sandboxing.

BUG=468455
Committed: https://crrev.com/e59ea892a5fb3d9c0bfa97c8f1e567fd57a07130
Cr-Commit-Position: refs/heads/master@{#321451}

[Robert Sesek, 2015-03-18 18:59:00]

Patchset #1 (id:1) has been deleted

[Robert Sesek, 2015-03-18 19:04:50]

rsesek@chromium.org changed reviewers:
+ jln@chromium.org

[Robert Sesek, 2015-03-18 19:04:51]

Julien: Mind taking a look before I send this out for OWNERS?

[Robert Sesek, 2015-03-18 19:26:07]

Patchset #2 (id:40001) has been deleted

[jln (very slow on Chromium), 2015-03-18 20:49:15]

Looks good in general, but the ownership of the SeccompSupportDetector instance
confused me.

Am I missing something?

https://codereview.chromium.org/1018953004/diff/20001/chrome/browser/android/...
File chrome/browser/android/seccomp_support_detector.cc (right):

https://codereview.chromium.org/1018953004/diff/20001/chrome/browser/android/...
chrome/browser/android/seccomp_support_detector.cc:17: enum AndroidSeccompStatus
{
No enum class?

https://codereview.chromium.org/1018953004/diff/20001/chrome/browser/android/...
chrome/browser/android/seccomp_support_detector.cc:18: kDetectionFailed,
The Chromium appendix to the style guide says to use MACRO_STYLE. I'm happy to
ignore this in new files though.

https://codereview.chromium.org/1018953004/diff/20001/chrome/browser/android/...
chrome/browser/android/seccomp_support_detector.cc:26: void
SeccompSupportDetector::StartDetection() {
//static?

https://codereview.chromium.org/1018953004/diff/20001/chrome/browser/android/...
chrome/browser/android/seccomp_support_detector.cc:27: // This class owns
itself. It is created here and the object is released
"It is created here" -> "An instance is created here" ?

https://codereview.chromium.org/1018953004/diff/20001/chrome/browser/android/...
chrome/browser/android/seccomp_support_detector.cc:28: // after seccomp suport
is detected.
The lifetime of this refcounted class is a little complicated. I don't think
"owns itself" captures it.

If I'm following correctly, we guarantee that for a StartDetection() call, there
will be a callback to OnDetectSeccompSupportResult() or OnProcessCrashed() which
will release the particular reference created in StartDetection().

But StartDetection could simply Release() its reference immediately (since the
callback you create also owns a reference).

So why not simply creating a scoped_refptr<..> detector? When StartDetection()
returns, the refcounter should be at one and the object will get deleted when
the various callbacks will be done with it. No need to call Release() from the
On* methods.

https://codereview.chromium.org/1018953004/diff/20001/chrome/browser/android/...
chrome/browser/android/seccomp_support_detector.cc:47: // Support known Android
kernel versions, and leave room up to 3.50.
3.20 is actually 4.0

https://codereview.chromium.org/1018953004/diff/20001/chrome/browser/android/...
chrome/browser/android/seccomp_support_detector.cc:61: utsname uts;
nit: I prefer to use "struct X" for low-level C code, but your choice.

https://codereview.chromium.org/1018953004/diff/20001/chrome/browser/android/...
chrome/browser/android/seccomp_support_detector.cc:64: if (sscanf(uts.release,
"%d.%d", &major, &minor) == 2) {
Ok to put all 2.6.X kernels in the same bucket?

For seccomp on Android I don't think it matters indeed.

https://codereview.chromium.org/1018953004/diff/20001/chrome/browser/android/...
File chrome/browser/android/seccomp_support_detector.h (right):

https://codereview.chromium.org/1018953004/diff/20001/chrome/browser/android/...
chrome/browser/android/seccomp_support_detector.h:12: // level of seccomp-bpf
support. The kerenl version is read from the FILE
kernel

https://codereview.chromium.org/1018953004/diff/20001/tools/metrics/histogram...
File tools/metrics/histograms/histograms.xml (right):

https://codereview.chromium.org/1018953004/diff/20001/tools/metrics/histogram...
tools/metrics/histograms/histograms.xml:44177: +  <int value="196688"
label="3.50"/>
3.20 is actually called 4.0

https://codereview.chromium.org/1018953004/diff/20001/tools/metrics/histogram...
tools/metrics/histograms/histograms.xml:44198: +  <int value="3" label="Syscall
Only Supported"/>
That shouldn't be possible. Will be interesting to see if we see that in the
field.
We've seen KernelSupportsSeccompTsync() crash on buggy kernels.

[Robert Sesek, 2015-03-18 21:41:36]

Thanks Julien!

https://codereview.chromium.org/1018953004/diff/20001/chrome/browser/android/...
File chrome/browser/android/seccomp_support_detector.cc (right):

https://codereview.chromium.org/1018953004/diff/20001/chrome/browser/android/...
chrome/browser/android/seccomp_support_detector.cc:17: enum AndroidSeccompStatus
{
On 2015/03/18 20:49:15, jln wrote:
> No enum class?

It doesn't work well with the UMA_HISTOGRAM_ENUMERATION since it tries to +1 the
last value.

https://codereview.chromium.org/1018953004/diff/20001/chrome/browser/android/...
chrome/browser/android/seccomp_support_detector.cc:18: kDetectionFailed,
On 2015/03/18 20:49:15, jln wrote:
> The Chromium appendix to the style guide says to use MACRO_STYLE. I'm happy to
> ignore this in new files though.

Ah, yeah I was using the Google style. I'll follow Chromium.

https://codereview.chromium.org/1018953004/diff/20001/chrome/browser/android/...
chrome/browser/android/seccomp_support_detector.cc:26: void
SeccompSupportDetector::StartDetection() {
On 2015/03/18 20:49:15, jln wrote:
> //static?

Done.

https://codereview.chromium.org/1018953004/diff/20001/chrome/browser/android/...
chrome/browser/android/seccomp_support_detector.cc:27: // This class owns
itself. It is created here and the object is released
On 2015/03/18 20:49:15, jln wrote:
> "It is created here" -> "An instance is created here" ?

Done.

https://codereview.chromium.org/1018953004/diff/20001/chrome/browser/android/...
chrome/browser/android/seccomp_support_detector.cc:28: // after seccomp suport
is detected.
On 2015/03/18 20:49:15, jln wrote:
> The lifetime of this refcounted class is a little complicated. I don't think
> "owns itself" captures it.
> 
> If I'm following correctly, we guarantee that for a StartDetection() call,
there
> will be a callback to OnDetectSeccompSupportResult() or OnProcessCrashed()
which
> will release the particular reference created in StartDetection().
> 
> But StartDetection could simply Release() its reference immediately (since the
> callback you create also owns a reference).
> 
> So why not simply creating a scoped_refptr<..> detector? When StartDetection()
> returns, the refcounter should be at one and the object will get deleted when
> the various callbacks will be done with it. No need to call Release() from the
> On* methods.

I initially did as you suggested and let the Closure own it, but I thought that
was actually less clear. But I do prefer that, so done.

https://codereview.chromium.org/1018953004/diff/20001/chrome/browser/android/...
chrome/browser/android/seccomp_support_detector.cc:47: // Support known Android
kernel versions, and leave room up to 3.50.
On 2015/03/18 20:49:15, jln wrote:
> 3.20 is actually 4.0

Done.

https://codereview.chromium.org/1018953004/diff/20001/chrome/browser/android/...
chrome/browser/android/seccomp_support_detector.cc:61: utsname uts;
On 2015/03/18 20:49:15, jln wrote:
> nit: I prefer to use "struct X" for low-level C code, but your choice.

Acknowledged.

https://codereview.chromium.org/1018953004/diff/20001/chrome/browser/android/...
chrome/browser/android/seccomp_support_detector.cc:64: if (sscanf(uts.release,
"%d.%d", &major, &minor) == 2) {
On 2015/03/18 20:49:15, jln wrote:
> Ok to put all 2.6.X kernels in the same bucket?
> 
> For seccomp on Android I don't think it matters indeed.

Yeah, I think so. I don't even know if Chrome runs on any Android devices with a
kernel <3.0.

https://codereview.chromium.org/1018953004/diff/20001/chrome/browser/android/...
File chrome/browser/android/seccomp_support_detector.h (right):

https://codereview.chromium.org/1018953004/diff/20001/chrome/browser/android/...
chrome/browser/android/seccomp_support_detector.h:12: // level of seccomp-bpf
support. The kerenl version is read from the FILE
On 2015/03/18 20:49:15, jln wrote:
> kernel

Done.

https://codereview.chromium.org/1018953004/diff/20001/tools/metrics/histogram...
File tools/metrics/histograms/histograms.xml (right):

https://codereview.chromium.org/1018953004/diff/20001/tools/metrics/histogram...
tools/metrics/histograms/histograms.xml:44177: +  <int value="196688"
label="3.50"/>
On 2015/03/18 20:49:15, jln wrote:
> 3.20 is actually called 4.0

Done.

https://codereview.chromium.org/1018953004/diff/20001/tools/metrics/histogram...
tools/metrics/histograms/histograms.xml:44198: +  <int value="3" label="Syscall
Only Supported"/>
On 2015/03/18 20:49:15, jln wrote:
> That shouldn't be possible. Will be interesting to see if we see that in the
> field.
> We've seen KernelSupportsSeccompTsync() crash on buggy kernels.

Right, hopefully nothing comes back with 3 ;-). Since we're doing the probing in
a utility process, we should be protected against buggy kernels in the browser.

[Robert Sesek, 2015-03-18 22:30:32]

PTAL. I changed utility process to send a message after each probing, that way
if the syscall crashes, we can still get data about the prctl.

[jln (very slow on Chromium), 2015-03-18 22:34:16]

lgtm

[jln (very slow on Chromium), 2015-03-18 22:35:06]

On 2015/03/18 22:30:32, Robert Sesek wrote:
> PTAL. I changed utility process to send a message after each probing, that way
> if the syscall crashes, we can still get data about the prctl.

Ahh, let me take a look at this version...

[jln (very slow on Chromium), 2015-03-19 00:12:12]

lgtm, but the complexity of our IPC system makes it somewhat difficult to be
confident in the ordering of the handlers.

This looks fine, but a DHECK and maybe some comments could help.

https://chromiumcodereview.appspot.com/1018953004/diff/80001/chrome/browser/a...
File chrome/browser/android/seccomp_support_detector.cc (right):

https://chromiumcodereview.appspot.com/1018953004/diff/80001/chrome/browser/a...
chrome/browser/android/seccomp_support_detector.cc:126:
UMA_HISTOGRAM_ENUMERATION("Android.SeccompStatus.Syscall",
DCHECK(prctl_detected); ?

https://chromiumcodereview.appspot.com/1018953004/diff/80001/chrome/utility/c...
File chrome/utility/chrome_content_utility_client.cc (right):

https://chromiumcodereview.appspot.com/1018953004/diff/80001/chrome/utility/c...
chrome/utility/chrome_content_utility_client.cc:290: Send(new
ChromeUtilityHostMsg_DetectSeccompSupport_ResultPrctl(
It's difficult to convince oneself that by performing two Send() requests in a
given order, we will get the two callbacks in the same order.

[Robert Sesek, 2015-03-19 00:18:41]

Thanks for the review.

https://codereview.chromium.org/1018953004/diff/80001/chrome/browser/android/...
File chrome/browser/android/seccomp_support_detector.cc (right):

https://codereview.chromium.org/1018953004/diff/80001/chrome/browser/android/...
chrome/browser/android/seccomp_support_detector.cc:126:
UMA_HISTOGRAM_ENUMERATION("Android.SeccompStatus.Syscall",
On 2015/03/19 00:12:12, jln wrote:
> DCHECK(prctl_detected); ?

Done.

https://codereview.chromium.org/1018953004/diff/80001/chrome/utility/chrome_c...
File chrome/utility/chrome_content_utility_client.cc (right):

https://codereview.chromium.org/1018953004/diff/80001/chrome/utility/chrome_c...
chrome/utility/chrome_content_utility_client.cc:290: Send(new
ChromeUtilityHostMsg_DetectSeccompSupport_ResultPrctl(
On 2015/03/19 00:12:12, jln wrote:
> It's difficult to convince oneself that by performing two Send() requests in a
> given order, we will get the two callbacks in the same order.

I'm pretty sure FIFO is guaranteed by the IPC system, so long as you're
receiving messages on the same thread (which we are, IO).

[Robert Sesek, 2015-03-19 00:19:04]

rsesek@chromium.org changed reviewers:
+ dtrainor@chromium.org, isherman@chromium.org, thestig@chromium.org

[Robert Sesek, 2015-03-19 00:19:04]

+dtrainor for chrome/browser/android/
+thestig for the rest of chrome/
+isherman for histograms.xml

[Ilya Sherman, 2015-03-19 00:37:44]

https://codereview.chromium.org/1018953004/diff/100001/chrome/browser/android...
File chrome/browser/android/seccomp_support_detector.cc (right):

https://codereview.chromium.org/1018953004/diff/100001/chrome/browser/android...
chrome/browser/android/seccomp_support_detector.cc:71:
UMA_HISTOGRAM_CUSTOM_ENUMERATION(
nit: Maybe a sparse enum would be simpler to use here?

https://codereview.chromium.org/1018953004/diff/100001/chrome/browser/android...
chrome/browser/android/seccomp_support_detector.cc:99:
UMA_HISTOGRAM_ENUMERATION("Android.SeccompStatus.Prctl",
Optional: I'd recommend having a single codepath per histogram name, so that
there's less chance of typos sneaking into one of the parallel codepaths.

https://codereview.chromium.org/1018953004/diff/100001/tools/metrics/histogra...
File tools/metrics/histograms/histograms.xml (right):

https://codereview.chromium.org/1018953004/diff/100001/tools/metrics/histogra...
tools/metrics/histograms/histograms.xml:254: +    The low 16 bits of each
version are combined into 32-bit integer. The range
nit: "into 32-bit integer" -> "into a 32-bit integer"

https://codereview.chromium.org/1018953004/diff/100001/tools/metrics/histogra...
tools/metrics/histograms/histograms.xml:255: +    is from [0x0002006,0x00040010]
to track kernel versions 2.6 through 4.10.
Did you mean 0x00020006 (i.e. an extra 0)?

https://codereview.chromium.org/1018953004/diff/100001/tools/metrics/histogra...
tools/metrics/histograms/histograms.xml:255: +    is from [0x0002006,0x00040010]
to track kernel versions 2.6 through 4.10.
Did you mean 0x0004000a?  I'd expect 0x0010 to mean 16...

[Lei Zhang, 2015-03-19 00:42:23]

https://codereview.chromium.org/1018953004/diff/100001/chrome/browser/android...
File chrome/browser/android/seccomp_support_detector.cc (right):

https://codereview.chromium.org/1018953004/diff/100001/chrome/browser/android...
chrome/browser/android/seccomp_support_detector.cc:32:
BrowserThread::PostTask(BrowserThread::FILE, FROM_HERE,
BrowserThread::PostBlockingPoolTask

https://codereview.chromium.org/1018953004/diff/100001/chrome/browser/android...
chrome/browser/android/seccomp_support_detector.cc:83:
DCHECK(BrowserThread::CurrentlyOn(BrowserThread::IO));
DCHECK_CURRENTLY_ON() is the new hotness. Add it to the various OnFoo() methods?

https://codereview.chromium.org/1018953004/diff/100001/chrome/browser/chrome_...
File chrome/browser/chrome_browser_main_android.cc (right):

https://codereview.chromium.org/1018953004/diff/100001/chrome/browser/chrome_...
chrome/browser/chrome_browser_main_android.cc:102:
content::BrowserThread::PostDelayedTask(
content::BrowserThread::GetBlockingPool()->PostDelayedTask(FROM_HERE, ...) and
adjust seccomp_support_detector.cc accordingly?

https://codereview.chromium.org/1018953004/diff/100001/chrome/utility/chrome_...
File chrome/utility/chrome_content_utility_client.cc (right):

https://codereview.chromium.org/1018953004/diff/100001/chrome/utility/chrome_...
chrome/utility/chrome_content_utility_client.cc:29: #if !defined(OS_ANDROID)
Maybe flip this to #if defined(OS_ANDROID) ?

[David Trainor- moved to gerrit, 2015-03-19 05:54:35]

chrome/browser/android lgtm with thestig@'s nits.

[Robert Sesek, 2015-03-19 13:56:42]

Fix use_seccomp_bpf==0

[Robert Sesek, 2015-03-19 14:57:30]

Thanks for the reviews, all comments addressed.

https://codereview.chromium.org/1018953004/diff/100001/chrome/browser/android...
File chrome/browser/android/seccomp_support_detector.cc (right):

https://codereview.chromium.org/1018953004/diff/100001/chrome/browser/android...
chrome/browser/android/seccomp_support_detector.cc:32:
BrowserThread::PostTask(BrowserThread::FILE, FROM_HERE,
On 2015/03/19 00:42:23, Lei Zhang wrote:
> BrowserThread::PostBlockingPoolTask

Done.

https://codereview.chromium.org/1018953004/diff/100001/chrome/browser/android...
chrome/browser/android/seccomp_support_detector.cc:71:
UMA_HISTOGRAM_CUSTOM_ENUMERATION(
On 2015/03/19 00:37:43, Ilya Sherman wrote:
> nit: Maybe a sparse enum would be simpler to use here?

I didn't know about that. Yes, done.

https://codereview.chromium.org/1018953004/diff/100001/chrome/browser/android...
chrome/browser/android/seccomp_support_detector.cc:83:
DCHECK(BrowserThread::CurrentlyOn(BrowserThread::IO));
On 2015/03/19 00:42:23, Lei Zhang wrote:
> DCHECK_CURRENTLY_ON() is the new hotness. Add it to the various OnFoo()
methods?

Nifty. Thanks for the tip.

https://codereview.chromium.org/1018953004/diff/100001/chrome/browser/android...
chrome/browser/android/seccomp_support_detector.cc:99:
UMA_HISTOGRAM_ENUMERATION("Android.SeccompStatus.Prctl",
On 2015/03/19 00:37:44, Ilya Sherman wrote:
> Optional: I'd recommend having a single codepath per histogram name, so that
> there's less chance of typos sneaking into one of the parallel codepaths.

I gave this a go, but it results in two one-line methods for setting the
histograms. It made the code a little less readable IMO, but if you feel
strongly I can reapply that change.

https://codereview.chromium.org/1018953004/diff/100001/chrome/browser/chrome_...
File chrome/browser/chrome_browser_main_android.cc (right):

https://codereview.chromium.org/1018953004/diff/100001/chrome/browser/chrome_...
chrome/browser/chrome_browser_main_android.cc:102:
content::BrowserThread::PostDelayedTask(
On 2015/03/19 00:42:23, Lei Zhang wrote:
> content::BrowserThread::GetBlockingPool()->PostDelayedTask(FROM_HERE, ...) and
> adjust seccomp_support_detector.cc accordingly?

Done.

https://codereview.chromium.org/1018953004/diff/100001/chrome/utility/chrome_...
File chrome/utility/chrome_content_utility_client.cc (right):

https://codereview.chromium.org/1018953004/diff/100001/chrome/utility/chrome_...
chrome/utility/chrome_content_utility_client.cc:29: #if !defined(OS_ANDROID)
On 2015/03/19 00:42:23, Lei Zhang wrote:
> Maybe flip this to #if defined(OS_ANDROID) ?

Done.

https://codereview.chromium.org/1018953004/diff/100001/tools/metrics/histogra...
File tools/metrics/histograms/histograms.xml (right):

https://codereview.chromium.org/1018953004/diff/100001/tools/metrics/histogra...
tools/metrics/histograms/histograms.xml:254: +    The low 16 bits of each
version are combined into 32-bit integer. The range
On 2015/03/19 00:37:44, Ilya Sherman wrote:
> nit: "into 32-bit integer" -> "into a 32-bit integer"

Done.

https://codereview.chromium.org/1018953004/diff/100001/tools/metrics/histogra...
tools/metrics/histograms/histograms.xml:255: +    is from [0x0002006,0x00040010]
to track kernel versions 2.6 through 4.10.
On 2015/03/19 00:37:44, Ilya Sherman wrote:
> Did you mean 0x0004000a?  I'd expect 0x0010 to mean 16...

Do'h. Thanks for catching that.

https://codereview.chromium.org/1018953004/diff/100001/tools/metrics/histogra...
tools/metrics/histograms/histograms.xml:255: +    is from [0x0002006,0x00040010]
to track kernel versions 2.6 through 4.10.
On 2015/03/19 00:37:44, Ilya Sherman wrote:
> Did you mean 0x00020006 (i.e. an extra 0)?

Done.

[Lei Zhang, 2015-03-19 18:29:13]

I'm not sure what the Android GN build status is, but look for the GN equivalent
to your .gypi files and update those as well.

[Lei Zhang, 2015-03-19 18:32:04]

https://codereview.chromium.org/1018953004/diff/140001/chrome/browser/android...
File chrome/browser/android/seccomp_support_detector.h (right):

https://codereview.chromium.org/1018953004/diff/140001/chrome/browser/android...
chrome/browser/android/seccomp_support_detector.h:25: // Called on the FILE
thread. This reads the utsname and records the kernel
s/FILE thread/blocking thread pool/

[Robert Sesek, 2015-03-19 19:37:16]

On 2015/03/19 18:29:13, Lei Zhang wrote:
> I'm not sure what the Android GN build status is, but look for the GN
equivalent
> to your .gypi files and update those as well.

I can't find any files in chrome/browser/android in GN, so I don't think that
target is done. I did copy over the bit into chrome/utility/BUILD.gn

https://codereview.chromium.org/1018953004/diff/140001/chrome/browser/android...
File chrome/browser/android/seccomp_support_detector.h (right):

https://codereview.chromium.org/1018953004/diff/140001/chrome/browser/android...
chrome/browser/android/seccomp_support_detector.h:25: // Called on the FILE
thread. This reads the utsname and records the kernel
On 2015/03/19 18:32:04, Lei Zhang wrote:
> s/FILE thread/blocking thread pool/

Done.

[Lei Zhang, 2015-03-19 19:46:36]

https://codereview.chromium.org/1018953004/diff/160001/chrome/chrome_browser....
File chrome/chrome_browser.gypi (right):

https://codereview.chromium.org/1018953004/diff/160001/chrome/chrome_browser....
chrome/chrome_browser.gypi:3429: 'sources': [
'<@(chrome_browser_android_sources)' ],
This is chrome/browser/BUILD.gn line 596.

https://codereview.chromium.org/1018953004/diff/160001/chrome/utility/BUILD.gn
File chrome/utility/BUILD.gn (right):

https://codereview.chromium.org/1018953004/diff/160001/chrome/utility/BUILD.g...
chrome/utility/BUILD.gn:35: deps += [ "//sandbox:seccomp_bpf" ]
sandbox/linux:seccomp_bpf

[Robert Sesek, 2015-03-19 19:56:29]

Patchset #7 (id:160001) has been deleted

[Robert Sesek, 2015-03-19 20:02:36]

On 2015/03/19 19:46:36, Lei Zhang wrote:
>
https://codereview.chromium.org/1018953004/diff/160001/chrome/chrome_browser....
> File chrome/chrome_browser.gypi (right):
> 
>
https://codereview.chromium.org/1018953004/diff/160001/chrome/chrome_browser....
> chrome/chrome_browser.gypi:3429: 'sources': [
> '<@(chrome_browser_android_sources)' ],
> This is chrome/browser/BUILD.gn line 596.

Ah, I didn't know GN did this.

> https://codereview.chromium.org/1018953004/diff/160001/chrome/utility/BUILD.gn
> File chrome/utility/BUILD.gn (right):
> 
>
https://codereview.chromium.org/1018953004/diff/160001/chrome/utility/BUILD.g...
> chrome/utility/BUILD.gn:35: deps += [ "//sandbox:seccomp_bpf" ]
> sandbox/linux:seccomp_bpf

Done.

[Lei Zhang, 2015-03-19 20:43:56]

lgtm

[Ilya Sherman, 2015-03-19 21:37:12]

histograms LGTM, thanks

[Robert Sesek, 2015-03-19 22:01:49]

The CQ bit was checked by rsesek@chromium.org

[Robert Sesek, 2015-03-19 22:01:50]

The patchset sent to the CQ was uploaded after l-g-t-m from jln@chromium.org,
dtrainor@chromium.org
Link to the patchset: https://codereview.chromium.org/1018953004/#ps200001
(title: "More GN")

[commit-bot: I haz the power, 2015-03-19 22:02:40]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1018953004/200001

[commit-bot: I haz the power, 2015-03-19 22:10:14]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-03-19 22:10:16]

Try jobs failed on following builders:
  chromium_presubmit on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[Robert Sesek, 2015-03-19 22:15:16]

Patchset #9 (id:220001) has been deleted

[Robert Sesek, 2015-03-19 22:23:00]

The CQ bit was checked by rsesek@chromium.org

[Robert Sesek, 2015-03-19 22:23:01]

The patchset sent to the CQ was uploaded after l-g-t-m from jln@chromium.org,
dtrainor@chromium.org
Link to the patchset: https://codereview.chromium.org/1018953004/#ps200001
(title: "More GN")

[commit-bot: I haz the power, 2015-03-19 22:23:30]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1018953004/200001

[commit-bot: I haz the power, 2015-03-19 22:28:07]

Committed patchset #8 (id:200001)

[commit-bot: I haz the power, 2015-03-19 22:29:03]

Patchset 8 (id:??) landed as
https://crrev.com/e59ea892a5fb3d9c0bfa97c8f1e567fd57a07130
Cr-Commit-Position: refs/heads/master@{#321451}