summaryrefslogtreecommitdiff
path: root/crypto/sha3_generic.c
diff options
context:
space:
mode:
authorPavel Tatashin <pasha.tatashin@oracle.com>2018-07-14 16:15:07 +0300
committerLinus Torvalds <torvalds@linux-foundation.org>2018-07-14 21:02:20 +0300
commite181ae0c5db9544de9c53239eb22bc012ce75033 (patch)
tree4af6ac8786ab6cc14c292b8dbf8aa8b75de62b30 /crypto/sha3_generic.c
parent2db39a2f491a48ec740e0214a7dd584eefc2137d (diff)
downloadlinux-e181ae0c5db9544de9c53239eb22bc012ce75033.tar.xz
mm: zero unavailable pages before memmap init
We must zero struct pages for memory that is not backed by physical memory, or kernel does not have access to. Recently, there was a change which zeroed all memmap for all holes in e820. Unfortunately, it introduced a bug that is discussed here: https://www.spinics.net/lists/linux-mm/msg156764.html Linus, also saw this bug on his machine, and confirmed that reverting commit 124049decbb1 ("x86/e820: put !E820_TYPE_RAM regions into memblock.reserved") fixes the issue. The problem is that we incorrectly zero some struct pages after they were setup. The fix is to zero unavailable struct pages prior to initializing of struct pages. A more detailed fix should come later that would avoid double zeroing cases: one in __init_single_page(), the other one in zero_resv_unavail(). Fixes: 124049decbb1 ("x86/e820: put !E820_TYPE_RAM regions into memblock.reserved") Signed-off-by: Pavel Tatashin <pasha.tatashin@oracle.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'crypto/sha3_generic.c')
0 files changed, 0 insertions, 0 deletions