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 46795C04A94 for ; Thu, 27 Jul 2023 18:00:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6C1F76B0072; Thu, 27 Jul 2023 14:00:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 672886B0074; Thu, 27 Jul 2023 14:00:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5395A6B0075; Thu, 27 Jul 2023 14:00:17 -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 44ADB6B0072 for ; Thu, 27 Jul 2023 14:00:17 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id E1D8EC052E for ; Thu, 27 Jul 2023 18:00:16 +0000 (UTC) X-FDA: 81058156032.24.C16D33C Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com [209.85.128.42]) by imf25.hostedemail.com (Postfix) with ESMTP id 4834BA0026 for ; Thu, 27 Jul 2023 18:00:11 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=O9vN5oXr; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf25.hostedemail.com: domain of jannh@google.com designates 209.85.128.42 as permitted sender) smtp.mailfrom=jannh@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1690480812; 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=oTn2+kxGlhVp4f9iv6z1bXXGresETQByJPAsZA28KKw=; b=FCDzdtEN90REkIw9PaGIfUjyfmpg3+9b2zJhEYIVKDHuabSfVzL8CUnd7zYW8qh4/snZpq AuslpdErDh3gIIJtsg1HWtrSl+EXn4omWz8yz52yDfWfxxNVt7apeChBqAoq/G1rWPxWy5 DptDsjTVCQ8+LuVqZD4Pi762yfsTRIY= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=O9vN5oXr; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf25.hostedemail.com: domain of jannh@google.com designates 209.85.128.42 as permitted sender) smtp.mailfrom=jannh@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1690480812; a=rsa-sha256; cv=none; b=ZqmSoZdn+K+8omiPCMFdJAFNFod9ilcVkhv7rpzC3pjxGhVqkoHexhCdDribT1JZkmpiry JvpMSYSE0Z2czh+S9V2HQ+e6RBRV6HJBCAFkL66WPk0FqVl+FlxOE+45p52/2QrNPVdVzf WHF+Bq1ns/Rc0rmYfECT7FxxeeyzexU= Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-3fbb07e7155so10055e9.0 for ; Thu, 27 Jul 2023 11:00:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1690480810; x=1691085610; 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=oTn2+kxGlhVp4f9iv6z1bXXGresETQByJPAsZA28KKw=; b=O9vN5oXrlqmXbSF6WeTcBJkLLHF4H1Q/1miHlegLRnV6C+vMSCP8ZAd+E+F3vEpmOO dOez8aEDj4dPCWiiwlXCgWmCD0KnBIgiylrn9LkmEZ6SaE7zWu1Ku+/s/HXGwR9C+H6S 8hqrmWwHpqPyjvXrGGH8gCFKx7ty71CWff/iRa27sSTPhqHNXsBExUZ/Kt49yoAZLQfh mLvz2FZwyv568Wb+F1n/71KJh5U1+G0GDS9rXXcoXp0g7t1jOfah3H9lxhZCqjicYa0r JyLBntNWxqxNG4aZaNYof2jS7R8QLqMOgoLOvlpDib6sF0AHX6jYA1ftMbgLadRWlau3 sjGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690480810; x=1691085610; 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=oTn2+kxGlhVp4f9iv6z1bXXGresETQByJPAsZA28KKw=; b=dGZ/15DGf8TaUj+tfj5q80L6vyrsnBX9L5g9S3FosVZSYln4eIfnklQ+wyIGbxTBBc lzLwmZp+PhkGFu6NYJMxIA0Pp0MFJQcOinEyyFkWoVvwsyduZsOVul616i2Ms1LqSdXZ 3MjeU7T5pnc/VfKFxmgykXs7sxjF6ILcG+ICAoAjOfYFMzy73ibKqlUEH2hA8UkDRheM P7wab6qfl/sa4/KkrtLzT9Yj1Z17n7m1eM5WYwlRhF8N9k5b2bE0ftxI+hBnnrGbvDbm +4VxXmPczawlI70dKWLl+0lmuRB4nJ/rR26VmRj7TGI8qSKiiFbK713HTw6Lv75kiLOS N8EQ== X-Gm-Message-State: ABy/qLZEkotvjIQfXKz+9k3G5GJ2tq/m5BKSHnStfNSSlMVV8JMt0ggC Wr304dBcHwJwo/uR3LXjnV9LSIHCuYi1r2BqRy9ggw== X-Google-Smtp-Source: APBJJlGuQWxAL4fqerBwoIv5mRHCYPIZPVe1BZ+MTPguHtmK71dR2/dAWktplHcOEGAI+WfFEOlqcL34Mu47y4FY3ac= X-Received: by 2002:a05:600c:3d1a:b0:3f1:73b8:b5fe with SMTP id bh26-20020a05600c3d1a00b003f173b8b5femr9532wmb.3.1690480810201; Thu, 27 Jul 2023 11:00:10 -0700 (PDT) MIME-Version: 1.0 References: <000000000000607ff905ffc8e477@google.com> <0000000000000aeb7f06015e5cbd@google.com> <20230727164757.e2di75xjybxncohn@revolver> In-Reply-To: From: Jann Horn Date: Thu, 27 Jul 2023 19:59:33 +0200 Message-ID: Subject: Re: [syzbot] [mm?] WARNING: suspicious RCU usage in mas_walk (2) To: Suren Baghdasaryan , Matthew Wilcox Cc: "Liam R. Howlett" , akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, syzkaller-bugs@googlegroups.com, syzbot Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4834BA0026 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: x1duabait57y68w4mdcjzzpd9eyyomww X-HE-Tag: 1690480811-564912 X-HE-Meta: U2FsdGVkX1+j+VkY/RTSqsAdwX5yTdviEcy60tuj9o0gJvccy2i1G/eVBcSOnI+xDPXhLWGeMRwpApEwDjz1dWUlTrFg/s8gflobgADEvFzpqVO447jJtoJPWI0DN/u4clmtnMvEO21nhrgNxnSb5jNdFQP4LYJHqAUjsSbyc/TExt/M1kSj4DVpBVv0s/mK5TT4OHsTpSGYDEYohjqv0xUNk/Q8ilZGjer11EqTNxZ7C4gi3iw7hgUNmXnBjEg0g8sAwQc5sMG/13LnAZ4WyBrNE9yOG+sMMoIIfPuzn0eR/5HXrubKqR2BjycmkHQDEyuzW3UPrc70CpaiZEvSZUGfrKhrUUWsCtggL2KY1r+otPSHaXmHUjByVmjqBLAvYx6ENFyhxLuR3Gf0MXbXCtmZnc4zgr3NSZ2Kq2L0q2fFV7VbHmivhkC1fK+EZQQ/DAuKdFl8cavcC7OvcrGQf/IrccQhiK78uRfovqOlFrEp+7wNxnQtqsrYmroN7vgIsQi6WbUZuWfVfzR7WiAxeW3AA1uyZPKTvo8ttiH8U5v9FqHlu/Bo35bSDlHtlFba2DTRcJNPOtPNnqUfI7LNSXVRhwe47jy1sQde4B0sj7oberhx26KCcGBcodvOiILx4Niv8pc7JhEGIqmRLeilhuV3Yrw7k8q0bh2D3r7+grEj/NX6ALY9fwGnFSoLAOjuuIIQhi71+8K+XxanyGdEtUKQkWdk4tA7uaw8tUcec43/XERgd35LSyBC6rfDE3oW3xRLU0io9hyO3Ry7bgfJ05uh5UiY3TLmRrnjd7ltSI5RpMcksAPSKsr0eh2O2yqHCagGJsRqpAf2V1iBdqSHt+iU30HimDIaEWWJ5HbN7+j/3+DJhVkCkoT8OBoSmFfqskN4fjvdhhXOoKZBjniC7VbhBgBjCkENF0hAho8vdI2AzLzlrqFvOQTOJvkyY9PWU65thbzsAS7UE08bYhI 7ubMt0iK ueR2dHfzeWX57+69dzugT2mjUppWkh/g7VU9avCaXPFJGd/30V5sheve1L/Pkh2CdPW04SQTs5pV7m73RaOn4iaZ3kHCyO75fHH9ctoSmUEebSAzVj5A5B0capTDwnHBhv7PXYTiizxlahpN42QeIYJwhRsJk5y6EAeu3zxFFe/TiL/5vQuZPW42D6bCDhI93LHZbIHBHKXO6N6LcKpSG9apn9AxpLBeXHlFkwsUL6ABGqarz87+nFsDp2tnBSV9trd0KSLmoo/rMHffAI3fNJ6ycYiiTiRKtCRzhYG0q4544AAUNa6tw3UDVlKEW5d77ARLCsTNBIcGc2PN9Romq++8wmz/gYZBkFBw4u4J84CWHBvESWnvKjenb+pSjDLFQu1BAR+kEbht+adll6LdPxL0sjztmy51VWZK/1nMJbV60LS7Fxgm/ky2j39C3Z4F9Xkq+nSDvsjoWPlGKkV3oV8uA0N2m7+GR8je1n3eYazVgNOHQW9zwTPCJBWCN25iPZO5L9SdyXFLgKuDGpl8s50e0MxNB7UDPdjL8l5NLQfNRackdUEXfZHWLYp1WACKSX7usRUaSMs7dRI2n6ZftXZ04WZztszClSv1uJkzPU7rmDuiXCfedxLqio44lhJdXkH7vSobx9Ibl24q8MWh4OGt666DUldjpbKSFkAkaOkgUfUloGd5t+f15PA6WXRjzCjmV/1bCGO+x2AyA5KOuaIfn9g5aVMJH8A3pe5X1NFNewPknd0zO5UlxFPVyLL9mxdUIAJ/bS55fkXqYZns1yUgLNNxrMQ9sEEAuV7KFs6JlELQKL+dU0z8MMGtfyUQ40kR15qe8iE4uQNQwAuum3Z34o3VRF7l68BDrd83oGxD1WZnYHKuKZjZsamcP5V1Nw3cueVpRRgb9jdfDSd3MjiE8CboazmWvotskpgEOsHR0PxTyCsZcuVAbvCX4MRWKH/Je5eGCMKJrFOI= 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: On Thu, Jul 27, 2023 at 7:22=E2=80=AFPM Suren Baghdasaryan wrote: > On Thu, Jul 27, 2023 at 9:48=E2=80=AFAM Liam R. Howlett wrote: > > > > * syzbot [23072= 6 02:57]: > > > syzbot has bisected this issue to: > > > > > > commit a52f58b34afe095ebc5823684eb264404dad6f7b > > > Author: Matthew Wilcox (Oracle) > > > Date: Mon Jul 24 18:54:10 2023 +0000 > > > > > > mm: handle faults that merely update the accessed bit under the V= MA lock > > > > > > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=3D178358= 5ea80000 > > > start commit: [unknown] > > > git tree: linux-next > > > final oops: https://syzkaller.appspot.com/x/report.txt?x=3D144358= 5ea80000 > > > console output: https://syzkaller.appspot.com/x/log.txt?x=3D1043585ea= 80000 > > > kernel config: https://syzkaller.appspot.com/x/.config?x=3Df481ab36c= e878b84 > > > dashboard link: https://syzkaller.appspot.com/bug?extid=3D8645fe63c4d= 22c8d27b8 > > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=3D1697cec= 9a80000 > > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=3D1566986ea= 80000 > > > > > > Reported-by: syzbot+8645fe63c4d22c8d27b8@syzkaller.appspotmail.com > > > Fixes: a52f58b34afe ("mm: handle faults that merely update the access= ed bit under the VMA lock") > > > > > > For information about bisection process see: https://goo.gl/tpsmEJ#bi= section > > > > This is caused by walking the maple tree without holding the mmap or rc= u > > read lock when per-vma locking is used for the page fault. > > > > We could wrap the find_mergeable_anon_vma() walk with an rcu read lock, > > but I am unsure if that's the correct way to handle this as the anon_vm= a > > lock is taken later in __anon_vma_prepare(). Note that the anon_vma > > lock is per-anon_vma, so we cannot just relocate that lock. > > Hmm. lock_vma_under_rcu() specifically checks for vma->anon_vma=3D=3DNULL > condition (see [1]) to avoid going into find_mergeable_anon_vma() (a > check inside anon_vma_prepare() should prevent that). So, it should > fall back to mmap_lock'ing. This syzkaller report applies to a tree with Willy's in-progress patch series, where lock_vma_under_rcu() only checks for vma->anon_vma if vma_is_anonymous() is true - it permits private non-anonymous VMAs (which require an anon_vma for handling write faults) even if they don't have an anon_vma. The commit bisected by syzkaller (https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit= /?id=3Da52f58b34afe095ebc5823684eb264404dad6f7b) removes the vma_is_anonymous() check in handle_pte_fault(), so it lets us reach do_wp_page() with a non-anonymous private VMA without anon_vma, even though that requires allocation of an anon_vma. So I think this is pretty clearly an issue with Willy's in-progress patch series that syzkaller blamed correctly. > Jann Horn is fixing an issue with this check in [2] which happens > before we take the vma lock. So, it's possible that this race is > causing a call to find_mergeable_anon_vma() while holding per-VMA > lock. Another possibility is that the recent addition of vma_is_tcp() > is messing things up here... Either way, find_mergeable_anon_vma() > should never be called under per-VMA locks because it relies on > neighboring VMAs to be stable and we do not lock those. > > [1] https://elixir.bootlin.com/linux/v6.5-rc3/source/mm/memory.c#L5396 > [2] https://lore.kernel.org/all/20230726214103.3261108-3-jannh@google.com= / > > > > > > I'm wondering if we need find_mergeable_anon_vma() to take a read lock > > on the VMA which contains the anon_vma to ensure it doesn't go away? > > Maybe a find_and_lock_mergeable_anon_vma() and return a locked anon_vma= ? > > Basically lock_vma_under_rcu(), anon_vma_lock_write(), vma_end_read(). > > > > Thoughts? > > > > Thanks, > > Liam > >