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 2E74EC43334 for ; Fri, 10 Jun 2022 23:27:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 429628D00EF; Fri, 10 Jun 2022 19:27:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3D8DC8D00E2; Fri, 10 Jun 2022 19:27:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2A0C18D00EF; Fri, 10 Jun 2022 19:27:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 18A738D00E2 for ; Fri, 10 Jun 2022 19:27:48 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id D65772173A for ; Fri, 10 Jun 2022 23:27:47 +0000 (UTC) X-FDA: 79563915774.04.1404A3E Received: from mail-ej1-f50.google.com (mail-ej1-f50.google.com [209.85.218.50]) by imf17.hostedemail.com (Postfix) with ESMTP id 7978940058 for ; Fri, 10 Jun 2022 23:27:43 +0000 (UTC) Received: by mail-ej1-f50.google.com with SMTP id o7so807835eja.1 for ; Fri, 10 Jun 2022 16:27:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GZoJzsRoNjoiccDOrK94bxpJ3hfAz32yrlvd2dEbdCc=; b=aLZKbkpPIDUtm14Pxye+efBZEkBYhaccf/7S7anQyCDaVOTMTbCHrjAXLEyx0JZ9oa rimx2FbptEmJpu4UBqIupfULzJT0n+9BDzC6Tpis2hVCNTS/XYH8TK8ADU4za2z3OWUs ybuPc8IqO7x9sgmL1xCFOSnxFrXkQ6mQGZ9jI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GZoJzsRoNjoiccDOrK94bxpJ3hfAz32yrlvd2dEbdCc=; b=faHiA2I+08Gfb/la9+Jq6M3QvbPjSpvBxqJ1B9sOxMGAQVC7UdnJdXgTZmSVXH2elA fIieTVjx4rG1gWCuQn8KpzzBlOUFIQGYY1oQneNgbQzjt6z+ILpugxsCi2bvR0iohBp1 29CvwGcmzyxPVkxYpfKGYVjkppbib616wXGYztPdLAEqN0nZVD+9e9trWstcOUZQ9XNq DCbsHdljkY+qVgBXI9mXhewqqgx558cObjRNj85FLIPOjTNSB49yj0Ctc45WPwo2IT8E GbQA0qN2KGfsu780fEx9LjjgzPne2YoKRZ49fMmlhZaxNo1KF2xjA4WaDW/CyIrPZZR8 YJlw== X-Gm-Message-State: AOAM530XUXOwqQGTzuLU3cki6wFzRxM6KJnK91x22djcY9keaeWMqONz i5QujCz+uAUrA06gJqepJkAjikko/CEzMLOC X-Google-Smtp-Source: ABdhPJyikNqjOVX6MRXCVIW1n22ALQFptWY+v6mRpi3q2R809uPoH+e8Xu8bezfxraZtob/venhgxQ== X-Received: by 2002:a17:907:8692:b0:711:d49f:994d with SMTP id qa18-20020a170907869200b00711d49f994dmr23967707ejc.578.1654903661585; Fri, 10 Jun 2022 16:27:41 -0700 (PDT) Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com. [209.85.221.49]) by smtp.gmail.com with ESMTPSA id ah19-20020a1709069ad300b00705976bcd01sm188085ejc.206.2022.06.10.16.27.40 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 10 Jun 2022 16:27:40 -0700 (PDT) Received: by mail-wr1-f49.google.com with SMTP id u8so354315wrm.13 for ; Fri, 10 Jun 2022 16:27:40 -0700 (PDT) X-Received: by 2002:a5d:414d:0:b0:213:be00:a35 with SMTP id c13-20020a5d414d000000b00213be000a35mr39200261wrq.97.1654903660246; Fri, 10 Jun 2022 16:27:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Linus Torvalds Date: Fri, 10 Jun 2022 16:27:24 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [GIT PULL] Folio fixes for 5.19 To: Matthew Wilcox Cc: linux-fsdevel , Linux-MM , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1654903663; a=rsa-sha256; cv=none; b=0aGiLcqkfBaBfKUqRu6S3Ua5PosN4ZArXHiTqh/B50Es5kTZOtpG2iqzzJ9VzEoaP/8cDV HsVEv4kjmAPfXKkPrKtNXohiwHx1+X4Hbld2gufTqS+ifLp04bKxNLKGNNZYOaeQnQsT3g urO9D3JGpNfDvLPc6ZubD01TO9j0Mgk= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=aLZKbkpP; spf=pass (imf17.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.50 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1654903663; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=GZoJzsRoNjoiccDOrK94bxpJ3hfAz32yrlvd2dEbdCc=; b=sVeykIL532swU1hDUZk7xgVv+SjfDmN36CaYQhyJeRfsx/fmrqfbc1Xf5kemIzXpSzn8xS y/9ETBzLiQTCFOeFVIER7AcK50HgP9K4Fm+yAdi5LJRZuRGLP5oCn4jo9/edA4TAta/3Fn 2x7/aztHvK6QZ3jzrs3ecP0EOGQOKA0= X-Rspamd-Queue-Id: 7978940058 Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=aLZKbkpP; spf=pass (imf17.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.50 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none X-Rspam-User: X-Rspamd-Server: rspam06 X-Stat-Signature: 51oibq63iknh7qckab4q9y5uauhetyo4 X-HE-Tag: 1654903663-999849 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 Fri, Jun 10, 2022 at 2:40 PM Matthew Wilcox wrote: > > But I don't want to change the refcounting rules on a method without > changing something else about the method, because trying to find a > missing refcount change is misery. Anyway, my cunning thought was > that if I bundle the change to the refcount rule with the change > from readahead_page() to readahead_folio(), once all filesystems > are converted to readahead_folio(), I can pull the refcount game out > of readahead_folio() and do it in the caller where it belongs, all > transparent to the filesystems. Hmm. Any reason why that can't be done right now? Aren't we basically converted already? Yeah, yeah, there's a couple of users of readahead_page() left, but if cleaning up the folio case requires some fixup to those, then that sounds better than the current "folio interface is very messy". > (I don't think the erofs code has a bug because it doesn't remove > the folio from the pagecache while holding the lock -- the folio lock > prevents anyone _else_ from removing the folio from the pagecache, > so there must be a reference on the folio up until erofs calls > folio_unlock()). Ahh. Ugh. And I guess the whole "clearing the lock bit is the last time we touch the page flags" and "folio_wake_bit() is very careful to only touch the external waitqueue" so that there can be no nasty races with somebody coming in *exactly* as the folio is unlocked. This has been subtle before, but I think we did allow it exactly for this kind of reason. I've swapped out the details. Linus