From patchwork Sun Oct 8 20:23:12 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Lorenzo Stoakes X-Patchwork-Id: 13412794 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 08F0CE95A67 for ; Sun, 8 Oct 2023 20:23:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E82906B015B; Sun, 8 Oct 2023 16:23:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E32596B015C; Sun, 8 Oct 2023 16:23:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CFA006B015E; Sun, 8 Oct 2023 16:23:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id C193A6B015B for ; Sun, 8 Oct 2023 16:23:23 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 8B6741601E2 for ; Sun, 8 Oct 2023 20:23:23 +0000 (UTC) X-FDA: 81323419086.27.736F8F0 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) by imf28.hostedemail.com (Postfix) with ESMTP id D221EC0010 for ; Sun, 8 Oct 2023 20:23:21 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=QEygaLcx; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf28.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.128.50 as permitted sender) smtp.mailfrom=lstoakes@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1696796601; 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=oAlFt19XSPitoEhPZtTBItR7ZhRoBTV71rlHM3x983M=; b=UiawXWshAoNAfYQ7bHP0tpoJ23TNx4FpiYpFymji2vJIM4976vuAkdEubi4DBNrM9BYMXY yGdw5ssSALsMiWQ7y4dC1DC9I36uuiguDHWbVvUAyUg6gU55U8rjRY6sRLgnkoKixj3s81 TUGjSrjvTRGvImo31IPxxe6KEazzZkI= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=QEygaLcx; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf28.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.128.50 as permitted sender) smtp.mailfrom=lstoakes@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1696796601; a=rsa-sha256; cv=none; b=QBG0iMm/je6VaxxiG2Wmr/8bgA6PO5A05pk5k42I1Skqy5r0DZt+RjjiB8SbTL+0OKRN9M N37xfHvpitKBhrAqiCofSJUIc/xuk68coVw6wv2KM8JIROK8cz7G0VTwKmOU0DrNtVQoUc KgRSjMTbuvmAc3Lhzw9Nz1aZvbJafLs= Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-405497850dbso35812395e9.0 for ; Sun, 08 Oct 2023 13:23:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696796600; x=1697401400; 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=oAlFt19XSPitoEhPZtTBItR7ZhRoBTV71rlHM3x983M=; b=QEygaLcxEzjQeNobBjRuZkDq2Bv54v/SFOp/VSElEwS3Yny1KNgOpju92/xMwxTZN5 rS6McFdZ4djsZcjDU2k/sTye0LppzlEzzSjGFDa9Y3IO0YqVEpoCwWKgtcj5ZSZyMq/Z s82NLfsf5buaFUdbcw2KmOR1gpK4AuSWgHeH/L/h6u5VMpaaNm9ikY2D0MPgEP/bVSGr OXSDQlMaqJRZTwQ7tbFMeYaATHiKUgwIuMM4ULpK1SzkfL8MZC2xhnLRtO7MFZvZNMbA JjIkirvZ+JYEwn3hgkveZu3V5LMNgLhP4htF+v89p2brCEDGg49x48JaH2eb6LDZL3XW /L8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696796600; x=1697401400; 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=oAlFt19XSPitoEhPZtTBItR7ZhRoBTV71rlHM3x983M=; b=OWKHvKGNaCJp2UWVKyL/B+QM7RCCPs6FhGdfMo9jwIqQq32WlM9anby/TCW+ki9NhH 8BXRtymCq7lbECoCePGNw0a3zxELYiUK/GdGCKVU0e8YqHSl8AJPbCCiNZS5HPdmuNM6 emBjx9imcpKZpTc1VMJxUoNPho5W8epw9mdCo5cBiuL7cw/ysCSB4YRzwnJFxt2Xqu26 XJNyk7UTZrujNtnCgBT/Tpe4/fktP8aUIiDcVvfZsPixna+CB4DFpKD8HZUzZPbMzZ0p eWBZ0GauPRD4qDPX0TXxTDRppPjOeE166vYSj9R8gggGJzKYlw98vxJbU09YLTojVcEt 5eDg== X-Gm-Message-State: AOJu0YyzolQqjMxRy5uxtloKVtGv3TvjnMvJGKjDCcg20sJ6bPxRn7PK Z8Bakj4DekrS69FpCk+2SkJvXHE4Hfg= X-Google-Smtp-Source: AGHT+IEKXIM2JzbB/++nhZ/TA/gEwzRYuFkvk6v+COl+Htl+x4F+7inAR6yDfVh+8rq4JdKFK6K5Uw== X-Received: by 2002:a05:600c:cc:b0:405:3955:5872 with SMTP id u12-20020a05600c00cc00b0040539555872mr11841823wmm.18.1696796599599; Sun, 08 Oct 2023 13:23:19 -0700 (PDT) Received: from lucifer.home ([2a00:23c5:dc8c:8701:1663:9a35:5a7b:1d76]) by smtp.googlemail.com with ESMTPSA id c5-20020a05600c0ac500b0040586360a36sm11474879wmr.17.2023.10.08.13.23.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 08 Oct 2023 13:23:18 -0700 (PDT) From: Lorenzo Stoakes To: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Alexander Viro , Christian Brauner Cc: "=Liam R . Howlett" , Vlastimil Babka , linux-fsdevel@vger.kernel.org, Lorenzo Stoakes Subject: [PATCH 0/4] Abstract vma_merge() and split_vma() Date: Sun, 8 Oct 2023 21:23:12 +0100 Message-ID: X-Mailer: git-send-email 2.42.0 MIME-Version: 1.0 X-Rspamd-Queue-Id: D221EC0010 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: oxiu6wmp7zo5zbuo7df8itqwejpr1jbd X-HE-Tag: 1696796601-760143 X-HE-Meta: U2FsdGVkX1/QAtxXJkiIxBJCzPHKpkn0duhItvJ8jUBrpzq64TmRHNA38h/sQ3yRoZyb2T7mNJ2/XBrHueC+cLJTI5W2RoVQS5GSVf/RprDGJCo6S4kg7Q932mFL2Sto26AB/vJMg5cr9HxyQghm0tso5Uf1TYbrfJgdTrE2yrsKZuWDHLMl2aSvREJLR4B3h2qNeCam9O/spKZKl2rOMt69W4a/EyDDk9TaOCLw50ow1utkEL3qw5gNMes5xpVwKA4HnCLo75D8ZQk8ci+Dnm8MF7TokqZg3RXAoz5TndoSRArQh6yzxoDQt9QRne0qUeh+84Z7wTNmo0RqlsyvNlJQ1hfbJE3e8GJeOBivq4hFb8REIIYpPYZ3O0mgUeMFFmWHWeOSeUJzNwv2Tqzfh8mwUGiZAtIi7nF0XWZZKntVBbntxvEBVA16jf3K14GB12/wQMNKV68XVyAsv/S/e6A0vnMbbNPRTwRv7ZaagFwIH145ncAEOwmYW9LZtjgBLbmcsA2O8IsJRbsbmN9vekaSh3cZG+60H/ybehMYVXHDgES+A1l8lXeGAsxrraQHpnsKJ7crb43yotms3EDbMaNywLtYmCC95Abve0Ot4ySYGtT9VqoNI4O6jmb+D/n9pKV7vzVWDkDYLsObg2HFpqtyvuRfabdNN7GGk5HxZvMImulzuGiD9UJEptNrYrQ7dx9tb+BMJsvBN9I/gyGXFsx9z09bZ+M8tAM4bl8P1MH85nRpphx0yPUijSMf4HCm3ZZNp9xH7F3fqts/JcOVz4lOS1s/IHsVkGu8zIWpTtu/D+TgVkwx8SAeiKUXq/+2lg3alNxBaQUFvLILhL0OygrqnZJiyj4fjRb2xC+brCUCoFuHUjI5fvJKZJybY04ZLg01QCpWpUWJG8E+/EwTtRqnDwezrxqFFidixmStyteXXegpyYU80Hq7h88w5+VdOpli6jNyXGAxpsX1C+j X0yxtyVJ PNypYs16Gkpwi4Oj67pCAanmHs2oESMzbk4t9Z97wUkm6Gw6I7PGl11cVDxvw74WHJRGWV07VQ7HrffX1lYGMMExmG9aKzZxyLPQxpqk6AYdrEBTRfhtMajDGpoyWxPUU9LRI+cPd85JJhR2RQ9fRRq39Bcz1XEI8j3knMwiIm0q+Zcgm5EkK0yD+aPAdFEMGoOp0Ijq4mVDeehPgu0vo7vO4dFpM7pbUA6yY4n4rDloalVswbhwbbb4epgq6+SIsRsZetkO1pzSZ4kl6jmxIW/9qvXFlaOdw6/2aY+9BlWUeMoYLnnwzlqtJEydqkWKi6i3igIpHXeoCWMu1Zv+0zaLuZ2FNDHwd+bidLaGpyNOa3DL36/Fffvx6HfhKNrNHDFf0XhgXtuMNjQrFgj2010Xnv9+WcAqMnmATFiuK6VFPHkHH3fuB9e82LsL3ljggfPix X-Bogosity: Ham, tests=bogofilter, spamicity=0.000323, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: The vma_merge() interface is very confusing and its implementation has led to numerous bugs as a result of that confusion. In addition there is duplication both in invocation of vma_merge(), but also in the common mprotect()-style pattern of attempting a merge, then if this fails, splitting the portion of a VMA about to have its attributes changed. This pattern has been copy/pasted around the kernel in each instance where such an operation has been required, each very slightly modified from the last to make it even harder to decipher what is going on. Simplify the whole thing by dividing the actual uses of vma_merge() and split_vma() into specific and abstracted functions and de-duplicate the vma_merge()/split_vma() pattern altogether. Doing so also opens the door to changing how vma_merge() is implemented - by knowing precisely what cases a caller is invoking rather than having a central interface where anything might happen, we can untangle the brittle and confusing vma_merge() implementation into something more workable. For mprotect()-like cases we introduce vma_modify() which performs the vma_merge()/split_vma() pattern, returning a pointer or an ERR_PTR(err) if the splits fail. This is an internal interface, as it is confusing having a number of different parameters available for fields that can be changed. Instead we split the kernel interface into four functions:- * vma_modify_flags() - Prepare to modify the VMA's flags. * vma_modify_flags_name() - Prepare to modify the VMA's flags/anon_vma_name * vma_modify_policy() - Prepare to modify the VMA's mempolicy. * vma_modify_uffd() - Prepare to modify the VMA's flags/uffd context. For cases where a new VMA is attempted to be merged with adjacent VMAs we add:- * vma_merge_new_vma() - Prepare to merge a new VMA. * vma_merge_extend() - Prepare to extend the end of a new VMA. Lorenzo Stoakes (4): mm: abstract the vma_merge()/split_vma() pattern for mprotect() et al. mm: make vma_merge() and split_vma() internal mm: abstract merge for new VMAs into vma_merge_new_vma() mm: abstract VMA extension and merge into vma_merge_extend() helper fs/userfaultfd.c | 53 +++++---------- include/linux/mm.h | 32 ++++++--- mm/internal.h | 7 ++ mm/madvise.c | 25 ++----- mm/mempolicy.c | 20 +----- mm/mlock.c | 24 ++----- mm/mmap.c | 160 ++++++++++++++++++++++++++++++++++++++++----- mm/mprotect.c | 27 ++------ mm/mremap.c | 30 ++++----- mm/nommu.c | 4 +- 10 files changed, 228 insertions(+), 154 deletions(-) --- 2.42.0