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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E3F83C433EF for ; Wed, 10 Nov 2021 08:57:39 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8933B61051 for ; Wed, 10 Nov 2021 08:57:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 8933B61051 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 03FF96B006C; Wed, 10 Nov 2021 03:57:39 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id F32826B0071; Wed, 10 Nov 2021 03:57:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DF98C6B0072; Wed, 10 Nov 2021 03:57:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0024.hostedemail.com [216.40.44.24]) by kanga.kvack.org (Postfix) with ESMTP id CD03A6B006C for ; Wed, 10 Nov 2021 03:57:38 -0500 (EST) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 8C02975836 for ; Wed, 10 Nov 2021 08:57:38 +0000 (UTC) X-FDA: 78792417396.30.856825E Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf02.hostedemail.com (Postfix) with ESMTP id D3F63700170E for ; Wed, 10 Nov 2021 08:57:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1636534657; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=3KAQ2TyWknxx/QWCYCyvuZx1be3dMQ9P5XgzUpSmndc=; b=MZDhOT/lTm7o5GtbTCHSDiqSXaqNIowNt3b2ThU7g3/lLA3BRVjcb9L4FuuI2FhTJ3kgk9 GDdrv7R2i+nsD8UPYQAsVt5a1nP4OYu3CtJ9wh8r1x6yVlvLW/SvK44Fk1Ghsae5SNefEv +6anAF9MAvvuXpTZCTXl6qMlMIcmkjU= Received: from mail-pf1-f198.google.com (mail-pf1-f198.google.com [209.85.210.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-445-TGqWMbrrN4mixxPCjnnweQ-1; Wed, 10 Nov 2021 03:57:36 -0500 X-MC-Unique: TGqWMbrrN4mixxPCjnnweQ-1 Received: by mail-pf1-f198.google.com with SMTP id x25-20020aa79199000000b0044caf0d1ba8so1640114pfa.1 for ; Wed, 10 Nov 2021 00:57:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=3KAQ2TyWknxx/QWCYCyvuZx1be3dMQ9P5XgzUpSmndc=; b=PjPdcb0IVxCLKH5r6aELqBQOLwNv+jQDdrSb/KMc6XO+29GG6X8BKUGM7gPw910Yzf 5E7DLJJpfRg32LXF73HuTxyHB1V3IWHccwZ99SsUUHLGgwDNeOfJh/9fcE3NDGU8TeJn R6QNdOepjtOG8jt5Eyq4UXsm+NcC6ijKEcgoLTqGkX8adJ0ZOOmn+LW9wQRUy1DRWndz aovFQug84DN0f3DL/zAtHoRu415YzqKyYwfh5mPQzTsiiwlaFp6SYWWFb0t0tZRJQ4/B lA1L3HoGPkQboxDnphdzM5F31eMKYlHxnCcf+Vi9f2mstcBpCj/GMbIhggwL6puJmZlO jyVw== X-Gm-Message-State: AOAM5337dB2PPkAAtItgfY7FOPi8SkQTQaBUqgTMpkUcv8f7wxGTXhmn +YXY7CJT3O4TavmgZnuuub+LcpvxVBzdv3EH4v6j3RUUhwDb91kfPoTutzvTGK7AF5lGMaUjN4Q REAR8QZUiWzo= X-Received: by 2002:a63:8b4b:: with SMTP id j72mr10705953pge.10.1636534655295; Wed, 10 Nov 2021 00:57:35 -0800 (PST) X-Google-Smtp-Source: ABdhPJyYVeA1YbnxCLJHeUVTE40Yp83p8k+PlYnN0X+h7COcawOK6O3AMBdyxxdFewwYzccU/o+c1Q== X-Received: by 2002:a63:8b4b:: with SMTP id j72mr10705930pge.10.1636534654994; Wed, 10 Nov 2021 00:57:34 -0800 (PST) Received: from xz-m1.local ([94.177.118.35]) by smtp.gmail.com with ESMTPSA id x33sm11454976pfh.133.2021.11.10.00.57.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Nov 2021 00:57:34 -0800 (PST) Date: Wed, 10 Nov 2021 16:57:27 +0800 From: Peter Xu To: David Hildenbrand Cc: Mina Almasry , Matthew Wilcox , "Paul E . McKenney" , Yu Zhao , Jonathan Corbet , Andrew Morton , Ivan Teterevkov , Florian Schmidt , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v4] mm: Add PM_HUGE_THP_MAPPING to /proc/pid/pagemap Message-ID: References: <20211107235754.1395488-1-almasrymina@google.com> <793685d2-be3f-9a74-c9a3-65c486e0ef1f@redhat.com> MIME-Version: 1.0 In-Reply-To: <793685d2-be3f-9a74-c9a3-65c486e0ef1f@redhat.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="MZDhOT/l"; spf=none (imf02.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 216.205.24.124) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: D3F63700170E X-Stat-Signature: 4igxr3j3uoma6us15cg4isyym7ousb1j X-HE-Tag: 1636534651-115676 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: On Wed, Nov 10, 2021 at 09:30:50AM +0100, David Hildenbrand wrote: > On 10.11.21 09:27, Peter Xu wrote: > > On Wed, Nov 10, 2021 at 09:14:42AM +0100, David Hildenbrand wrote: > >> On 10.11.21 08:03, Peter Xu wrote: > >>> Hi, Mina, > >>> > >>> Sorry to comment late. > >>> > >>> On Sun, Nov 07, 2021 at 03:57:54PM -0800, Mina Almasry wrote: > >>>> diff --git a/Documentation/admin-guide/mm/pagemap.rst b/Documentation/admin-guide/mm/pagemap.rst > >>>> index fdc19fbc10839..8a0f0064ff336 100644 > >>>> --- a/Documentation/admin-guide/mm/pagemap.rst > >>>> +++ b/Documentation/admin-guide/mm/pagemap.rst > >>>> @@ -23,7 +23,8 @@ There are four components to pagemap: > >>>> * Bit 56 page exclusively mapped (since 4.2) > >>>> * Bit 57 pte is uffd-wp write-protected (since 5.13) (see > >>>> :ref:`Documentation/admin-guide/mm/userfaultfd.rst `) > >>>> - * Bits 57-60 zero > >>>> + * Bit 58 page is a huge (PMD size) THP mapping > >>>> + * Bits 59-60 zero > >>>> * Bit 61 page is file-page or shared-anon (since 3.5) > >>>> * Bit 62 page swapped > >>>> * Bit 63 page present > >>>> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c > >>>> index ad667dbc96f5c..6f1403f83b310 100644 > >>>> --- a/fs/proc/task_mmu.c > >>>> +++ b/fs/proc/task_mmu.c > >>>> @@ -1302,6 +1302,7 @@ struct pagemapread { > >>>> #define PM_SOFT_DIRTY BIT_ULL(55) > >>>> #define PM_MMAP_EXCLUSIVE BIT_ULL(56) > >>>> #define PM_UFFD_WP BIT_ULL(57) > >>>> +#define PM_HUGE_THP_MAPPING BIT_ULL(58) > >>> > >>> The ending "_MAPPING" seems redundant to me, how about just call it "PM_THP" or > >>> "PM_HUGE" (as THP also means HUGE already)? > >>> > >>> IMHO the core problem is about permission controls, and it seems to me we're > >>> actually trying to workaround it by duplicating some information we have.. so > >>> it's kind of a pity. Totally not against this patch, but imho it'll be nicer > >>> if it's the permission part that to be enhanced, rather than a new but slightly > >>> duplicated interface. > >> > >> It's not a permission problem AFAIKS: even with permissions "changed", > >> any attempt to use /proc/kpageflags is just racy. Let's not go down that > >> path, it's really the wrong mechanism to export to random userspace. > > > > I agree it's racy, but IMHO that's fine. These are hints for userspace to make > > decisions, they cannot be always right. Even if we fetch atomically and seeing > > that this pte is swapped out, it can be quickly accessed at the same time and > > it'll be in-memory again. Only if we can freeze the whole pgtable but we > > can't, so they can only be used as hints. > > Sorry, I don't think /proc/kpageflags (or exporting the PFNs to random > users via /proc/self/pagemap) is the way to go. > > "Since Linux 4.0 only users with the CAP_SYS_ADMIN capability can get > PFNs. In 4.0 and 4.1 opens by unprivileged fail with -EPERM. Starting > from 4.2 the PFN field is zeroed if the user does not have > CAP_SYS_ADMIN. Reason: information about PFNs helps in exploiting > Rowhammer vulnerability." IMHO these are two problems that you mentioned. That's also what I was wondering about: could the app be granted with CAP_SYS_ADMIN then? I am not sure whether that'll work well with /proc/kpage* though, as it's by default 0400. So perhaps we need to manual adjust the file permission too to make sure the app can both access PFNs (with SYS_ADMIN) and the flags. Totally no expert on the permissions.. > > > > >> > >> We do have an interface to access this information from userspace > >> already: /proc/self/smaps IIRC. Mina commented that they are seeing > >> performance issues with that approach. > >> > >> It would be valuable to add these details to the patch description, > >> including a performance difference when using both interfaces we have > >> available. As the patch description stands, there is no explanation > >> "why" we want this change. > > > > I didn't notice Mina mention about performance issues with kpageflags, if so > > then I agree this solution helps. > The performance issue seems to be with /proc/self/smaps. This also reminded me that we've got issue with smaps being too slow, and in many cases we're only interested in a small portion of the whole memory. This made me wonder how about a new smaps interface taking memory range as input. Thanks, -- Peter Xu