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 892C0C636CD for ; Tue, 7 Feb 2023 04:14:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2311B6B0074; Mon, 6 Feb 2023 23:14:19 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1E0366B0075; Mon, 6 Feb 2023 23:14:19 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0A8626B0078; Mon, 6 Feb 2023 23:14:19 -0500 (EST) 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 EEF416B0074 for ; Mon, 6 Feb 2023 23:14:18 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id C2DBC40744 for ; Tue, 7 Feb 2023 04:14:18 +0000 (UTC) X-FDA: 80439178596.23.DA5726E Received: from mail-lf1-f41.google.com (mail-lf1-f41.google.com [209.85.167.41]) by imf09.hostedemail.com (Postfix) with ESMTP id ECCA5140005 for ; Tue, 7 Feb 2023 04:14:16 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=E6oFlolH; spf=pass (imf09.hostedemail.com: domain of stevensd@chromium.org designates 209.85.167.41 as permitted sender) smtp.mailfrom=stevensd@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675743257; a=rsa-sha256; cv=none; b=b/wNPerxIpQZUu+E9of6DGK/rzBToFp+3iVZwMo/kOz9UVyqlAxE8+jFtt6fe5K1qyFWHj FWKyGlXXstN953szdciHTZ3VIaSgZo0JzE2XF2M0sm9Xz+XY7paPGLgM/J7+ZJRulJSE2w JWK+1edEYNalWnqA0mOlankiJVGETJ4= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=E6oFlolH; spf=pass (imf09.hostedemail.com: domain of stevensd@chromium.org designates 209.85.167.41 as permitted sender) smtp.mailfrom=stevensd@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1675743257; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=+f7wjDPMrHW1PNP9DoscYbX49wctOswrwmMtmDVlKE8=; b=e3iyRQZGvQfE9MGs7RKtbELzCdLRSjNJaZ3gWAIacdGIg9eO+WkZ3TlxnnYzqDaMRdWePz rVsrF2DhH6uAaRqGNWYnjfiIiLSxjD5Dd9490GnUgZkutpzEcT9zk847zDCZoQux6wBYgu BluFSOL83YxLEJ/lxwczU4deZ2UNInI= Received: by mail-lf1-f41.google.com with SMTP id y25so20654510lfa.9 for ; Mon, 06 Feb 2023 20:14:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=+f7wjDPMrHW1PNP9DoscYbX49wctOswrwmMtmDVlKE8=; b=E6oFlolHJG5LWRWBkgxC0HcMNgoOleW+DNPE3juT6cQlrj0o1SMbutZOLszkJqL/nw ViDOqQfC/xwrP+UF2KzvQPRqofWumRHxI9jQD7z93r4sXZtd5lZSpYp1les3D4lKJQ5W 31YQesE1AHi0oHi0VsrW5A23GZK43KV1hH6Es= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=+f7wjDPMrHW1PNP9DoscYbX49wctOswrwmMtmDVlKE8=; b=q61DOESyJFZMdcd4OprZJmIyFv5WRORTzLcj0lGLuCDS6YeWrd3tEBzcueUq6J5JHL Lgy/GTCEjC22N503mlHTiEca2YBjlHcRtze5MfXR6oGP18FDE/w+5KeL/a9pNNhYjJgg Q6K7XMSXLV9sm9Ox3MKaAqNyMQA5WTB2olODvF9NbZXvfCLBNTtywHP/BYfZwF7Wt008 /LsBWBNl5PH0opLnx/oexykC7tyZoBztWAs0ZNtzHbjnCR+M0Qm+JSfnHoJBt+WAwBVQ XO4+TudvA9DkDT8u4GvlTJqLf4xtwJiBT/uhA53hsygfExtWAL6MakOWxNph5TCoMrlG HZpw== X-Gm-Message-State: AO0yUKXPDElLJbNEsxLbbEyRXTJmmCwE7Y2DmmmpmLEpws6xIs7RpZHZ bVnk5+f8t9N/WwUQUIWj6kX/iCBR5cZv4PdPBV8ovA== X-Google-Smtp-Source: AK7set8Sc2MnagCUxPldxu00Oh2fYduHpcAG5njrtPtAX+v6euiFZ3BkdoI0/eECrSdLrd1hBfYnlN1EahKKcj+Les0= X-Received: by 2002:ac2:528c:0:b0:4cb:6bcb:de45 with SMTP id q12-20020ac2528c000000b004cb6bcbde45mr239520lfm.272.1675743255429; Mon, 06 Feb 2023 20:14:15 -0800 (PST) MIME-Version: 1.0 References: <20230206112856.1802547-1-stevensd@google.com> In-Reply-To: From: David Stevens Date: Tue, 7 Feb 2023 13:14:04 +0900 Message-ID: Subject: Re: [PATCH v2] mm/khugepaged: skip shmem with userfaultfd To: Matthew Wilcox Cc: Peter Xu , linux-mm@kvack.org, Andrew Morton , "Kirill A . Shutemov" , Yang Shi , David Hildenbrand , Hugh Dickins , linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Queue-Id: ECCA5140005 X-Rspamd-Server: rspam01 X-Stat-Signature: r8r6eebjgs85pi4ik6hs1tpg3ymptjbr X-HE-Tag: 1675743256-248848 X-HE-Meta: U2FsdGVkX1+WQW/YvDsAprS4twjpJig50eTZg6bRSYbVzQuircDdF99r0pRwcPtXkJ4rROsJzRQqyl90AsE2J4Q3lulgXIuksUGIYLK5rYvnH3erEp0fO++FpLERminV8ZbGTK2Mar4PECkmWQ4lfu7mwn6Y5SyFV7cVnqyvmzESWLLL27ueCR0NlJeuCiLhgibVKIYg0kb0Q2xQ8oDjjUjIwmUEtmk3u9My81Xyg9rzuyuGuSm0d4+B0YoHLscCq/a5cOxuGRk/ZvcLcuGHlDiY3hFP4u6iqgTrhmetpKwuEk6xc5hJbl4gTvSBMMjK7iM2ahJ1GW4ernHm60XwTGjjn1EvrbrV48hj4YOtOEV2ztxcMuBWvtVJGAH1Wi0L0TRIbArzZsIMTDTwy0Vf2uZ3JkU3LxxyJ+T5yOdoQitYCMUpFGH9QLSd7MXr/ZYDPekda6dTTygjGPVKR1fJ++X440h7pJ7xEs6yutO0LVjjgyQqKJBo/G8jD7sDiNlkDSs6BdJUrA99cGTHwgVHzYj8gloYQmyyXIDEMa/daYoUw7B8QfDptuamh87R5BCiH/O0OkCdb4XMWwKNfp3rKo0guss4BuozSd1KasKx2iYshOZqk5D0/WIocZ4ZRELBcGh+ASEo/+GkyAvXYTJIfs9Z+NwxKSD0nC7ZJ+pAHm5O0iwh+fh5DQyk3+7EUvY/kbYztkrYzXAIKf0/rijBxpnxl9S1PniDWxqNdx4vTBj49StWqsOMIx42eZzQJ2kcbuVP7dBg6zMj1fWbkn3JqP5xlXtn6K9klJbeaFL5QInur8tCQOpq8yQLhRxEekhrVL8CD+MOZCWnjGBXdw+juAJizhM0qFtKu1X77phOSHqAFvkOxxtTlcf6MRLCL/FCGMZedVstDsBWSCKQ5SoCGr/jP0cnnKhWXB4RUOQv5U6lhmMelxZAC74RBaIdyfPJftrDjQ8zzvHh2R0v56V ZAPf00Ms 7KjJmvvCNw6g9ZFIJOlFTiGp8/Vbo514G9R/vzeFADM0/EL/GZoaxPbG8hQu2mtNag+Xw4GX6nNCKPekARryltrpUaL3zOk1riOLb9F9HUwVzKpYj32gEqSu7N+FTu10Q650Klnu3YZkcJscYIsqmfWLq0yMNU3G17voJYjszSbW7djUxGh3Kh61N3m2xNARCi4nK2krePSwNaDSSDIRwvzr28gWc9+OVfFEdbSzligStR+rsXZ8IofALJtaH0kLaHR7CNSgzzbTOTp11DsEXSsMeSda1HXTiRiM9yKF+3lB/pYOmggmssTtcyw== 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: On Tue, Feb 7, 2023 at 11:29 AM Matthew Wilcox wrote: > > On Tue, Feb 07, 2023 at 10:37:06AM +0900, David Stevens wrote: > > On Tue, Feb 7, 2023 at 6:50 AM Matthew Wilcox wrote: > > > On Mon, Feb 06, 2023 at 03:52:19PM -0500, Peter Xu wrote: > > > > The problem is khugepaged will release pgtable lock during collapsing, so > > > > AFAICT there can be a race where some other thread tries to insert pages > > > > into page cache in parallel with khugepaged right after khugepaged released > > > > the page cache lock. > > > > > > > > For example, it seems to me new page cache can be inserted when khugepaged > > > > is copying small page content to the new hpage. > > > > This particular race can't happen with either patch, since the missing > > page cache entries are filled when we create the multi-index entry for > > hpage. > > Can too. > > for (index = start; index < end; index++) { > ... > if (xa_is_value(page) || !PageUptodate(page)) { > xas_unlock_irq(&xas); > /* swap in or instantiate fallocated page */ > if (shmem_get_folio(mapping->host, index, > &folio, SGP_NOALLOC)) { > result = SCAN_FAIL; > goto xa_unlocked; > } > ... > > So we start the iteration, and then a page fault happens in one of > the indices we've already examined, but we don't have the page on > the list. It's a nice wide race too because we're bringing the > page in from swap. > Ah, I misunderstood your objection to refer specifically to the copy_highpage loop at the end of collapse_file, rather than the entire process of the collapse. Yes, there can definitely be faults that fill in pages during the overall process of collapsing. However, my patch re-checks nr_none after acquiring the page cache lock for the final time, right before creating the hpage multi-index entry. Since present pages are locked, they can't be truncated after we've looked at them. That means that if nr_none still matches, then there weren't any page faults that populated missing pages. If we do detect any filled in pages, we can just roll back the collapse to avoid any problems. -David