From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753059AbdKCOSC (ORCPT ); Fri, 3 Nov 2017 10:18:02 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:18953 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751356AbdKCOSA (ORCPT ); Fri, 3 Nov 2017 10:18:00 -0400 X-Google-Smtp-Source: ABhQp+TOgBWLVYzpw1yxHYZGWvyFg5WeNSs7nI7nFwjWT/bKDrF9rFhAk76QAzw2RCQ0/GNt/x6pisXRI71WMr0pt10= MIME-Version: 1.0 In-Reply-To: <20171103085958.pewhlyvkr5oa2fgf@dhcp22.suse.cz> References: <20171031155002.21691-1-pasha.tatashin@oracle.com> <20171031155002.21691-2-pasha.tatashin@oracle.com> <20171102133235.2vfmmut6w4of2y3j@dhcp22.suse.cz> <20171102135423.voxnzk2qkvfgu5l3@dhcp22.suse.cz> <94ab73c0-cd18-f58f-eebe-d585fde319e4@oracle.com> <20171102140830.z5uqmrurb6ohfvlj@dhcp22.suse.cz> <813ed7e3-9347-a1f2-1629-464d920f877d@oracle.com> <20171102142742.gpkif3hgnd62nyol@dhcp22.suse.cz> <8b3bb799-818b-b6b6-7c6b-9eee709decb7@oracle.com> <20171103085958.pewhlyvkr5oa2fgf@dhcp22.suse.cz> From: Pavel Tatashin Date: Fri, 3 Nov 2017 10:17:57 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v1 1/1] mm: buddy page accessed before initialized To: Michal Hocko Cc: Steve Sistare , Daniel Jordan , Andrew Morton , mgorman@techsingularity.net, Linux Memory Management List , linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Source-IP: userv0022.oracle.com [156.151.31.74] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > Why cannot we do something similar to the optimized struct page > initialization and write 8B at the time and fill up the size unaligned > chunk in 1B? I do not think this is a good idea: memset() on SPARC is slow for small sizes, this is why we ended up using stores, but thats not the case on x86 where memset() is well optimized for small sizes. So, I believe we will see regressions. But even without the regressions there are several reasons why I think this is not a good idea: 1. struct page size vary depending on configs. So, in order to create a pattern that looks like a valid struct page, we would need to figure out what is our struct page size. 2. memblock allocator is totally independent from struct pages, it is going to be strange to add this dependency. The allocatoted memory is also used for page tables, and kasan, so we do not really know where the pattern should start from the allocator point of view. 3. It is going to be too easy to break that pattern if something changes or shifts: struct page changes, vmemmap allocations change or anything else. Overall, I think now we have a good coverage now: CONFIG_DEBUG_VM option tests for totally invalid struct pages, and kexec tests for struct pages that look like valid ones, but they are invalid because from the previous instance of kernel. Pasha