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 6CBF1C369AB for ; Fri, 18 Apr 2025 19:31:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B0FB3280002; Fri, 18 Apr 2025 15:31:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A977A280001; Fri, 18 Apr 2025 15:31:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9126C280002; Fri, 18 Apr 2025 15:31:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 6F15A280001 for ; Fri, 18 Apr 2025 15:31:43 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 4ADD8160CFB for ; Fri, 18 Apr 2025 19:31:43 +0000 (UTC) X-FDA: 83348159286.21.BCB0A79 Received: from mail-qt1-f172.google.com (mail-qt1-f172.google.com [209.85.160.172]) by imf23.hostedemail.com (Postfix) with ESMTP id 7405514000E for ; Fri, 18 Apr 2025 19:31:41 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=rdf8yuv5; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf23.hostedemail.com: domain of surenb@google.com designates 209.85.160.172 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1745004701; a=rsa-sha256; cv=none; b=pPBDa5cQxJGATD37yqgfstMueiKY9zRGzfayNbm7TMhb40zmfJoU+WB8/gXbRaDAjF2WH0 0afcdvhEbAn1Fu+mZWuHbO8ol992xYKE+7YAI9mU+kQnkoO2u84uI65A2oqwM9Au3pVqR7 0XiC1qcYE4/3JKmVDw6v5ibg1ND2xro= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=rdf8yuv5; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf23.hostedemail.com: domain of surenb@google.com designates 209.85.160.172 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1745004701; 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=SWNK5ZwuejE7tXwmDLQZRJ8XpCbjqSeVlDw7EZQYS7E=; b=OwCIfR+3ljemq5/tyfusAkP8K6ktQQjrM0YB9HV7i7DeNx4CWtcyD9tKuNIXly6qAU6K5p BOm6rArUXvmSsndoFyR1GT8HrLSmGN/Q6MhpeOrv08KpLkgKRYEHVLFPudY2005ZyTyqpf +9UD3IzJVw+51/YXR+URNHj3ogfJUyk= Received: by mail-qt1-f172.google.com with SMTP id d75a77b69052e-47681dba807so347551cf.1 for ; Fri, 18 Apr 2025 12:31:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1745004700; x=1745609500; 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=SWNK5ZwuejE7tXwmDLQZRJ8XpCbjqSeVlDw7EZQYS7E=; b=rdf8yuv5Sv42Gi2CL9DEhGSMWoqxkTbXYC3sT8omCyH2qA1BpB6LGF4Qxll4Z5AZB6 /SEM92NjZd5H2cb+8gWYWJb6PkETMd7IFsFkapMPp5HCjmGYcau83nAAy4/00rRPcOr7 9Poqa1uTKtRXQDlpcQaw7ZrXJ1f8JEy1nX25Fw4gsafXe4C53j1Eo8RQ4/ph7Yj97bpW KHO3ES9Nx9s+Eu5diz+wHgX4pfKNOqmyOtgcaJhcVfX0JjQt73FioybhDxF8onl4qhqs kYT+LXOJdT91l9ixkf8ZhC8J0o0BsPrYHjrWB7QC5r00HgJCzY79v5eNfffKjJzmSAFJ QYCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745004700; x=1745609500; 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=SWNK5ZwuejE7tXwmDLQZRJ8XpCbjqSeVlDw7EZQYS7E=; b=uD5g8gJZuudvBytquetrdkAAqOWRb+A1pm92KYgi3hNHCYbjtulQXXWE6EbDXYIf4i IViOCsrlRk6eLaqWMvy8y1o7D+Q/0aitGFnBwqsh52mSnDF0LZRlBOJ8Qv5dPSIU1EDO /ewclvPWr0Kw109SKmteQzJeOMU3iUQqD+6qU7bRMpnEeyqyCXir35MLFFcxOUvkF1H2 NW34fk9Le4M2b1D8xBkXnPpH2VrXFbW1Mq3W9B5PcuCQpqpF1szQH8cL7cTnG+r2DR2K AEoe53m9KVO6Mau43Qu9PN23yY/nCc6SttJmb402GFCjqgWOhZuVQb0xewzReOZz+w9H ++2Q== X-Forwarded-Encrypted: i=1; AJvYcCXFkViR1LumO7Io8YIsLvEj4s4BrquJG3bwnRVmvxNVGYfWDy3Oxm2YKlWEBR6JjDorvBh7oAMkCg==@kvack.org X-Gm-Message-State: AOJu0YzyGCnkm5TU68zMTz9i2uCJQYsc6SGo4RifXQv3f9s1QJGKsjFL rHDI/JheYk5GBl5i+VtIT0ZBuGlCNuGob+t5Wxvwe5AXP+CJst2ymAZNPImJmMQIPoHses0x+Ce WXaEgFd8pCH0R8C2j34f3iF12JzBj8qjRM+Vj X-Gm-Gg: ASbGncuwU8VUFBq9TrqZIdVBdolWZ/+iE9QHhLzvgOtQC+7YmBKJTTOs4PjJPPsCQaO A7nFKcns332xQ9tCF4O/lvbht7IQKwWLgfkZGu/g7GSWjTJIbDDude3I0KCZjpAx8shyvhe8Mtf v4GS+ni6SbiSqPEuXWU09Dq7YqM6sXMDqkKw/ZhHqq/F++gwXQBqo= X-Google-Smtp-Source: AGHT+IGv7KDN4Lh/PcDOZZy0o9zxti5r+f9e4oyoOA8u8LUMboIW11yYiLi+ycBx4Ubd8zWM06bhkMxGNcQoP3RZ7DU= X-Received: by 2002:a05:622a:118d:b0:476:f4e9:3152 with SMTP id d75a77b69052e-47aecc8978amr4180221cf.25.1745004700221; Fri, 18 Apr 2025 12:31:40 -0700 (PDT) MIME-Version: 1.0 References: <20250418174959.1431962-1-surenb@google.com> <20250418174959.1431962-4-surenb@google.com> <5958fb2d-a2ac-4a24-8595-222d7e298951@lucifer.local> In-Reply-To: <5958fb2d-a2ac-4a24-8595-222d7e298951@lucifer.local> From: Suren Baghdasaryan Date: Fri, 18 Apr 2025 12:31:29 -0700 X-Gm-Features: ATxdqUHq0cj3b-wClcFL4LSAdvNKcZinahLl1OzjF_qAlRbobWNpAJquGdnFx-U Message-ID: Subject: Re: [PATCH v3 3/8] selftests/proc: extend /proc/pid/maps tearing test to include vma remapping 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, 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-Rspam-User: X-Rspamd-Queue-Id: 7405514000E X-Rspamd-Server: rspam04 X-Stat-Signature: sczmfnurpft54n8rash5nwrcmz97e89a X-HE-Tag: 1745004701-112596 X-HE-Meta: U2FsdGVkX193gpCOAsagJHyveRUnCOxtApcYJFe//YYolfj4rXjIzMBWrGVyg8w1qKRv0auNPCYUF8tU5XPHUEYBKVNMios+cN3qparZBjX4wC7MJb0uGpwCyJr8mOWAICZmu21DIm5HcPB5lQ1/0dMa2K3Fa1MnOtffRcN+xHUlr30ioQIP0NZXrR0oT3dlwP/q18E4yByJp7mohsfTWj31UQb6BkiotDXrWCqPAmj165Gdp3vFl0grO/QCwMcwiAIB7zJmyWpzcqLVpvuY/q/WtJPezfuRUXh7Oo66V7fkFvyl1dZ42FmS5iaSI49gJcZZ4zc++sl+3h8NPjYMcb/Pv7wFYVTBdeWBZFKtg0nVKz6mIeHVp7Hc1IlgW+slYd9FLSiVB/guFOk2a/y9x+oU/Ky+ipk9ZGvMAP1O1NN49lVwKILrxZ7BhZyaZWP9EbJRnwY6wEDCLlhTyioYzPQAOp3DOD6mCkpXmsq0MbD1YKfvNZpTDCti8NfKQDrn6LbUabtN4f5lU5ZVOoWiHeF4AEbmhRhU7Xhwxx/ynJuY20JrdXfG8ARZQPKm8UmZMf2k38aJgxyW7jX2N94FKZ+SRidgSKRXE4lgaCSL4sYHS2LWrjVC7id8/QJ7ZhCS+BSYb1QnoxQfFbHHMcoAZJ/tOb50IPmrXFIL7f/SCNCy3Xzo13f1msVKLjcWNvcE8i6l7Zaf+RcmFG37EmWmdICDiyBuiGWWcV76dvphKydO4ocGLFBJPIVhBr6AR/FvaBUEmsugp7rIs+tLAcBujQ4rq4TLS/VXiFiqZ5s5BtBB7f93YES3CYHqR8fccJeyq6zwW4zGQnWUKdW8OK1nbDLakv4z5g1wNy0MQzxdwvrhTvbKE/dw9+0XGCMxtPbAxIAznio4aDKGbvyVt7LL8nZroW+0N7Mb7pDIK0r7r9Oixeh/7TqlmOTrgrqpi3JcOmobhT8pHZ9qWYsTtxq 6CjX9lqc 8jQiz5n+3nyoM32D94lGuCCfG4fXKeKZ4ehjwTBCnCIVjhnJ2zwzV2DerqFr8kMtlrDcnYnU373OwlkNNrVQusd19Dz7BoJIJLUJzppIBpzOtADyqHTIADvFuzkReRESTI9VBgixRtc0BvskHGH2z0hWFpeJmb4Vz2JPqcKlTVXxbljkQbWiY2Zm7xOF+zaCKSppsTxBrFeJw22qQtscL5te6Fbwx5ZhXUT83pc9RN0zWi4oKm9JZz0ysWQ== 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, Apr 18, 2025 at 11:30=E2=80=AFAM Lorenzo Stoakes wrote: > > On Fri, Apr 18, 2025 at 10:49:54AM -0700, Suren Baghdasaryan wrote: > > Test that /proc/pid/maps does not report unexpected holes in the addres= s > > space when we concurrently remap a part of a vma into the middle of > > another vma. This remapping results in the destination vma being split > > into three parts and the part in the middle being patched back from, > > all done concurrently from under the reader. We should always see eithe= r > > original vma or the split one with no holes. > > > > Signed-off-by: Suren Baghdasaryan > > Umm, but we haven't fixed this in the mremap code right? :) So isn't this= test > failing right now? :P > > My understanding from meeting was you'd drop this commit/mark it skipped > for now or something like this? After you pointed out the issue in mremap_to() I spent some time investigating that code. IIUC the fact that mremap_to() does do_munmap() and move_vma() as two separate operations should not affect lockless reading because both those operations are done under mmap_write_lock() without dropping it in between. Since my lockless mechanism uses mmap_lock_speculate_xxx API to detect address space modifications and retry if concurrent update happen, it should be able to handle this case. The vma it reports should be either the version before mmap_write_lock was taken (before the mremap()) or after it got dropped (after mremap() is complete). Did I miss something more subtle? > > > --- > > tools/testing/selftests/proc/proc-pid-vm.c | 92 ++++++++++++++++++++++ > > 1 file changed, 92 insertions(+) > > > > diff --git a/tools/testing/selftests/proc/proc-pid-vm.c b/tools/testing= /selftests/proc/proc-pid-vm.c > > index 39842e4ec45f..1aef2db7e893 100644 > > --- a/tools/testing/selftests/proc/proc-pid-vm.c > > +++ b/tools/testing/selftests/proc/proc-pid-vm.c > > @@ -663,6 +663,95 @@ static void test_maps_tearing_from_resize(int maps= _fd, > > signal_state(mod_info, TEST_DONE); > > } > > > > +static inline void remap_vma(const struct vma_modifier_info *mod_info) > > +{ > > + /* > > + * Remap the last page of the next vma into the middle of the vma= . > > + * This splits the current vma and the first and middle parts (th= e > > + * parts at lower addresses) become the last vma objserved in the > > + * first page and the first vma observed in the last page. > > + */ > > + assert(mremap(mod_info->next_addr + page_size * 2, page_size, > > + page_size, MREMAP_FIXED | MREMAP_MAYMOVE | MREMAP_D= ONTUNMAP, > > + mod_info->addr + page_size) !=3D MAP_FAILED); > > +} > > + > > +static inline void patch_vma(const struct vma_modifier_info *mod_info) > > +{ > > + assert(!mprotect(mod_info->addr + page_size, page_size, > > + mod_info->prot)); > > +} > > + > > +static inline void check_remap_result(struct line_content *mod_last_li= ne, > > + struct line_content *mod_first_line= , > > + struct line_content *restored_last_= line, > > + struct line_content *restored_first= _line) > > +{ > > + /* Make sure vmas at the boundaries are changing */ > > + assert(strcmp(mod_last_line->text, restored_last_line->text) !=3D= 0); > > + assert(strcmp(mod_first_line->text, restored_first_line->text) != =3D 0); > > +} > > + > > +static void test_maps_tearing_from_remap(int maps_fd, > > + struct vma_modifier_info *mod_info, > > + struct page_content *page1, > > + struct page_content *page2, > > + struct line_content *last_line, > > + struct line_content *first_line) > > +{ > > + struct line_content remapped_last_line; > > + struct line_content remapped_first_line; > > + struct line_content restored_last_line; > > + struct line_content restored_first_line; > > + > > + wait_for_state(mod_info, SETUP_READY); > > + > > + /* re-read the file to avoid using stale data from previous test = */ > > + read_boundary_lines(maps_fd, page1, page2, last_line, first_line)= ; > > + > > + mod_info->vma_modify =3D remap_vma; > > + mod_info->vma_restore =3D patch_vma; > > + mod_info->vma_mod_check =3D check_remap_result; > > + > > + capture_mod_pattern(maps_fd, mod_info, page1, page2, last_line, f= irst_line, > > + &remapped_last_line, &remapped_first_line, > > + &restored_last_line, &restored_first_line); > > + > > + /* Now start concurrent modifications for test_duration_sec */ > > + signal_state(mod_info, TEST_READY); > > + > > + struct line_content new_last_line; > > + struct line_content new_first_line; > > + struct timespec start_ts, end_ts; > > + > > + clock_gettime(CLOCK_MONOTONIC_COARSE, &start_ts); > > + do { > > + read_boundary_lines(maps_fd, page1, page2, &new_last_line= , &new_first_line); > > + > > + /* Check if we read vmas after remapping it */ > > + if (!strcmp(new_last_line.text, remapped_last_line.text))= { > > + /* > > + * The vmas should be consistent with remap resul= ts, > > + * however if the vma was concurrently restored, = it > > + * can be reported twice (first as split one, the= n > > + * as restored one) because we found it as the ne= xt vma > > + * again. In that case new first line will be the= same > > + * as the last restored line. > > + */ > > + assert(!strcmp(new_first_line.text, remapped_firs= t_line.text) || > > + !strcmp(new_first_line.text, restored_last= _line.text)); > > + } else { > > + /* The vmas should be consistent with the origina= l/resored state */ > > + assert(!strcmp(new_last_line.text, restored_last_= line.text) && > > + !strcmp(new_first_line.text, restored_firs= t_line.text)); > > + } > > + clock_gettime(CLOCK_MONOTONIC_COARSE, &end_ts); > > + } while (end_ts.tv_sec - start_ts.tv_sec < test_duration_sec); > > + > > + /* Signal the modifyer thread to stop and wait until it exits */ > > + signal_state(mod_info, TEST_DONE); > > +} > > + > > static int test_maps_tearing(void) > > { > > struct vma_modifier_info *mod_info; > > @@ -757,6 +846,9 @@ static int test_maps_tearing(void) > > test_maps_tearing_from_resize(maps_fd, mod_info, &page1, &page2, > > &last_line, &first_line); > > > > + test_maps_tearing_from_remap(maps_fd, mod_info, &page1, &page2, > > + &last_line, &first_line); > > + > > stop_vma_modifier(mod_info); > > > > free(page2.data); > > -- > > 2.49.0.805.g082f7c87e0-goog > >