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 67F1AC3ABB2 for ; Wed, 28 May 2025 16:15:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D88F46B0089; Wed, 28 May 2025 12:15:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D605B6B008A; Wed, 28 May 2025 12:15:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C9F936B008C; Wed, 28 May 2025 12:15:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id ABB866B0089 for ; Wed, 28 May 2025 12:15:07 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 4A0F9C0DE5 for ; Wed, 28 May 2025 16:15:07 +0000 (UTC) X-FDA: 83492815854.02.09F6415 Received: from mail-yb1-f175.google.com (mail-yb1-f175.google.com [209.85.219.175]) by imf04.hostedemail.com (Postfix) with ESMTP id 49DD540006 for ; Wed, 28 May 2025 16:15:05 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=x5iBh8jS; spf=pass (imf04.hostedemail.com: domain of jthoughton@google.com designates 209.85.219.175 as permitted sender) smtp.mailfrom=jthoughton@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1748448905; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=oftCGjGpACLgWjDfLsAyXAfYxlJ+xGu9uinKdgFYgsQ=; b=OTlpcT2fuD5wXIUe+LNico4dzzdVq0hzvWUtCn/Xsm3pTzmc//ohXeF/RB86O+sBSRm7Si jqqC+FtxaA4U4C0piGeGbB7owNt7qFDsB0SL2UDrSxBr4QAHj2ZvVMOrsucxCUEziir8hi 18MTGTb/KpWyi4tHXclxymvi+Ysh3Wg= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=x5iBh8jS; spf=pass (imf04.hostedemail.com: domain of jthoughton@google.com designates 209.85.219.175 as permitted sender) smtp.mailfrom=jthoughton@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1748448905; a=rsa-sha256; cv=none; b=0TvtQbIeyojmVK8C6CX/i4teZG1pzkrm6Xs2rODJRaCyjMatmicvoVrq4LXavzCiVQ1djz nBIp8+KSAh+KjcFP5QRdmgszvOYa8ai0H6eKJcwUlGM0LYNzV2Nb0lbrKu4IljLpda/8Ev hfrhnGdd4NOC2PzWZjaXp4wvZB/bKY0= Received: by mail-yb1-f175.google.com with SMTP id 3f1490d57ef6-e7569ccf04cso3678067276.0 for ; Wed, 28 May 2025 09:15:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1748448904; x=1749053704; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=oftCGjGpACLgWjDfLsAyXAfYxlJ+xGu9uinKdgFYgsQ=; b=x5iBh8jSqoSBdPxuiNOLfBsXFfnjsYQWWyEWRva/3OhaVYI6ZvUCZlr5g6JHVMY8fV Dxr9/IOS0AJFbGYPcx/8D6POLSiFLDJdqrlxrjEMnXHtDnHLIWO+GTi0gUuxhupVdhov XBTRLG9yJEKxBd20mCXkXHZPzH5cMDZPuARUl7ImcvSOTflfc+S5tPGyYMEEBFIR0+Bi H6hAuAQzSsGVFf/chJjlLFrBZUcug8/w/Z4yerPLWZ/bP3u+81kIG1V2JSYTgigfBxYV 1+kwKq8ghVy/dmnkskG8nIWCnBzCEe+XVc3s4qTY4YPxf6MaFNgkXwMtNTB5enVWO+ss S+Iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748448904; x=1749053704; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=oftCGjGpACLgWjDfLsAyXAfYxlJ+xGu9uinKdgFYgsQ=; b=rM9EaXcbRNx1yTbcKOgryHK1lpXctbSlj10AwV59rmJipJ7d/2b/73MIW3XmS8VMm6 BodQBH580ntgw15T0+PJ6wpaI+B6IBd2b+V5tI6473w/VcGMf+apFy2jkKw/QAUAtSJk pzBhZOXxgz9NnAId4CRo/fOSpG0aApGrtqb5u49T/unVZrRjhQDeA9UI09AWw0vJA0qS WBgsn7JM157US+lV4fVCumMjcbIrDkgep4dUcSx2qkJXQp6n308JjVCNp4u63Qi3eBYu QZ9D/m7ioS6XuNBnwmaHN96X/PF00CNW8NBR1hJRvkMk++Aauq8sqCdHkaasR2ndiCjT Lhyw== X-Forwarded-Encrypted: i=1; AJvYcCUpsUOtPj5KFHUKy7IcsvHgUGfMc9yHfTnnVAnE0xzQyWw/EfR9L1syCNTADX6XNvMDp3yNt4Yb0w==@kvack.org X-Gm-Message-State: AOJu0YyD8g5m7toPSHcJrDLfMkBN7VFwaSYSCMp5f4i0DUM58CT1v3Sd oUUIAusf+WNf/buDZUIjauqy32O4+O+t002wIAc3cnw0mflsPoca7DOy+zR66qpyHa89hgxefr3 8mWYlbr2i/Rmdikw0toOaB+xroJyfbIO5+lKROb/D X-Gm-Gg: ASbGncuN+9DrR606wzmPZWqL9mI9ipButNs7cTQ/v4TGDeTBPUIovhxw47ermnae0Zj J/Ka5CZNk2930c5155vFs/cYSq1ifxZcq8nGhC2ph9dTz0BZa26eGRGsKB1+4aB3LsMSq0ulkDL nI2lMuqbw6HmhSvCP9U2QeAt9zKNO+MQfkGv6owEQKyE6AH2CPAOcywYUCqWJH6HnzO3U5o7VP3 XVe/Q== X-Google-Smtp-Source: AGHT+IFwW0/MrySaPT+ucgIg1dChgPDCXdJtXWgrMY95UPokdViJg0CdZ9UXjyC8CVjk5twtVkLrVgdpew1P2vJKaig= X-Received: by 2002:a05:6902:1b8a:b0:e7d:c87a:6249 with SMTP id 3f1490d57ef6-e7dc87a6957mr7030815276.36.1748448903884; Wed, 28 May 2025 09:15:03 -0700 (PDT) MIME-Version: 1.0 References: <20250528023326.3499204-1-gavinguo@igalia.com> <629bb87e-c493-4069-866c-20e02c14ddcc@redhat.com> In-Reply-To: From: James Houghton Date: Wed, 28 May 2025 12:14:28 -0400 X-Gm-Features: AX0GCFtQ3Y_TJAz9gxU-mydw8Rp4n4FQFwD-d7vMDgv4nmmNrG0P_Nb3Fcuv7Sk Message-ID: Subject: Re: [PATCH v3] mm/hugetlb: fix a deadlock with pagecache_folio and hugetlb_fault_mutex_table To: Oscar Salvador Cc: David Hildenbrand , Peter Xu , Gavin Guo , linux-mm@kvack.org, linux-kernel@vger.kernel.org, muchun.song@linux.dev, akpm@linux-foundation.org, mike.kravetz@oracle.com, kernel-dev@igalia.com, stable@vger.kernel.org, Hugh Dickins , Florent Revest , Gavin Shan Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: 49DD540006 X-Rspamd-Server: rspam09 X-Stat-Signature: 985huacmdjfnnugunqkpeux6ejrr8bsb X-HE-Tag: 1748448905-360169 X-HE-Meta: U2FsdGVkX1+7Rff2R5PA/mAnvYpBSNrK4j8vOxBL3RyCvWZUdRHT9H5z8tJJ2eUGSQOe0nq4r2iRiDIEdYl+lEROI67js5y787e5AgWtHv9vzGa8sdAJBvkbJwEpzui+Pcv2mnSH45Bc+EhhZxQ7Ky3NyUhMdlwb/OTCcKP2ffQhLg+wwtFaz8hjkprKvGcYw0WgBtnhV10u7pmJScgAYMTzWcEai+7aZpo5eW40W+6EFYiZS2LIa7OZDgqVnFDOm0igxGdmtatMOdaj+dq5ykCFuYudUmr3d15qcEbCN5Xc5MJwlH8VENWZ+Z25XsBWsjueFrmg+Xl6Prz+BD6wjYR+OudpTGGYHmPKANzbzdWuj1RyGdVouBY9thaXBM9fo225CbISG7BqM4kuwxJlWwYTnpZisjUPNVd1FZpQOtLYAl/btHVmLTc8P9re5CDDmg/QS2JC+/UqJrN1xS4B7e+uetIg/vX7cam0Ex7YFJ0krYhiee07HFE3tAjNND5Y1OjhpliCqmDgW/eXjKI07IH35XUf6dfxHmmuN1Y+QnBghm1jVCwyD3bIXk6ZncgoM3hbXiRPn6NZAPpkTpNJ3LHE867L1WKHNLfrUVJILd3+ngpMcPJFWmryjOQBCrpruUO4Lh1I1pmMwJdjpJC5WeKrqZUNFfpYV4Zxgd3at2Ip7bzfwRzA6pmFBZIdsEgUpf+xiRiyhzgK5cDJYdo8+kSAcNDFd1IwXt/WoP17jtxUBK8UAS1nJKn8me1WO2UoQKe1T6Q5jhtP7pvjht+f0skM+KALqOIu47IHBrWRf8PPgj/JBrhgvG65HtKOt1ARi+ndZVEv2+QAN9EjUqaWePE3YoBPxGpb/E258XJDGiUZ3xaKOkyt3ShIUtDiiDuxzXGpY75907lEEnHpIPHCkUfaiXcmzeN0R0oLc0EnznnnzVNGNNZCcBnw4Yjq1sWw1/0oGs8b5DYT73UqRw3 cFiO+QxF tOHIu8QQ3JpxyLClDAV8lk+3trgfY1PJSJIS4X7IfQxy3LnVH/i1lQwTFOkX+i5XFeG7KG8va4ZhzHjNtg79hzMxnDdB8M0AUBT8jfKvBLbl0Ou8eu0gbMbnx4Du+yGuYjyAX/mXTcnQ3W5wKLRzF0JSM9ny61qJDlMLPWrOhpaUDp/DkrQzizh67WGxCJShyKkl2GOc7VaC2OLwe6i+E4zMCqxnEaISAS/cZCOWSKUHmTqur/XPBq4fJKw== 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: List-Subscribe: List-Unsubscribe: On Wed, May 28, 2025 at 11:45=E2=80=AFAM Oscar Salvador = wrote: > > On Wed, May 28, 2025 at 05:09:26PM +0200, David Hildenbrand wrote: > > On 28.05.25 17:03, Peter Xu wrote: > > > So I'm not 100% sure we need the folio lock even for copy; IIUC a ref= count > > > would be enough? > > > > The introducing patches seem to talk about blocking concurrent migratio= n / > > rmap walks. > > I thought the main reason was because PageLock protects us against writes= , > so when copying (in case of copying the underlying file), we want the > file to be stable throughout the copy? > > > Maybe also concurrent fallocate(PUNCH_HOLE) is a problem regarding > > reservations? Not sure ... > > fallocate()->hugetlb_vmdelete_list() tries to grab the vma in write-mode, > and hugetlb_wp() grabs the lock in read-mode, so we should be covered? > > Also, hugetlbfs_punch_hole()->remove_inode_hugepages() will try to grab t= he mutex. > > The only fishy thing I see is hugetlbfs_zero_partial_page(). > > But that is for old_page, and as I said, I thought main reason was to > protect us against writes during the copy. > > > For 2) I am also not sure if we need need the pagecache folio locked; I > > doubt it ... but this code is not the easiest to follow. > > I have been staring at that code and thinking about potential scenarios > for a few days now, and I cannot convice myself that we need > pagecache_folio's lock when pagecache_folio !=3D old_folio because as a > matter of fact I cannot think of anything it protects us against. Hi Oscar, Have you thought about the UFFDIO_CONTINUE case (hugetlb_mfill_atomic_pte()= )? I'm slightly concerned that, if you aren't holding pagecache_folio's lock, there might be issues where hugetlb_mfill_atomic_pte() proceeds to map a hugetlb page that it is not supposed to. (For example, if the fault handler does not generally hold pagecache_folio's lock, hugetlb_mfill_atomic_pte() will see a page in the pagecache and map it, even though it may not have been zeroed yet.) I haven't had enough time to fully think through this case, but just want to make sure it has been considered. Thanks! > I plan to rework this in a more sane way, or at least less offusctaed, an= d then > Galvin can fire his syzkaller to check whether we are good. > > -- > Oscar Salvador > SUSE Labs >