From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752023AbdFHCnO (ORCPT ); Wed, 7 Jun 2017 22:43:14 -0400 Received: from mail-pg0-f67.google.com ([74.125.83.67]:35353 "EHLO mail-pg0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751449AbdFHCnM (ORCPT ); Wed, 7 Jun 2017 22:43:12 -0400 Date: Thu, 8 Jun 2017 11:43:05 +0900 From: Joonsoo Kim To: Andrey Ryabinin Cc: Dmitry Vyukov , Andrew Morton , Alexander Potapenko , kasan-dev , "linux-mm@kvack.org" , LKML , Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , kernel-team@lge.com Subject: Re: [PATCH v1 00/11] mm/kasan: support per-page shadow memory to reduce memory consumption Message-ID: <20170608024303.GC27998@js1304-desktop> References: <20170524074539.GA9697@js1304-desktop> <20170525004104.GA21336@js1304-desktop> <3a7664a9-e360-ab68-610a-1b697a4b00b5@virtuozzo.com> <20170531055047.GA21606@js1304-desktop> <80f2f6f7-0a37-53dc-843e-1adbed4377fa@virtuozzo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <80f2f6f7-0a37-53dc-843e-1adbed4377fa@virtuozzo.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 31, 2017 at 07:31:53PM +0300, Andrey Ryabinin wrote: > On 05/31/2017 08:50 AM, Joonsoo Kim wrote: > >>> But the main win as I see it is that that's basically complete support > >>> for 32-bit arches. People do ask about arm32 support: > >>> https://groups.google.com/d/msg/kasan-dev/Sk6BsSPMRRc/Gqh4oD_wAAAJ > >>> https://groups.google.com/d/msg/kasan-dev/B22vOFp-QWg/EVJPbrsgAgAJ > >>> and probably mips32 is relevant as well. > >> > >> I don't see how above is relevant for 32-bit arches. Current design > >> is perfectly fine for 32-bit arches. I did some POC arm32 port couple years > >> ago - https://github.com/aryabinin/linux/commits/kasan/arm_v0_1 > >> It has some ugly hacks and non-critical bugs. AFAIR it also super-slow because I (mistakenly) > >> made shadow memory uncached. But otherwise it works. > > > > Could you explain that where is the code to map shadow memory uncached? > > I don't find anything related to it. > > > > I didn't set set any cache policy (L_PTE_MT_*) on shadow mapping (see set_pte_at() calls ) > which means it's L_PTE_MT_UNCACHED Thanks for pointing it out. I did some quick tests and found that it's not super(?) slow on my QEMU. Maybe, it would be different with real machine. Thanks.