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=-12.9 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1, USER_IN_DEF_DKIM_WL autolearn=no 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 92CC4C433E1 for ; Thu, 27 Aug 2020 20:53:08 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2DB1320737 for ; Thu, 27 Aug 2020 20:53:08 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="DUv2JL9s" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2DB1320737 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 754536B0002; Thu, 27 Aug 2020 16:53:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6DABC6B0003; Thu, 27 Aug 2020 16:53:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 57CA36B0006; Thu, 27 Aug 2020 16:53:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0228.hostedemail.com [216.40.44.228]) by kanga.kvack.org (Postfix) with ESMTP id 3DA5C6B0002 for ; Thu, 27 Aug 2020 16:53:07 -0400 (EDT) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id D2A913643 for ; Thu, 27 Aug 2020 20:53:06 +0000 (UTC) X-FDA: 77197548372.25.sun77_5e07e3427070 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin25.hostedemail.com (Postfix) with ESMTP id 91A051804E3A9 for ; Thu, 27 Aug 2020 20:53:06 +0000 (UTC) X-HE-Tag: sun77_5e07e3427070 X-Filterd-Recvd-Size: 5228 Received: from mail-oi1-f174.google.com (mail-oi1-f174.google.com [209.85.167.174]) by imf43.hostedemail.com (Postfix) with ESMTP for ; Thu, 27 Aug 2020 20:53:06 +0000 (UTC) Received: by mail-oi1-f174.google.com with SMTP id v13so5827365oiv.13 for ; Thu, 27 Aug 2020 13:53:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=RhGr9j3VacI7USUWRQl+lZVR7KInvsEud0GT+v37QSc=; b=DUv2JL9sb/TCte8wvX2iBt64S0vKY5lBwd8SDkgCwl2ux+l/kh76pW31musXBzswwF sywxCMAYWRBHcRPqkYkRk9/nQweTNrYpeZkA0jUqB872aP1hszKchuwg4MTvTifTIzxH mWBdW7utS87NZrst2u4bVR5sil3OyXv7R8JYOckHjjk58exsj1J5jkoHmZvsbx5lxaH4 bEq/oHfzUO8AKvi6qOfY1uxsFK90++2EvMzW0RxuQ4UsBn+1XJQfHeKTBPC+9JBKrB0s eYIY/7bdpEaswBrY1DwKOqaUjRyuW2QT5OOXM1qCyIhju9DPvTPf6hNuLzUbJ2Yqeedf cZyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=RhGr9j3VacI7USUWRQl+lZVR7KInvsEud0GT+v37QSc=; b=lsan04SG8tnnGUtBfyYAhZQpr9yzDr/rfuTxemF73AYPr4D4GhAubGcCQfPoNN2blF 7EwR368FVoVojyobqe8oUVwoGGIKaffrlldodOfGaWLAqm+lHyddzKKqdXzH7VC85mO5 jqNRIhBQ2HBWEhE/WhKcz5rtzrElSFtuAqGorvildBhdXozWLdcITYH6/Ba3RTQWE1b0 5ttTbdDLR2qqW/SX5YEz+TxwCUVBokvSPggdcNHzY4MeBONXRBrkpkpV8Vo4lPxLa3NX 9nOVy23z4uVSFzPGVOHC4kAXou/vKLu7KYZH0nJ/JEtVlKGtVAXJchcsnzoutfl2/hji uU/A== X-Gm-Message-State: AOAM533PPkqTsKBzcOHg49Qz0DcknYqx17UhsFEBHKHYQ1H6MtOduX3D 9qnAiMyMGXJJDYvldxXW4xkYRA== X-Google-Smtp-Source: ABdhPJzPeUGHv3SkPnzbEGRSmNObnvSCA8EgzNTqCM66ABRtV3olipGK4kCqMiADn2WINDvNve/CrA== X-Received: by 2002:aca:bf0b:: with SMTP id p11mr519250oif.120.1598561585178; Thu, 27 Aug 2020 13:53:05 -0700 (PDT) Received: from eggly.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id w15sm689539otp.57.2020.08.27.13.53.03 (version=TLS1 cipher=ECDHE-ECDSA-AES128-SHA bits=128/128); Thu, 27 Aug 2020 13:53:04 -0700 (PDT) Date: Thu, 27 Aug 2020 13:52:47 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@eggly.anvils To: Matthew Wilcox cc: linux-mm@kvack.org Subject: Re: When is page->index stable? In-Reply-To: <20200827191407.GM14765@casper.infradead.org> Message-ID: References: <20200827191407.GM14765@casper.infradead.org> User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Rspamd-Queue-Id: 91A051804E3A9 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam04 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 Thu, 27 Aug 2020, Matthew Wilcox wrote: > We have a number of places where we look up a page in the page cache, > lock it, then have some kind of assertion that we got back the page we > asked for, eg filemap_fault(): > > page = find_get_page(mapping, offset); > ... > if (!lock_page_maybe_drop_mmap(vmf, page, &fpin)) > goto out_retry; > ... > VM_BUG_ON_PAGE(page_to_pgoff(page) != offset, page); > > but today I noticed this in shmem_undo_range(): > > pvec.nr = find_get_entries(mapping, index, > min(end - index, (pgoff_t)PAGEVEC_SIZE), > pvec.pages, indices); > ... > VM_BUG_ON_PAGE(page_to_pgoff(page) != index, page); > ... > if (!trylock_page(page)) > continue; > > So is page->index stable if we have a refcount on the page, Yes (once it has been found in the page cache - obviously not stable before it has been put into the page cache). > or is a lock on the page required? No. A lock on the page is required for page cache page->mapping to be stable, but not required for its page->index to remain stable. > A refcount on the page prevents it from being > split or freed. And there's plenty of comments along the lines of: > > mm/filemap.c: /* Leave page->index set: truncation lookup relies on it */ > > which indicates that once a page is removed from the page cache, its > index remains reliable (until it's freed). > > It might be nice to remove all these assertions from the callers and > bury them down in find_get_(entry,page,entries,...), but we can't do > that if we need the lock to check the index. If we don't need the lock, > then it should be safe to check as soon as we've checked that > page == xas_reload(). Yes. But you might then discover something violating the principle. I have an indistinct memory of spotting an instance once, maybe just in a prospective patchset that didn't reach the kernel; perhaps someone resetting page->index to 0 "for tidiness" before freeing; maybe page migration did that once upon a time, then got fixed. And of course beware of hugetlbfs, defining page->index differently (unless you have fixed that already). Hugh