From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-f197.google.com (mail-io0-f197.google.com [209.85.223.197]) by kanga.kvack.org (Postfix) with ESMTP id 3E20A6B025F for ; Tue, 26 Jul 2016 16:27:03 -0400 (EDT) Received: by mail-io0-f197.google.com with SMTP id m130so12786ioa.1 for ; Tue, 26 Jul 2016 13:27:03 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com. [156.151.31.81]) by mx.google.com with ESMTPS id j16si2793124ioo.23.2016.07.26.13.19.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Jul 2016 13:19:57 -0700 (PDT) Subject: Re: [PATCH] mm: correctly handle errors during VMA merging References: <1469514843-23778-1-git-send-email-vegard.nossum@oracle.com> <20160726114823.GC7370@node.shutemov.name> From: Vegard Nossum Message-ID: <5797C5E4.9010208@oracle.com> Date: Tue, 26 Jul 2016 22:19:48 +0200 MIME-Version: 1.0 In-Reply-To: <20160726114823.GC7370@node.shutemov.name> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: "Kirill A. Shutemov" Cc: linux-mm@kvack.org, Vlastimil Babka , Leon Yu , Konstantin Khlebnikov , Rik van Riel , Daniel Forrest On 07/26/2016 01:48 PM, Kirill A. Shutemov wrote: > On Tue, Jul 26, 2016 at 08:34:03AM +0200, Vegard Nossum wrote: >> Using trinity + fault injection I've been running into this bug a lot: >> >> ================================================================== >> BUG: KASAN: out-of-bounds in mprotect_fixup+0x523/0x5a0 at addr ffff8800b9e7d740 [...] >> What's happening is that we're doing an mprotect() on a range that spans >> three existing adjacent mappings. The first two are merged fine, but if >> we merge the last one and anon_vma_clone() runs out of memory, we return >> an error and mprotect_fixup() tries to use the (now stale) pointer. It >> goes like this: >> >> SyS_mprotect() >> - mprotect_fixup() >> - vma_merge() >> - vma_adjust() >> // first merge >> - kmem_cache_free(vma) >> - goto again; >> // second merge >> - anon_vma_clone() >> - kmem_cache_alloc() >> - return NULL >> - kmem_cache_alloc() >> - return NULL >> - return -ENOMEM >> - return -ENOMEM >> - return NULL >> - vma->vm_start // use-after-free >> >> In other words, it is possible to run into a memory allocation error >> *after* part of the merging work has already been done. In this case, >> we probably shouldn't return an error back to userspace anyway (since >> it would not reflect the partial work that was done). >> >> I *think* the solution might be to simply ignore the errors from >> vma_adjust() and carry on with distinct VMAs for adjacent regions that >> might otherwise have been represented with a single VMA. >> >> I have a reproducer that runs into the bug within a few seconds when >> fault injection is enabled -- with the patch I no longer see any >> problems. >> >> The patch and resulting code admittedly look odd and I'm *far* from >> an expert on mm internals, so feel free to propose counter-patches and >> I can give the reproducer a spin. > > Could you give this a try (barely tested): No apparent problems using either the quick reproducer or trinity (used to take 1-5 hours) after ~8 hours of testing :-) Vegard -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org