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 65669C433FE for ; Mon, 21 Nov 2022 18:33:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A9FD38E0001; Mon, 21 Nov 2022 13:33:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A4FB66B007B; Mon, 21 Nov 2022 13:33:57 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 917EB8E0001; Mon, 21 Nov 2022 13:33:57 -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 7EE356B0078 for ; Mon, 21 Nov 2022 13:33:57 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 153DC1404B2 for ; Mon, 21 Nov 2022 18:33:57 +0000 (UTC) X-FDA: 80158298514.09.CACE8E0 Received: from mail-yb1-f178.google.com (mail-yb1-f178.google.com [209.85.219.178]) by imf05.hostedemail.com (Postfix) with ESMTP id A92B0100008 for ; Mon, 21 Nov 2022 18:33:56 +0000 (UTC) Received: by mail-yb1-f178.google.com with SMTP id p81so6902756yba.4 for ; Mon, 21 Nov 2022 10:33:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=qg+e2O0H9WsioRdDgWCYzvTng7LFE6we2RznhTrz2ws=; b=BgcAbTBkUmbQyhNx3mRxuxNPych+Rkwd57U7c2CWZjgUTwsFkbwOTlnfj8SFjEK+Z5 XKKwkbnMdNN9i+PWrALNhZ4n1abMXnd8sYi8o7E+mWPrakYoJDzRy0yfL9RQy0cJW6Hb KXLguPyXXnGE/QshUwiBmN+AtC2kMzQZUJ6q3iWZr3/Mf93lTBqsJDMyNPlxYSZqdsoO nkocPx9qu6DEnC0c+Ckio5j+YNvna/M+t8fWB9erqvOyv/MFk647s7fvJ6QDGp3MIZj+ IL553LR4C6yl7wUx3v/sDQqm3VmkDMJ1Vp1uNJk+vLRtOEyW1vbQWS1XNgNEJO/+kVFd 6q/w== 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=qg+e2O0H9WsioRdDgWCYzvTng7LFE6we2RznhTrz2ws=; b=OGTB0r3or730LL1KEohvs/6gyf9kARo+UBOj2Qa8jQS+rsG6y8XiWkSrrdtbqgSkiv Jis8UIRjnhQd7ukD5DYE1dB6akXRrx2HBa6wCwBtNVZG8Z8xrm7SpIhdHxizYxhnS4Fa lNQx08s9Hi2p6AhUMA1WvVikdVY32tFIpQRUrNS+iC6Lz/XUIq5f77h5R1D6eAxVNWxf U2osEP47m6FwZTwPo1a8NYAOq09blcb1lC5lL+AIdEg2KYBDBA00zz3gzDChwamDLKDU wvj/0rU+lTp0+2rH5EdgxAf8m1jVgwk/NnZyLlyxRykGH8o5V9nhpP0YE0hu8bKWOS9k 2XSg== X-Gm-Message-State: ANoB5pm5aWH/JKAb+WiCSvLqbdVUr4NHpjuPe4ASQPlFEduNjxpZx4Ls YrPk8MqdCstSa8zTCl53gJCTRzNNV5vX45CM+8bj+Q== X-Google-Smtp-Source: AA0mqf6ZkhjZlk4W86OQFInQl+DM7rAm+6NRbPKEEIy3bftzt5PgeqFzOPhZQMqJohaGtGCO1jXtfRTlmVzw9uHZOGY= X-Received: by 2002:a5b:505:0:b0:6cf:e605:7707 with SMTP id o5-20020a5b0505000000b006cfe6057707mr117675ybp.638.1669055635817; Mon, 21 Nov 2022 10:33:55 -0800 (PST) MIME-Version: 1.0 References: <20221021163703.3218176-1-jthoughton@google.com> <20221021163703.3218176-2-jthoughton@google.com> In-Reply-To: From: James Houghton Date: Mon, 21 Nov 2022 10:33:45 -0800 Message-ID: Subject: Re: [RFC PATCH v2 01/47] hugetlb: don't set PageUptodate for UFFDIO_CONTINUE To: Peter Xu Cc: Mike Kravetz , Muchun Song , David Hildenbrand , David Rientjes , Axel Rasmussen , Mina Almasry , "Zach O'Keefe" , Manish Mishra , Naoya Horiguchi , "Dr . David Alan Gilbert" , "Matthew Wilcox (Oracle)" , Vlastimil Babka , Baolin Wang , Miaohe Lin , Yang Shi , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669055636; a=rsa-sha256; cv=none; b=4dyzIon6NZJBQ4sSqDRETFdqpC3qWZ4qF7FBRT8996lDK+i/9xIeU4PdQFN6N+xNKfFQfL s5Cc41iBB5TjTjtmGz0RekgIMUnuSxpGASxjLagym1AggHJCnVETO2DYI6IGee6M4Wo0ok 37RSLlDBFd5cN62DEiZTa8JUtRa8eiY= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=BgcAbTBk; spf=pass (imf05.hostedemail.com: domain of jthoughton@google.com designates 209.85.219.178 as permitted sender) smtp.mailfrom=jthoughton@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669055636; 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=qg+e2O0H9WsioRdDgWCYzvTng7LFE6we2RznhTrz2ws=; b=TOmAlLm2aLrrMA5/YUqliN7XcqP/Cc0LY5CKGQkpePMXIXiQTfgdKqZ0OS0bnKwcnzpVEF B8UxJz5YPqFgm6fZ0CW7G/N7CoAm45/aOq5CryyIgnR3/R6tyUKl9RbiwEUiyUMrwZXNP4 NIJb545Bg689q1dMGT2dOB9WReCxvTU= X-Rspam-User: X-Rspamd-Queue-Id: A92B0100008 Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=BgcAbTBk; spf=pass (imf05.hostedemail.com: domain of jthoughton@google.com designates 209.85.219.178 as permitted sender) smtp.mailfrom=jthoughton@google.com; dmarc=pass (policy=reject) header.from=google.com X-Stat-Signature: 5rdd75oggm4yhq3t5kqejsbwaaj1etpk X-Rspamd-Server: rspam10 X-HE-Tag: 1669055636-56389 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, Nov 16, 2022 at 8:30 AM Peter Xu wrote: > > On Fri, Oct 21, 2022 at 04:36:17PM +0000, James Houghton wrote: > > This is how it should have been to begin with. It would be very bad if > > we actually set PageUptodate with a UFFDIO_CONTINUE, as UFFDIO_CONTINUE > > doesn't actually set/update the contents of the page, so we would be > > exposing a non-zeroed page to the user. > > > > The reason this change is being made now is because UFFDIO_CONTINUEs on > > subpages definitely shouldn't set this page flag on the head page. > > > > Signed-off-by: James Houghton > > --- > > mm/hugetlb.c | 5 ++++- > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c > > index 1a7dc7b2e16c..650761cdd2f6 100644 > > --- a/mm/hugetlb.c > > +++ b/mm/hugetlb.c > > @@ -6097,7 +6097,10 @@ int hugetlb_mcopy_atomic_pte(struct mm_struct *dst_mm, > > * preceding stores to the page contents become visible before > > * the set_pte_at() write. > > */ > > - __SetPageUptodate(page); > > + if (!is_continue) > > + __SetPageUptodate(page); > > + else > > + VM_WARN_ON_ONCE_PAGE(!PageUptodate(page), page); > > Yeah the old code looks wrong, I'm just wondering whether we can 100% > guarantee this for hugetlb. E.g. for shmem that won't hold when we > uffd-continue on a not used page (e.g. by an over-sized fallocate()). > > Another safer approach is simply fail the ioctl if !uptodate, but if you're > certain then WARN_ON_ONCE sounds all good too. At least I did have a quick > look on hugetlb fallocate() and pages will be uptodate immediately. Failing the ioctl sounds better than only WARNing. I'll do that and drop the WARN_ON_ONCE for v1. Thanks! - James > > > > > /* Add shared, newly allocated pages to the page cache. */ > > if (vm_shared && !is_continue) { > > -- > > 2.38.0.135.g90850a2211-goog > > > > > > -- > Peter Xu >