From patchwork Tue Nov 20 10:35:13 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michal Hocko X-Patchwork-Id: 10690205 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 3AD9C15A7 for ; Tue, 20 Nov 2018 10:35:36 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 2BFAB2906E for ; Tue, 20 Nov 2018 10:35:36 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 204A02A87C; Tue, 20 Nov 2018 10:35:36 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 9A1402906E for ; Tue, 20 Nov 2018 10:35:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4E1CB6B1FCC; Tue, 20 Nov 2018 05:35:33 -0500 (EST) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 4681E6B1FCD; Tue, 20 Nov 2018 05:35:33 -0500 (EST) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 35B3D6B1FCE; Tue, 20 Nov 2018 05:35:33 -0500 (EST) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from mail-ed1-f71.google.com (mail-ed1-f71.google.com [209.85.208.71]) by kanga.kvack.org (Postfix) with ESMTP id CBB886B1FCC for ; Tue, 20 Nov 2018 05:35:32 -0500 (EST) Received: by mail-ed1-f71.google.com with SMTP id v4so1010256edm.18 for ; Tue, 20 Nov 2018 02:35:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-original-authentication-results:x-gm-message-state:from:to:cc :subject:date:message-id:in-reply-to:references:mime-version :content-transfer-encoding; bh=uxsJPkLcKckgPrN9D2d3v7GbIbgMcMizVEHoIL7/qsw=; b=MBQ6oFSFKiWYQTAQnNWw4wFehXhnKVn7bEuHBvA2KwnUDkEIhbhBQoOqftC81rt3X/ ki5BTRYoXFLohYCbIr76fBrUBbTh39PzQIM802UaY5DN8F+PetMIW/94K9vTGDLIEBOG pJq1XHA9RBg6gxLEdvlYKxqmEKBt4ohybBUj/lGGe4gex2eQT93O3kUOzz6S6szlp9TD fSAq+02l5bggkrz/B2MRYXfhrU69bjnaCOFHoDvZTKHivdbGFUuc2UmRP2n9pTjSc3qN y7XS9Y+xYGxrgsRFHuVan3G8PX/r40kqyugIT0n3D/faPg6w514Z65teu5dB+/TcKZ5V WZtQ== X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of mstsxfx@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=mstsxfx@gmail.com; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org X-Gm-Message-State: AGRZ1gKCDjJMloQzlW1/a9kfBmESA/fhCJmfZjhStyRk6DxlOFfUJZXK B4790MiINN6PinzbBc4aW8V0tyYcAG9IvBeN8BxsgyqDLEqU66omuUrIcO5zgLTmbkam4qyPvxu 4suqPDo7nswkXRH3C77+0tmTVOdJy9cqdaDzH9hoQqKWltKJ1VvbuwUZ4D0ABvzTtQtKqqT97k5 U4IIt2IssgP3IGIEWLlyNH161ujA0U6iDMfJj8ovPAafzNtjMXbk+AOF3HX4KpSNyQzKe/4Ad7B hfxWQtITAA0ZNkXQv+8mznmWOdilhj6DHr6rRSdJ4tJIDlBtIgKiRA+kYhc3zOKFZTP9aU3mAGM MP3tVUnwJIrHy/rhuTG9tFC9dVwaqoXbMw5YjVlAVmecOUevsjCejT993VBhjADRkfhqlrJw4Q= = X-Received: by 2002:a17:906:b243:: with SMTP id ce3-v6mr1540383ejb.87.1542710132285; Tue, 20 Nov 2018 02:35:32 -0800 (PST) X-Received: by 2002:a17:906:b243:: with SMTP id ce3-v6mr1540346ejb.87.1542710131222; Tue, 20 Nov 2018 02:35:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542710131; cv=none; d=google.com; s=arc-20160816; b=M3btcxA3GOWtd4FV/Ns94oZ0jTFMCbBkAApAz4Lv9iaUyq5uWA/EA954TnSlXN1ZCO lgyAF08w6Rd+6daz/EbsFISvqtCl0a4+j8j7TlqiT15vZNb4Y+nJco07rVyon+fUaqDo YMPN0LfhztNdSKNFm6+CnRlcH/E49rGQCP2StuUf9QXPi/NfjnX7jIEKz7SMJAKdFocE Do2mxzNt3mC2/BS8jEC4Zk+zL8WQ0pLnJnmPYbdkeb4XA7O7sUWDX0OnGTLev3W+dlil uXDz73Qywyk8DaIdxddiyzjnaK15Su4n9ZzW5VJL4bK+6EYQ+lu03V2Zq/vvv+Wrtmdi 7M6Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from; bh=uxsJPkLcKckgPrN9D2d3v7GbIbgMcMizVEHoIL7/qsw=; b=XLkUeZLVTeoGC47D+ZfI2e8zyfKon3J0iFyBkJfxsx1zo78LxZs5Kp/3+w+1lT4q74 PiI2NrMB8/46Aw+laLoI0gfej/NP2jLivW6yCzAC/8PmFipovk1pk6rIP1inQxmtZaH+ K9jYaIRFCrps0DhZogAkxBInBncEXXg8ELToVdk+0hAtDdCTYa6jLeGY9cf3oVXMWwW6 rg98C7enRyDRlKRp/aUTuJnZ7/7ukkVXJwenQ6yv4/A4RjpAcoKdAAq+JzgTqXa0kqeE CjdaN26VHEDZo/V3/Qsm0iF6XrgFWVutncgduyrH2rfEdHGkKuTc2+hOE0oZ0yWxn+GF wg2A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of mstsxfx@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=mstsxfx@gmail.com; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id h34sor12026592edb.28.2018.11.20.02.35.31 for (Google Transport Security); Tue, 20 Nov 2018 02:35:31 -0800 (PST) Received-SPF: pass (google.com: domain of mstsxfx@gmail.com designates 209.85.220.65 as permitted sender) client-ip=209.85.220.65; Authentication-Results: mx.google.com; spf=pass (google.com: domain of mstsxfx@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=mstsxfx@gmail.com; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org X-Google-Smtp-Source: AFSGD/XcnnedeezeTZmmFpCMjh4dc1ajw+LXBhUFZ7D3LPQ8LJxLKr4zWSjKw58X7+vbshNyIL2LJA== X-Received: by 2002:a50:8799:: with SMTP id a25mr1831824eda.96.1542710130747; Tue, 20 Nov 2018 02:35:30 -0800 (PST) Received: from tiehlicka.suse.cz (prg-ext-pat.suse.com. [213.151.95.130]) by smtp.gmail.com with ESMTPSA id a15-v6sm5967233ejj.5.2018.11.20.02.35.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Nov 2018 02:35:29 -0800 (PST) From: Michal Hocko To: linux-api@vger.kernel.org Cc: Andrew Morton , Alexey Dobriyan , , LKML , Michal Hocko , Jan Kara , Dan Williams , David Rientjes Subject: [RFC PATCH 1/3] mm, proc: be more verbose about unstable VMA flags in /proc//smaps Date: Tue, 20 Nov 2018 11:35:13 +0100 Message-Id: <20181120103515.25280-2-mhocko@kernel.org> X-Mailer: git-send-email 2.19.1 In-Reply-To: <20181120103515.25280-1-mhocko@kernel.org> References: <20181120103515.25280-1-mhocko@kernel.org> MIME-Version: 1.0 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: X-Virus-Scanned: ClamAV using ClamSMTP From: Michal Hocko Even though vma flags exported via /proc//smaps are explicitly documented to be not guaranteed for future compatibility the warning doesn't go far enough because it doesn't mention semantic changes to those flags. And they are important as well because these flags are a deep implementation internal to the MM code and the semantic might change at any time. Let's consider two recent examples: http://lkml.kernel.org/r/20181002100531.GC4135@quack2.suse.cz : commit e1fb4a086495 "dax: remove VM_MIXEDMAP for fsdax and device dax" has : removed VM_MIXEDMAP flag from DAX VMAs. Now our testing shows that in the : mean time certain customer of ours started poking into /proc//smaps : and looks at VMA flags there and if VM_MIXEDMAP is missing among the VMA : flags, the application just fails to start complaining that DAX support is : missing in the kernel. http://lkml.kernel.org/r/alpine.DEB.2.21.1809241054050.224429@chino.kir.corp.google.com : Commit 1860033237d4 ("mm: make PR_SET_THP_DISABLE immediately active") : introduced a regression in that userspace cannot always determine the set : of vmas where thp is ineligible. : Userspace relies on the "nh" flag being emitted as part of /proc/pid/smaps : to determine if a vma is eligible to be backed by hugepages. : Previous to this commit, prctl(PR_SET_THP_DISABLE, 1) would cause thp to : be disabled and emit "nh" as a flag for the corresponding vmas as part of : /proc/pid/smaps. After the commit, thp is disabled by means of an mm : flag and "nh" is not emitted. : This causes smaps parsing libraries to assume a vma is eligible for thp : and ends up puzzling the user on why its memory is not backed by thp. In both cases userspace was relying on a semantic of a specific VMA flag. The primary reason why that happened is a lack of a proper internface. While this has been worked on and it will be fixed properly, it seems that our wording could see some refinement and be more vocal about semantic aspect of these flags as well. Cc: Jan Kara Cc: Dan Williams Cc: David Rientjes Signed-off-by: Michal Hocko Acked-by: Jan Kara Acked-by: Dan Williams Acked-by: David Rientjes Acked-by: Mike Rapoport Acked-by: Vlastimil Babka --- Documentation/filesystems/proc.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index 12a5e6e693b6..b1fda309f067 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -496,7 +496,9 @@ flags associated with the particular virtual memory area in two letter encoded Note that there is no guarantee that every flag and associated mnemonic will be present in all further kernel releases. Things get changed, the flags may -be vanished or the reverse -- new added. +be vanished or the reverse -- new added. Interpretatation of their meaning +might change in future as well. So each consumnent of these flags have to +follow each specific kernel version for the exact semantic. This file is only present if the CONFIG_MMU kernel configuration option is enabled.