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 2EE83C83F1D for ; Tue, 15 Jul 2025 09:53:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C41368D0006; Tue, 15 Jul 2025 05:53:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BF2438D0001; Tue, 15 Jul 2025 05:53:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B09178D0006; Tue, 15 Jul 2025 05:53:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 9E6A88D0001 for ; Tue, 15 Jul 2025 05:53:02 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 509C9B91F7 for ; Tue, 15 Jul 2025 09:53:02 +0000 (UTC) X-FDA: 83666035404.17.167BD08 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf05.hostedemail.com (Postfix) with ESMTP id D32F6100005 for ; Tue, 15 Jul 2025 09:52:59 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=eQh1ePD5; spf=pass (imf05.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=quarantine) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752573180; a=rsa-sha256; cv=none; b=bHjpDPBOXfs2Gzk2fdr++YIUihPDXy2xUzCHIxxEEpYw1MSnqjQTd/lbtPVUBMSHldQRHS o1dzg3PwyVVrPHjxraho16AoDbFcNloo0KfoTyCZph965vmc9e5UzSEZWgkymxtdtnjGmQ b0B/mD/xMpkK2kNTqzC/dAozlLcsYas= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=eQh1ePD5; spf=pass (imf05.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=quarantine) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752573180; 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=SuWFbwcKFwkO4YE39Jv4l+w+Ru3JZyDbp4UzjIFZ0bE=; b=W2hZm8UPILBi0zGdyt5RMP4BlmG1ASTGtj2ChvZiuRR+cSWxSPR8k+bi05thGQoYkl6XaO QGO1NCazFpR5L2BViHe1u0bd7m/j6zyxL5fQHCH10HJ38M9WvWgPy0TcCR2ZopXDS8Ow2r y4rVKgXGVjA+rcb8APiydbwsDNL2JkU= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1752573179; h=from:from: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; bh=SuWFbwcKFwkO4YE39Jv4l+w+Ru3JZyDbp4UzjIFZ0bE=; b=eQh1ePD5hPLJCcTkW5iR43dHsvDKgpcNuMqpSAeiDfoVQtDPfgEfG5+HTIRL/B5M6QMwdT qbWSHiUObU1eESiqmPvmZ/3P3ME3kns8lz03MNxuVidmreuLOqM9XBS+wMtKLQ1/S/La9S 4yvHbh5HJ2DCX3BPwJwKW+wm9u72+FY= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-509-jDtga6XlPsahewNJD7lZCg-1; Tue, 15 Jul 2025 05:52:57 -0400 X-MC-Unique: jDtga6XlPsahewNJD7lZCg-1 X-Mimecast-MFC-AGG-ID: jDtga6XlPsahewNJD7lZCg_1752573177 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-3b604541741so1237375f8f.3 for ; Tue, 15 Jul 2025 02:52:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752573177; x=1753177977; h=content-transfer-encoding:in-reply-to:organization:content-language :from:references:cc:to:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=SuWFbwcKFwkO4YE39Jv4l+w+Ru3JZyDbp4UzjIFZ0bE=; b=IUWOU7QiHVt6tGglVix97jLE9L+CDJwIzcAFhA22i8JwDjeNDnmOTdTiELqN2FWOOa QqMr2ryYlvAj6rai0+h6LrWYFuj3/x1lb5TgDN/mcOFIhQY2s3PXG7xpH5pkeDoBDvLL 8bqLpgyXyDwosFN+7DxT1kx19PaUfe5qMYrY52T2HVgpX1T9w/PSep5PDRH7uKgRmKcP z0oT6SiRg3Wl+mcdXtc7TLLJC9m1H4f5uDRGhcshasoMJ5RTmKKyxLhsQDG9in3EFz1+ 1YhUpFawogHsomqRpBRmsbf40FX1KNi1QMXxwNBQvk2KqQocAPlBAa9nju9ZDk0cGirz qRuQ== X-Forwarded-Encrypted: i=1; AJvYcCUdNVp7Ww7pRxZpauK2v9yG9o28rQ8ACMnI+FShUQo7L1f44v5KNKNLaXn2LPI7OBag/i7ONTIEkw==@kvack.org X-Gm-Message-State: AOJu0YxfxeamD+tkgPy87AYisbm2CBjw3elL949CD2Cr8oM+HaK+rBbs 26d0JiCaTkl1vkcpEuqm/57qCQgoGFjNlN39dI0hwM+wYTiXaJF9H/Axkvd5M2RMv7qu9SoiCOW pfpYKO6XLhSOYQq/kg5I4i+dUDi0f2D3Oh660Sa728x/fklebnxJh X-Gm-Gg: ASbGncvcj0F0/Hlc2i1kt/fmRJn62PM+AcTVbJnLXASc/UI9P3rbLmwbBNEawrYFKIi tmwjYlL+9qibZBgOCab/dILPWNN4GF4rupdwJ4GOw04NXMrw7IxAP/0sqZhKe1w6PU8qqSzItrv Q5fiiviEHbFSZyzPXuQ01N21p8NWElt/wJeG86p/oZMaZ390LyocVy1mD8FVB6YC/j/UOV2tZP4 dbSm4D8Po59ntAF4UEZbjeBv1z6JCbQL5tFzKyaDdzPVq43BKHNCmUOsFpHh8J22I3L0meAVlqr bTT3/qafd9l9F2QEdv4zvSXjDhwsalBWMmDOvvj9pB2HBXmwQZm6L1ldJ3wzcSFfLCcb2VrSAn6 J1pnUd4CtC5b0J5jCI6hmmz6B+e91acA3aJtp9SqQDEPjZvCFCRssZGAF6iXKoVDWmV0= X-Received: by 2002:a05:6000:2189:b0:3b6:2f9:42b1 with SMTP id ffacd0b85a97d-3b602f944aamr4069431f8f.13.1752573176512; Tue, 15 Jul 2025 02:52:56 -0700 (PDT) X-Google-Smtp-Source: AGHT+IH+P4YnnefvGaKOACywNWvVTxwP1BSs56yJ4dRdeHF7Q116DlCh8GXFKl0VPzCL7ntocy4BVg== X-Received: by 2002:a05:6000:2189:b0:3b6:2f9:42b1 with SMTP id ffacd0b85a97d-3b602f944aamr4069396f8f.13.1752573176078; Tue, 15 Jul 2025 02:52:56 -0700 (PDT) Received: from ?IPV6:2003:d8:2f28:4900:2c24:4e20:1f21:9fbd? (p200300d82f2849002c244e201f219fbd.dip0.t-ipconnect.de. [2003:d8:2f28:4900:2c24:4e20:1f21:9fbd]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3b5e8e0d76fsm15000882f8f.64.2025.07.15.02.52.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Jul 2025 02:52:55 -0700 (PDT) Message-ID: <0b8617c1-a150-426f-8fa6-9ab3b5bcfa1e@redhat.com> Date: Tue, 15 Jul 2025 11:52:49 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 7/8] fs/proc/task_mmu: read proc/pid/maps under per-vma lock To: Lorenzo Stoakes , Vlastimil Babka Cc: 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 References: <3b3521f6-30c8-419e-9615-9228f539251e@suse.cz> <5ec10376-6a5f-4a94-9880-e59f1b6d425f@suse.cz> <19d46c33-bd5e-41d1-88ad-3db071fa1bed@lucifer.local> From: David Hildenbrand Organization: Red Hat In-Reply-To: <19d46c33-bd5e-41d1-88ad-3db071fa1bed@lucifer.local> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: lbUBcbBEYhykz0KNgn9EbbBk3KPyoBVN4jmcSZb_FTo_1752573177 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: D32F6100005 X-Stat-Signature: 885mh33hhtn6x9qh9kyso7cojz1j1nfz X-HE-Tag: 1752573179-120188 X-HE-Meta: U2FsdGVkX18DJ6kM3q2uw3Epxhqm4NMNRyOQtwE9sdzQ+xW72tkRnE3uczjaXdJsdUSeTDfAJzgiYokCxMZrkMswmoOyR6uBorstFmAvIgdcI4I0Ksehh3lt6/1BYh3rTH2qL0M7/MDDBvEYH5YGxbh4olxf96Q8VuTwPeeU/5Vtf44dNbm7Ynarf/9EY/i/TSzgMep4M9uzSE1FRyp5j59CI7cYQAxz4RAolIihghKnA1B/8RxQrQukZN+sBSsADpNTIAQxcnwVdYBnvWv+5/3+SH2AIAGGBCeJIBPjIpdd7JcpN964WxrO37Bb1yoIRKe+n6JveoKkSTt0egU3SJCIbiX1ZqRJuuQrppu8E/prBMLXbUeh4sl2/2Lu98nBs5Ak0465fgpzOmqrydwWQttv9S3jIDIc7OXPJaXvSIpP4sPqUG9jQE/xZ5JkqiUIEQLjHXwZKQRHd/IExyD6V9D8e6HH0AmzMpetcwaCeulD+0ETOWBboEDNXaUo0k3B6Zl4CkxgJn8UbdD+r1fUlG805K7WVZie7TiQAy1dtf2wKVJugsZBVRlKUyaaPwCGUjupJPSEFp6+p40+GiWHfrqCoKM/yZCtm1xWjZvhbq8PRvzV9OzrkuQD55Py36Pql31+BQb3QI0Y4jG+TcRyeqF9QmIq5PCDLDvpriHHMr/2P8mYLr2vHlFAZSERXWSiEUkz3MeUj4tgNWBSWMaOtJcsNlbCQ9HMnPancZ/eQFTsc6QahnjP8QucbMhR9H8so0k4q8nxSrYSqI91GN+MbNLCYt7Ega1zRgH6LWWM1UHhQg585hkn8zyhKO/qws8qb7ePfW+hXNgtjYVIf8X3dI80Kq+9Qu4SrNWQrr3Z6Ivaky9K0TW2vip9YHpe2qwWBA1x/RYmhKDO9HQeZyMOCSDak6Jk+Q+3j8ZRsTJp5KHDJQzVl+VV27KuVadObBUqn3SNjpsl6wHwPgaO2j4 FwQN/Rtp xLiQRvDT1UJAmqBmIzOZwRvGsXhBLbSC0JCNWbJ4u33NqxLAEkprGIoV60pNv3DQhINmGghYA/qTdTHi5J4mJEe1bDlbogvSdOwljDSrvmWs3Rxrr6fALAJWU+aAo3GCXfn0YQwvvyIxlyNcX2AgicdnDIOrYF65hCjbJbaLrBE0q1dfHjGfhIP02M8EMzbjWrwXIeXlT95/lUJMKabhaCbjTHT0lTwjvOEjjubrABgsbekOPvjWuw7ncgEomr6QQ2p7OaZndlH2ezf7HGu+2rP0cgOM0c/oTLu1SOLl1Ax4CoHEQ67N5mvir4LoeSADWZ8G3YmjATzw/MuHiVqjb5q02e3Pc3HW/38k3PjAMAREvxksjjds2Z9z2SQtfyIZKpabo6dUS4ihksBOT49zkdJ7FSLv0nHNT98pzi7/zTEYXrsVvgxgfT5NzZiDHmH2Y625RwPgDpxOwJPqA3aCu9R74C7+KyxP0TwpTvbk4wjC9Xv6PfqmGaylgsg== 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 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 each other >> (probably not even against read()) and yet we treat m->private as safe 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 right >> thing for us wrt serialization, but the ioctl addition violates that. We >> should rather recheck even the code before this series, if dangerous ioctl >> vs read() races are possible. And the ioctl implementation should be >> refactored to use an own per-ioctl-call private context, not the seq_file's >> per-file-open context. > > Entirely agree with this analysis. I had a look at most recent report, see: > > https://lore.kernel.org/linux-mm/f13cda37-06a0-4281-87d1-042678a38a6b@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 that > though. Probably. When I skimmed that series the first time, I was wondering "why are we even caring about PROCMAP_QUERY that in the context of this patch series". Maybe that helps :) -- Cheers, David / dhildenb