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 9BD93CD6136 for ; Mon, 9 Oct 2023 20:53:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DE9F08D008D; Mon, 9 Oct 2023 16:53:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D9A288D0089; Mon, 9 Oct 2023 16:53:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C8B088D008D; Mon, 9 Oct 2023 16:53:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id B6E7B8D0089 for ; Mon, 9 Oct 2023 16:53:37 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 807991403ED for ; Mon, 9 Oct 2023 20:53:37 +0000 (UTC) X-FDA: 81327124074.10.D868D30 Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) by imf02.hostedemail.com (Postfix) with ESMTP id BC35C80013 for ; Mon, 9 Oct 2023 20:53:35 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=gnR2y3h4; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf02.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.128.44 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=1696884815; 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=Us15zo8nGUmOlyk9vDcAmDiwdx4iJiZpKEJ1GTzA2B4=; b=QrTiNUEtdYmv7Ldw/dgjhrowh5++BeTPpi4n/CEAVxvT+w2FVNmdg04+WdKE6R0l894psW oZkqP+BrTqYL2SUiXdmgS7+a6KBVHUwrFFMNhqDlZH0EC1ABV84Q7zzm9lsP4tFlmfcCo1 l9yYFdI0O7LH3ARCB2bsozrLkXTucnM= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=gnR2y3h4; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf02.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.128.44 as permitted sender) smtp.mailfrom=lstoakes@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1696884815; a=rsa-sha256; cv=none; b=2IG1mLE1EQgAvGMRTNyCDPOCJtnfg1yE7MSr0T2fcNwqVofKAe0vkBcqmX92w2OC3z3gB7 2VcQsZXp0goDSpW4pxeulKzQs2uD1lzDJ+3UAFjVKEFNu0UxqLxAod4gaBMccEZKhdcUNi LLaWz8MvYg6jheSpfePZsgqHp+YuH1Y= Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-40666aa674fso47104825e9.0 for ; Mon, 09 Oct 2023 13:53:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696884813; x=1697489613; 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=Us15zo8nGUmOlyk9vDcAmDiwdx4iJiZpKEJ1GTzA2B4=; b=gnR2y3h4PbLFSF9vh63338Yi467iGn6OxtI1UGNk4XZsUFlhlHrZpnhwREIh7BWM/4 4rvbF7LdZ+k8EY4/W/K1d/BXVVHnzxEtJOEuGDPvXQS9iFLpyITlPfyyillTpevi2/wD 4n2R7OlNx/K2yRdXD0VnliC3RbiYmiZKQS4n7AEaJqCPcfufw7j01HFqySK0RJoorAny odnaqWcqdDv1rXdJeH80FriWrBoyJysdunsCblpDrv90sVWqjNkU8PbCPCgeHQ/OdtbR TOAmiNmARERN7eYNAdD75ElItr9Vkdy07EdpWukYzCmHZz4Sh2gHtY8bgOBSwBS0JMly R6Cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696884813; x=1697489613; 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=Us15zo8nGUmOlyk9vDcAmDiwdx4iJiZpKEJ1GTzA2B4=; b=JfIO/Vh1P9L3uxwX9s+gruztjM6RKmTagC+bgpkG+3DKv6ad01wOZKZYKT4NBIs0t9 IIOOhimSQvx1zw1xyBW+E56CWhgAwbB3luoZP80eAXJgcoYxcNkjSqnp8IFFRvVa+1Vm AsW+jbFn2v8sFAjrcN9GDWo2NIgG5vAAp4mMMqC1WxA0whFwbw/bRBF2z8iPPkqjbOIj JUDG+VT0s3SkndsVSmcStH1J6TVF8n3+KlR7InYD/xcK2Yi5ekRhmNXZKM74atiOU/8P LiuVI5xCywrb8QgAThBbskh/1JBtBKaDx4y6J3lt6kV2MpqRxsGV6TCwURGE3Sjgk2Q0 4piw== X-Gm-Message-State: AOJu0Yxc7XFARVS+ClqHLq2BEhq7JHNZt9qyu16uQFqf1BUhea3CL/3G NUygAAy3vkLiDIuDnuOfvC7aLKbyENY= X-Google-Smtp-Source: AGHT+IGDaRtGngfMceHEuNgbt1g4utdKAaZZhswlmGa50KFFUZN8yWub9TMmqHRfEB7VzWUkEOrU5Q== X-Received: by 2002:a05:6000:1a50:b0:314:1b4d:bb27 with SMTP id t16-20020a0560001a5000b003141b4dbb27mr14222708wry.64.1696884813218; Mon, 09 Oct 2023 13:53:33 -0700 (PDT) Received: from lucifer.home ([2a00:23c5:dc8c:8701:1663:9a35:5a7b:1d76]) by smtp.googlemail.com with ESMTPSA id l2-20020a5d4802000000b0031fe0576460sm10578130wrq.11.2023.10.09.13.53.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Oct 2023 13:53:32 -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 v2 0/5] Abstract vma_merge() and split_vma() Date: Mon, 9 Oct 2023 21:53:15 +0100 Message-ID: X-Mailer: git-send-email 2.42.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: BC35C80013 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: af9ikzmkyrzc4wb1offfx3acwdyiadtb X-HE-Tag: 1696884815-574953 X-HE-Meta: U2FsdGVkX1/CPPzDIU7nij7bNFvckt9jXaSTIU/tcE8seX7o5/MsrcaDR9Z8gAhXKvhPTnSbM5s75eVWzOOsu77ZMDPe4bdmo3Z9hSwEQRPXd8+VfsXFapDOb2KzlnKw4NnbiDk0vtd2hnds2dH5j+RswBNSe6JUgjkfyNPGfupaMoiSC7eYOBlf82TDRT9AQ4ML2ScyW8KEjYDZLeM+rTeKhI8bye05AAM5O2mzSYWiCN6MGgLSArcrhjr870+pwpraM73bX4XqBahe1ObnhTx+81v30L6Gz367+hVpF8ul3uQj4UdrSLsGNsjSNFIujfxZy8ZWyUew03ThhApeGhTboq7Qy6fla1gHjEpxb/yJIIu35UMgB6g2UREdxMyn3jTGBuAkarYT5cM5zVMTpiP/pRR84mg5SC7uSjGWOc2mO9lxDj96NFgEBVQwnLBBU367z6aMUG36tYgdIhUzistQLx7vFKhBcQ1eCrmTdb4dYSK5E5s7TtUwfst8gS7j6CErpcg+55098mbHiTnSyKpvJ7H1ANpCeHJQ0DIWf1PDpsPawELcRyvnA+weGP/PIzdWECFei5w46BF0/rXKa3ox19mSvYuEM7i51i0Yqvs5md83eKv5G15gh8JJ5KN5rJxJQBng6Rs6j4PhR6NVsb0SpUOIVPmXqSRDMFdrwJr+iKt37Xvfb6cV7YLFg759UyvBYF1sOxNMS246jKu57vmrLqio5tVimczEAkHSXS4UlQpx4mQrJxE3uMLwVbN4e4+ADXb8iZs/9YINksfjrVj9xbMOFVCvmqMiPout1k0dVoPGc7RCEELhuunZ5acWQVvCH+FZrWj43vMrBV1FE4O+keGc1W0SmdzDmp8yurHMp9c3y6jsXV223klK5Xloqn18EtrFzycatzwPTO2/qBfS7SmGTA0mlg1UzpDxFEe1G5hNrDl2gDwrtumFXYzvm7P8FElomGEIuY7Dqni oAlvdIEe ZTdVuEX5NUZyclMe6MViZFDaJLvVcFop1QyGXr/vJfgodR/a4lgX4y4XH+Un+QayhGKRXkB6XBnLEFoQiVkgTa7fnpXfY+Cot0RmOsWAdWIm4kJLW69mxu1xjet8+CZ9YLQJJDtSM8kGWHds/X6oriuIj5pzoXT8DJAYbASmKV9+NAzSXHBVAl4itKOEYbGIkfL9vlrCUAhFbC3Wq5nk8Y9/hvVSc8HS4y7IudI1Cunq9htkqHvy617FWDyYv+24zcemSpHulWi46wgsYrPqXfZL/RzNz9TQPaqQiYFm7KfYc88vPpLGC6nVC7kWnVdvhGPrXwStL4vGODVtzdPgXvlh7UE/Dzn/WIkjmIMVpjNpOoVrWT0J8rvgZ2/RQVFGRDvzq728bHh85XF4v1DuUFCk9+VF1yBNuRzl4+jjwVkOyFufseEvzoZbAAIWDNmd/9vmROcxBm9pAeg7eb8rKKX4xW4peQHuXDiG2rAX4Om7icXN2KZ8fKzMeIrDAenypPcemAox2TG2C0uYNSxIxqesh0g== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000021, 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. We provide a number of inline helper functions to make things even clearer:- * 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_flags_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. v2: * Correct mistake where error cases would have been treated as success as pointed out by Vlastimil. * Move vma_policy() define to mm_types.h. * Move anon_vma_name(), anon_vma_name_alloc() and anon_vma_name_free() to mm_types.h from mm_inline.h. * These moves make it possible to implement the vma_modify_*() helpers as static inline declarations, so do so. * Spelling corrections and clarifications. v1: https://lore.kernel.org/all/cover.1696795837.git.lstoakes@gmail.com/ Lorenzo Stoakes (5): mm: move vma_policy() and anon_vma_name() decls to mm_types.h 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 merge and extend into vma_merge_extend() helper fs/userfaultfd.c | 69 ++++++++---------------- include/linux/mempolicy.h | 4 -- include/linux/mm.h | 69 ++++++++++++++++++++---- include/linux/mm_inline.h | 20 +------ include/linux/mm_types.h | 27 ++++++++++ mm/internal.h | 7 +++ mm/madvise.c | 32 ++++------- mm/mempolicy.c | 22 ++------ mm/mlock.c | 27 +++------- mm/mmap.c | 111 +++++++++++++++++++++++++++++++------- mm/mprotect.c | 35 ++++-------- mm/mremap.c | 30 +++++------ mm/nommu.c | 4 +- 13 files changed, 255 insertions(+), 202 deletions(-) -- 2.42.0