From patchwork Tue Oct 10 18:23:03 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Lorenzo Stoakes X-Patchwork-Id: 13415849 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 857B6CD8CAE for ; Tue, 10 Oct 2023 18:23:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 06F6C8D00BF; Tue, 10 Oct 2023 14:23:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 01F768D0002; Tue, 10 Oct 2023 14:23:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E51508D00BF; Tue, 10 Oct 2023 14:23:18 -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 D6A9A8D0002 for ; Tue, 10 Oct 2023 14:23:18 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 9386DB4CCB for ; Tue, 10 Oct 2023 18:23:18 +0000 (UTC) X-FDA: 81330374076.03.2DA18C4 Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com [209.85.221.54]) by imf26.hostedemail.com (Postfix) with ESMTP id B8C55140013 for ; Tue, 10 Oct 2023 18:23:16 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=DOgYrX1j; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf26.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.221.54 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=1696962196; 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=MYdUcr6LWnDZrnnkem7MG80UUlLo7ehwo0Ax7lmWvGc=; b=cZrFwgmQM1zMy09KOiDoCoZ3IaQbOPK8tMjob4EHfgLFg4yRSY3ebtb8HVcI2xi2bewYr5 4aoPjshoefA0jFSE5NWUidMHhjkxgO0JWWNsyiksT4eyC5Oq7biutUApK1uI2lW+obS0v/ DdCMBc3rud4FDyDqgOOlChbwbl6tWE4= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=DOgYrX1j; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf26.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.221.54 as permitted sender) smtp.mailfrom=lstoakes@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1696962196; a=rsa-sha256; cv=none; b=MJUQcogHRvsNoGzbBLJ3WUxhXINwymYIPpWA6Y/TXljhnYdVxAI3QesWpdHNOmZAhLRMLz eHRvnKf68g6h4OnH7YY8a4M1rP6GLhX7Cas2knSnju5VEyJhnOkuF+R8JizZaU6N5lgM4m MMLFYpznUgIvb+7ZQP5VOshM2vWnQbo= Received: by mail-wr1-f54.google.com with SMTP id ffacd0b85a97d-3226cc3e324so5818509f8f.3 for ; Tue, 10 Oct 2023 11:23:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696962195; x=1697566995; 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=MYdUcr6LWnDZrnnkem7MG80UUlLo7ehwo0Ax7lmWvGc=; b=DOgYrX1j9sG0qxsSEVFQc6vjMtqXOQV29L2cZvE0gtS2w4ThCe6ayTBAgyrPYjpn0b YKRA16HvK+9SSQAKjQPn6IbUf4cntNlLQLkkbhvop+gBfCzYk0wZQeUwmSk6Hq/In7Kv zq9g71Pthz3La72+/+9QZWzcWOq+3QuEmN0Yy0samd9bnnVr1Fj53Sb5T704i3rU4E4N R64+JeaClMRBJgOhyQrMGAXK25E407Fnp1VOSRx3i+kL05lLzvpl7rrp2fO7TRaUOI+V dXTrak8bBcj3wjVsDHm5Rf6JN7545gVT7FlCoD2lMEqDFnkUL6nK0+VdNPG+xE0B9qhi sWGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696962195; x=1697566995; 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=MYdUcr6LWnDZrnnkem7MG80UUlLo7ehwo0Ax7lmWvGc=; b=UCjMnZGItV5Vm/glljFYIRe8faHfUHuGqstvzCcmj3j1jeFGx0jeTvJFFQ4NmmBGve TYODTVbYQKp1YfGUapVRYCjOMhkamxOzvy8UTJ4oaods9GmN8QWk+0Me0dqukmViE/Ma LWKttKk0X7G0Ss0ROFwTUnaaXLM9boK4hrSN9ifB5hokmV/OjP0j4+a8TQYokAnWpuBv RkV/uI6qzHfY8rxQ1LbSv9+k5SuR33t+Uw7f5xPddG/9Sgl1AKMOqblPNrAIQU+mUhpa rDa6CPcE9Y+C7Ask9tfuf4l7zO3I4XfQTnnb4Ibc9dU6Qy+pN6Pzk+ovO5aAqasJxhGm WbxA== X-Gm-Message-State: AOJu0YxhtVJ6KQyEKNX9KqrP2zVfn/FM2WQvbHYc9PpViRPR7BakEsRR kScKkHZEQhW7Vj1ywjQ77K0M1rWZdHY= X-Google-Smtp-Source: AGHT+IFy9nLGihsg0SD0URTc98BCX55JjX+6ATRlDYUzqh5HxVJ4aY8tFC5Zw1tuvOto/68hD1xqFQ== X-Received: by 2002:a05:6000:136e:b0:31f:f664:d87 with SMTP id q14-20020a056000136e00b0031ff6640d87mr16088629wrz.20.1696962194557; Tue, 10 Oct 2023 11:23:14 -0700 (PDT) Received: from lucifer.home ([2a00:23c5:dc8c:8701:1663:9a35:5a7b:1d76]) by smtp.googlemail.com with ESMTPSA id j16-20020a5d6190000000b003217cbab88bsm13225312wru.16.2023.10.10.11.23.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Oct 2023 11:23:12 -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 v3 0/5] Abstract vma_merge() and split_vma() Date: Tue, 10 Oct 2023 19:23:03 +0100 Message-ID: X-Mailer: git-send-email 2.42.0 MIME-Version: 1.0 X-Rspam-User: X-Stat-Signature: 9r37g7sesc7jbaeug61yc6kdx4e6pyjk X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: B8C55140013 X-HE-Tag: 1696962196-349839 X-HE-Meta: U2FsdGVkX1/MMAltCVdlkFACSA+mseRD7B0Rx5JAFBeQgi39d28uxs8YO0UHN89nhfXgGqmY9UcwgkmvWhJTso4yhjFIl+Q901ohw2DpKh8tpfdyGkDuJWIxJXaW2IuB0SLs9HqhHG9MAd7Aou6Tr9kDT5lr2rilz4bnhhzjODF6ZRl1bqhPf/kjMoPz0qFcYlY6e4uloghpDyzV8siN8EwoulcKqLyzQFf8/1MW8BVjeQ7jq0sXMkAxoI2NXvf6oq5t4T2wk4XvNYpU898c+N41xQTEzlbnrsWIIr5ZIIhk6vY/aAUbzyCUB5hu9ongMJYBDm7sYGSi7N8YSB/cOVAfjZByJaHJ/fBBd0EJAlY4llN8w0MILJrVHTABkjI7AmLw2lcb8f808APgq3FGNk252/7wvi1qudduvcL9MSel0I/8DS7WBGYVJGw/BZu9kkDaAXvSRRsHtcHGFxnzAhPNTtwXm3fvbOqFGL1F3IbQQrfAReZEvr5KdIzp5e/R3QEGDQQA7/3DdpIxg0928id4CEnBjVowlovmVkvpn0p4JDAxI5nVfgTV+pchL83G6qxT+5EqXSm1oAADVUyZLPRBeKTA/4iScm05G5V7vNHCcNreZdx4aHBkmw56VeBCCJvU4h3ExCR/5VB7y9jVNypym7IFyoE0mdpGr3XjvFBw1UKb8CwpaDef/ODg8zU3IqupSTaYR2N6q4ctCIpE1J5YP1hgYJlbENLB0z6kso+o2Ybmj5VdNCSkcxPXNA3hMBOE1Le1Skp9Hfhdm5gIgpIlQgYXQHj6BxY+2rP6heOoV91SJxfoKQBwhJQ/GKtALVTCDpBW+7a5+pTEkeJFc2yuGK1whSCoIP8CvXkm+0R/qcnf9T6TFyfWlQbvacIfEeBmX9bYiNsFeMjqGFtmDJedAOLBR3KKjtIS7JX9qsbH3RDCwiOyicPwFA0hBaCvwbK+N8f5Mg0AGbHV3P7 74jSyAx3 e6Dow/OQF5orsC5yPb42IE9uoWuQsZNaSmgrDevDCRNBrDZGzloR/9qjAjY04vURSHPHkCyf+dfb/GDY4l1fVIFwFb98Zgomt6Id9Rw81nzM6ROiqSO4JWIIY+fXILpV6iMwtKKNovlXkpxe8BqdE3HQcyYVp6Wa2QqQJmXONnrjFnIgr8Ghwue4b3cNutYhxmwERDux/KbbhiC85qmQcKb3MHgbrKiX0f8HrfzzpJDEuoRxZTrJvrwwjuffD94EpKxsByKXjlVlJ91gzi3SZMV4hth5zMpmhPweQQ8Bc4HcP8AUDBVh6INwIo3UnPjJj83lrQ+dcmeqat1bUO5GjoCOAeXAySRcANdNYxCfrVdZAXgw86A9YcUDc3jlYVR5vIwAJjbv6ao/uDVjb+Xj3Z5UM670rhPcbmqPKGmSRF1+PYxqf0G6xbrWp9Dy6AzSmYZwM7csJVG1PWDRHSrogKyIu7tDgNmQzcnQMEigSiuGcZRhMJaGdRI5xTw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000004, 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 to either the merged or split VMA 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. v3: * Drop unnecessary VM_WARN_ON(). * Implement excellent suggestion from Vlastimil to simply have vma_modify() return the vma if merge fails (and no error occurs on split), as all callers really only need to deal with either the merged VMA or the original one if split. This simplifies things even further. 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. https://lore.kernel.org/all/cover.1696884493.git.lstoakes@gmail.com/ 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 | 71 +++++++----------------- 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 | 26 ++------- mm/mempolicy.c | 26 +-------- mm/mlock.c | 25 ++------- mm/mmap.c | 114 ++++++++++++++++++++++++++++++++------ mm/mprotect.c | 29 ++-------- mm/mremap.c | 30 +++++----- mm/nommu.c | 4 +- 13 files changed, 240 insertions(+), 212 deletions(-) --- 2.42.0