This bug requires manual review: M60 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), josafat@(ChromeOS), bustamante@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Is this critical for M59? Will wait for merge to 60 first

Yes it's important for GCI/COS to get this in the stable branch soon. We have customers who are affected badly. b/62766247 and b/62755874

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

commit 87e57fe3d0c730becf153126668e883e8bdbe552
Author: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Date: Thu Jun 22 18:49:23 2017

UPSTREAM: ext4: handle the rest of ext4_mb_load_buddy() ENOMEM errors

I've got another report about breaking ext4 by ENOMEM error returned from
ext4_mb_load_buddy() caused by memory shortage in memory cgroup.
This time inside ext4_discard_preallocations().

This patch replaces ext4_error() with ext4_warning() where errors returned
from ext4_mb_load_buddy() are not fatal and handled by caller:
* ext4_mb_discard_group_preallocations() - called before generating ENOSPC,
  we'll try to discard other group or return ENOSPC into user-space.
* ext4_trim_all_free() - just stop trimming and return ENOMEM from ioctl.

Some callers cannot handle errors, thus __GFP_NOFAIL is used for them:
* ext4_discard_preallocations()
* ext4_mb_discard_lg_preallocations()

Fixes: adb7ef600cc9 ("ext4: use __GFP_NOFAIL in ext4_free_blocks()")
Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Andrey Ulanov <andreyu@google.com>
(cherry picked from commit 9651e6b2e20648d04d5e1fe6479a3056047e8781)

BUG=b:62766247
BUG= chromium:734727 
TEST=kernel compiles

Change-Id: I46e4f20688f25508afa77613cfc1ce4d0b2353ca
Reviewed-on: https://chromium-review.googlesource.com/540264
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Commit-Queue: Andrey Ulanov <andreyu@google.com>
Tested-by: Andrey Ulanov <andreyu@google.com>

[modify] https://crrev.com/87e57fe3d0c730becf153126668e883e8bdbe552/fs/ext4/mballoc.c

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

commit 00e5e918b8eb011c645fedcdd3ead75e7ca802f4
Author: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Date: Wed Jul 05 18:36:47 2017

UPSTREAM: ext4: handle the rest of ext4_mb_load_buddy() ENOMEM errors

I've got another report about breaking ext4 by ENOMEM error returned from
ext4_mb_load_buddy() caused by memory shortage in memory cgroup.
This time inside ext4_discard_preallocations().

This patch replaces ext4_error() with ext4_warning() where errors returned
from ext4_mb_load_buddy() are not fatal and handled by caller:
* ext4_mb_discard_group_preallocations() - called before generating ENOSPC,
  we'll try to discard other group or return ENOSPC into user-space.
* ext4_trim_all_free() - just stop trimming and return ENOMEM from ioctl.

Some callers cannot handle errors, thus __GFP_NOFAIL is used for them:
* ext4_discard_preallocations()
* ext4_mb_discard_lg_preallocations()

Fixes: adb7ef600cc9 ("ext4: use __GFP_NOFAIL in ext4_free_blocks()")
Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Andrey Ulanov <andreyu@google.com>
(cherry picked from commit 9651e6b2e20648d04d5e1fe6479a3056047e8781)

BUG=b:62766247
BUG= chromium:734727 
TEST=kernel compiles

Change-Id: I46e4f20688f25508afa77613cfc1ce4d0b2353ca
Reviewed-on: https://chromium-review.googlesource.com/540265
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Commit-Queue: Andrey Ulanov <andreyu@google.com>
Tested-by: Andrey Ulanov <andreyu@google.com>

[modify] https://crrev.com/00e5e918b8eb011c645fedcdd3ead75e7ca802f4/fs/ext4/mballoc.c