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 3A081C71148 for ; Fri, 13 Jun 2025 19:12:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A63026B007B; Fri, 13 Jun 2025 15:11:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9EBDE6B0089; Fri, 13 Jun 2025 15:11:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8B3F46B008A; Fri, 13 Jun 2025 15:11:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 6A8816B007B for ; Fri, 13 Jun 2025 15:11:59 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 060015E982 for ; Fri, 13 Jun 2025 19:11:59 +0000 (UTC) X-FDA: 83551322358.06.D950B44 Received: from mail-qt1-f179.google.com (mail-qt1-f179.google.com [209.85.160.179]) by imf04.hostedemail.com (Postfix) with ESMTP id 1CFE54000A for ; Fri, 13 Jun 2025 19:11:56 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="vCy/19Es"; spf=pass (imf04.hostedemail.com: domain of surenb@google.com designates 209.85.160.179 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1749841917; 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-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=3MLioFcu25SrzT1JXLpM40JWU5zBFcetADxV3Ug7jaY=; b=PPjMsfNDDlZyf09KGTKsDH68jmcnzYQG90IhBFRJxiQ5nlCB79IOMNjYPyifDptRyVXqil OxR4b26jopjBezRGPeIy/elAXYV88EwopcQAosEpdiUgEuqdVSHFZ8PpKxhEmwsuiWHykl RV4dn5FQAXUH//svsTP+NF+kL5ktC5Y= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="vCy/19Es"; spf=pass (imf04.hostedemail.com: domain of surenb@google.com designates 209.85.160.179 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749841917; a=rsa-sha256; cv=none; b=DszuD9uA/Ifi9GTVfr8xEyacYEtQmf0Bzqo6oLdNu3kQ4uUf4678TKOWcF4UnPzrYYMcNY hsbz2I6JzYS9KnjeTzYMfw5bo/bVAGYi8zIz44YEgQhtUikEOCHWX3rYfLBdTFi/Xcif80 +/PIDRP39mcHcMQaUFAe2OUNuhzZaiQ= Received: by mail-qt1-f179.google.com with SMTP id d75a77b69052e-4a58ef58a38so28851cf.0 for ; Fri, 13 Jun 2025 12:11:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1749841916; x=1750446716; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=3MLioFcu25SrzT1JXLpM40JWU5zBFcetADxV3Ug7jaY=; b=vCy/19Es+5Gz4/7lX/ZHMmTpNTwYm9gjoUp3RH76/sE58kwCRIwgQ8wkutMltbkYgK m8U1Yr9bprU9f7Cyz37bTwRUgI6Wt/jpA3sCqbPU472wyILfPy91kmj5ZLkUpta3yrwC QwmGF4cVZxAqLIUJlVmRsvFh2ncbk4lFIy9cdVpQYtDwogqE6xSlouh795zNuhBmWC1E 0HW656ZY49RtpEtB+Vy4VtLMv+zdeRPc7u9Q9JojMcrr0y/jNzj5VkX9u8ipFoQp0CbD mnPqu/YBjF+57hNfseIDHvVg15oFPxm+y6eeN1dehfEKOJVyDJP8oKU2cVqmWIkk0+YN tr8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749841916; x=1750446716; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=3MLioFcu25SrzT1JXLpM40JWU5zBFcetADxV3Ug7jaY=; b=REjKtx+pn4aIgUb2uesgpK1dCNkKogHh8PfKrq04qauYvaCjuTB/cHbzs1dCKPqVpO XdVp/+cMu2bVENnR9gW6zXS0f7OMiZDhy7acuFi0WwCjqvb9/7tdMYbupFPibTzbc8sb uIanMwrGoCDZWf7NO/ypktS+UGyzcYBpJmGE5bt30JApYxth6TKm6AKnz98YONB8IL1Q LvpkwQBjlvq0yyz2HXz+BeCBzWxlUdooxiu+YZ7aZBu54vzlAzR0h/Bmf5xpZC/qdpVP /HT6QaHhKQBjZYcEiqzlhANaTXKFF1byX4bJaLylvlwKQiMUeycOlnceUT899lzv+iF3 PG+A== X-Forwarded-Encrypted: i=1; AJvYcCVLBBxELaPj+yk8sPwdmiALFqhvKiraNcfIBGrE+1oMw881BaHXt67BzUH040wLmet2GO6b8/VBZQ==@kvack.org X-Gm-Message-State: AOJu0YxGgLHOk5L7mucyL/z7QdYSnEW9NDos+7G0i5pUcDxoOcP8aaOJ rgHyprA9x656n3FORaxZt/zNNodmZcV8XolNpLL515r188HNwQGqKdd7ctJk2iqZn6o6da5qUPR F3jo779WHDEHvDqfwutB92ojaCfHhqRP974MigDbl X-Gm-Gg: ASbGnctwnbTNJMm5scpApUivuJr3twMM3cefsvEMDvvjxT41+P98U+NiZXMHjZ13dGe GOmf68IUim7270HoVsjaGtLRGyhFaKRVpierlKmkfD+tPXe7Kt+dJK9ZNqkBVTlV1cQGjTljbSS B1mPBjKu6MQOj4Jwu+ldmFLN+TM3wCE2DSSiJwxWCM4g== X-Google-Smtp-Source: AGHT+IFvnQIut+5bnSYDZt2/+KLVzB00ESAWF3T/ASeTAbTQtzNN2t7bhybaTsWELXSkO5KBPEuQ4qfCSd8Vl9SZ45Q= X-Received: by 2002:a05:622a:118a:b0:494:763e:d971 with SMTP id d75a77b69052e-4a73c74bad2mr380121cf.23.1749841915704; Fri, 13 Jun 2025 12:11:55 -0700 (PDT) MIME-Version: 1.0 References: <20250604231151.799834-1-surenb@google.com> In-Reply-To: From: Suren Baghdasaryan Date: Fri, 13 Jun 2025 12:11:43 -0700 X-Gm-Features: AX0GCFvFrVv3MRasBZx4Viw_BkVYZSdZQVHNBuDMFpy95J_U6Iwdmy5s59K2S_Y Message-ID: Subject: Re: [PATCH v4 0/7] use per-vma locks for /proc/pid/maps reads and PROCMAP_QUERY To: Lorenzo Stoakes Cc: akpm@linux-foundation.org, Liam.Howlett@oracle.com, david@redhat.com, vbabka@suse.cz, peterx@redhat.com, jannh@google.com, hannes@cmpxchg.org, mhocko@kernel.org, paulmck@kernel.org, shuah@kernel.org, adobriyan@gmail.com, brauner@kernel.org, josef@toxicpanda.com, yebin10@huawei.com, linux@weissschuh.net, willy@infradead.org, osalvador@suse.de, andrii@kernel.org, ryan.roberts@arm.com, christophe.leroy@csgroup.eu, tjmercier@google.com, kaleshsingh@google.com, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 1CFE54000A X-Stat-Signature: j975uec4zkuo6s991az3m79b6bnht4cb X-Rspam-User: X-HE-Tag: 1749841916-224967 X-HE-Meta: U2FsdGVkX19dpPjplmNpOVBlWRxhcKzZE3KYY0x7bU/VHb/X0Q3CZY/RsPLskY+v+Gccs1mt99CSLdINGW9xQIlSRdzLr9ad2R/lZU/d3/0Oc0epBMqk+1QlNFW0UnV91P4Q2klG7zNNdWdkrVdSD9sS/QULUnK2q41jQpFNO4BXKSWlQK/BhCvhUq6JobwB6GS10cohbgySbl+mssVcgiPVj5pCUKBmXRo0qiI0+z5Nnm+FVC2VwYRPX7KWyCAKE2G+uTlErypgUR9RGAKNBdjRyauXLzc0zNU643L6bl3I/K6sgoARdDrZyKAFey2at9fu9u4u7WTyiZs9bK2ogfTU9yZBsgx/LGIp1X3G1FaFxrliKcmOLgP8M6D2DNrtC9DMd2y/MGD8AYPP5qnFcNRmbQugnMDaObDLOePkQyRQRcYg4JNjkAC/XswcysGmzdJT6/wUUjMOT9sRoubbZZh2M3XMOH170ZTGQ6Wcs6VUPH/yCKwxT1JhsapPj7n8F2uVQJ40Xqbt6fhGvpM21AJfJd/H4THgep2MXm7DLi4+42hN6Rn+Ls6e4j0Ji2Qaf7oAVlO1hvO3RqcwS8S69ean1wmSJ8tZQZ0eBvV7VSX9Wfy4CKl1bYYNvYA5P0AM+kHS+aJghgRwg5iwnYGv3R8g+EUqMoE1yMh80W5xPfvebMr5r3lSharQWgybsUZxmGfnJXj+OpukY0+vGYTmxlbvybzIXzDiP7RyEJbwTisBxyt5hKR6PPNG6me3oWQ3ELShLUeZYyUUDTewJUx7uCprun+QaYOfL0fack4kHwLJ/wu9x663u9SseVCW34aDE++tnvFQZ0zR1L9SHRP2qoVeomADYRB/GSrnaEZ3cahIQI1GbCoGOJeNA7w/k/KlxVvdfGMDVRm50TXv2ljd1D6gIEiajtvDIIoTCPzwoVDuVdNui0vMn3IBcC2YNQqY2vwKgHh/3OapHnXzi+O GIFYMdlJ UsHus36NqqQHtqOtaBw+TLxjxJVpCamqk+3HUwKJr3nqRF5+uCZnRn2Z6URNag6Qv6lF/0DVa3MAglNpGkNWGAY2FSidLXNbvaAs9fvtEsJ7mq2lNcEAA2iB5w+0Cbpu3V4cJbqnSSEFZvPnZqQ5F8CJSJV2xsFXVwSWxkVOMHF3kG7BPUPLfOaWw8C5nqN8VJ0hGpza2QdqKSUxQstJHqWckbzLf14lxyL+hTZqHU9zUGPWvyMr5A7TF0faUQjV1q38iyYs0o1UCjaw= 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: On Fri, Jun 13, 2025 at 8:01=E2=80=AFAM Lorenzo Stoakes wrote: > > Hi Suren, > > I promised I'd share VMA merging scenarios so we can be absolutely sure w= e have > all cases covered, I share that below. I also included information on spl= it. Thanks Lorenzo! This is great and very helpful. > > Hopefully this is useful! And maybe we can somehow put in a comment or co= mmit > msg or something somewhere? Not sure if a bit much for that though :) I'll see if I can add a short version into my next cover letter. > > Note that in all of the below we hold exclusive mmap, vma + rmap write lo= cks. > > ## Merge with change to EXISTING VMA > > ### Merge both > > start end > |<---->| > |-------********-------| > prev middle next > extend delete delete > > 1. Set prev VMA range [prev->vm_start, next->vmend) > 2. Overwrite prev, middle, next nodes in maple tree with prev > 3. Detach middle VMA > 4. Free middle VMA > 5. Detach next VMA > 6. Free next VMA This case should be fine with per-vma locks while reading /proc/pid/maps. In the worst case we will report some of the original vmas before the merge and then the final merged vma, so prev might be seen twice but no gaps should be observed. > > ### Merge left full > > start end > |<--------->| > |-------************* > prev middle > extend delete > > 1. Set prev VMA range [prev->vm_start, end) > 2. Overwrite prev, middle nodes in maple tree with prev > 3. Detach middle VMA > 4. Free middle VMA Same as the previous case. Worst case we report prev twice - once before the merge, once after the merge. > > ### Merge left partial > > start end > |<---->| > |-------************* > prev middle > extend partial overwrite > > 1. Set prev VMA range [prev->vm_start, end) > 2. Set middle range [end, middle->vm_end) > 3. Overwrite prev, middle (partial) nodes in maple tree with prev We might report prev twice here and this might cause us to retry if we see a temporary gap between old prev and new middle vma. But retry should handle this case, so I think we are good here. > > ### Merge right full > > start end > |<--------->| > *************-------| > middle next > delete extend > > 1. Set next range [start, next->vm_end) > 2. Overwrite middle, next nodes in maple tree with next > 3. Detach middle VMA > 4. Free middle VMA Worst case we report middle twice. > > ### Merge right partial > > start end > |<----->| > *************-------| > middle next > shrink extend > > 1. Set middle range [middle->vm_start, start) > 2. Set next range [start, next->vm_end) > 3. Overwrite middle (partial), next nodes in maple tree with next Worse case we retry and report middle twice. > > ## Merge due to introduction of proposed NEW VMA > > These cases are easier as there's no existing VMA to either remove or par= tially > adjust. > > ### Merge both > > start end > |<------>| > |-------..........-------| > prev (proposed) next > extend delete > > 1. Set prev VMA range [prev->vm_start, next->vm_end) > 2. Overwrite prev, next nodes in maple tree with prev > 3. Detach next VMA > 4. Delete next VMA Worst case we report prev twice after retry. > > ### Merge left > > start end > |<------>| > |-------.......... > prev (proposed) > extend > > 1. Set prev VMA range [prev->vm_start, end) > 2. Overwrite prev node in maple tree with newly extended prev Worst case we report prev twice. > > (This is what's used for brk() and bprm_mm_init() stack relocation in > relocate_vma_down() too) > > ### Merge right > > start end > |<------>| > ..........-------| > (proposed) next > extend > > 1. Set next VMA range [start, next->vm_end) > 2. Overwrite next node in maple tree with newly extended next This will show either a legit gap + original next or the extended next with no gap. Both ways we are fine. > > ## Split VMA > > If new below: > > addr > |-----.-----| > | new . | > |-----.-----| > vma > Otherwise: > > addr > |-----.-----| > | . new | > |-----.-----| > vma > > 1. Duplicate vma > 2. If new below, set new range to [vma-vm_start, addr) > 3. Otherwise, set new range to [addr, vma->vm_end) > 4. If new below, Set vma range to [addr, vma->vm_end) > 5. Otherwise, set vma range to [vma->vm_start, addr) > 6. Partially overwrite vma node in maple tree with new These are fine too. We will either report before-split view or after-split = view. Thanks, Suren. > > Cheers, Lorenzo