From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) by kanga.kvack.org (Postfix) with ESMTP id 00CAA6B0255 for ; Mon, 24 Aug 2015 09:16:22 -0400 (EDT) Received: by wicja10 with SMTP id ja10so72037144wic.1 for ; Mon, 24 Aug 2015 06:16:21 -0700 (PDT) Received: from pandora.arm.linux.org.uk (pandora.arm.linux.org.uk. [2001:4d48:ad52:3201:214:fdff:fe10:1be6]) by mx.google.com with ESMTPS id gp2si3520719wib.13.2015.08.24.06.16.19 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 24 Aug 2015 06:16:20 -0700 (PDT) Date: Mon, 24 Aug 2015 14:15:57 +0100 From: Russell King - ARM Linux Subject: Re: [PATCH v2 5/5] arm64: add KASan support Message-ID: <20150824131557.GB7557@n2100.arm.linux.org.uk> References: <1431698344-28054-1-git-send-email-a.ryabinin@samsung.com> <1431698344-28054-6-git-send-email-a.ryabinin@samsung.com> <55AE56DB.4040607@samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Linus Walleij Cc: Andrey Ryabinin , Arnd Bergmann , "linux-mm@kvack.org" , Catalin Marinas , Will Deacon , "linux-kernel@vger.kernel.org" , David Keitel , Andrey Ryabinin , Alexander Potapenko , "linux-arm-kernel@lists.infradead.org" , Andrew Morton , Dmitry Vyukov On Tue, Jul 21, 2015 at 11:27:56PM +0200, Linus Walleij wrote: > On Tue, Jul 21, 2015 at 4:27 PM, Andrey Ryabinin wrote: > > > I used vexpress. Anyway, it doesn't matter now, since I have an update > > with a lot of stuff fixed, and it works on hardware. > > I still need to do some work on it and tomorrow, probably, I will share. > > Ah awesome. I have a stash of ARM boards so I can test it on a > range of hardware once you feel it's ready. > > Sorry for pulling stuff out of your hands, people are excited about > KASan ARM32 as it turns out. People may be excited about it because it's a new feature, but we really need to consider whether gobbling up 512MB of userspace for it is a good idea or not. There are programs around which like to map large amounts of memory into their process space, and the more we steal from them, the more likely these programs are to fail. The other thing which I'm not happy about is having a 16K allocation per thread - the 16K allocation for the PGD is already prone to invoking the OOM killer after memory fragmentation has set in, we don't need another 16K allocation. We're going from one 16K allocation per process to that _and_ one 16K allocation per thread. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- 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