Received: by 2002:a05:6358:a55:b0:ec:fcf4:3ecf with SMTP id 21csp6741070rwb; Wed, 18 Jan 2023 08:49:54 -0800 (PST) X-Google-Smtp-Source: AMrXdXtMp0mHyWWnHQ8hG58AsAIP6UArj6L+IU4Jfdm9m5sxoxVp3Dou8qCLG7HYicb0BnOA92N5 X-Received: by 2002:a17:903:2154:b0:194:a371:716a with SMTP id s20-20020a170903215400b00194a371716amr7108555ple.60.1674060594102; Wed, 18 Jan 2023 08:49:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1674060594; cv=none; d=google.com; s=arc-20160816; b=VL6kCRSUvWdFGlFXl90BFX3tXjkPHU6OeZ8aTDe9Hpxg9NlUIcq1K2tEy8RshUeLvS ChhGOoF/TfvEBSKYGtsJyKXMc4fOXNKxI+/FBfDau8kzAz3ZKnYdGrLDHa/bP21QgAd1 KcCmnXOWXx48ft2qZ0RBQjV7vzn2RRPXNbpSJ+5hAv7V2sdy8XzSueBRulyv6qwxo1C3 1+ZXRCRVr4Q+5ErY4h0v9vEYnwsBdkNjg+riMUZ37IEGKGi5rVNJrUQ9ycxQ1hzUYwkl aXg5oyQpmw1yq86jBuK3caIkYHRlSmMkm06YgEugVVWq9luhbFF764IFDVuHnJjftAsa w9Fg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=XTcn6EOmvdcaySj22rnAGZTgHq4wvd/ke03TGVcbMbc=; b=eziIioObQuyeWQ9ELrHadq1dhSbCrBceQJXVdAAcjUEoSY1v2EuojAuF4IXXTy2oCw 0h2Ou3x7WtQAzfrtpnlpCxRJNrxHi9eq3rQ4ZoTOm4sDis41a1k52gIfGv+RHF4eCTl2 cMKWSNqnKBd0ZsiXl1H+1kilhD/TGIhZGiSEQmQt9tKDqJGtCpMZBt/QPwJcJJy2/M5F 00P2h4G3S6OVELwh6rB+DSx3TpcDws60Qov8gket7CMXxRcsB+8ePhSzHY+iwCRBZ9sQ lSe1qpENuqo0ZXgJob1sof/fRYnPQieGy4h/toxEHNJ5wFpVC7RG9oqHmLi69AuelDpp 9LAw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id c19-20020a170902c1d300b001898ecbeef8si34609612plc.9.2023.01.18.08.49.41; Wed, 18 Jan 2023 08:49:54 -0800 (PST) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229861AbjARQpD (ORCPT + 99 others); Wed, 18 Jan 2023 11:45:03 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47240 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229787AbjARQoW (ORCPT ); Wed, 18 Jan 2023 11:44:22 -0500 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1322C54206; Wed, 18 Jan 2023 08:44:02 -0800 (PST) Received: by verein.lst.de (Postfix, from userid 2407) id 6550568D17; Wed, 18 Jan 2023 17:43:59 +0100 (CET) Date: Wed, 18 Jan 2023 17:43:58 +0100 From: Christoph Hellwig To: Brian Foster Cc: Christoph Hellwig , Andrew Morton , Matthew Wilcox , Hugh Dickins , linux-afs@lists.infradead.org, linux-btrfs@vger.kernel.org, linux-ext4@vger.kernel.org, cluster-devel@redhat.com, linux-mm@kvack.org, linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-nilfs@vger.kernel.org Subject: Re: [PATCH 4/9] shmem: remove shmem_get_partial_folio Message-ID: <20230118164358.GD7584@lst.de> References: <20230118094329.9553-1-hch@lst.de> <20230118094329.9553-5-hch@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Wed, Jan 18, 2023 at 08:57:05AM -0500, Brian Foster wrote: > This all seems reasonable to me at a glance, FWIW, but I am a little > curious why this wouldn't split up into two changes. I.e., switch this > over to filemap_get_entry() to minimally remove the FGP_ENTRY dependency > without a behavior change, then (perhaps after the next patch) introduce > SGP_FIND in a separate patch. That makes it easier to review and > potentially undo if it happens to pose a problem in the future. Hm? The minimal change to filemap_get_entry would require to add the lock, check mapping and retry loop and thus add a fair amount of code. So I looked for ways to avoid that and came up with this version. But if there is a strong preference to first open code the logic and then later consolidate it I could do that.