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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 43CBDC77B7A for ; Tue, 6 Jun 2023 17:38:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233697AbjFFRig (ORCPT ); Tue, 6 Jun 2023 13:38:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43476 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237905AbjFFRic (ORCPT ); Tue, 6 Jun 2023 13:38:32 -0400 Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 563D010DE; Tue, 6 Jun 2023 10:38:31 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id B91B45C01D5; Tue, 6 Jun 2023 13:38:30 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Tue, 06 Jun 2023 13:38:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kroah.com; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm1; t=1686073110; x=1686159510; bh=z0 7aqGgk2gNY0nVjmeEqLTPg7LkT0Cu/HRqUK3Vyzb0=; b=3nnUpd5RCQjMSYPS8q afRoOos3u5wjohmf+Vre7sDLsouET/MIDHveotO9d74UZquRHxJ+pY3dXbOnEGan n6HZuqauMdIFCz6UHFnvFt2pPbJ6ptC/WcRxIhCy3JTd234RImNUGsTItXUOt2iL Cn9Ssyk8JgCSSHbCsr/REJ26vRLk+mgaPVpo4wjuX5DC15fDj4eppfDoK22axv+E st5diAFvtylpJ6z1DZoPVfSm4zP2eGCOW4nxJHDPtfGuXIipbXm6+4Tt3D5Zg27c 6iLUcvFqDVUn5F7mJ2Zq8Ttc5rxoOYxDAQ7cPll0A7CgfDiklY+rqo0Wqf4g0G9i qbQg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; t=1686073110; x=1686159510; bh=z07aqGgk2gNY0 nVjmeEqLTPg7LkT0Cu/HRqUK3Vyzb0=; b=BkhxQXmeWW21qBv6PD47vxFGcZHVG 0PlYLlMcOp0FIt5dMFlsY4n2+Ck69eDSamhna2E85P8vQ5fQpDoYA5pFnn6mair3 Msmr2IMrMxZPGEEMCMkAqBq4MJxxHKV8tx01rKfMmulLsRpLTthQWopAKnZxVazA ymdegCqvwEEbbzkrcf2Gevzp7dKAG1WNFxa4Pznt5WSEvNo7/h+8+JpOMEiWj2W8 OeAkZBfUF/iMUVO5RHHbncImhWOdFgIP63iOTapoYA3cefGJjtKzv8C0Jdia0bv7 qLGeXZlkhcOmZKsGbe0h8y4wwD7beAo+FXdrL9Mgj5RgmzXtUQZqmHbPw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrgedtuddguddujecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvvefukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpefirhgv ghcumffjuceoghhrvghgsehkrhhorghhrdgtohhmqeenucggtffrrghtthgvrhhnpeeghe euhefgtdeluddtleekfeegjeetgeeikeehfeduieffvddufeefleevtddtvdenucffohhm rghinhepkhgvrhhnvghlrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomhepghhrvghgsehkrhhorghhrdgtohhm X-ME-Proxy: Feedback-ID: i787e41f1:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 6 Jun 2023 13:38:29 -0400 (EDT) Date: Tue, 6 Jun 2023 19:38:27 +0200 From: Greg KH To: Sidhartha Kumar Cc: stable@vger.kernel.org, linux-kernel@vger.kernel.org, songmuchun@bytedance.com, mike.kravetz@oracle.com, Ackerley Tng Subject: Re: [PATCH 6.3.y] mm/hugetlb: revert use of page_cache_next_miss() Message-ID: <2023060650-overlying-skiing-191d@gregkh> References: <20230606172022.128441-1-sidhartha.kumar@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230606172022.128441-1-sidhartha.kumar@oracle.com> Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On Tue, Jun 06, 2023 at 10:20:22AM -0700, Sidhartha Kumar wrote: > As reported by Ackerley[1], the use of page_cache_next_miss() in > hugetlbfs_fallocate() introduces a bug where a second fallocate() call to > same offset fails with -EEXIST. Revert this change and go back to the > previous method of using get from the page cache and then dropping the > reference on success. > > hugetlbfs_pagecache_present() was also refactored to use > page_cache_next_miss(), revert the usage there as well. > > User visible impacts include hugetlb fallocate incorrectly returning > EEXIST if pages are already present in the file. In addition, hugetlb > pages will not be included in core dumps if they need to be brought in via > GUP. userfaultfd UFFDIO_COPY also uses this code and will not notice pages > already present in the cache. It may try to allocate a new page and > potentially return ENOMEM as opposed to EEXIST. > > Fixes: d0ce0e47b323 ("mm/hugetlb: convert hugetlb fault paths to use alloc_hugetlb_folio()") > Cc: #v6.3 > Reported-by: Ackerley Tng > Signed-off-by: Sidhartha Kumar > Reviewed-by: Mike Kravetz > > [1] https://lore.kernel.org/linux-mm/cover.1683069252.git.ackerleytng@google.com/ > --- > > This revert is the safest way to fix 6.3. The upstream fix will either > fix page_cache_next_miss() itself or use Ackerley's patch to introduce a > new function to check if a page is present in the page cache. Both > directions are currently under review so we can use this safe and simple > fix for 6.3 Is there any specific reason why we don't just wait for the fix for Linus's tree before applying this one, or applying the real fix instead? thanks, greg k-h