Add a new driver bug workaround SANDBOX_START_EARLY

Add a new driver bug workaround SANDBOX_START_EARLY

It is usefull for drivers that create threads so that
it requires to start the sandbox first.
It is not really a bug but it fits with workarounds.

This CL also add a json entry for llvmpipe driver from Mesa
to enable this new driver bug woraround.

A new json entry could be added for Mali driver. According
to gpu_main.cc this driver creates threads.

BUG=264818
R=jam@chromium.org, kbr@chromium.org, mdempsky@chromium.org, piman@chromium.org, zmo@chromium.org

TEST= GALLIUM_DRIVER=llvmpipe LIBGL_ALWAYS_SOFTWARE=1
CHROME_DEVEL_SANDBOX=out/Release/chrome_sandbox
It prints:
ERROR:sandbox_linux.cc(333)] InitializeSandbox() called with
multiple threads in process gpu-process

Review URL:
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel

[Julien Isorce Samsung, 2016-04-28 17:49:09]

Instead of a new gpu driver bug workaround, I know think it should just be a
boolean entry "sandbox_start_early" in GpuControlList. (like "direct_rendering"
and "in_process_gpu"). 

I would set it in existing id 110 in kSoftwareRenderingListJson.

According to the comment in gpu_main.cc around switches::kGpuSandboxStartEarly
it would be beneficial not only for llvmpipe driver. So mali driver could setup
that from kSoftwareRenderingListJson too.

Is it something of interest ? Thx.

[piman, 2016-04-28 23:49:56]

lgtm

[Julien Isorce Samsung, 2016-04-29 17:39:47]

Description was changed from

==========
Add a new driver bug workaround SANDBOX_START_EARLY

It is usefull for drivers that create threads so that
it requires to start the sandbox first.
It is not really a bug but it fits with workarounds.

This CL also add a json entry for llvmpipe driver from Mesa
to enable this new driver bug woraround.

A new json entry could be added for Mali driver. According
to gpu_main.cc this driver creates threads.

BUG=264818

R=kbr@chromium.org, piman@chromium.org, zmo@chromium.org

TEST= GALLIUM_DRIVER=llvmpipe LIBGL_ALWAYS_SOFTWARE=1
CHROME_DEVEL_SANDBOX=out/Release/chrome_sandbox
It prints:
ERROR:sandbox_linux.cc(333)] InitializeSandbox() called with
multiple threads in process gpu-process

Review URL:
==========

to

==========
Add a new driver bug workaround SANDBOX_START_EARLY

It is usefull for drivers that create threads so that
it requires to start the sandbox first.
It is not really a bug but it fits with workarounds.

This CL also add a json entry for llvmpipe driver from Mesa
to enable this new driver bug woraround.

A new json entry could be added for Mali driver. According
to gpu_main.cc this driver creates threads.

BUG=264818

R=kbr@chromium.org, piman@chromium.org, zmo@chromium.org

TEST= GALLIUM_DRIVER=llvmpipe LIBGL_ALWAYS_SOFTWARE=1
CHROME_DEVEL_SANDBOX=out/Release/chrome_sandbox
It prints:
ERROR:sandbox_linux.cc(333)] InitializeSandbox() called with
multiple threads in process gpu-process

Review URL:
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_optional_gpu_tests_rel;tryserver.chromium.mac:mac_optional_gpu_tests_rel;tryserver.chromium.win:win_optional_gpu_tests_rel
==========

[Julien Isorce Samsung, 2016-04-29 17:42:15]

On 2016/04/28 23:49:56, piman OOO back 2016-5-2 wrote:
> lgtm

Actually I was wrong in my previous comment because "direct_rendering"
and "in_process_gpu" are actually fields in GpuInfo which are detected so these
fields serve as control field like other. So it is not intended to activate
something or not.
In the end I think my initial patch is the only solution so I rebased it and
re-wrote it more appropriately. Please have a look, thx.

[Julien Isorce Samsung, 2016-04-30 07:47:56]

The CQ bit was checked by j.isorce@samsung.com to run a CQ dry run

[commit-bot: I haz the power, 2016-04-30 07:48:08]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1542013005/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1542013005/20001

[commit-bot: I haz the power, 2016-04-30 09:08:52]

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

[commit-bot: I haz the power, 2016-04-30 09:08:53]

Dry run: Try jobs failed on following builders:
  linux_chromium_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[piman, 2016-05-02 20:26:44]

On 2016/04/30 09:08:53, commit-bot: I haz the power wrote:
> Dry run: Try jobs failed on following builders:
>   linux_chromium_rel_ng on tryserver.chromium.linux (JOB_FAILED,
>
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

Do you know what causes this failure? It seems like it could be related, but I'm
not sure how.

[Ken Russell (switch to Gerrit), 2016-05-02 20:32:10]

On 2016/05/02 20:26:44, piman OOO back 2016-5-2 wrote:
> On 2016/04/30 09:08:53, commit-bot: I haz the power wrote:
> > Dry run: Try jobs failed on following builders:
> >   linux_chromium_rel_ng on tryserver.chromium.linux (JOB_FAILED,
> >
>
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
> 
> Do you know what causes this failure? It seems like it could be related, but
I'm
> not sure how.

In the test run for GpuProcess.readback_webgl_gpu_process, the browser's picking
up the llvmpipe GL implementation rather than NVIDIA's. The sandbox_start_early
driver bug workaround is being used for this test. It definitely seems related.

[Julien Isorce Samsung, 2016-05-03 16:10:46]

On 2016/05/02 20:32:10, Ken Russell wrote:
> On 2016/05/02 20:26:44, piman OOO back 2016-5-2 wrote:
> > On 2016/04/30 09:08:53, commit-bot: I haz the power wrote:
> > > Dry run: Try jobs failed on following builders:
> > >   linux_chromium_rel_ng on tryserver.chromium.linux (JOB_FAILED,
> > >
> >
>
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
> > 
> > Do you know what causes this failure? It seems like it could be related, but
> I'm
> > not sure how.
> 
> In the test run for GpuProcess.readback_webgl_gpu_process, the browser's
picking
> up the llvmpipe GL implementation rather than NVIDIA's. The
sandbox_start_early
> driver bug workaround is being used for this test. It definitely seems
related.

Yes it is related. Also I found another problem. Actually since the sandbox is
started earlier it now fails to load libGL.so.1. (maybe it is the same problem
actually). But it was not behaving like that when I tested last week so I missed
something. I'll have a look tomorrow.

Btw I noticed that gl_implementation_osmesa.h::LoadLibraryAndPrintError is used
in a some places that have nothing to do with osmesa so debugging is confusing
since I see traces that starts with: gl_implementation_osmesa.cc. Can I move it
to gl_implementation.h/.cc ?

[Ken Russell (switch to Gerrit), 2016-05-03 16:52:52]

On 2016/05/03 16:10:46, j.isorce wrote:
> On 2016/05/02 20:32:10, Ken Russell wrote:
> > On 2016/05/02 20:26:44, piman OOO back 2016-5-2 wrote:
> > > On 2016/04/30 09:08:53, commit-bot: I haz the power wrote:
> > > > Dry run: Try jobs failed on following builders:
> > > >   linux_chromium_rel_ng on tryserver.chromium.linux (JOB_FAILED,
> > > >
> > >
> >
>
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
> > > 
> > > Do you know what causes this failure? It seems like it could be related,
but
> > I'm
> > > not sure how.
> > 
> > In the test run for GpuProcess.readback_webgl_gpu_process, the browser's
> picking
> > up the llvmpipe GL implementation rather than NVIDIA's. The
> sandbox_start_early
> > driver bug workaround is being used for this test. It definitely seems
> related.
> 
> Yes it is related. Also I found another problem. Actually since the sandbox is
> started earlier it now fails to load libGL.so.1. (maybe it is the same problem
> actually). But it was not behaving like that when I tested last week so I
missed
> something. I'll have a look tomorrow.
> 
> Btw I noticed that gl_implementation_osmesa.h::LoadLibraryAndPrintError is
used
> in a some places that have nothing to do with osmesa so debugging is confusing
> since I see traces that starts with: gl_implementation_osmesa.cc. Can I move
it
> to gl_implementation.h/.cc ?

Yes, please do move it. Looks like a bad refactoring somewhere along the line.

[Julien Isorce Samsung, 2016-05-04 10:44:51]

On 2016/05/03 16:52:52, Ken Russell wrote:
> On 2016/05/03 16:10:46, j.isorce wrote:
> > On 2016/05/02 20:32:10, Ken Russell wrote:
> > > On 2016/05/02 20:26:44, piman OOO back 2016-5-2 wrote:
> > > > On 2016/04/30 09:08:53, commit-bot: I haz the power wrote:
> > > > > Dry run: Try jobs failed on following builders:
> > > > >   linux_chromium_rel_ng on tryserver.chromium.linux (JOB_FAILED,
> > > > >
> > > >
> > >
> >
>
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
> > > > 
> > > > Do you know what causes this failure? It seems like it could be related,
> but
> > > I'm
> > > > not sure how.
> > > 
> > > In the test run for GpuProcess.readback_webgl_gpu_process, the browser's
> > picking
> > > up the llvmpipe GL implementation rather than NVIDIA's. The
> > sandbox_start_early
> > > driver bug workaround is being used for this test. It definitely seems
> > related.
> > 
> > Yes it is related. Also I found another problem. Actually since the sandbox
is
> > started earlier it now fails to load libGL.so.1. (maybe it is the same
problem
> > actually). But it was not behaving like that when I tested last week so I
> missed
> > something. I'll have a look tomorrow.
> > 
> > Btw I noticed that gl_implementation_osmesa.h::LoadLibraryAndPrintError is
> used
> > in a some places that have nothing to do with osmesa so debugging is
confusing
> > since I see traces that starts with: gl_implementation_osmesa.cc. Can I move
> it
> > to gl_implementation.h/.cc ?
> 
> Yes, please do move it. Looks like a bad refactoring somewhere along the line.

Ok I'll submit this in another CL but keep same bug id.

Also in "Patch Set 3" I added some code as "draft" because the switch
kGpuSandboxStartEarly will only work if the gpu process sandbox policy add
requires shared libraries to the white list.
I am suggesting to rename CrosArmGpuProcessPolicy to
GpuProcessPolicyEarlySandbox to generalize it in order to make it use-able for
other gl drivers that requires early sandbox (as a reminder this is needed
because these drivers start threads when creating a gl context).
GpuProcessPolicyEarlySandbox will contain specific rule for arm case but at
least of all this will be grouped in one place to serve the same purpose.
Please comment on the XXX I added, thx!

[Ken Russell (switch to Gerrit), 2016-05-04 20:36:17]

https://codereview.chromium.org/1542013005/diff/40001/content/common/sandbox_...
File content/common/sandbox_linux/bpf_cros_arm_gpu_policy_linux.cc (right):

https://codereview.chromium.org/1542013005/diff/40001/content/common/sandbox_...
content/common/sandbox_linux/bpf_cros_arm_gpu_policy_linux.cc:60: // XXX:
Generalize CrosArmGpuProcessPolicy to a new
TODO(j.isorce@samsung.com) instead of XXX, here and below

https://codereview.chromium.org/1542013005/diff/40001/content/gpu/gpu_main.cc
File content/gpu/gpu_main.cc (right):

https://codereview.chromium.org/1542013005/diff/40001/content/gpu/gpu_main.cc...
content/gpu/gpu_main.cc:508: dlopen("dri/swrast_dri.so",
RTLD_NOW|RTLD_GLOBAL|RTLD_NODELETE);
Yes, this is not acceptable to commit in its current form.

If you can't call GLSurface::InitializeOneOff() before initializing the sandbox
because the driver starts threads, and you can't call it after initializing the
sandbox because you can't touch the filesystem afterward, that's a problem.

I think you should come up with some general code which will traverse the
link-time dependencies of the OpenGL-related shared objects you need, dlopen'ing
each one. Would that solve the problem of hardcoding these shared library names?

[Julien Isorce Samsung, 2016-05-05 00:53:51]

On 2016/05/04 20:36:17, Ken Russell wrote:
>
https://codereview.chromium.org/1542013005/diff/40001/content/common/sandbox_...
> File content/common/sandbox_linux/bpf_cros_arm_gpu_policy_linux.cc (right):
> 
>
https://codereview.chromium.org/1542013005/diff/40001/content/common/sandbox_...
> content/common/sandbox_linux/bpf_cros_arm_gpu_policy_linux.cc:60: // XXX:
> Generalize CrosArmGpuProcessPolicy to a new
> mailto:TODO(j.isorce@samsung.com) instead of XXX, here and below
> 
> https://codereview.chromium.org/1542013005/diff/40001/content/gpu/gpu_main.cc
> File content/gpu/gpu_main.cc (right):
> 
>
https://codereview.chromium.org/1542013005/diff/40001/content/gpu/gpu_main.cc...
> content/gpu/gpu_main.cc:508: dlopen("dri/swrast_dri.so",
> RTLD_NOW|RTLD_GLOBAL|RTLD_NODELETE);
> Yes, this is not acceptable to commit in its current form.

Thx for the comments.

> 
> If you can't call GLSurface::InitializeOneOff() before initializing the
sandbox
> because the driver starts threads, and you can't call it after initializing
the
> sandbox because you can't touch the filesystem afterward, that's a problem.

Yes this is exactly the problem. With Mali driver they solve that by both doing
some dlopen and adding a list of accepted file for the broker process.
Initially I saw I could reuse CrosArmGpuProcessPolicy but the EvaluateSyscall
handler
is different than the one in GpuProcessPolicy so I prefer not to touch
CrosArmGpuProcessPolicy.

Moreover, looking at GpuProcessPolicy::PreSandboxHook() it seems more
appropriate to
do the dlopen there like it is done for vaapi driver. I did it in "Patch Set 4".
Please have a look, thx.

> 
> I think you should come up with some general code which will traverse the
> link-time dependencies of the OpenGL-related shared objects you need,
dlopen'ing
> each one. Would that solve the problem of hardcoding these shared library
names?

I would agree with that if I was doing a
"std::vector<BrokerFilePermission>.push_back"
In that case I would indeed need to white list each dependency. But since I use
dlopen(RTLD_NOW)
it will load all dependencies automatically. But maybe I miss understood your
remark.
Just to clarify, the "Patch Set 4" is a solution for the issue 264818 ("Path Set
3" too).
Thx!

[Ken Russell (switch to Gerrit), 2016-05-05 21:38:04]

I'm not sure it's a good idea to hardcode these library names and the location
of swrast_dri.so, but if piman re-reviews this, then lgtm.

https://codereview.chromium.org/1542013005/diff/80001/content/common/sandbox_...
File content/common/sandbox_linux/bpf_gpu_policy_linux.cc (right):

https://codereview.chromium.org/1542013005/diff/80001/content/common/sandbox_...
content/common/sandbox_linux/bpf_gpu_policy_linux.cc:352: // FIXME(j.isorce):
During gyp/gn step parse "dridriverdir" variable from
FIXME -> TODO

[Julien Isorce Samsung, 2016-05-06 14:44:11]

On 2016/05/05 21:38:04, Ken Russell wrote:
> I'm not sure it's a good idea to hardcode these library names and the location
> of swrast_dri.so, but if piman re-reviews this, then lgtm.

Thx Ken for your comments and review. In "Patch Set 6" that I just uploaded, I
made all of this generic.

> 
>
https://codereview.chromium.org/1542013005/diff/80001/content/common/sandbox_...
> File content/common/sandbox_linux/bpf_gpu_policy_linux.cc (right):
> 
>
https://codereview.chromium.org/1542013005/diff/80001/content/common/sandbox_...
> content/common/sandbox_linux/bpf_gpu_policy_linux.cc:352: // FIXME(j.isorce):
> During gyp/gn step parse "dridriverdir" variable from
> FIXME -> TODO

Done in Patch Set 6.

Antoine, please re-review because I added more changes since your last stamp.
Thx!

[Julien Isorce Samsung, 2016-05-06 16:55:09]

The CQ bit was checked by j.isorce@samsung.com to run a CQ dry run

[commit-bot: I haz the power, 2016-05-06 16:55:27]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1542013005/120001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1542013005/120001

[commit-bot: I haz the power, 2016-05-06 17:09:44]

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

[commit-bot: I haz the power, 2016-05-06 17:09:45]

Dry run: Try jobs failed on following builders:
  android_compile_dbg on tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_comp...)
  cast_shell_android on tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/cast_shell_a...)
  chromeos_daisy_chromium_compile_only_ng on tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_daisy_...)

[piman, 2016-05-06 19:53:10]

piman@chromium.org changed reviewers:
+ mdempsky@chromium.org

[piman, 2016-05-06 19:53:11]

+mdempsky to review the sandbox changes and agree to the general direction.

https://codereview.chromium.org/1542013005/diff/120001/base/sys_info_posix.cc
File base/sys_info_posix.cc (right):

https://codereview.chromium.org/1542013005/diff/120001/base/sys_info_posix.cc...
base/sys_info_posix.cc:117: if (!strlen(info.release) && uname(&info) < 0) {
This is not thread safe. Why the change?

[Julien Isorce Samsung, 2016-05-07 08:18:13]

https://codereview.chromium.org/1542013005/diff/120001/base/sys_info_posix.cc
File base/sys_info_posix.cc (right):

https://codereview.chromium.org/1542013005/diff/120001/base/sys_info_posix.cc...
base/sys_info_posix.cc:117: if (!strlen(info.release) && uname(&info) < 0) {
On 2016/05/06 19:53:11, piman wrote:
> This is not thread safe. Why the change?

Txh for pointing that, well I made this change because uname is used from
GpuControlList when calling gpu::ApplyGpuDriverBugWorkarounds. This is a problem
when switches::kGpuSandboxStartEarly is set. On arm when kGpuSandboxStartEarly
is set they solve that by enabling uname from the sandbox policy directly since
they do not use the common GpuProcessPolicy but they use
CrosArmGpuProcessPolicy::EvaluateSyscall instead.

[Julien Isorce Samsung, 2016-05-07 08:19:00]

The CQ bit was checked by j.isorce@samsung.com to run a CQ dry run

[commit-bot: I haz the power, 2016-05-07 08:19:13]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1542013005/140001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1542013005/140001

[commit-bot: I haz the power, 2016-05-07 08:45:26]

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

[commit-bot: I haz the power, 2016-05-07 08:45:27]

Dry run: Try jobs failed on following builders:
  chromeos_daisy_chromium_compile_only_ng on tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_daisy_...)

[Julien Isorce Samsung, 2016-05-07 13:16:18]

The CQ bit was checked by j.isorce@samsung.com to run a CQ dry run

[commit-bot: I haz the power, 2016-05-07 13:16:31]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1542013005/160001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1542013005/160001

[commit-bot: I haz the power, 2016-05-07 14:37:59]

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

[commit-bot: I haz the power, 2016-05-07 14:38:00]

Dry run: Try jobs failed on following builders:
  linux_chromium_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Julien Isorce Samsung, 2016-05-07 16:09:07]

The CQ bit was checked by j.isorce@samsung.com to run a CQ dry run

[commit-bot: I haz the power, 2016-05-07 16:09:18]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1542013005/180001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1542013005/180001

[commit-bot: I haz the power, 2016-05-07 17:41:11]

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

[commit-bot: I haz the power, 2016-05-07 17:41:12]

Dry run: This issue passed the CQ dry run.

[Julien Isorce Samsung, 2016-05-10 14:47:39]

Description was changed from

==========
Add a new driver bug workaround SANDBOX_START_EARLY

It is usefull for drivers that create threads so that
it requires to start the sandbox first.
It is not really a bug but it fits with workarounds.

This CL also add a json entry for llvmpipe driver from Mesa
to enable this new driver bug woraround.

A new json entry could be added for Mali driver. According
to gpu_main.cc this driver creates threads.

BUG=264818

R=kbr@chromium.org, piman@chromium.org, zmo@chromium.org

TEST= GALLIUM_DRIVER=llvmpipe LIBGL_ALWAYS_SOFTWARE=1
CHROME_DEVEL_SANDBOX=out/Release/chrome_sandbox
It prints:
ERROR:sandbox_linux.cc(333)] InitializeSandbox() called with
multiple threads in process gpu-process

Review URL:
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_optional_gpu_tests_rel;tryserver.chromium.mac:mac_optional_gpu_tests_rel;tryserver.chromium.win:win_optional_gpu_tests_rel
==========

to

==========
Add a new driver bug workaround SANDBOX_START_EARLY

It is usefull for drivers that create threads so that
it requires to start the sandbox first.
It is not really a bug but it fits with workarounds.

This CL also add a json entry for llvmpipe driver from Mesa
to enable this new driver bug woraround.

A new json entry could be added for Mali driver. According
to gpu_main.cc this driver creates threads.

BUG=264818

R=kbr@chromium.org, mdempsky@chromium.org, piman@chromium.org, zmo@chromium.org

TEST= GALLIUM_DRIVER=llvmpipe LIBGL_ALWAYS_SOFTWARE=1
CHROME_DEVEL_SANDBOX=out/Release/chrome_sandbox
It prints:
ERROR:sandbox_linux.cc(333)] InitializeSandbox() called with
multiple threads in process gpu-process

Review URL:
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_optional_gpu_tests_rel;tryserver.chromium.mac:mac_optional_gpu_tests_rel;tryserver.chromium.win:win_optional_gpu_tests_rel
==========

[Julien Isorce Samsung, 2016-05-10 15:31:57]

The CQ bit was checked by j.isorce@samsung.com to run a CQ dry run

[commit-bot: I haz the power, 2016-05-10 15:32:19]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1542013005/200001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1542013005/200001

[commit-bot: I haz the power, 2016-05-10 18:00:17]

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

[commit-bot: I haz the power, 2016-05-10 18:00:18]

Dry run: This issue passed the CQ dry run.

[Julien Isorce Samsung, 2016-05-16 09:36:24]

On 2016/05/06 19:53:11, piman OOO back 2016-5-16 wrote:
> +mdempsky to review the sandbox changes and agree to the general direction.
> 

Hi mdempsky, gentle reminder. Thx.

[piman, 2016-05-16 19:29:54]

piman@chromium.org changed reviewers:
+ rickyz@chromium.org
- mdempsky@chromium.org

[piman, 2016-05-16 19:30:46]

-mdempsky +rickyz
Ricky, do you have time to take a look at the direction here?

[rickyz (no longer on Chrome), 2016-05-16 23:07:10]

On 2016/05/16 at 19:30:46, piman wrote:
> -mdempsky +rickyz
> Ricky, do you have time to take a look at the direction here?

Hi, I don't understand from the description what problem this change is fixing -
was there a driver that did not work prior to this change? Or does this allow
enabling the sandbox from a single-threaded context?

[Julien Isorce Samsung, 2016-05-16 23:39:34]

On 2016/05/16 23:07:10, rickyz wrote:
> On 2016/05/16 at 19:30:46, piman wrote:
> > -mdempsky +rickyz
> > Ricky, do you have time to take a look at the direction here?
> 
> Hi, I don't understand from the description what problem this change is fixing
-
> was there a driver that did not work prior to this change? Or does this allow
> enabling the sandbox from a single-threaded context?

Hi Ricky, thx for taking the time to look at this issue.
This CL allows to use the Mesa llvmpipe software driver with a sandboxed GPU
process.
The current behavior is: "ERROR:sandbox_linux.cc(333)] InitializeSandbox()
called with multiple threads in process gpu-process"
This CL is required because this driver starts threads during gl initialization.
Initially I thought I could just use existing kGpuSandboxStartEarly but I
realized that mechanism
is currently meant to be used only with CrosArmGpuProcessPolicy instead of the
generic content/common/sandbox_linux/bpf_gpu_policy_linux.cc::GpuProcessPolicy.
This CL improves the later to dlopen(RTLD_NOW) the required gl libraries to
satisfy kGpuSandboxStartEarly logic, i.e. start the seccomp bpf sandbox earlier
but allow to initialize gl afterward.
Let me know if you need more details.
Julien

[rickyz (no longer on Chrome), 2016-05-16 23:41:18]

On 2016/05/16 at 23:39:34, j.isorce wrote:
> On 2016/05/16 23:07:10, rickyz wrote:
> > On 2016/05/16 at 19:30:46, piman wrote:
> > > -mdempsky +rickyz
> > > Ricky, do you have time to take a look at the direction here?
> > 
> > Hi, I don't understand from the description what problem this change is
fixing -
> > was there a driver that did not work prior to this change? Or does this
allow
> > enabling the sandbox from a single-threaded context?
> 
> Hi Ricky, thx for taking the time to look at this issue.
> This CL allows to use the Mesa llvmpipe software driver with a sandboxed GPU
process.
> The current behavior is: "ERROR:sandbox_linux.cc(333)] InitializeSandbox()
called with multiple threads in process gpu-process"
> This CL is required because this driver starts threads during gl
initialization.
> Initially I thought I could just use existing kGpuSandboxStartEarly but I
realized that mechanism
> is currently meant to be used only with CrosArmGpuProcessPolicy instead of the
generic content/common/sandbox_linux/bpf_gpu_policy_linux.cc::GpuProcessPolicy.
> This CL improves the later to dlopen(RTLD_NOW) the required gl libraries to
satisfy kGpuSandboxStartEarly logic, i.e. start the seccomp bpf sandbox earlier
> but allow to initialize gl afterward.
> Let me know if you need more details.
> Julien

Does this mean that the threads it starts are destroyed after initialization, so
the process will be single-threaded when the sandbox is enabled?

[Julien Isorce Samsung, 2016-05-16 23:45:12]

On 2016/05/16 23:41:18, rickyz wrote:
> On 2016/05/16 at 23:39:34, j.isorce wrote:
> > On 2016/05/16 23:07:10, rickyz wrote:
> > > On 2016/05/16 at 19:30:46, piman wrote:
> > > > -mdempsky +rickyz
> > > > Ricky, do you have time to take a look at the direction here?
> > > 
> > > Hi, I don't understand from the description what problem this change is
> fixing -
> > > was there a driver that did not work prior to this change? Or does this
> allow
> > > enabling the sandbox from a single-threaded context?
> > 
> > Hi Ricky, thx for taking the time to look at this issue.
> > This CL allows to use the Mesa llvmpipe software driver with a sandboxed GPU
> process.
> > The current behavior is: "ERROR:sandbox_linux.cc(333)] InitializeSandbox()
> called with multiple threads in process gpu-process"
> > This CL is required because this driver starts threads during gl
> initialization.
> > Initially I thought I could just use existing kGpuSandboxStartEarly but I
> realized that mechanism
> > is currently meant to be used only with CrosArmGpuProcessPolicy instead of
the
> generic
content/common/sandbox_linux/bpf_gpu_policy_linux.cc::GpuProcessPolicy.
> > This CL improves the later to dlopen(RTLD_NOW) the required gl libraries to
> satisfy kGpuSandboxStartEarly logic, i.e. start the seccomp bpf sandbox
earlier
> > but allow to initialize gl afterward.
> > Let me know if you need more details.
> > Julien
> 
> Does this mean that the threads it starts are destroyed after initialization,
so
> the process will be single-threaded when the sandbox is enabled?

The threads are not destroyed after initialization. This software driver
starts as many threads as there are cpus and use them to parallelize
computation.

[rickyz (no longer on Chrome), 2016-05-16 23:47:40]

On 2016/05/16 at 23:45:12, j.isorce wrote:
> On 2016/05/16 23:41:18, rickyz wrote:
> > On 2016/05/16 at 23:39:34, j.isorce wrote:
> > > On 2016/05/16 23:07:10, rickyz wrote:
> > > > On 2016/05/16 at 19:30:46, piman wrote:
> > > > > -mdempsky +rickyz
> > > > > Ricky, do you have time to take a look at the direction here?
> > > > 
> > > > Hi, I don't understand from the description what problem this change is
> > fixing -
> > > > was there a driver that did not work prior to this change? Or does this
> > allow
> > > > enabling the sandbox from a single-threaded context?
> > > 
> > > Hi Ricky, thx for taking the time to look at this issue.
> > > This CL allows to use the Mesa llvmpipe software driver with a sandboxed
GPU
> > process.
> > > The current behavior is: "ERROR:sandbox_linux.cc(333)] InitializeSandbox()
> > called with multiple threads in process gpu-process"
> > > This CL is required because this driver starts threads during gl
> > initialization.
> > > Initially I thought I could just use existing kGpuSandboxStartEarly but I
> > realized that mechanism
> > > is currently meant to be used only with CrosArmGpuProcessPolicy instead of
the
> > generic
content/common/sandbox_linux/bpf_gpu_policy_linux.cc::GpuProcessPolicy.
> > > This CL improves the later to dlopen(RTLD_NOW) the required gl libraries
to
> > satisfy kGpuSandboxStartEarly logic, i.e. start the seccomp bpf sandbox
earlier
> > > but allow to initialize gl afterward.
> > > Let me know if you need more details.
> > > Julien
> > 
> > Does this mean that the threads it starts are destroyed after
initialization, so
> > the process will be single-threaded when the sandbox is enabled?
> 
> The threads are not destroyed after initialization. This software driver
> starts as many threads as there are cpus and use them to parallelize
computation.

If those threads aren't destroyed after initialization, then that error message
is accurate, right? Would the process would fail to start before this change, or
was the only issue that error message?

[Julien Isorce Samsung, 2016-05-16 23:57:13]

On 2016/05/16 23:47:40, rickyz wrote:
> On 2016/05/16 at 23:45:12, j.isorce wrote:
> > On 2016/05/16 23:41:18, rickyz wrote:
> > > On 2016/05/16 at 23:39:34, j.isorce wrote:
> > > > On 2016/05/16 23:07:10, rickyz wrote:
> > > > > On 2016/05/16 at 19:30:46, piman wrote:
> > > > > > -mdempsky +rickyz
> > > > > > Ricky, do you have time to take a look at the direction here?
> > > > > 
> > > > > Hi, I don't understand from the description what problem this change
is
> > > fixing -
> > > > > was there a driver that did not work prior to this change? Or does
this
> > > allow
> > > > > enabling the sandbox from a single-threaded context?
> > > > 
> > > > Hi Ricky, thx for taking the time to look at this issue.
> > > > This CL allows to use the Mesa llvmpipe software driver with a sandboxed
> GPU
> > > process.
> > > > The current behavior is: "ERROR:sandbox_linux.cc(333)]
InitializeSandbox()
> > > called with multiple threads in process gpu-process"
> > > > This CL is required because this driver starts threads during gl
> > > initialization.
> > > > Initially I thought I could just use existing kGpuSandboxStartEarly but
I
> > > realized that mechanism
> > > > is currently meant to be used only with CrosArmGpuProcessPolicy instead
of
> the
> > > generic
> content/common/sandbox_linux/bpf_gpu_policy_linux.cc::GpuProcessPolicy.
> > > > This CL improves the later to dlopen(RTLD_NOW) the required gl libraries
> to
> > > satisfy kGpuSandboxStartEarly logic, i.e. start the seccomp bpf sandbox
> earlier
> > > > but allow to initialize gl afterward.
> > > > Let me know if you need more details.
> > > > Julien
> > > 
> > > Does this mean that the threads it starts are destroyed after
> initialization, so
> > > the process will be single-threaded when the sandbox is enabled?
> > 
> > The threads are not destroyed after initialization. This software driver
> > starts as many threads as there are cpus and use them to parallelize
> computation.
> 
> If those threads aren't destroyed after initialization, then that error
message
> is accurate, right?

Yes it is.

> Would the process would fail to start before this change, or was the only
> issue that error message?

Without this CL, this gpu process fails to start because of that only error. In
other words
the gpu process succeeds to start if the user append either --no-sandbox or
--disable-gpu-sandbox.
Maybe you are missing the fact that this software driver has been white listed
recently, some weeks ago it would
have required to append --ignore-gpu-blacklist.

[rickyz (no longer on Chrome), 2016-05-17 00:03:23]

On 2016/05/16 at 23:57:13, j.isorce wrote:
> On 2016/05/16 23:47:40, rickyz wrote:
> > On 2016/05/16 at 23:45:12, j.isorce wrote:
> > > On 2016/05/16 23:41:18, rickyz wrote:
> > > > On 2016/05/16 at 23:39:34, j.isorce wrote:
> > > > > On 2016/05/16 23:07:10, rickyz wrote:
> > > > > > On 2016/05/16 at 19:30:46, piman wrote:
> > > > > > > -mdempsky +rickyz
> > > > > > > Ricky, do you have time to take a look at the direction here?
> > > > > > 
> > > > > > Hi, I don't understand from the description what problem this change
is
> > > > fixing -
> > > > > > was there a driver that did not work prior to this change? Or does
this
> > > > allow
> > > > > > enabling the sandbox from a single-threaded context?
> > > > > 
> > > > > Hi Ricky, thx for taking the time to look at this issue.
> > > > > This CL allows to use the Mesa llvmpipe software driver with a
sandboxed
> > GPU
> > > > process.
> > > > > The current behavior is: "ERROR:sandbox_linux.cc(333)]
InitializeSandbox()
> > > > called with multiple threads in process gpu-process"
> > > > > This CL is required because this driver starts threads during gl
> > > > initialization.
> > > > > Initially I thought I could just use existing kGpuSandboxStartEarly
but I
> > > > realized that mechanism
> > > > > is currently meant to be used only with CrosArmGpuProcessPolicy
instead of
> > the
> > > > generic
> > content/common/sandbox_linux/bpf_gpu_policy_linux.cc::GpuProcessPolicy.
> > > > > This CL improves the later to dlopen(RTLD_NOW) the required gl
libraries
> > to
> > > > satisfy kGpuSandboxStartEarly logic, i.e. start the seccomp bpf sandbox
> > earlier
> > > > > but allow to initialize gl afterward.
> > > > > Let me know if you need more details.
> > > > > Julien
> > > > 
> > > > Does this mean that the threads it starts are destroyed after
> > initialization, so
> > > > the process will be single-threaded when the sandbox is enabled?
> > > 
> > > The threads are not destroyed after initialization. This software driver
> > > starts as many threads as there are cpus and use them to parallelize
> > computation.
> > 
> > If those threads aren't destroyed after initialization, then that error
message
> > is accurate, right?
> 
> Yes it is.
> 
> > Would the process would fail to start before this change, or was the only
> > issue that error message?
> 
> Without this CL, this gpu process fails to start because of that only error.
In other words
> the gpu process succeeds to start if the user append either --no-sandbox or
--disable-gpu-sandbox.
> Maybe you are missing the fact that this software driver has been white listed
recently, some weeks ago it would
> have required to append --ignore-gpu-blacklist.

Hm, that error isn't fatal, so it shouldn't be responsible by itself for
preventing the driver from starting. I think there's a different root cause for
the GPU process failure that happens to be avoided or hidden by dlopening the
library first. I'd prefer to figure out what that is and if there is a nicer
solution than dlopening the driver unsandboxed.

[Julien Isorce Samsung, 2016-05-17 00:28:38]

On 2016/05/17 00:03:23, rickyz wrote:
> On 2016/05/16 at 23:57:13, j.isorce wrote:
> > On 2016/05/16 23:47:40, rickyz wrote:
> > > On 2016/05/16 at 23:45:12, j.isorce wrote:
> > > > On 2016/05/16 23:41:18, rickyz wrote:
> > > > > On 2016/05/16 at 23:39:34, j.isorce wrote:
> > > > > > On 2016/05/16 23:07:10, rickyz wrote:
> > > > > > > On 2016/05/16 at 19:30:46, piman wrote:
> > > > > > > > -mdempsky +rickyz
> > > > > > > > Ricky, do you have time to take a look at the direction here?
> > > > > > > 
> > > > > > > Hi, I don't understand from the description what problem this
change
> is
> > > > > fixing -
> > > > > > > was there a driver that did not work prior to this change? Or does
> this
> > > > > allow
> > > > > > > enabling the sandbox from a single-threaded context?
> > > > > > 
> > > > > > Hi Ricky, thx for taking the time to look at this issue.
> > > > > > This CL allows to use the Mesa llvmpipe software driver with a
> sandboxed
> > > GPU
> > > > > process.
> > > > > > The current behavior is: "ERROR:sandbox_linux.cc(333)]
> InitializeSandbox()
> > > > > called with multiple threads in process gpu-process"
> > > > > > This CL is required because this driver starts threads during gl
> > > > > initialization.
> > > > > > Initially I thought I could just use existing kGpuSandboxStartEarly
> but I
> > > > > realized that mechanism
> > > > > > is currently meant to be used only with CrosArmGpuProcessPolicy
> instead of
> > > the
> > > > > generic
> > > content/common/sandbox_linux/bpf_gpu_policy_linux.cc::GpuProcessPolicy.
> > > > > > This CL improves the later to dlopen(RTLD_NOW) the required gl
> libraries
> > > to
> > > > > satisfy kGpuSandboxStartEarly logic, i.e. start the seccomp bpf
sandbox
> > > earlier
> > > > > > but allow to initialize gl afterward.
> > > > > > Let me know if you need more details.
> > > > > > Julien
> > > > > 
> > > > > Does this mean that the threads it starts are destroyed after
> > > initialization, so
> > > > > the process will be single-threaded when the sandbox is enabled?
> > > > 
> > > > The threads are not destroyed after initialization. This software driver
> > > > starts as many threads as there are cpus and use them to parallelize
> > > computation.
> > > 
> > > If those threads aren't destroyed after initialization, then that error
> message
> > > is accurate, right?
> > 
> > Yes it is.
> > 
> > > Would the process would fail to start before this change, or was the only
> > > issue that error message?
> > 
> > Without this CL, this gpu process fails to start because of that only error.
> In other words
> > the gpu process succeeds to start if the user append either --no-sandbox or
> --disable-gpu-sandbox.
> > Maybe you are missing the fact that this software driver has been white
listed
> recently, some weeks ago it would
> > have required to append --ignore-gpu-blacklist.
> 
> Hm, that error isn't fatal, so it shouldn't be responsible by itself for
> preventing the driver from starting. I think there's a different root cause
for
> the GPU process failure that happens to be avoided or hidden by dlopening the
> library first. I'd prefer to figure out what that is and if there is a nicer
> solution than dlopening the driver unsandboxed.

Sorry I was wrong in my very last comment, the gpu process starts even with that
error message we are talking about, so you are right it is not fatal. I have
double checked some minutes ago. Sorry about that I think I got confused at some
point.
The only problem is that the sandbox is not actually activated.

[Julien Isorce Samsung, 2016-05-17 00:44:05]

On 2016/05/17 00:28:38, j.isorce wrote:
> On 2016/05/17 00:03:23, rickyz wrote:
> > On 2016/05/16 at 23:57:13, j.isorce wrote:
> > > On 2016/05/16 23:47:40, rickyz wrote:
> > > > On 2016/05/16 at 23:45:12, j.isorce wrote:
> > > > > On 2016/05/16 23:41:18, rickyz wrote:
> > > > > > On 2016/05/16 at 23:39:34, j.isorce wrote:
> > > > > > > On 2016/05/16 23:07:10, rickyz wrote:
> > > > > > > > On 2016/05/16 at 19:30:46, piman wrote:
> > > > > > > > > -mdempsky +rickyz
> > > > > > > > > Ricky, do you have time to take a look at the direction here?
> > > > > > > > 
> > > > > > > > Hi, I don't understand from the description what problem this
> change
> > is
> > > > > > fixing -
> > > > > > > > was there a driver that did not work prior to this change? Or
does
> > this
> > > > > > allow
> > > > > > > > enabling the sandbox from a single-threaded context?
> > > > > > > 
> > > > > > > Hi Ricky, thx for taking the time to look at this issue.
> > > > > > > This CL allows to use the Mesa llvmpipe software driver with a
> > sandboxed
> > > > GPU
> > > > > > process.
> > > > > > > The current behavior is: "ERROR:sandbox_linux.cc(333)]
> > InitializeSandbox()
> > > > > > called with multiple threads in process gpu-process"
> > > > > > > This CL is required because this driver starts threads during gl
> > > > > > initialization.
> > > > > > > Initially I thought I could just use existing
kGpuSandboxStartEarly
> > but I
> > > > > > realized that mechanism
> > > > > > > is currently meant to be used only with CrosArmGpuProcessPolicy
> > instead of
> > > > the
> > > > > > generic
> > > > content/common/sandbox_linux/bpf_gpu_policy_linux.cc::GpuProcessPolicy.
> > > > > > > This CL improves the later to dlopen(RTLD_NOW) the required gl
> > libraries
> > > > to
> > > > > > satisfy kGpuSandboxStartEarly logic, i.e. start the seccomp bpf
> sandbox
> > > > earlier
> > > > > > > but allow to initialize gl afterward.
> > > > > > > Let me know if you need more details.
> > > > > > > Julien
> > > > > > 
> > > > > > Does this mean that the threads it starts are destroyed after
> > > > initialization, so
> > > > > > the process will be single-threaded when the sandbox is enabled?
> > > > > 
> > > > > The threads are not destroyed after initialization. This software
driver
> > > > > starts as many threads as there are cpus and use them to parallelize
> > > > computation.
> > > > 
> > > > If those threads aren't destroyed after initialization, then that error
> > message
> > > > is accurate, right?
> > > 
> > > Yes it is.
> > > 
> > > > Would the process would fail to start before this change, or was the
only
> > > > issue that error message?
> > > 
> > > Without this CL, this gpu process fails to start because of that only
error.
> > In other words
> > > the gpu process succeeds to start if the user append either --no-sandbox
or
> > --disable-gpu-sandbox.
> > > Maybe you are missing the fact that this software driver has been white
> listed
> > recently, some weeks ago it would
> > > have required to append --ignore-gpu-blacklist.
> > 
> > Hm, that error isn't fatal, so it shouldn't be responsible by itself for
> > preventing the driver from starting. I think there's a different root cause
> for
> > the GPU process failure that happens to be avoided or hidden by dlopening
the
> > library first. I'd prefer to figure out what that is and if there is a nicer
> > solution than dlopening the driver unsandboxed.
> 
> Sorry I was wrong in my very last comment, the gpu process starts even with
that
> error message we are talking about, so you are right it is not fatal. I have
> double checked some minutes ago. Sorry about that I think I got confused at
some
> point.
> The only problem is that the sandbox is not actually activated.

Indeed in chrome://gpu contains a field "Sandboxed false".
With this CL it becomes true. (with and without this CL, the field "In-process
GPU" in chrome://gpu is false, and
Chromium task manager shows the GPU process and chrome://gpu shows "WebGL:
Hardware accelerated but at reduced performance"
in both cases)

> if there is a nicer solution than dlopening the driver unsandboxed.

Note that even not talking about this CL, the real hardware GL drivers are
always dlopen unsandboxed, though it is a RTLD_LAZY
(not RTLD_NOW). See
src/ui/gl/gl_implementation_x11.cc::LoadLibraryAndPrintError(kGLLibraryName)
which is called from
gpu_main.cc::"gfx::GLSurface::InitializeOneOff()"
Or maybe you was not talking about the GL libs but about the *_dri.so driver
libs ?
Thx for your comments.

[rickyz (no longer on Chrome), 2016-05-17 00:47:40]

On 2016/05/17 at 00:28:38, j.isorce wrote:
> On 2016/05/17 00:03:23, rickyz wrote:
> > On 2016/05/16 at 23:57:13, j.isorce wrote:
> > > On 2016/05/16 23:47:40, rickyz wrote:
> > > > On 2016/05/16 at 23:45:12, j.isorce wrote:
> > > > > On 2016/05/16 23:41:18, rickyz wrote:
> > > > > > On 2016/05/16 at 23:39:34, j.isorce wrote:
> > > > > > > On 2016/05/16 23:07:10, rickyz wrote:
> > > > > > > > On 2016/05/16 at 19:30:46, piman wrote:
> > > > > > > > > -mdempsky +rickyz
> > > > > > > > > Ricky, do you have time to take a look at the direction here?
> > > > > > > > 
> > > > > > > > Hi, I don't understand from the description what problem this
change
> > is
> > > > > > fixing -
> > > > > > > > was there a driver that did not work prior to this change? Or
does
> > this
> > > > > > allow
> > > > > > > > enabling the sandbox from a single-threaded context?
> > > > > > > 
> > > > > > > Hi Ricky, thx for taking the time to look at this issue.
> > > > > > > This CL allows to use the Mesa llvmpipe software driver with a
> > sandboxed
> > > > GPU
> > > > > > process.
> > > > > > > The current behavior is: "ERROR:sandbox_linux.cc(333)]
> > InitializeSandbox()
> > > > > > called with multiple threads in process gpu-process"
> > > > > > > This CL is required because this driver starts threads during gl
> > > > > > initialization.
> > > > > > > Initially I thought I could just use existing
kGpuSandboxStartEarly
> > but I
> > > > > > realized that mechanism
> > > > > > > is currently meant to be used only with CrosArmGpuProcessPolicy
> > instead of
> > > > the
> > > > > > generic
> > > > content/common/sandbox_linux/bpf_gpu_policy_linux.cc::GpuProcessPolicy.
> > > > > > > This CL improves the later to dlopen(RTLD_NOW) the required gl
> > libraries
> > > > to
> > > > > > satisfy kGpuSandboxStartEarly logic, i.e. start the seccomp bpf
sandbox
> > > > earlier
> > > > > > > but allow to initialize gl afterward.
> > > > > > > Let me know if you need more details.
> > > > > > > Julien
> > > > > > 
> > > > > > Does this mean that the threads it starts are destroyed after
> > > > initialization, so
> > > > > > the process will be single-threaded when the sandbox is enabled?
> > > > > 
> > > > > The threads are not destroyed after initialization. This software
driver
> > > > > starts as many threads as there are cpus and use them to parallelize
> > > > computation.
> > > > 
> > > > If those threads aren't destroyed after initialization, then that error
> > message
> > > > is accurate, right?
> > > 
> > > Yes it is.
> > > 
> > > > Would the process would fail to start before this change, or was the
only
> > > > issue that error message?
> > > 
> > > Without this CL, this gpu process fails to start because of that only
error.
> > In other words
> > > the gpu process succeeds to start if the user append either --no-sandbox
or
> > --disable-gpu-sandbox.
> > > Maybe you are missing the fact that this software driver has been white
listed
> > recently, some weeks ago it would
> > > have required to append --ignore-gpu-blacklist.
> > 
> > Hm, that error isn't fatal, so it shouldn't be responsible by itself for
> > preventing the driver from starting. I think there's a different root cause
for
> > the GPU process failure that happens to be avoided or hidden by dlopening
the
> > library first. I'd prefer to figure out what that is and if there is a nicer
> > solution than dlopening the driver unsandboxed.
> 
> Sorry I was wrong in my very last comment, the gpu process starts even with
that
> error message we are talking about, so you are right it is not fatal. I have
> double checked some minutes ago. Sorry about that I think I got confused at
some point.
> The only problem is that the sandbox is not actually activated.

Yeah, the sandbox won't be enabled, but that should be the case even after this
change.

It might be useful to investigate attempting to use the seccomp tsync feature
(SeccompLevel::MULTI_THREADED in chromium) as a best effort when GPU drivers
create threads, if you're interested - though I should warn that it will be
quite challenge to do this without lots of painful breakage, since these drivers
may expect to do many other things normally blocked by the sandbox.

[rickyz (no longer on Chrome), 2016-05-17 00:55:17]

On 2016/05/17 at 00:47:40, rickyz wrote:
> On 2016/05/17 at 00:28:38, j.isorce wrote:
> > On 2016/05/17 00:03:23, rickyz wrote:
> > > On 2016/05/16 at 23:57:13, j.isorce wrote:
> > > > On 2016/05/16 23:47:40, rickyz wrote:
> > > > > On 2016/05/16 at 23:45:12, j.isorce wrote:
> > > > > > On 2016/05/16 23:41:18, rickyz wrote:
> > > > > > > On 2016/05/16 at 23:39:34, j.isorce wrote:
> > > > > > > > On 2016/05/16 23:07:10, rickyz wrote:
> > > > > > > > > On 2016/05/16 at 19:30:46, piman wrote:
> > > > > > > > > > -mdempsky +rickyz
> > > > > > > > > > Ricky, do you have time to take a look at the direction
here?
> > > > > > > > > 
> > > > > > > > > Hi, I don't understand from the description what problem this
change
> > > is
> > > > > > > fixing -
> > > > > > > > > was there a driver that did not work prior to this change? Or
does
> > > this
> > > > > > > allow
> > > > > > > > > enabling the sandbox from a single-threaded context?
> > > > > > > > 
> > > > > > > > Hi Ricky, thx for taking the time to look at this issue.
> > > > > > > > This CL allows to use the Mesa llvmpipe software driver with a
> > > sandboxed
> > > > > GPU
> > > > > > > process.
> > > > > > > > The current behavior is: "ERROR:sandbox_linux.cc(333)]
> > > InitializeSandbox()
> > > > > > > called with multiple threads in process gpu-process"
> > > > > > > > This CL is required because this driver starts threads during gl
> > > > > > > initialization.
> > > > > > > > Initially I thought I could just use existing
kGpuSandboxStartEarly
> > > but I
> > > > > > > realized that mechanism
> > > > > > > > is currently meant to be used only with CrosArmGpuProcessPolicy
> > > instead of
> > > > > the
> > > > > > > generic
> > > > >
content/common/sandbox_linux/bpf_gpu_policy_linux.cc::GpuProcessPolicy.
> > > > > > > > This CL improves the later to dlopen(RTLD_NOW) the required gl
> > > libraries
> > > > > to
> > > > > > > satisfy kGpuSandboxStartEarly logic, i.e. start the seccomp bpf
sandbox
> > > > > earlier
> > > > > > > > but allow to initialize gl afterward.
> > > > > > > > Let me know if you need more details.
> > > > > > > > Julien
> > > > > > > 
> > > > > > > Does this mean that the threads it starts are destroyed after
> > > > > initialization, so
> > > > > > > the process will be single-threaded when the sandbox is enabled?
> > > > > > 
> > > > > > The threads are not destroyed after initialization. This software
driver
> > > > > > starts as many threads as there are cpus and use them to parallelize
> > > > > computation.
> > > > > 
> > > > > If those threads aren't destroyed after initialization, then that
error
> > > message
> > > > > is accurate, right?
> > > > 
> > > > Yes it is.
> > > > 
> > > > > Would the process would fail to start before this change, or was the
only
> > > > > issue that error message?
> > > > 
> > > > Without this CL, this gpu process fails to start because of that only
error.
> > > In other words
> > > > the gpu process succeeds to start if the user append either --no-sandbox
or
> > > --disable-gpu-sandbox.
> > > > Maybe you are missing the fact that this software driver has been white
listed
> > > recently, some weeks ago it would
> > > > have required to append --ignore-gpu-blacklist.
> > > 
> > > Hm, that error isn't fatal, so it shouldn't be responsible by itself for
> > > preventing the driver from starting. I think there's a different root
cause for
> > > the GPU process failure that happens to be avoided or hidden by dlopening
the
> > > library first. I'd prefer to figure out what that is and if there is a
nicer
> > > solution than dlopening the driver unsandboxed.
> > 
> > Sorry I was wrong in my very last comment, the gpu process starts even with
that
> > error message we are talking about, so you are right it is not fatal. I have
> > double checked some minutes ago. Sorry about that I think I got confused at
some point.
> > The only problem is that the sandbox is not actually activated.
> 
> Yeah, the sandbox won't be enabled, but that should be the case even after
this change.
> 
> It might be useful to investigate attempting to use the seccomp tsync feature
(SeccompLevel::MULTI_THREADED in chromium) as a best effort when GPU drivers
create threads, if you're interested - though I should warn that it will be
quite challenge to do this without lots of painful breakage, since these drivers
may expect to do many other things normally blocked by the sandbox.

Just saw your other reply. I think I might be misunderstanding what this change
does - my assumption was that the threads would be started immediately upon
dlopening the driver, but it seems like that's not the case if this change is
causing the threads to start after the sandbox is enabled.

[Julien Isorce Samsung, 2016-05-17 17:38:44]

On 2016/05/17 00:55:17, rickyz wrote:
> On 2016/05/17 at 00:47:40, rickyz wrote:
> > On 2016/05/17 at 00:28:38, j.isorce wrote:
> > > On 2016/05/17 00:03:23, rickyz wrote:
> > > > On 2016/05/16 at 23:57:13, j.isorce wrote:
> > > > > On 2016/05/16 23:47:40, rickyz wrote:
> > > > > > On 2016/05/16 at 23:45:12, j.isorce wrote:
> > > > > > > On 2016/05/16 23:41:18, rickyz wrote:
> > > > > > > > On 2016/05/16 at 23:39:34, j.isorce wrote:
> > > > > > > > > On 2016/05/16 23:07:10, rickyz wrote:
> > > > > > > > > > On 2016/05/16 at 19:30:46, piman wrote:
> > > > > > > > > > > -mdempsky +rickyz
> > > > > > > > > > > Ricky, do you have time to take a look at the direction
> here?
> > > > > > > > > > 
> > > > > > > > > > Hi, I don't understand from the description what problem
this
> change
> > > > is
> > > > > > > > fixing -
> > > > > > > > > > was there a driver that did not work prior to this change?
Or
> does
> > > > this
> > > > > > > > allow
> > > > > > > > > > enabling the sandbox from a single-threaded context?
> > > > > > > > > 
> > > > > > > > > Hi Ricky, thx for taking the time to look at this issue.
> > > > > > > > > This CL allows to use the Mesa llvmpipe software driver with a
> > > > sandboxed
> > > > > > GPU
> > > > > > > > process.
> > > > > > > > > The current behavior is: "ERROR:sandbox_linux.cc(333)]
> > > > InitializeSandbox()
> > > > > > > > called with multiple threads in process gpu-process"
> > > > > > > > > This CL is required because this driver starts threads during
gl
> > > > > > > > initialization.
> > > > > > > > > Initially I thought I could just use existing
> kGpuSandboxStartEarly
> > > > but I
> > > > > > > > realized that mechanism
> > > > > > > > > is currently meant to be used only with
CrosArmGpuProcessPolicy
> > > > instead of
> > > > > > the
> > > > > > > > generic
> > > > > >
> content/common/sandbox_linux/bpf_gpu_policy_linux.cc::GpuProcessPolicy.
> > > > > > > > > This CL improves the later to dlopen(RTLD_NOW) the required gl
> > > > libraries
> > > > > > to
> > > > > > > > satisfy kGpuSandboxStartEarly logic, i.e. start the seccomp bpf
> sandbox
> > > > > > earlier
> > > > > > > > > but allow to initialize gl afterward.
> > > > > > > > > Let me know if you need more details.
> > > > > > > > > Julien
> > > > > > > > 
> > > > > > > > Does this mean that the threads it starts are destroyed after
> > > > > > initialization, so
> > > > > > > > the process will be single-threaded when the sandbox is enabled?
> > > > > > > 
> > > > > > > The threads are not destroyed after initialization. This software
> driver
> > > > > > > starts as many threads as there are cpus and use them to
parallelize
> > > > > > computation.
> > > > > > 
> > > > > > If those threads aren't destroyed after initialization, then that
> error
> > > > message
> > > > > > is accurate, right?
> > > > > 
> > > > > Yes it is.
> > > > > 
> > > > > > Would the process would fail to start before this change, or was the
> only
> > > > > > issue that error message?
> > > > > 
> > > > > Without this CL, this gpu process fails to start because of that only
> error.
> > > > In other words
> > > > > the gpu process succeeds to start if the user append either
--no-sandbox
> or
> > > > --disable-gpu-sandbox.
> > > > > Maybe you are missing the fact that this software driver has been
white
> listed
> > > > recently, some weeks ago it would
> > > > > have required to append --ignore-gpu-blacklist.
> > > > 
> > > > Hm, that error isn't fatal, so it shouldn't be responsible by itself for
> > > > preventing the driver from starting. I think there's a different root
> cause for
> > > > the GPU process failure that happens to be avoided or hidden by
dlopening
> the
> > > > library first. I'd prefer to figure out what that is and if there is a
> nicer
> > > > solution than dlopening the driver unsandboxed.
> > > 
> > > Sorry I was wrong in my very last comment, the gpu process starts even
with
> that
> > > error message we are talking about, so you are right it is not fatal. I
have
> > > double checked some minutes ago. Sorry about that I think I got confused
at
> some point.
> > > The only problem is that the sandbox is not actually activated.
> > 
> > Yeah, the sandbox won't be enabled, but that should be the case even after
> this change.
> > 
> > It might be useful to investigate attempting to use the seccomp tsync
feature
> (SeccompLevel::MULTI_THREADED in chromium) as a best effort when GPU drivers
> create threads, if you're interested - though I should warn that it will be
> quite challenge to do this without lots of painful breakage, since these
drivers
> may expect to do many other things normally blocked by the sandbox.
> 
> Just saw your other reply. I think I might be misunderstanding what this
change
> does - my assumption was that the threads would be started immediately upon
> dlopening the driver, but it seems like that's not the case if this change is
> causing the threads to start after the sandbox is enabled.

Yes I confirm that dlopening the driver does "not" cause to start the threads.
The call that causes to start the threads is glXQueryExtensionsString from
src/ui/gl/gl_bindings.cc::"DriverGLX::GetPlatformExtensions()".
Which one is called from InitializeStaticGLBindingsGLX() which one is called
from
gpu_main.cc::"gl::init::InitializeGLOneOff()".
Which one is normally called before to start the sandbox. So that why it needs
the kGpuSandboxStartEarly logic.

Do you need more information ? Thx a lot for your help.

[Julien Isorce Samsung, 2016-05-18 08:52:13]

The CQ bit was checked by j.isorce@samsung.com to run a CQ dry run

[commit-bot: I haz the power, 2016-05-18 08:52:30]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1542013005/220001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1542013005/220001

[Julien Isorce Samsung, 2016-05-18 09:00:28]

Description was changed from

==========
Add a new driver bug workaround SANDBOX_START_EARLY

It is usefull for drivers that create threads so that
it requires to start the sandbox first.
It is not really a bug but it fits with workarounds.

This CL also add a json entry for llvmpipe driver from Mesa
to enable this new driver bug woraround.

A new json entry could be added for Mali driver. According
to gpu_main.cc this driver creates threads.

BUG=264818

R=kbr@chromium.org, mdempsky@chromium.org, piman@chromium.org, zmo@chromium.org

TEST= GALLIUM_DRIVER=llvmpipe LIBGL_ALWAYS_SOFTWARE=1
CHROME_DEVEL_SANDBOX=out/Release/chrome_sandbox
It prints:
ERROR:sandbox_linux.cc(333)] InitializeSandbox() called with
multiple threads in process gpu-process

Review URL:
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_optional_gpu_tests_rel;tryserver.chromium.mac:mac_optional_gpu_tests_rel;tryserver.chromium.win:win_optional_gpu_tests_rel
==========

to

==========
Add a new driver bug workaround SANDBOX_START_EARLY

It is usefull for drivers that create threads so that
it requires to start the sandbox first.
It is not really a bug but it fits with workarounds.

This CL also add a json entry for llvmpipe driver from Mesa
to enable this new driver bug woraround.

A new json entry could be added for Mali driver. According
to gpu_main.cc this driver creates threads.

BUG=264818

R=jam@chromium.org, kbr@chromium.org, mdempsky@chromium.org, piman@chromium.org,
zmo@chromium.org

TEST= GALLIUM_DRIVER=llvmpipe LIBGL_ALWAYS_SOFTWARE=1
CHROME_DEVEL_SANDBOX=out/Release/chrome_sandbox
It prints:
ERROR:sandbox_linux.cc(333)] InitializeSandbox() called with
multiple threads in process gpu-process

Review URL:
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_optional_gpu_tests_rel;tryserver.chromium.mac:mac_optional_gpu_tests_rel;tryserver.chromium.win:win_optional_gpu_tests_rel
==========

[Julien Isorce Samsung, 2016-05-18 09:00:28]

j.isorce@samsung.com changed reviewers:
+ jam@chromium.org

[commit-bot: I haz the power, 2016-05-18 10:22:36]

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

[commit-bot: I haz the power, 2016-05-18 10:22:38]

Dry run: This issue passed the CQ dry run.

[rickyz (no longer on Chrome), 2016-06-28 05:57:58]

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

[rickyz (no longer on Chrome), 2016-06-28 05:58:00]

Apologies for the long delay here.

So my current understanding is that:

Before drivers are dlopened, glXQueryExtensionsString (called in GpuMain before
enabling the sandbox) code starts thread. The solution here is to use
kGpuSandboxStartEarly to enable the sandbox before the offending call. However,
the libraries need to be loaded first, hence dlopening them in PreSandboxHook.

jln@: we discussed a similar problem today and ended up leaning towards
dlopening a library before enabling the sandbox - does this seem safe for us to
do here as well? Hoping you might be a little more familiar with the history of
why we ended up going with the broker process for solving the dlopen problem.

https://codereview.chromium.org/1542013005/diff/220001/base/sys_info_posix.cc
File base/sys_info_posix.cc (right):

https://codereview.chromium.org/1542013005/diff/220001/base/sys_info_posix.cc...
base/sys_info_posix.cc:116: static struct utsname info = {};
Did this previously need to be thread safe?

[Julien Isorce Samsung, 2016-06-28 16:01:41]

https://codereview.chromium.org/1542013005/diff/220001/base/sys_info_posix.cc
File base/sys_info_posix.cc (right):

https://codereview.chromium.org/1542013005/diff/220001/base/sys_info_posix.cc...
base/sys_info_posix.cc:116: static struct utsname info = {};
On 2016/06/28 05:58:00, rickyz wrote:
> Did this previously need to be thread safe?

piman noted ealier that this change is not thread safe:
https://codereview.chromium.org/1542013005/diff/120001/base/sys_info_posix.cc...
so I suspect it needs to be thread safe.
In any case that is not a big deal I can add a new parameter "os_version" to the
helper gpu::ApplyGpuDriverBugWorkarounds() which is called in gpu_main.cc after
that the sandbox is started. The call to SysInfo::OperatingSystemVersion() is
done from GpuControlList::MakeDecision. See also my other reply I made in the
link I pointed above.
I would say we should not focus on this issue for now, this is just a small
collateral damage which I think I can workaround easily. But I agree it will
have to be fixed before we land the CL if we go there.

[Julien Isorce Samsung, 2016-06-28 16:22:11]

On 2016/06/28 05:58:00, rickyz wrote:
> Apologies for the long delay here.
> 
> So my current understanding is that:
> 
> Before drivers are dlopened, glXQueryExtensionsString (called in GpuMain
before
> enabling the sandbox) code starts thread. The solution here is to use
> kGpuSandboxStartEarly to enable the sandbox before the offending call.
However,
> the libraries need to be loaded first, hence dlopening them in PreSandboxHook.

Yes.
But note that without this CL it is already the case for GL libraries, i.e.
in current upstream chromium it dlopen gl libraries before to start the sandbox.
So in the CL the real addition is just the dlopen call to swrast_dri.so.

> 
> jln@: we discussed a similar problem today and ended up leaning towards
> dlopening a library before enabling the sandbox - does this seem safe for us
to
> do here as well? Hoping you might be a little more familiar with the history
of
> why we ended up going with the broker process for solving the dlopen problem.

Sorry to jump here, I also would like to have jln@ inputs. But here is my
understanding:
Broker process is useful to open files where we have knowledge of the file path.
For gl libraries it would requires to white list full directories because it is
not possible
to know in advance the list of file names or it would require to list all
dependencies
in advance and iterate over these deps to white list them one by one (need to
deal with
recursive deps ...).
But that is my understanding you guys are much more experts than me on sandbox
:)

In any case current chromium without my CL does not use broker process to load
gl libraries.
(broker process is not even started yet when loading gl libraries)
As said above it does like my CL actually, i.e. dlopen the gl libs before
starting the sandbox.

Thx a lot for the review rickyz. Let me know if I am missing something.

[Julien Isorce Samsung, 2016-07-04 16:40:33]

The CQ bit was checked by j.isorce@samsung.com to run a CQ dry run

[commit-bot: I haz the power, 2016-07-04 16:40:47]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-04 16:52:26]

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

[commit-bot: I haz the power, 2016-07-04 16:52:28]

Dry run: Try jobs failed on following builders:
  chromeos_amd64-generic_chromium_compile_only_ng on
master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_amd64-...)

[Julien Isorce Samsung, 2016-07-04 17:18:42]

The CQ bit was checked by j.isorce@samsung.com to run a CQ dry run

[commit-bot: I haz the power, 2016-07-04 17:19:00]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-04 18:18:08]

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

[commit-bot: I haz the power, 2016-07-04 18:18:10]

Dry run: This issue passed the CQ dry run.

[Julien Isorce Samsung, 2016-07-05 13:04:04]

The CQ bit was checked by j.isorce@samsung.com to run a CQ dry run

[commit-bot: I haz the power, 2016-07-05 13:04:12]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-05 13:22:58]

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

[commit-bot: I haz the power, 2016-07-05 13:22:59]

Dry run: Try jobs failed on following builders:
  mac_optional_gpu_tests_rel on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_optional_gpu_...)

[Julien Isorce Samsung, 2016-07-05 13:52:38]

The CQ bit was checked by j.isorce@samsung.com to run a CQ dry run

[commit-bot: I haz the power, 2016-07-05 13:52:50]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-05 14:06:03]

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

[commit-bot: I haz the power, 2016-07-05 14:06:05]

Dry run: Try jobs failed on following builders:
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)
  mac_optional_gpu_tests_rel on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_optional_gpu_...)

[Julien Isorce Samsung, 2016-07-05 14:12:51]

The CQ bit was checked by j.isorce@samsung.com to run a CQ dry run

[commit-bot: I haz the power, 2016-07-05 14:13:05]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-05 16:19:52]

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

[commit-bot: I haz the power, 2016-07-05 16:19:54]

Dry run: This issue passed the CQ dry run.

[Julien Isorce Samsung, 2016-07-17 12:42:45]

On 2016/06/28 05:58:00, rickyz wrote:
> jln@: we discussed a similar problem today and ended up leaning towards
> dlopening a library before enabling the sandbox - does this seem safe for us
to
> do here as well? Hoping you might be a little more familiar with the history
of
> why we ended up going with the broker process for solving the dlopen problem.

Gentle reminder to @jln. Thx.

Also it seems you have been aware of this some time ago:
https://bugs.chromium.org/p/chromium/issues/detail?id=132893

[Julien Isorce Samsung, 2016-10-07 15:26:37]

https://codereview.chromium.org/1542013005/diff/340001/build/config/linux/dri...
File build/config/linux/dri/BUILD.gn (right):

https://codereview.chromium.org/1542013005/diff/340001/build/config/linux/dri...
build/config/linux/dri/BUILD.gn:15: defines = [
"DRI_DRIVER_DIR=\"$dri_driver_dir\"" ]
Maybe I can also put "swrast_dri.so" in a define here.

[Julien Isorce Samsung, 2016-10-07 15:27:09]

The CQ bit was checked by j.isorce@samsung.com to run a CQ dry run

[commit-bot: I haz the power, 2016-10-07 15:27:27]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-07 15:27:29]

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

[commit-bot: I haz the power, 2016-10-07 15:27:30]

Dry run: Your CL was about to rely on recently removed CQ feature(s):
 * Specifying master names in CQ_INCLUDE_TRYBOTS part of description without
"master." prefix is no longer supported:
     tryserver.chromium.linux
     tryserver.chromium.mac
     tryserver.chromium.win
   For more details, see http://crbug.com/617627.

[Julien Isorce Samsung, 2016-10-07 15:43:51]

Description was changed from

==========
Add a new driver bug workaround SANDBOX_START_EARLY

It is usefull for drivers that create threads so that
it requires to start the sandbox first.
It is not really a bug but it fits with workarounds.

This CL also add a json entry for llvmpipe driver from Mesa
to enable this new driver bug woraround.

A new json entry could be added for Mali driver. According
to gpu_main.cc this driver creates threads.

BUG=264818

R=jam@chromium.org, kbr@chromium.org, mdempsky@chromium.org, piman@chromium.org,
zmo@chromium.org

TEST= GALLIUM_DRIVER=llvmpipe LIBGL_ALWAYS_SOFTWARE=1
CHROME_DEVEL_SANDBOX=out/Release/chrome_sandbox
It prints:
ERROR:sandbox_linux.cc(333)] InitializeSandbox() called with
multiple threads in process gpu-process

Review URL:
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_optional_gpu_tests_rel;tryserver.chromium.mac:mac_optional_gpu_tests_rel;tryserver.chromium.win:win_optional_gpu_tests_rel
==========

to

==========
Add a new driver bug workaround SANDBOX_START_EARLY

It is usefull for drivers that create threads so that
it requires to start the sandbox first.
It is not really a bug but it fits with workarounds.

This CL also add a json entry for llvmpipe driver from Mesa
to enable this new driver bug woraround.

A new json entry could be added for Mali driver. According
to gpu_main.cc this driver creates threads.

BUG=264818

R=jam@chromium.org, kbr@chromium.org, mdempsky@chromium.org, piman@chromium.org,
zmo@chromium.org

TEST= GALLIUM_DRIVER=llvmpipe LIBGL_ALWAYS_SOFTWARE=1
CHROME_DEVEL_SANDBOX=out/Release/chrome_sandbox
It prints:
ERROR:sandbox_linux.cc(333)] InitializeSandbox() called with
multiple threads in process gpu-process

Review URL:
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
==========

[Julien Isorce Samsung, 2016-10-07 15:44:08]

The CQ bit was checked by j.isorce@samsung.com to run a CQ dry run

[commit-bot: I haz the power, 2016-10-07 15:44:31]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-07 15:48:25]

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

[commit-bot: I haz the power, 2016-10-07 15:48:27]

Dry run: Try jobs failed on following builders:
  android_clang_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_clan...)
  cast_shell_linux on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)
  linux_chromium_asan_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_compile_dbg_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Julien Isorce Samsung, 2016-10-07 15:54:02]

The CQ bit was checked by j.isorce@samsung.com to run a CQ dry run

[commit-bot: I haz the power, 2016-10-07 15:54:25]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-07 17:01:55]

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

[commit-bot: I haz the power, 2016-10-07 17:01:57]

Dry run: This issue passed the CQ dry run.

[Julien Isorce Samsung, 2016-10-17 09:19:49]

The CQ bit was checked by j.isorce@samsung.com to run a CQ dry run

[commit-bot: I haz the power, 2016-10-17 09:20:06]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-17 10:33:24]

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

[commit-bot: I haz the power, 2016-10-17 10:33:26]

Dry run: This issue passed the CQ dry run.