From patchwork Wed Aug 14 07:14:22 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeff Xu X-Patchwork-Id: 13762913 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 60BE5C531DC for ; Wed, 14 Aug 2024 07:14:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CBB3F6B0082; Wed, 14 Aug 2024 03:14:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C6C686B0083; Wed, 14 Aug 2024 03:14:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B33A26B0085; Wed, 14 Aug 2024 03:14:34 -0400 (EDT) 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 8FA456B0082 for ; Wed, 14 Aug 2024 03:14:34 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 0788F140C5F for ; Wed, 14 Aug 2024 07:14:34 +0000 (UTC) X-FDA: 82449988068.29.BD04EC9 Received: from mail-oi1-f177.google.com (mail-oi1-f177.google.com [209.85.167.177]) by imf28.hostedemail.com (Postfix) with ESMTP id F105CC0022 for ; Wed, 14 Aug 2024 07:14:31 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=JWBdBi2U; spf=pass (imf28.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.167.177 as permitted sender) smtp.mailfrom=jeffxu@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=1723619659; 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-transfer-encoding:content-transfer-encoding: in-reply-to:references:dkim-signature; bh=VwReknVIrDSfw0EPNLA7Z9rOAS1qkGFQa9Wg0CMwvkc=; b=GPHlLdGhqCr409jUcmNNzmgWtpNHFlUHl97nYLUVkhGzb+gm+xNVeKPT/fvjYLZE4UT8s4 Nfm1xNE8v0Adx3pmmfilaKXgn7n9W5WMYa5v8oqjpYZZY5vTnbl3TVf9QS6lBt1PkE2A+I RlesspLmX8Bl2e1zebBmdLSZgaZxmQw= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=JWBdBi2U; spf=pass (imf28.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.167.177 as permitted sender) smtp.mailfrom=jeffxu@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723619659; a=rsa-sha256; cv=none; b=GidfRvR6FkkZ3+vQxGrFK22iiKDmEJESB4Zap2tV8Wk1rRodEqfrO8ow28+8HeNiQD+cNR ppCyvtJhMd3jLKACF0e9EZzS7ll/CMmWnlSZ/pokDH9BWD9V0Dh0zg5lT3Vtu4dGpWqOW7 CVil5XTtWuXtBQ92WdVM2abkJ079oSo= Received: by mail-oi1-f177.google.com with SMTP id 5614622812f47-3db1657c0fdso4216313b6e.1 for ; Wed, 14 Aug 2024 00:14:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1723619670; x=1724224470; darn=kvack.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=VwReknVIrDSfw0EPNLA7Z9rOAS1qkGFQa9Wg0CMwvkc=; b=JWBdBi2UgQZS+elSRnHYHDAGZlNEtdkmjeysOgp5XqQn3QSs8BeRlQtLzUJYWle/LV uM4W1ahkRsxe+9RpxflFlINPmaMl4sHMmUYQnDu5Xljd8X7cm8ovvbd6B3lIqMRpd5wP 1UIgRMGafqr0jBnsLdZDjXPNmS1rPrsPmxO3I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723619670; x=1724224470; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=VwReknVIrDSfw0EPNLA7Z9rOAS1qkGFQa9Wg0CMwvkc=; b=a3TfGRknUHzGzihoRGaruTHFAMGB9ljT8FGff+DNLatxKaIYqtBZvv95MH9k8umVTP 8uU0xOtjAPU73GS0onbvphmXJyQUx1LDVJrEsN22+HpeAQcZANd/tH803gHNK7PyLMZy 5bmMeiyJnPAz9bp6ywDB++31VeY8VW0C3Qg9fZW8TP6S0QB4/MH76ktRdN6y+o+O4Xgk +gkcL6P+/q1oHVqE9JwQDJ+3IasJI6XSr+6tiADfEkABJgjhUEfAFrQSaxWVxsQIWuus kTEwJIQ4ELTtY/nJj8+ogIcAk/Xcf8+Fzq5/gxXCBAltIbwMyBl8Vf49vvKDgVCoopm+ vj4A== X-Forwarded-Encrypted: i=1; AJvYcCV4AS+7XPNVvNeMpoRPbS7274gGESnv/Q5EmfjeXXPowsrenacKHbU6R7jq4qLJ8edFgh2X04PxSIDREAZtAQ5NI1A= X-Gm-Message-State: AOJu0YwWtJ7eLDikkyUWq+wkhCOFBOt+7PHEtxvWbjWEAXr7hrzqVNGm 1KHWi+gId2aoKLjd2lHuXsfpzGmOCiB7C0qLvsIRpPpSaUr3gGpmAho/jGveEw== X-Google-Smtp-Source: AGHT+IHYwRGCLISGoy8hJhOKkAgqX6DtlBOZAVZZqhX4BMHm8h57bmHw97vihcaDfkE2jw2NCAP0Jw== X-Received: by 2002:a05:6870:3508:b0:268:9642:aa08 with SMTP id 586e51a60fabf-26fe59da324mr1981775fac.10.1723619670385; Wed, 14 Aug 2024 00:14:30 -0700 (PDT) Received: from localhost (150.12.83.34.bc.googleusercontent.com. [34.83.12.150]) by smtp.gmail.com with UTF8SMTPSA id d2e1a72fcca58-710e5873ad4sm6962870b3a.15.2024.08.14.00.14.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Aug 2024 00:14:29 -0700 (PDT) From: jeffxu@chromium.org To: akpm@linux-foundation.org, willy@infradead.org, torvalds@linux-foundation.org, Liam.Howlett@oracle.com, pedro.falcato@gmail.com Cc: linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, linux-hardening@vger.kernel.org, jeffxu@google.com, lorenzo.stoakes@oracle.com, mpe@ellerman.id.au, oliver.sang@intel.com, vbabka@suse.cz, keescook@chromium.org, Jeff Xu Subject: [PATCH v1 0/2] mremap refactor: check src address for vma boundaries first. Date: Wed, 14 Aug 2024 07:14:22 +0000 Message-ID: <20240814071424.2655666-1-jeffxu@chromium.org> X-Mailer: git-send-email 2.46.0.76.ge559c4bf1a-goog MIME-Version: 1.0 X-Rspam-User: X-Stat-Signature: 4ezsxoektgexfau11iowfkggoyd6b9mq X-Rspamd-Queue-Id: F105CC0022 X-Rspamd-Server: rspam11 X-HE-Tag: 1723619671-369753 X-HE-Meta: U2FsdGVkX1+E4jiUYpJEuR5akr/GhbMUXHtY+m+cuBrgJR25MXMexglMcpiqmqDwY7E3dB/gro3WAoOsrOjrtjc6mp75KRUzkJp67zfHwS8uR7Ms1QBKBACXtIzc8loStwmNEvkcOJsKlyfKvNHre82lKf9aBuQM4OtuGx+AVe/nOE/sr3D/8Lc/pGE7qNJvKrx3+DNxqsZ90Np/VGLnuku5QIHM64FNWLioDtfbku20Bw33gqMG3NqUAjaMYQxPg1ROc/v50v/+7jyj/tnZS4RmDiMWcRnSLk1mrFUEEj6fY0Hg6fGD9hrG8q92kVnFYX0k9CNoxkbLsz3m8/JyXH7JRBF8OvxlyuO2CNnzG5es8f3Hq5zr8L43+qdHWdJLOLXjNrpty9+aK7J2GMoMgmI30A6ETmRIYWSdycRlOzcBT6z0ZNjgRjIsijUUIPLihDycgkFV8Pszx6GOz2UXvPxmofCUxsshXIWm5CWne77YBo3FwuPfJEgzcra7JAzQ4KGzJIBuT/sd+JU3k/VatR5Ujp5ruUTIcKW3L9uFLMG+z2vOHlg/cF1g8y0i2TItR61YpzWa2obLxTHpRXmxOmyRxDvhuuUMyqYsjagfRuYyXsnSnnZxajtTbRLHvAK9FXSofObOJVt17eDAA0M9+JQAlhWJ/EM7MYw30NXJA0J6JEstZI+5qYaFHxwgpAlIHRN5mb1RPOQHWVeN+D+ct8AC80/hW5MYZQFPdYr1NmGnARGOanNZFT7sofT0pBR97XhNeL3UfwRwrYV7WxAlQ5qQpKRRNPxQ7I3fd8dBNG8nkJ6V4RACbZ+VNTWJTccKiCPmaxC1WjrcYrZS/JaKKaYD5jAUVrTl4EahyJMWU80w8kh6h4mWsdvqJesO7QCAfKxKLbFzsFXK0ylVN3u2NeG4kSeN4HRdyBI/QGXhClcTcfhAy7M00jkeRdTOuDi8HOSyOGyOmmFVYReM+/d B1LQIkME Gr0h5IZ3l7MdHP3j5i5bDkf9bkQPsbvoFIWhsX2tv+ZtwfIfUjQvto2g0gRKcxpv77Wtzbr0OLfYs8D1tgFwFmBEhsc8SL5qrAPJXEGJMyRsc0MB+qoogGpkcufpOm2mc3JNob/QFQYfODZ2YGJdAxKU1GAtZXeLrcRfMeh7YmGD98Gf/gdDF2DMzaRPkzoKSY1XrUYxJ8dLm6qc2zOk63r8LjxAegXT43Z8z3qqKcVigjoA6N1e211yKDLLR/DFW0TzUI5PMpP5ziIgYFDooQiuuvGoz2pNNcUSYZHiTtO1Kg66Ihn7HHWMUyADZ/Hb8pkVYfuroJHkOH68kLsZjh/hGmLVtCiA/BAge4o8ez0bbrQg1z6nIxYiIc6vJeNZcPZTZtRfZWtP3R0i8VWHyfc80OQse4clATJYjOWz8s9Id6jw/AHVF1XjPd3rjQjv/3LcM 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: List-Subscribe: List-Unsubscribe: From: Jeff Xu mremap doesn't allow relocate, expand, shrink across VMA boundaries, refactor the code to check src address range before doing anything on the destination, i.e. destination won't be unmapped, if src address failed the boundaries check. This also allows us to remove can_modify_mm from mremap.c, since the src address must be single VMA, can_modify_vma is used. It is likely this will improve the performance on mremap, previously the code does sealing check using can_modify_mm for the src address range, and the new code removed the loop (used by can_modify_mm). In order to verify this patch doesn't regress on mremap, I added tests in mseal_test, the test patch can be applied before mremap refactor patch or checkin independently. Also this patch doesn't change mseal's existing schematic: if sealing fail, user can expect the src/dst address isn't updated. So this patch can be applied regardless if we decided to go with current out-of-loop approach or in-loop approach currently in discussion. Regarding the perf test report by stress-ng [1] title: 8be7258aad: stress-ng.pagemove.page_remaps_per_sec -4.4% regression The test is using below for testing: stress-ng --timeout 60 --times --verify --metrics --no-rand-seed --pagemove 64 I can't repro this using ChromeOS, the pagemove test shows large value of stddev and stderr, and can't reasonably refect the performance impact. For example: I write a c program [2] to run the above pagemove test 10 times and calculate the stddev, stderr, for 3 commits: 1> before mseal feature is added: Ops/sec: Mean : 3564.40 Std Dev : 2737.35 (76.80% of Mean) Std Err : 865.63 (24.29% of Mean) 2> after mseal feature is added: Ops/sec: Mean : 2703.84 Std Dev : 2085.13 (77.12% of Mean) Std Err : 659.38 (24.39% of Mean) 3> after current patch (mremap refactor) Ops/sec: Mean : 3603.67 Std Dev : 2422.22 (67.22% of Mean) Std Err : 765.97 (21.26% of Mean) The result shows 21%-24% stderr, this means whatever perf improvment/impact there might be won't be measured correctly by this test. This test machine has 32G memory, Intel(R) Celeron(R) 7305, 5 CPU. And I reboot the machine before each test, and take the first 10 runs with run_stress_ng 10 (I will run longer duration to see if test still shows large stdDev,StdErr) [1] https://lore.kernel.org/lkml/202408041602.caa0372-oliver.sang@intel.com/ [2] https://github.com/peaktocreek/mmperf/blob/main/run_stress_ng.c Jeff Xu (2): mseal:selftest mremap across VMA boundaries. mseal: refactor mremap to remove can_modify_mm mm/internal.h | 24 ++ mm/mremap.c | 77 +++---- mm/mseal.c | 17 -- tools/testing/selftests/mm/mseal_test.c | 293 +++++++++++++++++++++++- 4 files changed, 353 insertions(+), 58 deletions(-)