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 E97AAC05027 for ; Wed, 15 Feb 2023 01:57:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1CC636B0072; Tue, 14 Feb 2023 20:57:26 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 17C5F6B0073; Tue, 14 Feb 2023 20:57:26 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 044E66B0074; Tue, 14 Feb 2023 20:57:26 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id EAFDD6B0072 for ; Tue, 14 Feb 2023 20:57:25 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id BA262161274 for ; Wed, 15 Feb 2023 01:57:25 +0000 (UTC) X-FDA: 80467864050.30.BE54BA6 Received: from mail-lj1-f172.google.com (mail-lj1-f172.google.com [209.85.208.172]) by imf11.hostedemail.com (Postfix) with ESMTP id DAB7340010 for ; Wed, 15 Feb 2023 01:57:23 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=AcguxSU9; spf=pass (imf11.hostedemail.com: domain of stevensd@chromium.org designates 209.85.208.172 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=1676426244; 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=cYMyKojxXxWghsfpVdAPfvlnxMoCvfLD+NRFUZR90tk=; b=kOFiQqHyZxl3/ZRKlN0sWirqC6TTRqc6jUj6dt2UDfqyZXYBc5eDs8FAqPJsw7k/ZFBOcU 9SoNpWT4YNWTzFIMdXqWzmBqN4pF/faldGQZSiCYJdXTcBWzhjHtGS3B9XR6KY31HCY83P OBSzLLmvp5tQBtvmmDPBm2X6J3w9q+g= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=AcguxSU9; spf=pass (imf11.hostedemail.com: domain of stevensd@chromium.org designates 209.85.208.172 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=1676426244; a=rsa-sha256; cv=none; b=JdHWo05ff2whcBIBfR14RRHxb9Y0yrGFokStkf/W689e1V7Chne4ZOSHbDwTgRftYHpjV+ AkyTOSB7XuY3JNyAlc/QYNMTb/VL1M4D/HEYfitwJjUyE3XWrc4IdjuuIvvkdcmSHu85u1 q0vGUYjyS2jdRdwfQmGMs5c6Jz764GM= Received: by mail-lj1-f172.google.com with SMTP id u27so20493835ljo.12 for ; Tue, 14 Feb 2023 17:57:23 -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=cYMyKojxXxWghsfpVdAPfvlnxMoCvfLD+NRFUZR90tk=; b=AcguxSU9/O9NtruNgs2xpDm26HeYPyDxEez7bq0rUpyIhBoi1tTFR7+ahB4H5GzwKn dY18vJVzL0vPnIPFCILVpTTxWLBHNMopFqesOPPYuoF6J/+XMQwtISmcOL+4o0zv/9ki 58jwVZe7FuFQohwNEyVX+R7mxEsi7uyAF7EB4= 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=cYMyKojxXxWghsfpVdAPfvlnxMoCvfLD+NRFUZR90tk=; b=qm2oulryagJ0cT5oBf2C/BSjb+lyxiBPMoZIjHD2L6pTbEeZgEH5SBkPJ5pjD2DzVJ +c+P/rF01udOGXFCAzugL8MXwZmkhfcGsnxe/6U2GqnsxR9nE1f0Zdszk6HO4inqnQeW T1tN0iDMayyJD9lRkRSlSFlfjvSztoVOw/g4i6zNLuMtQiNSilDU3znL9dIpyHF6RNqN NT3G23bVhq5HZtTpRT4H0cm5bMPXDrpfrjhqSBXaeiJjLdTe5hDIlYxF9hCgcU9yIHM6 GZM5qIhUVMQK6TmKN4IbscOK/6j05VZCy3YK/wJcQ88BT3TFh9896wgVGX2hM7IQJK/S lvRQ== X-Gm-Message-State: AO0yUKWGDirUkr6uQKm0C4fn3SgL5bGzoObz0OZU0huyblqnektW9lNj GLMoqk0Ee5Rodf2IcosiR2QSGP9M6yhdS1QLmeEDrlh1WLxKvQJV X-Google-Smtp-Source: AK7set863q/bVzvozkrgJEZCBK9xxNSAnJIlUOHNgskReBusI2JJzk/miopUpJRkyhtVXgauxh3TO1Vaw811U+H9gNo= X-Received: by 2002:a2e:bc09:0:b0:293:4862:5e31 with SMTP id b9-20020a2ebc09000000b0029348625e31mr348809ljf.5.1676426242166; Tue, 14 Feb 2023 17:57:22 -0800 (PST) MIME-Version: 1.0 References: <20230214075710.2401855-1-stevensd@google.com> <20230214075710.2401855-2-stevensd@google.com> In-Reply-To: From: David Stevens Date: Wed, 15 Feb 2023 10:57:11 +0900 Message-ID: Subject: Re: [PATCH 2/2] mm/khugepaged: skip shmem with userfaultfd To: Peter Xu Cc: linux-mm@kvack.org, Matthew Wilcox , 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-Server: rspam04 X-Rspamd-Queue-Id: DAB7340010 X-Stat-Signature: s5f1io7rgg6k468dwcj5qbmqmx89qw9k X-HE-Tag: 1676426243-382186 X-HE-Meta: U2FsdGVkX1/MhXucpoWmaJqhHUJv1CYOZKnt2QxDaZ4Rcq2+avhbo+JpNs8uOR8uKmzYTMvAJAP3PPuaiIpadcG6m473vaZFlXhtWbj+ZuhD2pLU1KNAS0P3IGkVh1o12OLxJHP4cTPWBZHoyRPgWOpOF+NqbC3BBqoa0cFvxQ6LOsrjCvg3Ch7dvn9rWPHZ3BsrK8vzbhRBTamemyLeQz1OLwq3w/jecCl59o1S3wjZi9K9tb9acosEC4hAx89bzMR+Wqs6maOLHLrgVgvze05+G3BWoBs5bGzRtXi7HOAQpsPkD2bMNzoT+fvPKEiSTj9mRmdF9DiD45kFZKSboO+NqytFwNso6CzhcNm7KGb+tckKntrPnBHfyQKZegn4gAm5gGbMOHulkbk8vvLnfy8fmlbw4V3jcDV1/RNWE03gNJ8NsOUrxloI74nvpnIZzyRiLL9vXHe2fAjXXqh4vFtppUaYeDrN8+YF3qV19Ic2h5KoIGq9SH8QPuL1TnIcFNYr36aoKdvoKoTrLuz4sY7YHL7wGQzp/2nP7NfaYQ/+PE9zuRpiEWaAGylE7OgN9V2uMMKX6K05IYq452dYih1qlTNdJboVRRL0BdqEcIEztj/47R5AAlkC6wvWnc4vJt7OW9G4uR9tk5Nxg7jQWPZpS0eLL1zv7tnsvkPaG7zBn9tRrgiqHCpcxrAdkpGgYmPX8uE085n9MMqq5ZFqi5OPoLgCd5V1RJN9H3RcHOZHE+6zFz82mDv+GCmkaijggoOhVJm8MwjO61kn5cM152R3/Z5FSFPXB8HPigJM04klFVxLGG5jUF/C1R+zIXKI9F/25fAiM4P1+b2+zaH2reaw36RoseEg7ib8kRrrEmjvLv6KCLB04299GwodghoOaKDtoK546qxRrqyADHbJGCF0KNaU5zlxJJzyTYig742NwCtUpSOwjPbGmZgjmoCf+o/+OOEm9uuM1YeZr7f OS9Eko+v t5OcPbf+EgB1lOUtUFpNRe7v1IuTcZ9uGJfuGTfeW/NTClDn3wtTLacEpLUjcJVrtEvXbCcLQ7FUS98qcJQlFME0ACgTcvZFjtoNarT3JEgq2gz2iSKBjJZ7bIvGqWCaUDjahdz9pB7jcAZW4BodfRP/N6K/JTwU54xrB8WWtR3PPPfmP7DOap5OD7aUHQdl8DM3sWx0KUKk+ynihFCMuN5Lj0VEVqyvhyaHN2jKsc3OPk9dg73W06OzXINgce50UiaCcCmLV1s2oNqsLclVp/sBIJNmtFWnMHihNZ47qBPsyNRgHChktiCfhzfsDjksU5Z7GdVdmapm/AFU= 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 Wed, Feb 15, 2023 at 7:35 AM Peter Xu wrote: > > Hi, David, > > On Tue, Feb 14, 2023 at 04:57:10PM +0900, David Stevens wrote: > > From: David Stevens > > > > Make sure that collapse_file respects any userfaultfds registered with > > MODE_MISSING. If userspace has any such userfaultfds registered, then > > for any page which it knows to be missing, it may expect a > > UFFD_EVENT_PAGEFAULT. This means collapse_file needs to take care when > > collapsing a shmem range would result in replacing an empty page with a > > THP, so that it doesn't break userfaultfd. > > > > Synchronization when checking for userfaultfds in collapse_file is > > tricky because the mmap locks can't be used to prevent races with the > > registration of new userfaultfds. Instead, we provide synchronization by > > ensuring that userspace cannot observe the fact that pages are missing > > before we check for userfaultfds. Although this allows registration of a > > userfaultfd to race with collapse_file, it ensures that userspace cannot > > observe any pages transition from missing to present after such a race. > > This makes such a race indistinguishable to the collapse occurring > > immediately before the userfaultfd registration. > > > > The first step to provide this synchronization is to stop filling gaps > > during the loop iterating over the target range, since the page cache > > lock can be dropped during that loop. The second step is to fill the > > gaps with XA_RETRY_ENTRY after the page cache lock is acquired the final > > time, to avoid races with accesses to the page cache that only take the > > RCU read lock. > > > > This fix is targeted at khugepaged, but the change also applies to > > MADV_COLLAPSE. MADV_COLLAPSE on a range with a userfaultfd will now > > return EBUSY if there are any missing pages (instead of succeeding on > > shmem and returning EINVAL on anonymous memory). There is also now a > > window during MADV_COLLAPSE where a fault on a missing page will cause > > the syscall to fail with EAGAIN. > > > > The fact that intermediate page cache state can no longer be observed > > before the rollback of a failed collapse is also technically a > > userspace-visible change (via at least SEEK_DATA and SEEK_END), but it > > is exceedingly unlikely that anything relies on being able to observe > > that transient state. > > > > Signed-off-by: David Stevens > > --- > > mm/khugepaged.c | 66 +++++++++++++++++++++++++++++++++++++++++++------ > > 1 file changed, 58 insertions(+), 8 deletions(-) > > Could you attach a changelog in your next post (probably with a cover > letter when patches more than one)? > > Your patch 1 reminded me that, I think both lseek and mincore will not > report DATA but HOLE on the thp holes during collapse, no matter we fill > hpage in (as long as hpage being !uptodate) or not (as what you do with > this one). > > However I don't understand how this new patch can avoid the same race issue > I mentioned in the last version at all. If find_get_entry sees an XA_RETRY_ENTRY, then it will re-read from the xarray. This means find_get_entry will loop while we're finalizing the collapse - either until we finalize the collapse with the multi-index hpage entry or abort the collapse and clear the retry entry. This means that even if userspace registers a userfaultfd and calls lseek after khugepage check for userfaultfd, the call to lseek will block until the collapse is finished. There are a number of other places in filemap.c/shmem.c that do their own iteration over the xarray, and they all retry on xas_retry() as well. -David