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 B50DAC636D4 for ; Wed, 15 Feb 2023 22:28:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CD88E6B0071; Wed, 15 Feb 2023 17:27:59 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C88C26B0072; Wed, 15 Feb 2023 17:27:59 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B50416B0073; Wed, 15 Feb 2023 17:27:59 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id A751D6B0071 for ; Wed, 15 Feb 2023 17:27:59 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 67D8CC043F for ; Wed, 15 Feb 2023 22:27:59 +0000 (UTC) X-FDA: 80470965078.01.7B61CCB Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf15.hostedemail.com (Postfix) with ESMTP id 1B936A0011 for ; Wed, 15 Feb 2023 22:27:56 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=FOVg79UD; spf=pass (imf15.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1676500077; 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=vft1Qv3jLlAD1lBQ+InfzxWLMn34pjK5f9gIV8ktH5k=; b=SuimUIp1ZMiOduxyrsieY8Qt4vFW3PKwaEdsXHv7ecPQ7ryZshxkMUSEpwc40rpefjBSWP 0uOC3ZS31TCvO8u5hh4qCVnDm1SCkPDMpzUiC6aQ3La3rb1vw+GYUqGWr4msLIB4Ym8Fry 21U8W9fPc6Acwa2TTpO1Mm27ET2AeL4= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=FOVg79UD; spf=pass (imf15.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1676500077; a=rsa-sha256; cv=none; b=wEnm3xKqEmnfjf/xKjU89BbJ5ZwC1AnURvtZKd+bcSTjvlxWuZTM1GT1jFmcxIjMwCv0VI 3pXRmsQiEu4I0Yrs5TvtIc1rIQCNY73Q2NRYKRG37oEwZuclKr8wsIA7mTR9u9B61703Ky YSK+psvitgecOzPpXvVKmtToBQSlQ3A= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1676500076; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=vft1Qv3jLlAD1lBQ+InfzxWLMn34pjK5f9gIV8ktH5k=; b=FOVg79UDSwWl7TJcfONvlnEhL8re4G1Nbj9XmC0gFjnEJ7COSQzY5HkejkBwWD4G4Qg9Kb 3YG+3li4qa2hSPdIzrZBE37lpukfm3/bqw1Dh/b3wztQrc7lDCRtbifI/9cnAH15ggG+hY cE5OZbJYvRSGQ3Wc604A+lvCat3PaTs= Received: from mail-il1-f198.google.com (mail-il1-f198.google.com [209.85.166.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-256-dHJ4EAs4PBqwBI099GmUfw-1; Wed, 15 Feb 2023 17:27:55 -0500 X-MC-Unique: dHJ4EAs4PBqwBI099GmUfw-1 Received: by mail-il1-f198.google.com with SMTP id s12-20020a056e021a0c00b0030efd0ed890so242228ild.7 for ; Wed, 15 Feb 2023 14:27:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=vft1Qv3jLlAD1lBQ+InfzxWLMn34pjK5f9gIV8ktH5k=; b=W+9WeOXvdhH216YKMvzI5xhdPkVPToWZROKhcAwS8+31DFcrctec3THxmAHvKmQSHn yTLsZM2LYvwOH7HEfxS9sIi1YMHxUA8UXjp3x0ZCbn0NMRRvoZWKaPFr+YuFO+MV4yDB 0IvE70GYqxlVNujJDLdHKC572AA1e0cL3qA4Z9cTIfs8Q0T7U8a2nhGPGeDj4Wf1GqhX mrz9p3giCkZwBRBxslMSyO6rv/ArIZvYzm/ttWu7W5IcWN7IQ37gYceWKktU9T6PS+43 OBOVzib0kNoe1OT5tl2aZU+3gpnhrXs8NwGeAEys3FpUfosxIVIhi0xStbxh8zkvNyAR CboQ== X-Gm-Message-State: AO0yUKXJTfayQYiwUwSN3/y80hqbhr7FmMayetUIpUreMGiY/WfdiAf1 5xBWQzfjTuUkLcyssnh/m8RlFBWuOp25/yI/n4cwN6gQcG/isLFUIV19ZcVPNqOEizn3NMLmPqY xqJzRjJi9K88= X-Received: by 2002:a05:6602:5cd:b0:73a:6c75:5a85 with SMTP id w13-20020a05660205cd00b0073a6c755a85mr2423116iox.0.1676500074420; Wed, 15 Feb 2023 14:27:54 -0800 (PST) X-Google-Smtp-Source: AK7set8YQb9C6xFgZu/24UXnVJo7RqQebXMxXct5eaVPh3FRSWk6iqMS8w5jj8njEBwcZYSo5ASRlg== X-Received: by 2002:a05:6602:5cd:b0:73a:6c75:5a85 with SMTP id w13-20020a05660205cd00b0073a6c755a85mr2423104iox.0.1676500074087; Wed, 15 Feb 2023 14:27:54 -0800 (PST) Received: from x1n (bras-base-aurron9127w-grc-56-70-30-145-63.dsl.bell.ca. [70.30.145.63]) by smtp.gmail.com with ESMTPSA id g2-20020a056602242200b007437276ae6dsm233214iob.3.2023.02.15.14.27.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Feb 2023 14:27:53 -0800 (PST) Date: Wed, 15 Feb 2023 17:27:52 -0500 From: Peter Xu To: David Stevens Cc: linux-mm@kvack.org, Matthew Wilcox , Andrew Morton , "Kirill A . Shutemov" , Yang Shi , David Hildenbrand , Hugh Dickins , linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] mm/khugepaged: skip shmem with userfaultfd Message-ID: References: <20230214075710.2401855-1-stevensd@google.com> <20230214075710.2401855-2-stevensd@google.com> MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 1B936A0011 X-Stat-Signature: juqjm48afix4nyupfibbyn1j3gfq4srt X-HE-Tag: 1676500076-8540 X-HE-Meta: U2FsdGVkX18JewrZQfVwr12d+8hHe66CTwscRWb9v8WwwLcAeT4X0gdRrDtXJUS2YUkoPPP9DnLZtDz5bCqeABv74HDncDz2UFAKsy1LWdFeSK34Lwq7aBQHBMDnmP2oqEuIermwOAJ1Uqn/4G04cGqAS/OMJSdSjUXCL2B58D7z3P8wnmEnEM9CqdjmW7py+47nYrC5tRZm9WmAR4gGbeV1XziavJdGyuwOgwVNPDaec1I5J/Ozfe0GoIoSpn2ynXtOLBp08nzze3i26FN1EvysCGd+Qjcw8i6zonrZ4wgvA9o5ffeEf09hFjZW9M4jjpkyKcvOeKNTF+bzXwHC5ljJp/0pf+6cEXM5iIcJoGKbAzZ+GFr1l+WNBe6cc2eggNlCNRi+iTZtaEM/eWUS20W5qfxDYzLSjA7/U5lh9mDWC+PjB6cYIxWjywrkuEfvPsxY+4g8ybqWUXXHmG7J9i/xC7DMBomiCYtmivc8KmEYDyqUiftR2eV+6m1J4Hvf3Bud0AQlNizq+fV/BVl7PfXmTmD9xs3DZ5piHIP3aTigrg9hkJ7QADQCiBPIa6nbIOrZHKojbWVUwJwNii0AMtvxXBcDW/cZAqLIHOUiIxUaOiLAQs0AVwQNJhuxN2gfE5LykPDG3ReqpyO4cTQj1X1hSUmleWEexFv4P9P86dQ5rFDkE9KW75yNJWI4MasE5CxsHGxylKmWvHibZEqXsOIUtTmfWl9KuyXM4Ur5YODS68ql5K9jVyLfHfYTn2qpj/76WweZRYriqEiVjZVUOBp4bv62M+SIceQxN27dvi7VRl2ouJ0LVIu/EFcE+VJxw/2GkSq08ztVJaJVBDiwL33XAN8IVM/+/+Adn0vG4wQZpkhNB8EP/LNxWR5bSU38LRDRcE93imoY+ep1xuVcK0K/hVvlOXtIF3gxZmrSQjYFzmvfk5BCzFCN7kzneMRVllDORiOkC462ZXRUCiB 1c5a1DZv IvPw9PrJP+m/fsUdF9Ty7uqu6sEx0Aptnh4gp+kbT+f/8Mk4Y3ldhBligvkDqw5WoaLd1GwmgkQI8pjplR1QzpOfRwmDRUWvGtdH2TUS/1cgCwIVfp32ooyYsDzsBNnmZkzqSWyBMy4hifamOgyblQbPs6TJSOmS39UzRrWwvyqnEVcsWLkVNXPZnjkIZBfqnNA8nSpfeBzBjAJWeSN3uUm46A2M5YvIjycIsZIZphSzhuZ75iyRSP1c7iyZI+Qr1nnQtjPyY9UvepWwIAA1eV3u4Ps5QFXImqYD2ZvUb74QsC5RAxFdyYc2j6oY9URYPDpuzAFUj/QuX7edqtFuowbTtum/SMfiegwY+PCb4HFDhNvyg3ZbbSnjlsB4yz/Fsbcm+B59X41Gv4uLkZFAHWPExd4KKtSeP8u0ao46P/xvhBbKptXb2O2aKpS0vK60nm3hMTqc9XCCtyXY= 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 10:57:11AM +0900, David Stevens wrote: > 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. I've no problem on using RETRY entries (as long as others are fine with it :). It seems your logic depends on patch 1 being there already, so right after the RETRY got replaced with the thp it'll show Uptodate==DATA. However I doubt whether patch 1 is correct at all.. Maybe that can be instead fixed by having: folio_mark_uptodate(folio); To be before: xas_set_order(&xas, start, HPAGE_PMD_ORDER); xas_store(&xas, hpage); To replace patch 1, but I think there's still some issue in patch 2 even if it works. Ouch, I cut the codes.. I'll comment inline in another reply. -- Peter Xu