[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20171204155942.679696553@linuxfoundation.org>
Date: Mon, 4 Dec 2017 16:59:35 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-kernel@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
stable@...r.kernel.org, chenjie <chenjie6@...wei.com>,
guoxuenan <guoxuenan@...wei.com>, Michal Hocko <mhocko@...e.com>,
Minchan Kim <minchan@...nel.org>,
"zhangyi (F)" <yi.zhang@...wei.com>, Miao Xie <miaoxie@...wei.com>,
Mike Rapoport <rppt@...ux.vnet.ibm.com>,
Shaohua Li <shli@...com>,
Andrea Arcangeli <aarcange@...hat.com>,
Mel Gorman <mgorman@...hsingularity.net>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
David Rientjes <rientjes@...gle.com>,
Anshuman Khandual <khandual@...ux.vnet.ibm.com>,
Rik van Riel <riel@...hat.com>,
Carsten Otte <cotte@...ibm.com>,
Dan Williams <dan.j.williams@...el.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: [PATCH 4.4 10/27] mm/madvise.c: fix madvise() infinite loop under special circumstances
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: chenjie <chenjie6@...wei.com>
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@...e.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@...wei.com>
Signed-off-by: guoxuenan <guoxuenan@...wei.com>
Acked-by: Michal Hocko <mhocko@...e.com>
Cc: Minchan Kim <minchan@...nel.org>
Cc: zhangyi (F) <yi.zhang@...wei.com>
Cc: Miao Xie <miaoxie@...wei.com>
Cc: Mike Rapoport <rppt@...ux.vnet.ibm.com>
Cc: Shaohua Li <shli@...com>
Cc: Andrea Arcangeli <aarcange@...hat.com>
Cc: Mel Gorman <mgorman@...hsingularity.net>
Cc: Kirill A. Shutemov <kirill.shutemov@...ux.intel.com>
Cc: David Rientjes <rientjes@...gle.com>
Cc: Anshuman Khandual <khandual@...ux.vnet.ibm.com>
Cc: Rik van Riel <riel@...hat.com>
Cc: Carsten Otte <cotte@...ibm.com>
Cc: Dan Williams <dan.j.williams@...el.com>
Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@...ux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
---
mm/madvise.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -223,15 +223,14 @@ static long madvise_willneed(struct vm_a
{
struct file *file = vma->vm_file;
+ *prev = vma;
#ifdef CONFIG_SWAP
if (!file) {
- *prev = vma;
force_swapin_readahead(vma, start, end);
return 0;
}
if (shmem_mapping(file->f_mapping)) {
- *prev = vma;
force_shm_swapin_readahead(vma, start, end,
file->f_mapping);
return 0;
@@ -246,7 +245,6 @@ static long madvise_willneed(struct vm_a
return 0;
}
- *prev = vma;
start = ((start - vma->vm_start) >> PAGE_SHIFT) + vma->vm_pgoff;
if (end > vma->vm_end)
end = vma->vm_end;
Powered by blists - more mailing lists