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 A0A6FC369AB for ; Fri, 18 Apr 2025 20:03:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 657166B0024; Fri, 18 Apr 2025 16:03:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 607D96B0025; Fri, 18 Apr 2025 16:03:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4A6716B0026; Fri, 18 Apr 2025 16:03:28 -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 2C73E6B0024 for ; Fri, 18 Apr 2025 16:03:28 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 909AF1CCA1F for ; Fri, 18 Apr 2025 20:03:28 +0000 (UTC) X-FDA: 83348239296.10.F2241F9 Received: from mail-qt1-f171.google.com (mail-qt1-f171.google.com [209.85.160.171]) by imf19.hostedemail.com (Postfix) with ESMTP id A46BA1A000B for ; Fri, 18 Apr 2025 20:03:26 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="3e/DoFRv"; spf=pass (imf19.hostedemail.com: domain of surenb@google.com designates 209.85.160.171 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=1745006606; 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=C+oOpqVmU39D7pSdmadeSMDPqu3kAnHCqdURVPU0NY8=; b=LTSbWyQ/4UiIxR/qVohgjtHAKy40g/kPWolTJv4aJ+n0wNlG55Jpl6kxnETgPCkrzbcLgU GHbMjsKfDma1N8XKGzIeMLNNPMO2f+EIkRzcKr3B1yfbZv3sKHoLYotNjNa6PA7y3gnuuX DspaHlVaFgK1w6rpch8zHE7UTBJptRs= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="3e/DoFRv"; spf=pass (imf19.hostedemail.com: domain of surenb@google.com designates 209.85.160.171 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=1745006606; a=rsa-sha256; cv=none; b=68iH6EvtHYFqLXbn6hgXcaYadfvx/bSVOqFiq4gbZjhdnPQ+fYmnG/pxgyh7UKMMSlyyt8 obcp5XbXRYutH/TfGlpcPvKNMiyfC4MolYHAANvhAKBiOiokFnmtLTHFFzdeHJ1MdK+NUl aksg5nkBvZFVlXIGmiLW3rQsTaCcwd4= Received: by mail-qt1-f171.google.com with SMTP id d75a77b69052e-4769e30af66so513581cf.1 for ; Fri, 18 Apr 2025 13:03:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1745006606; x=1745611406; 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=C+oOpqVmU39D7pSdmadeSMDPqu3kAnHCqdURVPU0NY8=; b=3e/DoFRvsi+Wr8ijnm1M3vNE2wkSCAmxX2PER1+E1DxFImNciSk/eY5S8I0p4p+Mib bmDMtyGfHYigvyyqCdWxxCXCRkrRrp0jog83ufVWlTzkxlyaZOYTQ6Ab+PNQKOd17yZd Su/aNs/Pg8zrdgFB8eqfSQ5UaCpAS446d8SfeBsnbMxU8y81oF4FTjEmCiGlBn6xxOUH nmTy6CEa2cpq4nLOHG71nUEiqZ/39dvuSGOncbi08Udm4w88DDanUwAaXKj59pRbL5kX Jlse6MvB4sik94X+mDS4LHrJInM44aSstwFJMeXT1iV2Tc6Peo0/ROFfCz6BS1YTRaG7 DevQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745006606; x=1745611406; 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=C+oOpqVmU39D7pSdmadeSMDPqu3kAnHCqdURVPU0NY8=; b=MLbm02+2tEdF+Nnq3wWHVPF+NQejbQ82nMow3dz2++xr7nnI3ma0UMxH2iaS121+FU cyRe8wFALJ5+2J17dwCSN5x9zMSA+OoqbFN/raJziU2ualT2qElLvAfu1g8sFa+sp5Sx 6TCL40mGmFzlq3C4jqQk81OmQ3L++uAPTc67FcXNGqnbRfL5SDt/ncHCu79buQL6nuW8 JouEyfmH1qICRf0rQmO+Mwf5qy0Q7Ry6Tnzs/U7O5s1gOUv1vMeORbCIP8BaCXUeeGOO eAeDcjvfRTu5K4S7E1E/uoqim4bLfchoYwqvWjdMQzCKHKTlIy+xYVCj4djyTYwXceck rGtA== X-Forwarded-Encrypted: i=1; AJvYcCXuJe7uLBkkfMyRK6gFi9ScoGALLbZktm5xwcb1/1lfOFh96ENnDCP74bwfcDaULIi3/mi/K3wi2A==@kvack.org X-Gm-Message-State: AOJu0YwOxY5xbTzY3z+9EWsgEG0tZYzgiFuzDfkm6zY4fWQTWM1YJTnn X5JiXiR9kPbbH6T0AOKiZ9B9hfgJrtCU8BfkNZd5x/i+2lbr/Zd//BJ6d8F30dxKsEPAmERFQGb nlpAhHxdCjW8XZbNexCIXfvs7LryhunY7H+gy X-Gm-Gg: ASbGncv5WusL9qltmgcidcpu89z14oIEXaol+2swJaj3s3T05jlNeKRMuRCKGSsO27h vj6jlVqZC9g21FAy0AkfmuG0VwYAk6ZZtjGcyW4rGMYATlhUk0Zl58AahqMtiiiaDyku5MpfIQj cLbHOmpnsnlH0Njq8yPsfh X-Google-Smtp-Source: AGHT+IEp1qePU0PupxqAwvljmN3koti1+LUS4DXKxAoFbiSXRYU93X8EtDbhsmQD9vTQaLe5ynHWCwoNQz4TkmLkIk8= X-Received: by 2002:a05:622a:491:b0:476:f4e9:314e with SMTP id d75a77b69052e-47aecc92a27mr4420151cf.25.1745006605364; Fri, 18 Apr 2025 13:03:25 -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> <361e32be-7faa-41e5-a64f-fa95317abdb8@lucifer.local> In-Reply-To: <361e32be-7faa-41e5-a64f-fa95317abdb8@lucifer.local> From: Suren Baghdasaryan Date: Fri, 18 Apr 2025 13:03:14 -0700 X-Gm-Features: ATxdqUEenzbjQtOpE6Q6rVXg11gqNC0rtlK0DuSQk3YtHt5FbZ3QGSYLe-E2TGU 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-Stat-Signature: 39nyuy49z35y3hphxocibu87z5mmaxut X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: A46BA1A000B X-Rspam-User: X-HE-Tag: 1745006606-438187 X-HE-Meta: U2FsdGVkX187WZBHgxCWSJRLyWfhp+Om3nEhAuJnf67WHdYly7wkP70hwo0e1z3yxCDOYm4zxP2OUgy2t9UARRiX4cSVyIi/L0FrLYgCvZ3UNOx634T3AaYPOSQLWtLEUyFmokPY3ZdEc3c6+m8P+fDEKVOo09Gzezuq/L5oy3dF1G2aHaSwncUA3hgnFkB2QBFLFmttlLDI3PM5oXH3RTz9li1LKsKd2Yjm/Akwm/FIDTxCA1vCI6oe35SJqsrF7lU4yq1Bq+iDfWVfcrNNSCvHAM6YqUyuhSiaXO1j1DSd7AqhCSq7D/7A5VjwJstFf1If5hStZniynV2CIZZ2zrPiUI4PWTnZi6dVbC59nUae/fV30lKk2ibLcDxzJrJzdbqSOgIt6AewWHSGdssVTxPJN+y/QfR4LwSwVzZZ+qT1DSbKU8uaFXN76mbQYFiSokHwsVkTk/xLlEfxzlHiMrQWc/iC5CrwOzr9tW2Ig7R546yv1rzFPJGMmJgNYLH/ENCwW1dz5yeuIipAeF61kGsF3mq/Dmd/MnK5fQ3OxFwNA+/ktBtEgiuxUTWUSPCHIxfw74xPKvAdinj3Yhp9Y/2E66QuS+Sh8Erigy1giqKGhFs9b6BZRlO1CnHCZTfZy9ajphP5E/FOs5WAQEIehDXZ9SXbSkaEBbWXluaWcmg1JDQ0Xdnbj1DhdvzIbmjxMjVwbpWeiYO58jxLJHWs0C9H9+6L39bdqw1ZUAKAiQWSPJg4uMiIkxG7KoVanzo5Nq5J5r9OT5KcXmmYiP/LlSHqMdR31r/tHz6ORnUYxJC3pbHKQ6isWUBVjqSdaGBKsyXNt3JpZFkMBRdafggICsbExcnouO21hZ8FmXkDtSuuZVVVCcYImU2vJ5CqvWBE5ysf6CXSJlI0lTOn8/if24LEqyrwqV2KEN37Pba6+W29Qou6H+ggiGFjLQ3hq4LeGQVWp0itCq+1xJ152vj cM8iRHnc bwgPV3mhf7niE5uhCIyw/krUeDDmxCOtlUnsJZpMqqaHQ91qD/c6e2HYYCe1NtVg6G3VaQCjhuXtFi75uQbk9zinV7eGDTxuX2Bnqp7DfPAEHwn+Hog+LB+iuPyIgyY1J4YTsEoD1qFJaQwuhAMxoviQrx0c88LX82J1UtEa0WQRQJuweH3TEF8MezFkJNjc5i2zpSqRqhg1b8K/nSJUEdRa0w7+UapwRDSairKbTOnIaxDarrRLp0TV0Ew== 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 12:56=E2=80=AFPM Lorenzo Stoakes wrote: > > On Fri, Apr 18, 2025 at 12:31:29PM -0700, Suren Baghdasaryan wrote: > > 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 ad= dress > > > > space when we concurrently remap a part of a vma into the middle of > > > > another vma. This remapping results in the destination vma being sp= lit > > > > into three parts and the part in the middle being patched back from= , > > > > all done concurrently from under the reader. We should always see e= ither > > > > 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 skip= ped > > > 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? > > Speaking to Liam, seems perhaps the implementation has changed since we f= irst > started looking at this? > > I guess it's this speculation stuff that keeps you safe then, yeah we hol= d the > write lock over both. > > So actually ideal if we can avoid having to fix up the mremap implementat= ion! > > If you're sure that the speculation combined with mmap write lock keeps u= s safe > then we should be ok I'd say. Yeah, I tested that quite rigorously and confirmed (using the mm->mm_lock_seq) that mmap_write_lock is not dropped somewhere in the middle of those operations. I think we should be safe. > > > > > > > > > > --- > > > > 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/tes= ting/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_i= nfo) > > > > +{ > > > > + /* > > > > + * 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= (the > > > > + * 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 | MREM= AP_DONTUNMAP, > > > > + mod_info->addr + page_size) !=3D MAP_FAILED); > > > > +} > > > > + > > > > +static inline void patch_vma(const struct vma_modifier_info *mod_i= nfo) > > > > +{ > > > > + assert(!mprotect(mod_info->addr + page_size, page_size, > > > > + mod_info->prot)); > > > > +} > > > > + > > > > +static inline void check_remap_result(struct line_content *mod_las= t_line, > > > > + struct line_content *mod_first_= line, > > > > + struct line_content *restored_l= ast_line, > > > > + struct line_content *restored_f= irst_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 t= est */ > > > > + read_boundary_lines(maps_fd, page1, page2, last_line, first_l= ine); > > > > + > > > > + 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_lin= e, first_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.te= xt)) { > > > > + /* > > > > + * The vmas should be consistent with remap r= esults, > > > > + * however if the vma was concurrently restor= ed, it > > > > + * can be reported twice (first as split one,= then > > > > + * as restored one) because we found it as th= e next vma > > > > + * again. In that case new first line will be= the same > > > > + * as the last restored line. > > > > + */ > > > > + assert(!strcmp(new_first_line.text, remapped_= first_line.text) || > > > > + !strcmp(new_first_line.text, restored_= last_line.text)); > > > > + } else { > > > > + /* The vmas should be consistent with the ori= ginal/resored state */ > > > > + assert(!strcmp(new_last_line.text, restored_l= ast_line.text) && > > > > + !strcmp(new_first_line.text, restored_= first_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, &pag= e2, > > > > &last_line, &first_line); > > > > > > > > + test_maps_tearing_from_remap(maps_fd, mod_info, &page1, &page= 2, > > > > + &last_line, &first_line); > > > > + > > > > stop_vma_modifier(mod_info); > > > > > > > > free(page2.data); > > > > -- > > > > 2.49.0.805.g082f7c87e0-goog > > > >