From patchwork Wed Oct 11 17:04:26 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Lorenzo Stoakes X-Patchwork-Id: 13417643 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 2A092CDB467 for ; Wed, 11 Oct 2023 17:04:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6496E8D00CC; Wed, 11 Oct 2023 13:04:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5F9798D0050; Wed, 11 Oct 2023 13:04:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4C0F48D00CC; Wed, 11 Oct 2023 13:04:39 -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 3AC478D0050 for ; Wed, 11 Oct 2023 13:04:39 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 99F581A0395 for ; Wed, 11 Oct 2023 17:04:38 +0000 (UTC) X-FDA: 81333804636.05.95269C6 Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) by imf20.hostedemail.com (Postfix) with ESMTP id B003D1C0017 for ; Wed, 11 Oct 2023 17:04:36 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=dgNVpyo7; spf=pass (imf20.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.128.48 as permitted sender) smtp.mailfrom=lstoakes@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1697043876; a=rsa-sha256; cv=none; b=3q+MRi+j2wvu8ChPZfRCF0OM83JytFFvAlr71cT0+8KT3jKK1zJp0mHlUvfpsrZRdRiDEI 3vMvmCUCJrkJkJ82YiqjUqSuEj6tTM1fqy2QRGCYNys5ErDIIwehMoAp+PwPgkvM3GCFjW kNPvr2/8PCEnr5vDG7V0scKyfzWu0LA= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=dgNVpyo7; spf=pass (imf20.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.128.48 as permitted sender) smtp.mailfrom=lstoakes@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1697043876; 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=/MEM2vJvwV4uJcosJuPLdVvwtT2Ba54U+cdzG9D8R5Q=; b=lydNFUGV7Cf6D0gO9OLlCtwwWfyhHEihUSaHGj+T4df80mwULJvuc5G33jEz3bwNlOkUdR b57tgB4S07TAij+pS7b1gytedZ+FPF2y+UAfdYmQSzSV6MIxAHdHIqqMZKAfzi9zcuLd98 1WeQxKeFBfMS8THuEQe/s86xB/DUty0= Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-406618d0992so1415825e9.0 for ; Wed, 11 Oct 2023 10:04:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1697043875; x=1697648675; 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=/MEM2vJvwV4uJcosJuPLdVvwtT2Ba54U+cdzG9D8R5Q=; b=dgNVpyo73+eV8aMwrvQZhYNcJN4PyQeB7hb0VhgFsUPvsUbLqEdFDUKGXhiQRpNq9l 9xZ5vVR97x+UqXMasOoet5RVA/Q+1m4wB/5Au598mBFs/PfDoCW0IF5xtl0P4mK1HUUO qS4kwqbk2wTW6YemmrV4GmVPxu08XcUpU3ZnFtN8VPW5ZHhZM1GhX7AdgyyygcOsMAWG CrOR1fdW7BB63IZoJnfEQ1Sw01KA2VOBcQgp9AavB422QPVbRfBDhwbj3SCyRFQ+OFTF 0hgri6lhGT1mwVCnEvca/F/RjRbYerUdFfzBg5ctiy8nr7OYMXEqNJXLqEdBciKUL4CR RB7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697043875; x=1697648675; 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=/MEM2vJvwV4uJcosJuPLdVvwtT2Ba54U+cdzG9D8R5Q=; b=Uj9QMFtTSnMleQSilGGcVHceG5j8EpFfJrRcRX5V3Qxyt31w7tXhemROY853wjGG7F C/LomYUctnvkTqold0UOuIJeugRFBDbmFsYyiW0Y/553nw9cavkmXf8oWtyZ3G41KaSR T0giodD6Xu6eRr+QsdgOXCQDJVvu4ZAefeCTYEqX1c7Vqz80NxC4plg+oaauNDtRKm0b Gh/SpCcMWZc+RZB1rsmRzrm1sk7B8JGUFTFuEmOiF0DC79B8attL/3K5Eu40LI4VsYYX NbORM80GZ/tu5cGbTYUAGxBU1asVmxW33pSuqmlo/ynX7BD1bP62y4+rFgtP8oT13CWF wYHg== X-Gm-Message-State: AOJu0Yw1Ty297Wo9umfq7DG36/AkhHfHuUPNuabz9t0XIiEPLazLdbPW bWT7Ie9Y+8fdx0FKH2dIgKsZRLcWs0I= X-Google-Smtp-Source: AGHT+IGbXjrJzkJ87J02ncABOsWtecsmidXq2EtYOCOUy2qPIw2XclV4pUxW9L3MXWYJIXDVAtXYwA== X-Received: by 2002:a05:600c:2946:b0:405:4daa:6e3d with SMTP id n6-20020a05600c294600b004054daa6e3dmr18874865wmd.39.1697043874487; Wed, 11 Oct 2023 10:04:34 -0700 (PDT) Received: from lucifer.home ([2a00:23c5:dc8c:8701:1663:9a35:5a7b:1d76]) by smtp.googlemail.com with ESMTPSA id y19-20020a05600c20d300b004075b3ce03asm3834495wmm.6.2023.10.11.10.04.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Oct 2023 10:04:33 -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 v4 0/5] Abstract vma_merge() and split_vma() Date: Wed, 11 Oct 2023 18:04:26 +0100 Message-ID: X-Mailer: git-send-email 2.42.0 MIME-Version: 1.0 X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: B003D1C0017 X-Stat-Signature: awif5dt5r8ugz8mpbkkoz61zutfrefwh X-Rspam-User: X-HE-Tag: 1697043876-84252 X-HE-Meta: U2FsdGVkX1+TCRaYBhlevF3d093QQWs246VtndmAXA8S8m+THYVK1SPAsWBz9NsDPR3BxDNqXJNrNL1wdzy1th682zxDIpliC3GQ2pizcqF/0mHJLVaGGWiS7e7iJrcPtcpqtwSH/NiB4u20cxuWwqptSoskcOqnChJC9NjRXpP2Cyc1d1mDgZvu2Lx53WjQOExEXTX/ioHWBZ2cwY0Lfs3BnTwN4IkU53Xnew0XZZ8RdXHunUZmLpEmMyf+RLG8M6rm/4r0ZqBfjYhcvbXz75hUyhru9W0b1IKc9NVTahiOJ77ODZwTjmoFYVvbo/QSdAVfnM62365oBTXuePG9gUSIwAxdFL4UqTyk0ZZgt7GJTTljth4YX/BXofRzD8BVRJM+kqzko0efVrWypLGAmT2zFZ0TMYeGMz7od99PTQMrX5QAnbVVB2CGmeVkt6H6CsGCXr5LBq5GYEd4+PAhS+yDlVTU1FOyFebCxvOhx0XrAK/W8aaIr0RCya0COhrlnKVtOWZSVKW9wdmtT1y8h3U7iS0OieMcmNuRjqfKkXuXcyXDE8q9ytzwlvfFF6oAO4REOic6HatWfN8FM6KzbozMkc7G9vcVHMaT8Wg+W6fq8T/G/j3iUKnRRdRyOQ1ZAfuV/pblEKbZlwWWX3U0EdjYM34n1PZC/BVAm8xbunt4i1IWHBYl9fDKao6in3U4ACtwRXDvpYAziHdpZ8QTJeIa60YRws2N4L0MET74x/zD9u0wpEDhDLCdXO+lllcpB9pQeoj+HvLhTP/16/0AWzJAuH9TLLcSMSHKTxd8wuz1iMREsSUy7Imy/4mWhUCVDiBO+riOo0311piCJisoOyCAFBLQF0HYwS0Knwif2i4WWTZbMijzd+0TuEWzFIwNZux8XMxMXXOJoZbCGnDhlPmnYKbFUY+Siln67lJSBzBLKDRd7lTV49hU6GL8uijxGZHd4qdM+Qjp6GEQEp8 Hwxr39JG CKbdDDffuKFThWXruf1lLPXuTc2uosXL+FaTmknntEBufU3OJyBsINbcweixO3P0fE/mLHyNMU+eCpS+osWCXn//a/DN/YZf3NQUh7H/jw1hHHmLXiBJuoC7KUOihQL3C7X8iLqxOnSAomVE+7KkYMdArfFXWL3/rGW+Dy/711mjYVR2MJ4jsM7n7m9YAqOAE5wuSb7Sp7XeZuBuGLQ4fRsV+BqxLesV6SdomfkHjJ6E57jNTvf6QZvXPwKUN2xZIlFQP4PPb2yIjr/NP/w0XuB1k2vEa8QeFwQurrnlBGJ6grJnIRBTiDphu1ZlRPGtEvi4/EN6ga2O8gOgo3XGuTuQQJxNczoVldvQZlU6kqCR8ywYp9Qciklv85mlT4aeck88FVSs6wH20cJQsJ/gQ7l5VbGi6kKXBvJz64NfyIK5Prcr4ZW6Nl0E8CDH0PEfIi1zWJ3FaIuDr8HlzWHbosrPMp6JE/kwx/aelPhUmB1oELTSMvtM7qc3z5g== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000002, 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. v4: * Correct bug where PTR_ERR() was accidentally pased prev rather than VMA, as suggested by Vlastimil. * Updated comment and styling, and moved from using pgoff in vma_merge_new_vma() to vma->vm_pgoff in case driver changes it, as suggested by Liam. 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. https://lore.kernel.org/all/cover.1696929425.git.lstoakes@gmail.com/ 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 | 70 ++++++------------------ 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 | 112 ++++++++++++++++++++++++++++++++------ mm/mprotect.c | 29 ++-------- mm/mremap.c | 30 +++++----- mm/nommu.c | 4 +- 13 files changed, 237 insertions(+), 212 deletions(-) --- 2.42.0