From patchwork Sat Dec 24 08:12:02 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Zach O'Keefe X-Patchwork-Id: 36394 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4e01:0:0:0:0:0 with SMTP id p1csp64356wrt; Sat, 24 Dec 2022 00:19:54 -0800 (PST) X-Google-Smtp-Source: AMrXdXtx2lbHeMLGVEIDV9ea+F9aK0vLNU6LfiN9yOaGI8Lx6lp023DkNQbA+28me7vHiXyk1nbp X-Received: by 2002:a17:907:c386:b0:7c1:31b:2181 with SMTP id tm6-20020a170907c38600b007c1031b2181mr10991297ejc.19.1671869994060; Sat, 24 Dec 2022 00:19:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1671869994; cv=none; d=google.com; s=arc-20160816; b=c97YV39sFZB6/XdUM/6oTDWHsVcbOg4ibMB7fE/T5xeOHIVhPY/Hd74moqWn/Nr1+X YY/kDjzuIyXbnAFRWIrsJaJ+PNIfchO2zd7vIWUPLwDXSZ1nja0KCTPAWwlZfZPPOLO9 OgC9+n97q51j82bUXdv0nKCmfxkiW60YmPJpgyYqc1u9Vt+WPD6o/dO/uoDcY74rh8m+ 51SCnopovIqlNro2eeodhaT+t/697lXxnLFyDZgHa39lAoDPcR/+S6cKjgt5c5wBgeHf G/nT6cJJwCu2Sn5A28P9PsXWcW5mvE7QtZZRHz8EU7xSmEqdYCUhc5Vz9EuTS5uLThZp piwA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:message-id:mime-version:date :dkim-signature; bh=CLNnJd70ppyA/NycQ0X3RpMhQCUPbfoR/CeGZ2SECtc=; b=ILiP280vVLrdZkoXPXLFeOEHnqiIwRyidCx4upGVEKMUbj5HcI2YLZYPdcr2tM9Oir 3lzde2NXGCdSbtsrFvGaFjhULLXS5zCTa/wnGvDuLrnARlU9ML4BmOZ2naUjg1gC09HU 6+tzG4PFytfddDZqKZwxcljYEfNJGrZON4nMhDXQaxm1+4cprv47PSgzJshr6WPmqaOE BlM+3BnFgE7ygbYRsW1lASL6ehvBpvHvka8BStvG4VAq1fmxRWIKKh0YKEAnXoeaINLv 5afndCYbPMZIxuhea3YrEGmGNT3sKTEskIOeE549vciGhK+j3Vfban9Auao0CZvMrFSz biEA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=KvJVzUtz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id hr9-20020a1709073f8900b0078223ff2756si4738282ejc.244.2022.12.24.00.19.30; Sat, 24 Dec 2022 00:19:54 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-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; dkim=pass header.i=@google.com header.s=20210112 header.b=KvJVzUtz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230294AbiLXIMT (ORCPT + 99 others); Sat, 24 Dec 2022 03:12:19 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55810 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229445AbiLXIMQ (ORCPT ); Sat, 24 Dec 2022 03:12:16 -0500 Received: from mail-pj1-x1049.google.com (mail-pj1-x1049.google.com [IPv6:2607:f8b0:4864:20::1049]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D3D08D13B for ; Sat, 24 Dec 2022 00:12:15 -0800 (PST) Received: by mail-pj1-x1049.google.com with SMTP id pi14-20020a17090b1e4e00b0021d20da7a51so6181086pjb.2 for ; Sat, 24 Dec 2022 00:12:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject :date:message-id:reply-to; bh=CLNnJd70ppyA/NycQ0X3RpMhQCUPbfoR/CeGZ2SECtc=; b=KvJVzUtz4kTrA5zSMYZsEaF5rzMBMjUkNdUpmskBApF6t9+qSaYHK35X8ZMt7v36Va TiOrYOTKQS+jN5D9i7C+qkRZ3j0fulIHp72+Uc328W/QtqOseEMLXqvEfy9tf6Jemgg9 aR2dN1MvkwRKrALxrMBa50w7wHDzxmZbGJTXfWY8snWJ7yZO81TKhba1pp1Z1GyYVyZv 25si/eIHF48gJEGGDDO/Pw24iQWOgduzQY6FY2yGjdRJvQkhz7YR3+LsX5BkI0vnYkJy 6+p6ss7S7BcyxnCJFmie3egThN21Rwq7OUUrgGzL2zr/81XUjihHEiiq8Uy1h/y6s6kt yKmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=CLNnJd70ppyA/NycQ0X3RpMhQCUPbfoR/CeGZ2SECtc=; b=NREhn7xrxqujtVOZ1Nmjai62gs5oMOULRKtXAcF0PNqhIwNWwNM5xir5FrhJ3mDnGM ofqigQdaNm8HQaWObeDDJdO+85TUiTuHUrWqihTmgXMpNn73faVjIb3jhSMAdaqqT8mZ mIlg50Kiyd87ib+2jU136NniiHQpSG3/yU5ue2vfMfhLFWoFMu1AqVfrXsMP0whjhUh0 kh9cMzzOCgq1PHA7YJYzwP4/+1s51Vcaxgl1HcccEU8IEmeI8qQEUozClEC5ticQgla3 y33FvgZoFSYCpYSYtquXk+7lJgNgXfKS3pUfT1IoSXVedo4j1Zi+WIQymPtEwH0fEC/z IudA== X-Gm-Message-State: AFqh2kpAmMEzcl6KPBIEozqcckzW7skZbhv2Ue6Ce2QmGbzFbjMOChnC kkvHiK4UuC/awehLOBVi0WQt+uUX7njw X-Received: from zokeefe3.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:1b6]) (user=zokeefe job=sendgmr) by 2002:a17:902:ce06:b0:188:fd3f:cb06 with SMTP id k6-20020a170902ce0600b00188fd3fcb06mr614142plg.23.1671869535430; Sat, 24 Dec 2022 00:12:15 -0800 (PST) Date: Sat, 24 Dec 2022 00:12:02 -0800 Mime-Version: 1.0 X-Mailer: git-send-email 2.39.0.314.g84b9a713c41-goog Message-ID: <20221224081203.3193960-1-zokeefe@google.com> Subject: [PATCH v2 1/2] mm/MADV_COLLAPSE: don't expand collapse when vm_end is past requested end From: "Zach O'Keefe" To: linux-mm@kvack.org Cc: stable@vger.kernel.org, linux-kernel@vger.kernel.org, Andrew Morton , Hugh Dickins , Yang Shi , "Zach O'Keefe" X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1753082750891856516?= X-GMAIL-MSGID: =?utf-8?q?1753082750891856516?= MADV_COLLAPSE acts on one hugepage-aligned/sized region at a time, until it has collapsed all eligible memory contained within the bounds supplied by the user. At the top of each hugepage iteration we (re)lock mmap_lock and (re)validate the VMA for eligibility and update variables that might have changed while mmap_lock was dropped. One thing that might occur, is that the VMA could be resized, and as such, we refetch vma->vm_end to make sure we don't collapse past the end of the VMA's new end. However, it's possible that when refetching vma>vm_end that we expand the region acted on by MADV_COLLAPSE if vma->vm_end is greater than size+len supplied by the user. The consequence here is that we may attempt to collapse more memory than requested, possibly yielding either "too much success" or "false failure" user-visible results. An example of the former is if we MADV_COLLAPSE the first 4MiB of a 2TiB mmap()'d file, the incorrect refetch would cause the operation to block for much longer than anticipated as we attempt to collapse the entire TiB region. An example of the latter is that applying MADV_COLLPSE to a 4MiB file mapped to the start of a 6MiB VMA will successfully collapse the first 4MiB, then incorrectly attempt to collapse the last hugepage-aligned/sized region -- fail (since readahead/page cache lookup will fail) -- and report a failure to the user. Don't expand the acted-on region when refetching vma->vm_end. Fixes: 4d24de9425f7 ("mm: MADV_COLLAPSE: refetch vm_end after reacquiring mmap_lock") Reported-by: Hugh Dickins Signed-off-by: Zach O'Keefe Cc: Yang Shi --- v1->v2 : Updated changelog to make clear what user-visible issues this patch addresses, as well makes the case for backporting (Andrew Morton). While there aren't any stability risks, without this patch there exist trivial examples where MADV_COLLAPSE won't work; as such, this should be backported to stable 6.1.X to make MADV_COLLAPSE dependable in such cases. v1: https://lore.kernel.org/linux-mm/CAAa6QmRx_b2UCJWE2XZ3=3c3-_N3R4cDGX6Wm4OT7qhFC6U_SQ@mail.gmail.com/T/#m6c91da3cdbd9b1d1ebb29d415962deb158a2c658 --- mm/khugepaged.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/khugepaged.c b/mm/khugepaged.c index 5cb401aa2b9d..b4d2ec0a94ed 100644 --- a/mm/khugepaged.c +++ b/mm/khugepaged.c @@ -2649,7 +2649,7 @@ int madvise_collapse(struct vm_area_struct *vma, struct vm_area_struct **prev, goto out_nolock; } - hend = vma->vm_end & HPAGE_PMD_MASK; + hend = min(hend, vma->vm_end & HPAGE_PMD_MASK); } mmap_assert_locked(mm); memset(cc->node_load, 0, sizeof(cc->node_load));