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=-8.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED, 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 65AAAC43441 for ; Wed, 21 Nov 2018 17:54:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id F397E214C4 for ; Wed, 21 Nov 2018 17:54:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F397E214C4 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.ibm.com 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 S1732742AbeKVEaB (ORCPT ); Wed, 21 Nov 2018 23:30:01 -0500 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:35102 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1732724AbeKVEaB (ORCPT ); Wed, 21 Nov 2018 23:30:01 -0500 Received: from pps.filterd (m0098420.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id wALHmVRp023081 for ; Wed, 21 Nov 2018 12:54:38 -0500 Received: from e06smtp05.uk.ibm.com (e06smtp05.uk.ibm.com [195.75.94.101]) by mx0b-001b2d01.pphosted.com with ESMTP id 2nwbxerkgf-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 21 Nov 2018 12:54:38 -0500 Received: from localhost by e06smtp05.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 21 Nov 2018 17:54:36 -0000 Received: from b06cxnps3075.portsmouth.uk.ibm.com (9.149.109.195) by e06smtp05.uk.ibm.com (192.168.101.135) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Wed, 21 Nov 2018 17:54:32 -0000 Received: from d06av26.portsmouth.uk.ibm.com (d06av26.portsmouth.uk.ibm.com [9.149.105.62]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id wALHsVER62718092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 21 Nov 2018 17:54:31 GMT Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 234D2AE051; Wed, 21 Nov 2018 17:54:31 +0000 (GMT) Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 24BD3AE04D; Wed, 21 Nov 2018 17:54:30 +0000 (GMT) Received: from rapoport-lnx (unknown [9.148.207.68]) by d06av26.portsmouth.uk.ibm.com (Postfix) with ESMTPS; Wed, 21 Nov 2018 17:54:30 +0000 (GMT) Date: Wed, 21 Nov 2018 18:54:28 +0100 From: Mike Rapoport To: Michal Hocko Cc: linux-api@vger.kernel.org, Andrew Morton , Alexey Dobriyan , linux-mm@kvack.org, LKML , Michal Hocko , Jan Kara , Dan Williams , David Rientjes Subject: Re: [RFC PATCH 1/3] mm, proc: be more verbose about unstable VMA flags in /proc//smaps References: <20181120103515.25280-1-mhocko@kernel.org> <20181120103515.25280-2-mhocko@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181120103515.25280-2-mhocko@kernel.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-TM-AS-GCONF: 00 x-cbid: 18112117-0020-0000-0000-000002EBA99C X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18112117-0021-0000-0000-0000213AE2FF Message-Id: <20181121175427.GB5704@rapoport-lnx> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-11-21_09:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1811210155 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 20, 2018 at 11:35:13AM +0100, Michal Hocko wrote: > 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 > --- > 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 consumer? has > +follow each specific kernel version for the exact semantic. > > This file is only present if the CONFIG_MMU kernel configuration option is > enabled. > -- > 2.19.1 > -- Sincerely yours, Mike.