From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=MAILING_LIST_MULTI,SPF_PASS, USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E5E53ECDE5F for ; Mon, 23 Jul 2018 12:30:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9F10720883 for ; Mon, 23 Jul 2018 12:30:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9F10720883 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389361AbeGWNbp (ORCPT ); Mon, 23 Jul 2018 09:31:45 -0400 Received: from mx2.suse.de ([195.135.220.15]:43904 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2388079AbeGWNbo (ORCPT ); Mon, 23 Jul 2018 09:31:44 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 4A9F2AE18; Mon, 23 Jul 2018 12:30:44 +0000 (UTC) Date: Mon, 23 Jul 2018 14:30:43 +0200 From: Michal Hocko To: Vlastimil Babka Cc: David Hildenbrand , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Baoquan He , Dave Young , Greg Kroah-Hartman , Hari Bathini , Huang Ying , "Kirill A. Shutemov" , =?iso-8859-1?Q?Marc-Andr=E9?= Lureau , Matthew Wilcox , Miles Chen , Pavel Tatashin , Petr Tesarik Subject: Re: [PATCH v1 0/2] mm/kdump: exclude reserved pages in dumps Message-ID: <20180723123043.GD31229@dhcp22.suse.cz> References: <20180720123422.10127-1-david@redhat.com> <9f46f0ed-e34c-73be-60ca-c892fb19ed08@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9f46f0ed-e34c-73be-60ca-c892fb19ed08@suse.cz> User-Agent: Mutt/1.10.0 (2018-05-17) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon 23-07-18 13:45:18, Vlastimil Babka wrote: > On 07/20/2018 02:34 PM, David Hildenbrand wrote: > > Dumping tools (like makedumpfile) right now don't exclude reserved pages. > > So reserved pages might be access by dump tools although nobody except > > the owner should touch them. > > Are you sure about that? Or maybe I understand wrong. Maybe it changed > recently, but IIRC pages that are backing memmap (struct pages) are also > PG_reserved. And you definitely do want those in the dump. You are right. reserve_bootmem_region will make all early bootmem allocations (including those backing memmaps) PageReserved. I have asked several times but I haven't seen a satisfactory answer yet. Why do we even care for kdump about those. If they are reserved the nobody should really look at those specific struct pages and manipulate them. Kdump tools are using a kernel interface to read the content. If the specific content is backed by a non-existing memory then they should simply not return anything. -- Michal Hocko SUSE Labs