Fix Linker.sInBrowserProcess to avoid false negatives

Fix Linker.sInBrowserProcess to avoid false negatives

Linker.sInBrowserProcess can currently be incorrectly set to false in
the browser process if it uses shared RELROs and loading a library
fails. This problem is fixed by renaming Linker.initServiceProcess() to
Linker.enableSharedRelros() and factoring out common code shared by
Linker.disableSharedRelros() and Linker.enableSharedRelros() into a
separate method Linker.initServiceProcess(). Consequently,
LibraryLoader.loadAlreadyLocked() can call Linker.disableSharedRelros()
without setting Linker.sInBrowserProcess to false.

BUG=423699, 458056

[petrcermak, 2015-02-17 16:32:02]

petrcermak@chromium.org changed reviewers:
+ rmcilroy@chromium.org, yfriedman@chromium.org

[petrcermak, 2015-02-17 16:32:03]

Hi, please review this patch.

rmcilroy: *
simonb: *
yfriedman: content/

Thanks,
Petr

[rmcilroy, 2015-02-17 17:30:34]

This is definitely a step in the right direction. I'm wondering if we could
improve things more by factoring out the renderer / browser differences in a
more consistent manner.

https://codereview.chromium.org/930333003/diff/1/base/android/java/src/org/ch...
File base/android/java/src/org/chromium/base/library_loader/Linker.java (right):

https://codereview.chromium.org/930333003/diff/1/base/android/java/src/org/ch...
base/android/java/src/org/chromium/base/library_loader/Linker.java:577: assert
!sBrowserUsesSharedRelro;
As discussed, maybe we should consider packaging this info up into a enum or
config object, since there are some bools which only make sense for the browser
process, and some which only make sense on the renderer process.

[petrcermak, 2015-02-23 18:57:40]

Patchset #2 (id:20001) has been deleted

[petrcermak, 2015-04-10 15:29:07]

+cc oth

[petrcermak, 2015-07-14 13:16:17]

On 2015/04/10 15:29:07, petrcermak wrote:
> +cc oth

Ross, do you think we should still do this (it would definitely need a rewrite
due to https://codereview.chromium.org/1224963002/)?

Thanks,
Petr

[rmcilroy, 2015-07-14 14:22:57]

+simonb

I think the proper fix for this is Orion's CL which he did based on this CL
(https://codereview.chromium.org/1101473006/). We've closed this for now, but
SimonB agreed we should do this at some point during the refactor for
LinkerModern/Legacy.

[petrcermak, 2015-07-14 17:36:29]

On 2015/07/14 14:22:57, rmcilroy wrote:
> +simonb
> 
> I think the proper fix for this is Orion's CL which he did based on this CL
> (https://codereview.chromium.org/1101473006/). We've closed this for now, but
> SimonB agreed we should do this at some point during the refactor for
> LinkerModern/Legacy.

Thanks for your reply. In that case, I'm closing this issue.

Petr