Received: by 2002:a25:2c96:0:0:0:0:0 with SMTP id s144csp1398741ybs; Mon, 25 May 2020 15:16:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx1rZ9KkhUeVEpq1pVJJr4uUaIwz06/j6StTCGUmTzgaqf+IngusibuSXpU3AaR5LPFFhBb X-Received: by 2002:a50:c091:: with SMTP id k17mr16660079edf.106.1590444963021; Mon, 25 May 2020 15:16:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590444963; cv=none; d=google.com; s=arc-20160816; b=XYZvfHit3MKBvWYm/IsIwNBCm91ZNbRttL9GKTrAmPpI8YZoMYEYNhupfPHBumDAMI FhwBfClggpRc/C5s7gGUWSYQjmNTwdtD/ZJfoMPYbGtwLRnGzscd9Pi2QRJsJ9zZcHfX 4yMLuLaEAR3Gl9HSgX9DBpSrl5R4VmM8SXtYRy2sMn+xEjEmzko+jpEhr9QTUdPEm5e/ EApVGNPUhHbDvPKy6yo+3rvEK2nqDPr+BVdsynOkQoMJzWLyVfkpD/hb9LN3unSw8Hki A1M53vt/ZTal3bfQfdkGKw6I0hXdJsbuiNAmuyoF7AfTS07c4l/XioKu4w2yzWE2rnRN Uzmg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:references:cc:to:from:subject:dkim-signature; bh=3jjWtTMGhPjbcVtg1vx9q6LAmq5WMdmzmKwCRrGUnXY=; b=FrMiH+E/rAVjMqAvolpA0AP+PbjIybyhezk+2AE5lkfiMlE4Qj6aBltqMzW894NL4D MeeWEHen6Y6Y1lmi0t6kOV9qLM3XyWl+pDGA2HAjBHGpzpg2jwj5zioL3mKzQ2rJwF5l rWTrGf4JSLqpv+BgYKaNHc6qnypb0oPK7s46HA58VEcqiP0EL2lS/8zl9eNgF32pIK9p JNgiYlCN3mmcB0Bn6NaV6vdQnJSnT1qFU6bC6yrCQFw7RricRqRpM8X9n86sUdZ86Pj7 Cq8sE3MJk0O01FpOYN4EWXJVlWXpbV9d7OHNsjXm+83vU5idPoNtkNdSeTP/kZivtL60 vB7w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@yandex-team.ru header.s=default header.b=ShmAblQJ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=yandex-team.ru Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k12si10045122ejx.675.2020.05.25.15.15.39; Mon, 25 May 2020 15:16:03 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@yandex-team.ru header.s=default header.b=ShmAblQJ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=yandex-team.ru Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391170AbgEYQFO (ORCPT + 99 others); Mon, 25 May 2020 12:05:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33250 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388432AbgEYQFN (ORCPT ); Mon, 25 May 2020 12:05:13 -0400 Received: from forwardcorp1p.mail.yandex.net (forwardcorp1p.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b6:217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B6336C061A0E for ; Mon, 25 May 2020 09:05:13 -0700 (PDT) Received: from mxbackcorp1g.mail.yandex.net (mxbackcorp1g.mail.yandex.net [IPv6:2a02:6b8:0:1402::301]) by forwardcorp1p.mail.yandex.net (Yandex) with ESMTP id 9C0F52E152E; Mon, 25 May 2020 19:05:09 +0300 (MSK) Received: from myt5-70c90f7d6d7d.qloud-c.yandex.net (myt5-70c90f7d6d7d.qloud-c.yandex.net [2a02:6b8:c12:3e2c:0:640:70c9:f7d]) by mxbackcorp1g.mail.yandex.net (mxbackcorp/Yandex) with ESMTP id Z7kgGVoVQI-582aU5bh; Mon, 25 May 2020 19:05:09 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1590422709; bh=3jjWtTMGhPjbcVtg1vx9q6LAmq5WMdmzmKwCRrGUnXY=; h=In-Reply-To:Message-ID:Date:References:To:From:Subject:Cc; b=ShmAblQJNrB/m8kYudhCcdYABE5rOPwX7rwEN/qmbozIaPXffxJheetH9txX4dmRQ xApC3NJx5O8/zc5g8CEMLlyb9QthU3l3bQvOj2wbtBFUbB7noxKNiwY8s1mP+xmkdr 1mdAWXL3Z8mNtjaIit05w0yLxvoPcyU0WzKBR7mQ= Authentication-Results: mxbackcorp1g.mail.yandex.net; dkim=pass header.i=@yandex-team.ru Received: from dynamic-vpn.dhcp.yndx.net (dynamic-vpn.dhcp.yndx.net [2a02:6b8:b081:603::1:c]) by myt5-70c90f7d6d7d.qloud-c.yandex.net (smtpcorp/Yandex) with ESMTPSA id WUrga2wuLw-58XSDtYm; Mon, 25 May 2020 19:05:08 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) Subject: Re: [PATCH] mm: dump_page: add debugfs file for dumping page state by pfn From: Konstantin Khlebnikov To: Matthew Wilcox Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Vlastimil Babka , "Kirill A. Shutemov" References: <159041635119.987025.7321864888027213705.stgit@buzz> <20200525153315.GC17206@bombadil.infradead.org> Message-ID: Date: Mon, 25 May 2020 19:05:08 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-CA Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org b On 25/05/2020 19.03, Konstantin Khlebnikov wrote: > > > On 25/05/2020 18.33, Matthew Wilcox wrote: >> On Mon, May 25, 2020 at 05:19:11PM +0300, Konstantin Khlebnikov wrote: >>> Tool 'page-types' could list pages mapped by process or file cache pages, >>> but it shows only limited amount of state exported via procfs. >>> >>> Let's employ existing helper dump_page() to reach remaining information: >>> writing pfn into /sys/kernel/debug/dump_page dumps state into kernel log. >>> >>> # echo 0x37c43c > /sys/kernel/debug/dump_page >>> # dmesg | tail -6 >>>   page:ffffcb0b0df10f00 refcount:1 mapcount:0 mapping:000000007755d3d9 index:0x30 >>>   0xffffffffae4239e0 name:"libGeoIP.so.1.6.9" >>>   flags: 0x200000000020014(uptodate|lru|mappedtodisk) >>>   raw: 0200000000020014 ffffcb0b187fd288 ffffcb0b189e6248 ffff9528a04afe10 >>>   raw: 0000000000000030 0000000000000000 00000001ffffffff 0000000000000000 >>>   page dumped because: debugfs request >> >> This makes me deeply uncomfortable.  We're using %px, and %lx >> (for the 'raw' lines) so we actually get to see kernel addresses. >> We've rationalised this in the past as being acceptable because you're >> already in an "assert triggered" kind of situation.  Now you're adding >> a way for any process with CAP_SYS_ADMIN to get kernel addresses dumped >> into the syslog. >> >> I think we need a different function for this, or we need to re-audit >> dump_page() for exposing kernel pointers, and not expose the raw data >> in struct page. >> > > It's better to add switch for disabling paranoia if bad things happening. > I.e. keep everything safe by default (or whatever sysctl/config set) and > flip the switch when needed. Also I'm ok to seal this interface if kernel in mode of serious paranoia.