Upstream commit 6ea8d958a2c ("mm/madvise.c: fix madvise() infinite loop under special circumstances"). Fixed in chromeos-4.14 with merge of v4.14.4. Fixed in chromeos-4.4 with merge of v4.4.104. Upstream patch does not apply to chromeos-3.18 and earlier. However, the fix has been backported into v3.18.y as commit d5ec57c35ac4 which does apply, at least to chromeos-3.18.

3.18 cherry-pick from stable branch applies to 3.10..3.18, but not to 3.8 where a conflict is observed. We'll fix the problem inall releases but 3.8.

Lakitu's vulnerability monitoring is temporarily broken, so I am updating here. No stable impact, and both lakitu beta and dev are on 4.14.5+.

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

commit 7876690f3260a8667e0f38c38eceec919fd89dee
Author: chenjie <chenjie6@huawei.com>
Date: Wed Mar 28 01:01:38 2018

BACKPORT: mm/madvise.c: fix madvise() infinite loop under special circumstances

commit 6ea8d958a2c95a1d514015d4e29ba21a8c0a1a91 upstream.

MADVISE_WILLNEED has always been a noop for DAX (formerly XIP) mappings.
Unfortunately madvise_willneed() doesn't communicate this information
properly to the generic madvise syscall implementation.  The calling
convention is quite subtle there.  madvise_vma() is supposed to either
return an error or update &prev otherwise the main loop will never
advance to the next vma and it will keep looping for ever without a way
to get out of the kernel.

It seems this has been broken since introduction.  Nobody has noticed
because nobody seems to be using MADVISE_WILLNEED on these DAX mappings.

[mhocko@suse.com: rewrite changelog]
Link: http://lkml.kernel.org/r/20171127115318.911-1-guoxuenan@huawei.com
Fixes: fe77ba6f4f97 ("[PATCH] xip: madvice/fadvice: execute in place")
Signed-off-by: chenjie <chenjie6@huawei.com>
Signed-off-by: guoxuenan <guoxuenan@huawei.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: zhangyi (F) <yi.zhang@huawei.com>
Cc: Miao Xie <miaoxie@huawei.com>
Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
Cc: Shaohua Li <shli@fb.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Carsten Otte <cotte@de.ibm.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

BUG= chromium:825480 
TEST=Build and boot

Change-Id: I8d13ab842bd07819c266db4cbe3badbcd2c67377
Signed-off-by: Guenter Roeck <groeck@chromium.org>
(cherry picked from commit d5ec57c35ac4eeee9b18fb31a953281e63672c0f
 git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.18.y)
Reviewed-on: https://chromium-review.googlesource.com/980661

[modify] https://crrev.com/7876690f3260a8667e0f38c38eceec919fd89dee/mm/madvise.c

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

commit d379f01c6516cfa2cd70e8781ecda8bc00d7dd6a
Author: chenjie <chenjie6@huawei.com>
Date: Wed Mar 28 03:35:13 2018

BACKPORT: mm/madvise.c: fix madvise() infinite loop under special circumstances

commit 6ea8d958a2c95a1d514015d4e29ba21a8c0a1a91 upstream.

MADVISE_WILLNEED has always been a noop for DAX (formerly XIP) mappings.
Unfortunately madvise_willneed() doesn't communicate this information
properly to the generic madvise syscall implementation.  The calling
convention is quite subtle there.  madvise_vma() is supposed to either
return an error or update &prev otherwise the main loop will never
advance to the next vma and it will keep looping for ever without a way
to get out of the kernel.

It seems this has been broken since introduction.  Nobody has noticed
because nobody seems to be using MADVISE_WILLNEED on these DAX mappings.

[mhocko@suse.com: rewrite changelog]
Link: http://lkml.kernel.org/r/20171127115318.911-1-guoxuenan@huawei.com
Fixes: fe77ba6f4f97 ("[PATCH] xip: madvice/fadvice: execute in place")
Signed-off-by: chenjie <chenjie6@huawei.com>
Signed-off-by: guoxuenan <guoxuenan@huawei.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: zhangyi (F) <yi.zhang@huawei.com>
Cc: Miao Xie <miaoxie@huawei.com>
Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
Cc: Shaohua Li <shli@fb.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Carsten Otte <cotte@de.ibm.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

BUG= chromium:825480 
TEST=Build and boot

Change-Id: I8d13ab842bd07819c266db4cbe3badbcd2c67377
Signed-off-by: Guenter Roeck <groeck@chromium.org>
(cherry picked from commit d5ec57c35ac4eeee9b18fb31a953281e63672c0f
 git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.18.y)
Reviewed-on: https://chromium-review.googlesource.com/980660

[modify] https://crrev.com/d379f01c6516cfa2cd70e8781ecda8bc00d7dd6a/mm/madvise.c

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

commit 81356feec24ff35b8278c06273a388e8ffe56d0f
Author: chenjie <chenjie6@huawei.com>
Date: Wed Mar 28 03:35:10 2018

BACKPORT: mm/madvise.c: fix madvise() infinite loop under special circumstances

commit 6ea8d958a2c95a1d514015d4e29ba21a8c0a1a91 upstream.

MADVISE_WILLNEED has always been a noop for DAX (formerly XIP) mappings.
Unfortunately madvise_willneed() doesn't communicate this information
properly to the generic madvise syscall implementation.  The calling
convention is quite subtle there.  madvise_vma() is supposed to either
return an error or update &prev otherwise the main loop will never
advance to the next vma and it will keep looping for ever without a way
to get out of the kernel.

It seems this has been broken since introduction.  Nobody has noticed
because nobody seems to be using MADVISE_WILLNEED on these DAX mappings.

[mhocko@suse.com: rewrite changelog]
Link: http://lkml.kernel.org/r/20171127115318.911-1-guoxuenan@huawei.com
Fixes: fe77ba6f4f97 ("[PATCH] xip: madvice/fadvice: execute in place")
Signed-off-by: chenjie <chenjie6@huawei.com>
Signed-off-by: guoxuenan <guoxuenan@huawei.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: zhangyi (F) <yi.zhang@huawei.com>
Cc: Miao Xie <miaoxie@huawei.com>
Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
Cc: Shaohua Li <shli@fb.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Carsten Otte <cotte@de.ibm.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

BUG= chromium:825480 
TEST=Build and boot

Change-Id: I8d13ab842bd07819c266db4cbe3badbcd2c67377
Signed-off-by: Guenter Roeck <groeck@chromium.org>
(cherry picked from commit d5ec57c35ac4eeee9b18fb31a953281e63672c0f
 git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.18.y)
Reviewed-on: https://chromium-review.googlesource.com/981073
Reviewed-by: Zubin Mithra <zsm@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>

[modify] https://crrev.com/81356feec24ff35b8278c06273a388e8ffe56d0f/mm/madvise.c

Merge request for chromeos-3.10, chromeos-3.14, chromeos-3.18

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

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

let's let it bake on ToT for a week before merging to M66 to ensure to side effects 

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

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

commit b70ea0ac59f5d87565a16d5f0972190bd9a25064
Author: chenjie <chenjie6@huawei.com>
Date: Mon Apr 09 16:41:58 2018

BACKPORT: mm/madvise.c: fix madvise() infinite loop under special circumstances

commit 6ea8d958a2c95a1d514015d4e29ba21a8c0a1a91 upstream.

MADVISE_WILLNEED has always been a noop for DAX (formerly XIP) mappings.
Unfortunately madvise_willneed() doesn't communicate this information
properly to the generic madvise syscall implementation.  The calling
convention is quite subtle there.  madvise_vma() is supposed to either
return an error or update &prev otherwise the main loop will never
advance to the next vma and it will keep looping for ever without a way
to get out of the kernel.

It seems this has been broken since introduction.  Nobody has noticed
because nobody seems to be using MADVISE_WILLNEED on these DAX mappings.

[mhocko@suse.com: rewrite changelog]
Link: http://lkml.kernel.org/r/20171127115318.911-1-guoxuenan@huawei.com
Fixes: fe77ba6f4f97 ("[PATCH] xip: madvice/fadvice: execute in place")
Signed-off-by: chenjie <chenjie6@huawei.com>
Signed-off-by: guoxuenan <guoxuenan@huawei.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: zhangyi (F) <yi.zhang@huawei.com>
Cc: Miao Xie <miaoxie@huawei.com>
Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
Cc: Shaohua Li <shli@fb.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Carsten Otte <cotte@de.ibm.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

BUG= chromium:825480 
TEST=Build and boot

Change-Id: I8d13ab842bd07819c266db4cbe3badbcd2c67377
Signed-off-by: Guenter Roeck <groeck@chromium.org>
(cherry picked from commit d5ec57c35ac4eeee9b18fb31a953281e63672c0f
 git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.18.y)
Reviewed-on: https://chromium-review.googlesource.com/981420

[modify] https://crrev.com/b70ea0ac59f5d87565a16d5f0972190bd9a25064/mm/madvise.c

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

commit adc30606937f9a31d92419ce08f1c26892033c12
Author: chenjie <chenjie6@huawei.com>
Date: Mon Apr 09 16:42:06 2018

BACKPORT: mm/madvise.c: fix madvise() infinite loop under special circumstances

commit 6ea8d958a2c95a1d514015d4e29ba21a8c0a1a91 upstream.

MADVISE_WILLNEED has always been a noop for DAX (formerly XIP) mappings.
Unfortunately madvise_willneed() doesn't communicate this information
properly to the generic madvise syscall implementation.  The calling
convention is quite subtle there.  madvise_vma() is supposed to either
return an error or update &prev otherwise the main loop will never
advance to the next vma and it will keep looping for ever without a way
to get out of the kernel.

It seems this has been broken since introduction.  Nobody has noticed
because nobody seems to be using MADVISE_WILLNEED on these DAX mappings.

[mhocko@suse.com: rewrite changelog]
Link: http://lkml.kernel.org/r/20171127115318.911-1-guoxuenan@huawei.com
Fixes: fe77ba6f4f97 ("[PATCH] xip: madvice/fadvice: execute in place")
Signed-off-by: chenjie <chenjie6@huawei.com>
Signed-off-by: guoxuenan <guoxuenan@huawei.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: zhangyi (F) <yi.zhang@huawei.com>
Cc: Miao Xie <miaoxie@huawei.com>
Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
Cc: Shaohua Li <shli@fb.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Carsten Otte <cotte@de.ibm.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

BUG= chromium:825480 
TEST=Build and boot

Change-Id: I8d13ab842bd07819c266db4cbe3badbcd2c67377
Signed-off-by: Guenter Roeck <groeck@chromium.org>
(cherry picked from commit d5ec57c35ac4eeee9b18fb31a953281e63672c0f
 git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.18.y)
Reviewed-on: https://chromium-review.googlesource.com/981419

[modify] https://crrev.com/adc30606937f9a31d92419ce08f1c26892033c12/mm/madvise.c

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

commit 604318aa523b15b76116299d280d8a7a864a0377
Author: chenjie <chenjie6@huawei.com>
Date: Mon Apr 09 16:45:34 2018

BACKPORT: mm/madvise.c: fix madvise() infinite loop under special circumstances

commit 6ea8d958a2c95a1d514015d4e29ba21a8c0a1a91 upstream.

MADVISE_WILLNEED has always been a noop for DAX (formerly XIP) mappings.
Unfortunately madvise_willneed() doesn't communicate this information
properly to the generic madvise syscall implementation.  The calling
convention is quite subtle there.  madvise_vma() is supposed to either
return an error or update &prev otherwise the main loop will never
advance to the next vma and it will keep looping for ever without a way
to get out of the kernel.

It seems this has been broken since introduction.  Nobody has noticed
because nobody seems to be using MADVISE_WILLNEED on these DAX mappings.

[mhocko@suse.com: rewrite changelog]
Link: http://lkml.kernel.org/r/20171127115318.911-1-guoxuenan@huawei.com
Fixes: fe77ba6f4f97 ("[PATCH] xip: madvice/fadvice: execute in place")
Signed-off-by: chenjie <chenjie6@huawei.com>
Signed-off-by: guoxuenan <guoxuenan@huawei.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: zhangyi (F) <yi.zhang@huawei.com>
Cc: Miao Xie <miaoxie@huawei.com>
Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
Cc: Shaohua Li <shli@fb.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Carsten Otte <cotte@de.ibm.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

BUG= chromium:825480 
TEST=Build and boot

Change-Id: I8d13ab842bd07819c266db4cbe3badbcd2c67377
Signed-off-by: Guenter Roeck <groeck@chromium.org>
(cherry picked from commit d5ec57c35ac4eeee9b18fb31a953281e63672c0f
 git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.18.y)
Reviewed-on: https://chromium-review.googlesource.com/981421

[modify] https://crrev.com/604318aa523b15b76116299d280d8a7a864a0377/mm/madvise.c

This bug has been closed for more than 14 weeks. Removing security view restrictions.

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