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 X-Spam-Level: X-Spam-Status: No, score=-18.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0D976C4707F for ; Sat, 22 May 2021 21:32:56 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6B7AB61131 for ; Sat, 22 May 2021 21:32:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6B7AB61131 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 457418E008E; Sat, 22 May 2021 17:32:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 401168E007F; Sat, 22 May 2021 17:32:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E625A8E008E; Sat, 22 May 2021 17:32:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0234.hostedemail.com [216.40.44.234]) by kanga.kvack.org (Postfix) with ESMTP id A26048E007F for ; Sat, 22 May 2021 17:32:53 -0400 (EDT) Received: from smtpin40.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 49DC262D0 for ; Sat, 22 May 2021 21:32:53 +0000 (UTC) X-FDA: 78170167026.40.795A13B Received: from mail-pl1-f175.google.com (mail-pl1-f175.google.com [209.85.214.175]) by imf13.hostedemail.com (Postfix) with ESMTP id 0138EE000808 for ; Sat, 22 May 2021 21:32:48 +0000 (UTC) Received: by mail-pl1-f175.google.com with SMTP id b7so8563359plg.0 for ; Sat, 22 May 2021 14:32:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KtBEuGQ1o7oVCLGDY9TPaDyiL0J04eVGf33YaGC2H4c=; b=QpxcOhwyLU3cySR/6dwTjMBmh/ncAxaELXXs4697zfQSCiLtLDWwYLBxMKDO2lxDbu FwrznFgtIgHPJBDfRR+zekC1BKJ+wgjLoa/rsW+y80aqI+6xUbDd+xi3Ce+O/DEF3e7j BOS+w+4mqTfHuO81r+OzT5LoGYV1YpZf1fjTLNfZnlir10MS6WHUtkOUWXPm4Uj/Bi7k E5usSst4w4y5m6TDe2iBHTvhfiqPxUUdJhy1gl72Hmg8W1grH5hMsZlVjJk/5/yJTz4c DVjAdu8E81Z7y4cGjSVJInK7Rq8Gt19zMYV0jfvyFhipXLBtUu9nQ6nBXuuQbn6A4Ep/ RWyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KtBEuGQ1o7oVCLGDY9TPaDyiL0J04eVGf33YaGC2H4c=; b=YcnX07F7v/DuSklcsllikU8aX/uwZbi1MgQtMW+hZK0r66HQYTL7Jrou9bvIQr/wFS 5meMVRX4bhX8pTHEQLzT4olVme6p+HZTKNLvVLJDRh2OwOuH5Lq65Ui4an+OpQvinQp6 5FYI/GtL2DGWt904UMsG13PF9G0nz2ocKzTE8Ob/1uugnxiUlJJ+A6xUEEbc9xbrHBWc za9ABBTL62JJUzEg/WmfN3pD961NrM6Bje1Qp27o/IoOUnWnP8cBUsjP9ZgBnpAPGcmY B9gZmEYCS4nhosI36V6PibeGRy5rET3b62ab96lQ+Ql2V6ooMKHsmT3+irMoDqz019DG Moww== X-Gm-Message-State: AOAM530ufmVdGcfijaB2v0GM0kZ5u+L8DJR8ZDB8soEAXsCOK7M7CIIh sm6PllLNTmyVtzSj8m57ovE/NSMR88pQgkz57V3afQ== X-Google-Smtp-Source: ABdhPJwBqNS+yuo0Duaw7TB2yGMxtuVm7HwdJ5HsTDOQazp4ES5K37sJrUJ9pN3lz5Ez/c6nyGHKuOtt8etPjVQGLuQ= X-Received: by 2002:a17:90a:1a:: with SMTP id 26mr17243668pja.187.1621719171771; Sat, 22 May 2021 14:32:51 -0700 (PDT) MIME-Version: 1.0 References: <20210521074433.931380-1-almasrymina@google.com> <20210522141946.f8a62010350a76302b9508fb@linux-foundation.org> In-Reply-To: <20210522141946.f8a62010350a76302b9508fb@linux-foundation.org> From: Mina Almasry Date: Sat, 22 May 2021 14:32:40 -0700 Message-ID: Subject: Re: [PATCH v3] mm, hugetlb: fix resv_huge_pages underflow on UFFDIO_COPY To: Andrew Morton Cc: Axel Rasmussen , Peter Xu , Linux-MM , Mike Kravetz , open list Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20161025 header.b=QpxcOhwy; spf=pass (imf13.hostedemail.com: domain of almasrymina@google.com designates 209.85.214.175 as permitted sender) smtp.mailfrom=almasrymina@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 0138EE000808 X-Stat-Signature: tymgeo3f7j8eyd3c6xat81qei7bzpphe X-HE-Tag: 1621719168-919106 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000012, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Sat, May 22, 2021 at 2:19 PM Andrew Morton wrote: > > On Fri, 21 May 2021 00:44:33 -0700 Mina Almasry wrote: > > > The userfaultfd hugetlb tests detect a resv_huge_pages underflow. This > > happens when hugetlb_mcopy_atomic_pte() is called with !is_continue on > > an index for which we already have a page in the cache. When this > > happens, we allocate a second page, double consuming the reservation, > > and then fail to insert the page into the cache and return -EEXIST. > > > > To fix this, we first if there exists a page in the cache which already > > ^ check > > > consumed the reservation, and return -EEXIST immediately if so. > > > > Secondly, if we fail to copy the page contents while holding the > > hugetlb_fault_mutex, we will drop the mutex and return to the caller > > after allocating a page that consumed a reservation. In this case there > > may be a fault that double consumes the reservation. To handle this, we > > free the allocated page, fix the reservations, and allocate a temporary > > hugetlb page and return that to the caller. When the caller does the > > copy outside of the lock, we again check the cache, and allocate a page > > consuming the reservation, and copy over the contents. > > > > Test: > > Hacked the code locally such that resv_huge_pages underflows produce > > a warning and the copy_huge_page_from_user() always fails, then: > > > > ./tools/testing/selftests/vm/userfaultfd hugetlb_shared 10 > > 2 /tmp/kokonut_test/huge/userfaultfd_test && echo test success > > ./tools/testing/selftests/vm/userfaultfd hugetlb 10 > > 2 /tmp/kokonut_test/huge/userfaultfd_test && echo test success > > > > Both tests succeed and produce no warnings. After the test runs > > number of free/resv hugepages is correct. > > > > ... > > > > include/linux/hugetlb.h | 4 ++ > > mm/hugetlb.c | 103 ++++++++++++++++++++++++++++++++++++---- > > mm/migrate.c | 39 +++------------ > > 3 files changed, 103 insertions(+), 43 deletions(-) > > I'm assuming we want this in -stable? > Umm I'll yield to Mike. This is a transient underflow; not actually THAT serious of an issue. Sorry, I'll clarify that in the commit message for the next version. > Are we able to identify a Fixes: for this? > No, this issue has been there latent for some time. It repros as far back as 5.11 at least, which is why maybe it's not that serious to require in -stable. > It's a large change. Can we come up with some smaller and easier to > review and integrate version which we can feed into 5.13 and -stable > and do the fancier version for 5.14? > Yes. If we only do the hugetlbfs_pagecache_present() check then that gets us some 90% of the way there, the rest of the patch addresses an unlikely race. > If you don't think -stable needs this then this version will be OK as-is.