diff for duplicates of <20170705182849.GA18027@dhcp22.suse.cz> diff --git a/a/1.txt b/N1/1.txt index f49af82..49c5854 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -11,3 +11,55 @@ On Wed 05-07-17 10:43:27, Linus Torvalds wrote: Dohh, that was on mmotm which has a clean up by Oleg which reorganizes the code a bit. This is on top of the current master --- +>From fd538009ac373a5f87538786412a3e6191fa6001 Mon Sep 17 00:00:00 2001 +From: Michal Hocko <mhocko@suse.com> +Date: Tue, 4 Jul 2017 11:27:39 +0200 +Subject: [PATCH] mm: mm, mmap: do not blow on PROT_NONE MAP_FIXED holes in the + stack + +"mm: enlarge stack guard gap" has introduced a regression in some rust +and Java environments which are trying to implement their own stack +guard page. They are punching a new MAP_FIXED mapping inside the +existing stack Vma. + +This will confuse expand_{downwards,upwards} into thinking that the stack +expansion would in fact get us too close to an existing non-stack vma +which is a correct behavior wrt. safety. It is a real regression on +the other hand. Let's work around the problem by considering PROT_NONE +mapping as a part of the stack. This is a gros hack but overflowing to +such a mapping would trap anyway an we only can hope that usespace +knows what it is doing and handle it propely. + +Fixes: d4d2d35e6ef9 ("mm: larger stack guard gap, between vmas") +Debugged-by: Vlastimil Babka <vbabka@suse.cz> +Signed-off-by: Michal Hocko <mhocko@suse.com> +--- + mm/mmap.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +diff --git a/mm/mmap.c b/mm/mmap.c +index a5e3dcd75e79..ece0f6d3a1b5 100644 +--- a/mm/mmap.c ++++ b/mm/mmap.c +@@ -2244,7 +2244,8 @@ int expand_upwards(struct vm_area_struct *vma, unsigned long address) + gap_addr = TASK_SIZE; + + next = vma->vm_next; +- if (next && next->vm_start < gap_addr) { ++ if (next && next->vm_start < gap_addr && ++ (next->vm_flags & (VM_WRITE|VM_READ|VM_EXEC))) { + if (!(next->vm_flags & VM_GROWSUP)) + return -ENOMEM; + /* Check that both stack segments have the same anon_vma? */ +@@ -2328,7 +2329,8 @@ int expand_downwards(struct vm_area_struct *vma, + if (gap_addr > address) + return -ENOMEM; + prev = vma->vm_prev; +- if (prev && prev->vm_end > gap_addr) { ++ if (prev && prev->vm_end > gap_addr && ++ (prev->vm_flags & (VM_WRITE|VM_READ|VM_EXEC))) { + if (!(prev->vm_flags & VM_GROWSDOWN)) + return -ENOMEM; + /* Check that both stack segments have the same anon_vma? */ +-- +2.11.0 diff --git a/a/content_digest b/N1/content_digest index c1a70e7..3ffb0c5 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -26,6 +26,58 @@ "\n" "Dohh, that was on mmotm which has a clean up by Oleg which reorganizes\n" "the code a bit. This is on top of the current master\n" - --- + "---\n" + ">From fd538009ac373a5f87538786412a3e6191fa6001 Mon Sep 17 00:00:00 2001\n" + "From: Michal Hocko <mhocko@suse.com>\n" + "Date: Tue, 4 Jul 2017 11:27:39 +0200\n" + "Subject: [PATCH] mm: mm, mmap: do not blow on PROT_NONE MAP_FIXED holes in the\n" + " stack\n" + "\n" + "\"mm: enlarge stack guard gap\" has introduced a regression in some rust\n" + "and Java environments which are trying to implement their own stack\n" + "guard page. They are punching a new MAP_FIXED mapping inside the\n" + "existing stack Vma.\n" + "\n" + "This will confuse expand_{downwards,upwards} into thinking that the stack\n" + "expansion would in fact get us too close to an existing non-stack vma\n" + "which is a correct behavior wrt. safety. It is a real regression on\n" + "the other hand. Let's work around the problem by considering PROT_NONE\n" + "mapping as a part of the stack. This is a gros hack but overflowing to\n" + "such a mapping would trap anyway an we only can hope that usespace\n" + "knows what it is doing and handle it propely.\n" + "\n" + "Fixes: d4d2d35e6ef9 (\"mm: larger stack guard gap, between vmas\")\n" + "Debugged-by: Vlastimil Babka <vbabka@suse.cz>\n" + "Signed-off-by: Michal Hocko <mhocko@suse.com>\n" + "---\n" + " mm/mmap.c | 6 ++++--\n" + " 1 file changed, 4 insertions(+), 2 deletions(-)\n" + "\n" + "diff --git a/mm/mmap.c b/mm/mmap.c\n" + "index a5e3dcd75e79..ece0f6d3a1b5 100644\n" + "--- a/mm/mmap.c\n" + "+++ b/mm/mmap.c\n" + "@@ -2244,7 +2244,8 @@ int expand_upwards(struct vm_area_struct *vma, unsigned long address)\n" + " \t\tgap_addr = TASK_SIZE;\n" + " \n" + " \tnext = vma->vm_next;\n" + "-\tif (next && next->vm_start < gap_addr) {\n" + "+\tif (next && next->vm_start < gap_addr &&\n" + "+\t\t\t(next->vm_flags & (VM_WRITE|VM_READ|VM_EXEC))) {\n" + " \t\tif (!(next->vm_flags & VM_GROWSUP))\n" + " \t\t\treturn -ENOMEM;\n" + " \t\t/* Check that both stack segments have the same anon_vma? */\n" + "@@ -2328,7 +2329,8 @@ int expand_downwards(struct vm_area_struct *vma,\n" + " \tif (gap_addr > address)\n" + " \t\treturn -ENOMEM;\n" + " \tprev = vma->vm_prev;\n" + "-\tif (prev && prev->vm_end > gap_addr) {\n" + "+\tif (prev && prev->vm_end > gap_addr &&\n" + "+\t\t\t(prev->vm_flags & (VM_WRITE|VM_READ|VM_EXEC))) {\n" + " \t\tif (!(prev->vm_flags & VM_GROWSDOWN))\n" + " \t\t\treturn -ENOMEM;\n" + " \t\t/* Check that both stack segments have the same anon_vma? */\n" + "-- \n" + 2.11.0 -6f8810e60da656c30665172a79dcae94b762a64beee9513430e9441e5f35596c +012c75546bf2e5f05de22a09e65b0ed705611a9e67e180c4d1de353f99b979cd
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.