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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id F22FAC28CF5 for ; Wed, 26 Jan 2022 18:55:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 703D16B0071; Wed, 26 Jan 2022 13:55:00 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6AFAE6B0073; Wed, 26 Jan 2022 13:55:00 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5508A6B0074; Wed, 26 Jan 2022 13:55:00 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0148.hostedemail.com [216.40.44.148]) by kanga.kvack.org (Postfix) with ESMTP id 46F7C6B0071 for ; Wed, 26 Jan 2022 13:55:00 -0500 (EST) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id F168E181D5AAB for ; Wed, 26 Jan 2022 18:54:59 +0000 (UTC) X-FDA: 79073340318.06.7A76844 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf01.hostedemail.com (Postfix) with ESMTP id 197FA4000F for ; Wed, 26 Jan 2022 18:54:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1643223298; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=hhj664AgQt2KQtf7ayYCvSA5RqB+++2Rhwj5UZ7qWsg=; b=LbNbY/etdVE3pfl8mWPsWcOfqdoDZG4mMmE98xHVXkE6JDNpKLE5o6XtbH1DbW9G4O4Onc ygtHC88Y7ttVyhSUlejI7i+XrBfWoVFy2wgSqJe0iA6vmj+NVzmW+BB4+FsOV3fskr1/we BfA9N+tlcokxoSagUHe7Z42WX5YMMx4= Received: from mail-ed1-f72.google.com (mail-ed1-f72.google.com [209.85.208.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-451-hDdsmjxUOSqJ_-ePPUdWjA-1; Wed, 26 Jan 2022 13:54:57 -0500 X-MC-Unique: hDdsmjxUOSqJ_-ePPUdWjA-1 Received: by mail-ed1-f72.google.com with SMTP id j1-20020aa7c341000000b0040417b84efeso145658edr.21 for ; Wed, 26 Jan 2022 10:54:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:cc:references:from:organization:subject :in-reply-to:content-transfer-encoding; bh=hhj664AgQt2KQtf7ayYCvSA5RqB+++2Rhwj5UZ7qWsg=; b=LBIko98awL12/+qxARZ6OgBcr2rMWxgZaIQ37Bm58kOBswRjxAKB/tH3/e49Zl5/vM uXl8J5MwKS1oTAcMg0XRlSwDaTrHAodJ5BWSqjDsPnUcR8k4+niBY5VzZ3E7Gv8qW4iJ IPnU5M9QdyjPzI8SXncTeYtOksd2fXCzr0HMsAM0/Jo9LS41TMXHKMV12uGPS0PE0pXb CbIklsq2jWJxLa82j0jzv6U6fgaJBYBkCWf9cQpIdBfVUcERNVzFVhc2rPUzrF34W0PW FBi3nEscWuOUKYVc+8BiJU9pgZUwViLEeWr0Cxvftxvfn0gbGGdW09Vv5ElUF2cfjXzz MFnA== X-Gm-Message-State: AOAM5319XHQS8dGUKc2ad0saKb9b2uGwJDWfXcD/TBufpWbdkY62YE2B K2dZcJMCSV0N7tHdMpIo/4o2vTHyurz92zN6uoupyvH5+YmAZ8Xe+4hxgihfOnP01KzIyS5UdJ7 gjuPOICyVt7s= X-Received: by 2002:a50:9fc6:: with SMTP id c64mr373302edf.5.1643223295980; Wed, 26 Jan 2022 10:54:55 -0800 (PST) X-Google-Smtp-Source: ABdhPJwNVlUS4gG6iKHrXL4vEtlyLwR50PsiO1uMeg6vr7kFp887V1xsTCa2ukZkyA57E8IaC8YFEQ== X-Received: by 2002:a50:9fc6:: with SMTP id c64mr373279edf.5.1643223295724; Wed, 26 Jan 2022 10:54:55 -0800 (PST) Received: from ?IPV6:2003:cb:c709:2700:cdd8:dcb0:2a69:8783? (p200300cbc7092700cdd8dcb02a698783.dip0.t-ipconnect.de. [2003:cb:c709:2700:cdd8:dcb0:2a69:8783]) by smtp.gmail.com with ESMTPSA id h3sm10210165edq.83.2022.01.26.10.54.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 26 Jan 2022 10:54:55 -0800 (PST) Message-ID: <2a1c5bd2-cb8c-b93b-68af-de620438d19a@redhat.com> Date: Wed, 26 Jan 2022 19:54:53 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 To: Yang Shi Cc: Jann Horn , "Kirill A. Shutemov" , Matthew Wilcox , Andrew Morton , Linux MM , Linux Kernel Mailing List , stable References: <20220120202805.3369-1-shy828301@gmail.com> <5b4e2c29-8f1a-5a68-d243-a30467cc02d4@redhat.com> <5a565d5a-0540-4041-ce63-a8fd5d1bb340@redhat.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [v2 PATCH] fs/proc: task_mmu.c: don't read mapcount for migration entry In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 197FA4000F X-Stat-Signature: n8pea5ft9ar6narkp1z8dw3e98tj641n Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="LbNbY/et"; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf01.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=david@redhat.com X-Rspam-User: nil X-HE-Tag: 1643223298-510710 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: >>> Just page lock or elevated page refcount could serialize against THP >>> split AFAIK. >>> >>>> >>>> But yeah, using the mapcount of a page that is not even mapped >>>> (migration entry) is clearly wrong. >>>> >>>> To summarize: reading the mapcount on an unlocked page will easily >>>> return a wrong result and the result should not be relied upon. reading >>>> the mapcount of a migration entry is dangerous and certainly wrong. >>> >>> Depends on your usecase. Some just want to get a snapshot, just like >>> smaps, they don't care. >> >> Right, but as discussed, even the snapshot might be slightly wrong. That >> might be just fine for smaps (and I would have enjoyed a comment in the >> code stating that :) ). > > I think that is documented already, see Documentation/filesystems/proc.rst: > > Note: reading /proc/PID/maps or /proc/PID/smaps is inherently racy (consistent > output can be achieved only in the single read call). Right, but I think there is a difference between * Atomic values that change immediately afterwards ("this value used to be true at one point in time") * Values that are unstable because we cannot read them atomically ("this value never used to be true") I'd assume with the documented race we actually talk about the first point, but I might be just wrong. > > Of course, if the extra note is preferred in the code, I could try to > add some in a separate patch. When staring at the (original) code I would have hoped to find something like: /* * We use page_mapcount() to get a snapshot of the mapcount. Without * holding the page lock this snapshot can be slightly wrong as we * cannot always read the mapcount atomically. As long we hold the PT * lock, the page cannot get unmapped and it's at safe to call * page_mapcount(). */ With the addition of "... For unmapped pages (e.g., migration entries) we cannot guarantee that, so treat the mapcount as being 1." But this is just my personal preference ... :) I do think the patch does the right thing in regard to migration entries. -- Thanks, David / dhildenb