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 1536FC83F22 for ; Tue, 15 Jul 2025 17:06:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 779A56B0089; Tue, 15 Jul 2025 13:06:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7517F6B0093; Tue, 15 Jul 2025 13:06:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 640846B0095; Tue, 15 Jul 2025 13:06:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 4FB8C6B0089 for ; Tue, 15 Jul 2025 13:06:07 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 0717D160128 for ; Tue, 15 Jul 2025 17:06:07 +0000 (UTC) X-FDA: 83667126774.09.C760B77 Received: from mail-pj1-f44.google.com (mail-pj1-f44.google.com [209.85.216.44]) by imf12.hostedemail.com (Postfix) with ESMTP id 4A5DA40002 for ; Tue, 15 Jul 2025 17:06:05 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Kzd9gBii; spf=pass (imf12.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.216.44 as permitted sender) smtp.mailfrom=andrii.nakryiko@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=1752599165; 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=nNVdOuKoan23VnHElyXa1O9OQOwkYvq2YE9Vv0XlCJQ=; b=KCILpVGxiRN7fy1TpdeSr3mz3SQSkMAr6lF+fKdujigOVMbQvzPj5GTgBmTyFC4j7lejg5 pgyNmQIP0mHN/l7k+G/s3UnqXOfays+fcTXAEop1z3MVpVPUKWuSknDm/74BfQeKBalkeV 2aAxb1JZjLHhPxyDZpjryg9OR6Fz3QQ= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752599165; a=rsa-sha256; cv=none; b=KbnELncbWqOMguRiv0ty9nKT4GI1w1eluL6NbjkXo2+CK/iAgvqA7PIhqsrTngIktEeOMi OiW+za1vph3prIGYpY4qJZpjOTXAxsAzf9RVmmiYZRoLgPFjczCjEyBDISJf9pVNqD61Ah P9yZSGuyKkPsh8Z4gxh0I9iJQ74BaqY= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Kzd9gBii; spf=pass (imf12.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.216.44 as permitted sender) smtp.mailfrom=andrii.nakryiko@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pj1-f44.google.com with SMTP id 98e67ed59e1d1-315f6b20cf9so6154625a91.2 for ; Tue, 15 Jul 2025 10:06:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1752599164; x=1753203964; 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=nNVdOuKoan23VnHElyXa1O9OQOwkYvq2YE9Vv0XlCJQ=; b=Kzd9gBiiarbI3p1hN5bOK/PHFnO1mx77TOERMspIOvp2/STbMomlprcgKibi7PYxc0 UztZIkyW1rwFn82kjr4tE7D5XijlCfUx3JQmVRdjK4PSxTvGVLjhfl84hdGPxW3hnAXz lgp38lO/zjlxPyyQYtdn6U3jAYcxox+yZeHBJd+OXKrJ7YM3rmBgipTwr+VbnWgYBO/L Lxs08JSkfF6ajn6Lteco5TvCpRjGvyszN0XhKRCCuBPR8egt9ZuBc0/r9WP4d9AoAQk6 ZBKKz7KyHIcwimqWpX7xzD+OSgiffurbfd8WnrZr9mWPFzD0QYR4/W5WMps51DYtm0IU uW6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752599164; x=1753203964; 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=nNVdOuKoan23VnHElyXa1O9OQOwkYvq2YE9Vv0XlCJQ=; b=MtYt2Z/2xMLpYX2j3X4+0vyp2hIiG8Gwl9ImbrfM/xEFWYgXT10VZ1xQYWi6cGjBXK 4iK39C7R7+VmgnpYDyyShFlmWE4RwC0w1B8SHvFLJrf/K7CtP+YcMY9ohCLZUL0akBG2 US+SFIYxNMf5N4ltxew/kdOaFnd2ZAhAKfpgb/74HGibCEqEfmMlxlltCocfuhvnhOEY /XwELYemGrC6oeAoTmx1WlPHjUqpUAExDbSB/lBDuqkFX+SICE+tO7OOAKS5fWWZ5DWt 1v7dW+Kr2COlt7xd7O75tnOa0P31FWGBi9FWqdOXhJezYLjcQkeIVT5pbPCoijTXYj2i /J4w== X-Forwarded-Encrypted: i=1; AJvYcCUGv6LNRSs2kEd5Se2lhPZsqwwNLPcOJ7i9JwnVOLdy9JdD2lnsOqA+HhoWhWDVgdH1D8nDiL44CQ==@kvack.org X-Gm-Message-State: AOJu0Yz/sO6wiKm3z1FRnPjyGRA539VnUEqETDkbB6mF2mX1uEGfTgWm 1Kc5lLfpWzx+xtx7Chont76/ZuTmaWBWZsqDcC1MkKUnm91j6RgsWHITstPqZYaRTdpEqbsOjmb 97VnmOjgBbSaYLxKUGi9MJunxEusIz+k= X-Gm-Gg: ASbGncskEGo0/9CjOD6xwvlvCf+50GlwWh/SK2htaIG5wOb5gEZT4fj1uGwuEmbq9qm TO2AHgpjyGQajCAnuO/Fsq5raGFHdZ5I7HD/lERv9gV6Y1oXXPtYp5smePagrA281T+A/PFvbpY L4d9Ysq6bt6pZDxNVJSSNnlaHJoSEDWgcTipwplBVqbe++Fu7MOmU6Xqk6tQrpCo5XVMOpTmzpS a51vwLFILoy6Es6an00IQQ= X-Google-Smtp-Source: AGHT+IHWqURmLszmS2cR9qYVf+7DTyCLlk2oIrQTrSNPf7Sik3aoVs3pk12vcxBQJlr2vazV6C5tHVX8fcy6hAcG1xY= X-Received: by 2002:a17:90b:1d89:b0:31a:b92c:d679 with SMTP id 98e67ed59e1d1-31c4f5e3054mr25099820a91.35.1752599163826; Tue, 15 Jul 2025 10:06:03 -0700 (PDT) MIME-Version: 1.0 References: <3b3521f6-30c8-419e-9615-9228f539251e@suse.cz> <5ec10376-6a5f-4a94-9880-e59f1b6d425f@suse.cz> <19d46c33-bd5e-41d1-88ad-3db071fa1bed@lucifer.local> <0b8617c1-a150-426f-8fa6-9ab3b5bcfa1e@redhat.com> <8026c455-6237-47e3-98af-e3acb90dba25@suse.cz> <5f8d3100-a0dd-4da3-8797-f097e063ca97@lucifer.local> In-Reply-To: <5f8d3100-a0dd-4da3-8797-f097e063ca97@lucifer.local> From: Andrii Nakryiko Date: Tue, 15 Jul 2025 10:05:49 -0700 X-Gm-Features: Ac12FXwuHfagbWZ-YO4ikvn0k0dO4RWKvyLjInqotU51-B4cAdEKuZJSujCN-MQ Message-ID: Subject: Re: [PATCH v6 7/8] fs/proc/task_mmu: read proc/pid/maps under per-vma lock To: Lorenzo Stoakes Cc: Vlastimil Babka , David Hildenbrand , Suren Baghdasaryan , "Liam R. Howlett" , akpm@linux-foundation.org, 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, aha310510@gmail.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-Queue-Id: 4A5DA40002 X-Stat-Signature: ex43c7bfmp1kz7ge5s1d1i9a9kahid6q X-Rspam-User: X-Rspamd-Server: rspam07 X-HE-Tag: 1752599165-636972 X-HE-Meta: U2FsdGVkX19Yi74gC8uyYa+q/V7vvv7sibGn7QwIFlixXVstNtr0wOXsgfayWySHX1cquIdjCErxMN9QQamlvQSn4HWuoed66senhtB9I0pUmBvbfH33a16016rSYCda1BSMjv3VBJSTTrS2JHNc6wq2NHODibCvPsORViDHimQmKjFV75oiRagKrfzdnQYXBTsOeR6SN4BX9kYQs432DfSqnMFtUR/Z3PW6Fpksme5RBHGaOba2DrKtJev+Av4CzTmBXZGYzmYJg6p1jXQ65MAkyGJoqwX92UcTKGkHDdxTfTgKlZw+7XpuB3xRwmC6WdiQLFZxm0L85DBSZgFoa831lU1iPOBEJrt8TPbqCsRbCp+JqBFiAj4KTfbplHTZdiuOBJJ2FRjUHGexgEAoN19GuAG+RmgUEfM87GV19otDhxdd3649xlvWKpOQvbNsdAIRq7InjZ5jopwme7ctJa8Eku6CAxg6lmLKHO2NhV8tJpqzmbvEuwLhCnYFAYNBtk3Zax9V+Lo9pIsVXhvRGUo4duoOKdwaGXuvcGgzFp7YWHFmi4LjQvsQv+1a9zPvSNjEBjBOJ5ylSW1u9Kw3V/hljqaAp03uXlYUMZhJmu9aeJzyy1r8cI6RNjrXcu7/+PmC2Bah+orIA7BVKBDGhJAfOvhYoUagfU3CrnykEQhNnXSxaswJ6JvZcmX9tc2FiRRDwwFKyMKurk16E1bmUCjOL2pD5wtPGweAr7PI3zR9bR5hlBZ0KRapjLP7zLcUcc8leTFb18erfEqCdSlrsTL0cQMUIVbLmLI+3xl5n7tpmFljEtTJbTaAii+4gt+zqQUntErr7VlIBgR5Yft6jvRXWB+/T+8IZxdw6GMxR11CsKk0IeUo96m/l+AUpbigRzixk9+ah4WDYggoyg62IM1w5FV7/fb7Tmely2gIOzobp1WDPQudtDHQGUUX+9Yu61AG4l16fZNZ/zYE3nU SthtWeoV XxNp9xlnh46XrXz8mjPGde1QiHnOUlVu1jLlkmwENcP+iLyU+1HFjZNuiXA== 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 Tue, Jul 15, 2025 at 3:31=E2=80=AFAM Lorenzo Stoakes wrote: > > On Tue, Jul 15, 2025 at 12:23:31PM +0200, Vlastimil Babka wrote: > > On 7/15/25 11:52, David Hildenbrand wrote: > > > On 15.07.25 11:40, Lorenzo Stoakes wrote: > > >> On Tue, Jul 15, 2025 at 10:16:41AM +0200, Vlastimil Babka wrote: > > >>>> Andrew, could you please remove this patchset from mm-unstable for= now > > >>>> until I fix the issue and re-post the new version? > > >>> > > >>> Andrew can you do that please? We keep getting new syzbot reports. > > >> > > >> I also pinged up top :P just to be extra specially clear... > > >> > > >>> > > >>>> The error I got after these fixes is: > > >>> > > >>> I suspect the root cause is the ioctls are not serialized against e= ach other > > >>> (probably not even against read()) and yet we treat m->private as s= afe to > > >>> work on. Now we have various fields that are dangerous to race on -= for > > >>> example locked_vma and iter races would explain a lot of this. > > >>> > > >>> I suspect as long as we used purely seq_file workflow, it did the r= ight > > >>> thing for us wrt serialization, but the ioctl addition violates tha= t. We > > >>> should rather recheck even the code before this series, if dangerou= s ioctl > > >>> vs read() races are possible. And the ioctl implementation should b= e > > >>> refactored to use an own per-ioctl-call private context, not the se= q_file's > > >>> per-file-open context. > > >> > > >> Entirely agree with this analysis. I had a look at most recent repor= t, see: > > >> > > >> https://lore.kernel.org/linux-mm/f13cda37-06a0-4281-87d1-042678a38a6= b@lucifer.local/ > > >> > > >> AFAICT we either have to lock around the ioctl or find a new way of = storing > > >> per-ioctl state. > > >> > > >> We'd probably need to separate out the procmap query stuff to do tha= t > > >> though. Probably. > > > > > > When I skimmed that series the first time, I was wondering "why are w= e > > > even caring about PROCMAP_QUERY that in the context of this patch ser= ies". > > > > > > Maybe that helps :) > > > > Yeah seems like before patch 8/8 the ioctl handling, specifically > > do_procmap_query() only looks at priv->mm and nothing else so it should= be > > safe as that's a stable value. > > > > So it should be also enough to drop the last patch from mm for now, not > > whole series. > > Yeah to save the mothership we can ditch the landing craft :P > > Maybe worth doing that, and figure out in a follow up how to fix this. For PROCMAP_QUERY, we need priv->mm, but the newly added locked_vma and locked_vma don't need to be persisted between ioctl calls. So we can just add those two fields into a small struct, and for seq_file case have it in priv, but for PROCMAP_QUERY just have it on the stack. The code can be written to accept this struct to maintain the state, which for PROCMAP_QUERY ioctl will be very short-lived on the stack one. Would that work? > > Or we could just sling in a cheeky spinlock