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 05819C2BD05 for ; Mon, 24 Jun 2024 09:39:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 92D2F6B03F1; Mon, 24 Jun 2024 05:39:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8DC9A6B03F2; Mon, 24 Jun 2024 05:39:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7A4AE6B03F3; Mon, 24 Jun 2024 05:39:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 578136B03F1 for ; Mon, 24 Jun 2024 05:39:18 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 08A70160D3D for ; Mon, 24 Jun 2024 09:39:18 +0000 (UTC) X-FDA: 82265283996.10.A64742F Received: from mail-ua1-f46.google.com (mail-ua1-f46.google.com [209.85.222.46]) by imf06.hostedemail.com (Postfix) with ESMTP id 55604180019 for ; Mon, 24 Jun 2024 09:39:16 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=B5etrCSs; spf=pass (imf06.hostedemail.com: domain of elver@google.com designates 209.85.222.46 as permitted sender) smtp.mailfrom=elver@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=1719221942; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=IoWqpu6r3gUVAVjJpJT9iCQKouKBD1EH5Hld1KMrMpM=; b=dpDJRP0MtZmH2u3w6/5pCNpcEZMGyNQbfIIMYIUbtmVFPpV5PMap7D9ueAcHyz1UagAQZ2 EBeCeSRbIhec82ZzGH2mUGuVqo0ZDKQnD5BlGSsMLl05LLw1a8o0+9/xbEOh6GZiAmZjZh 5fapK096ZwWKDYkeUzakTcTresSGOgA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1719221942; a=rsa-sha256; cv=none; b=zC+boHSOFqSsMx17QxQUd41wWyWOQH0PwGPafeKiA+JtmLF4qusEUdMTAHQz3GNpwokrGV bHJOKHjexJoV+QjgYnGlFc9yPcd/QggIgtBb2fxM0QLHV5TFJWAcrsbpFwfwxR+mIU3tOa J7G3dyQYT7RljQJV6nCDzYmYTP0aPMw= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=B5etrCSs; spf=pass (imf06.hostedemail.com: domain of elver@google.com designates 209.85.222.46 as permitted sender) smtp.mailfrom=elver@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-ua1-f46.google.com with SMTP id a1e0cc1a2514c-80d64c817a7so1102492241.3 for ; Mon, 24 Jun 2024 02:39:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1719221955; x=1719826755; darn=kvack.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=IoWqpu6r3gUVAVjJpJT9iCQKouKBD1EH5Hld1KMrMpM=; b=B5etrCSsHC2Fsb4jB1jC7FvrZScpcSOxSFXeF8KC2Tc4hHEaUZ622aluONjtk6OsP3 jE854OQ/iB6ZqATxpgBqaI9GJQRtwTizs5sVmchQzCB/gnQ3Jh9gLD6PpU5BE+tfvAfh aRDZeNvKjrbqM5qOq9JQP/vNn0yF+hhxXbxeoOZP7T9zV9WR9H1+I84pMhwV++2R8OKE 11FzqzUNNvL3ksqO0fSH7NlcxMR4ul2Q8AvaDOHRsCi7MDz2baMErSfMeug+WbMmRgMi UVkFM6EKtHBRXI5w19QESgaOha/K6Cs/SxyjQcCDovdc8PrZqvqOE31lv0eT0oJV3HlX weNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719221955; x=1719826755; h=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=IoWqpu6r3gUVAVjJpJT9iCQKouKBD1EH5Hld1KMrMpM=; b=ZNN/yMbUCDOWJr3TREftsM4HXSkVgUqspH9tSZWyCn9h4EQhTP7jPhYAx8OudMZZ/W KYVSnZ/RSRaHi6U2CsV/AJHBoQK3TNHhKzR4v3MXrkciGWL/qot2T9TT7Gsoun4yxsFi vFvnLSOl8Qui3VU4Gw9kiTe8Yh/2Bu4xNX6DhdiDR96EbmjcmvzbnEOJSyCdueZhn6wm QAtF7AU28tjWISYjwyEhD1z2SlPkmr8oRHqflR8CBNsCPgUkitBWJTl8+seDTM9yYEU/ GUw2YbKQRrZciG5ubdIZ23xk+pJdtIAL9eL76rtIskuumiX9Do6nkCoIl/rJ+4AvhyDE CSlA== X-Forwarded-Encrypted: i=1; AJvYcCXzx3cmHPJG8cl9h4gHCyluqCHkowDTAnwsMd9HQtlxjY8N9ovnsidVLvbudAT8BDQSBeSF7N4WXcTBagNA66sTV+Q= X-Gm-Message-State: AOJu0YxVcX4Hiq+4rZua7VKaACTWTQwbH1afv43bRJuogr+CO8zkGt+7 PxooqQKcLSBLIFdPQ8zzjBtVBOyBLHf/9dtKJawWtTkphdCe05ng8g3C7W+Y5pCSBe60ruds85i Y1qOHwcAfDwkrvr8O9cB/cqJ8MeFjNC0oFjEv X-Google-Smtp-Source: AGHT+IHCUgNT5G+QF2omWXK3OQoPtsprTqEOTdUMRsBani2GJwAGTlfM9odozZN4RQihJXk6g3Dpe2OnZTSS5dadaiM= X-Received: by 2002:a67:fb88:0:b0:48f:4396:38a2 with SMTP id ada2fe7eead31-48f52ba2552mr3288434137.34.1719221955135; Mon, 24 Jun 2024 02:39:15 -0700 (PDT) MIME-Version: 1.0 References: <0000000000008d1e5a061b666b11@google.com> <3sldogk6uc4vxas366obosrgz6jwd4sms7edvsayt6l47aoieu@n5a4lee2rjnc> In-Reply-To: <3sldogk6uc4vxas366obosrgz6jwd4sms7edvsayt6l47aoieu@n5a4lee2rjnc> From: Marco Elver Date: Mon, 24 Jun 2024 11:38:36 +0200 Message-ID: Subject: Re: [syzbot] [mm?] KCSAN: data-race in mtree_range_walk / rcu_segcblist_enqueue (2) To: "Liam R. Howlett" , Marco Elver , syzbot , akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, lstoakes@gmail.com, syzkaller-bugs@googlegroups.com, vbabka@suse.cz, RCU , "Paul E. McKenney" , Joel Fernandes Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: w69ogcuniua4iahii165at9yhhzatijs X-Rspamd-Queue-Id: 55604180019 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1719221956-683758 X-HE-Meta: U2FsdGVkX1/KzS6cCc7vPCFHd6Uvd4FUxUY3MQCZvFyPGb+7G15gh66a4p8CkOsayAhgj9kaeBNMKnpSC7DKfcCVLBEsDr1yyH4q7ljOTNh2rU+tGyv4xJpbBUGkAfnIyzWudcTG5cD06a4tHSpQ2EdceC4pY1kFJyrcre6nzoSVAEj/P+aAOwC6KibwuT7OzakDHgSYHce1yFtMm9uScDVDrdQcTtEuRoP0IFHL/0v8kssWdFD43NP9ff1zGvUP65AHFJ7aJ3zngbE2YYHvgP8kh5QDiRvNsAl3qNl2Af1F8mdUmRjQuctmrYpkkajX74OSd5SsIS5qSAlb91Oc3ZAMAQ1ciaDyHCJtne/47Mtw1nBCUWNZNWNmMYqYqPP4Db4qqJ7TOabaEgtG8KWZbOvk4GgvUtOlR+P0A2pqkFc09UvCRy8I9pSCgSv5YbEgl1U58Vf+u8udHc5EVP1aYJ65fnbtvVicHJBhfTZMZ0x6BZryJ+1S0kuJiPbcnoYEeXc6/MzieGgaYVEOLEqbDN1lfL3iwyahYT6HEunK407acapvOVotslLwXixYsVzqOAGpB1vH9LhYyGbvh0mDMZthvt6jwL/8954l7errjfmj/0SvzvLdMVHnlNvfGMKu5p5yLcD1Q8NwVPqffr/hadyDw092jSAQ/drDqTo+zMGSRpGkgTtSyALYhAPdzzFTNV+6AgNlkwlcl2Cwk3nm6g+WQHXLRsWhAm1XvehxCCZdKQFfuAJ3LaH33cG8IpndrqPJ6PUYD+UzHBp50tuNmAHK5DulxiofJAOKSpFwZc6oRqPOFj025XWZqd5oqXvpk0C0KrsPSox+k0Xdr/2WpDdo5RH4CbfR5We8BwUczDQ0DEO1z8ZaKZ9Js2nW2VB8GbfsMdaXzZLA/U7ONFTojjuzIhMs0gMSAJh5/z8xU7JGGKhGu+MWEIvNY3T4/RZx32Q60/V+DpPDFECteRh xLJ83g2F Pn0QFm5LCGkCFH7Z8Bef+5CtmZgYmBZycaF7nC1ngClMqnNwU9EvTiWkCthE7VHDb049NlVnj+PX+/LcTwMcukkFIUOHYWdBaXSxpXsTi7I9gPAVn7uHvDcYQBi4MOF4hpHSJcVWv2IqYWPjPKveVmT2wh6dP2rKboZrxlEGIGpSPgAYI+8TQPD2n9gnDqrEknspYCm8tGQ0jgNpFPdBmA85uZhuW9hjXf0Z4ECho/UqOlrd8Q7W4T8WwQ9DcKeqCfkz0ffKlbU9GECa+VwwyKPUvQn3SV6nOcOFuTamMX3yJ/DzVP4C1Cb7Ym/D7jVIrbxJPEZm/pSJzRbXY1obxKDjmtdmfuM5lk49DFGIaHNRhjKIdJvkLRuhB31I5m2C8RnOtGZNm+OuSAVq9rxb+s7sB9XKMpokQ4b9t5O9t/TSFNjYdf47qe+92pVGMBA+17k+O1Ig4g/ojmNoVzr+nxVJErdW2kqOIhVjDKBWNvTuxxD8YkPaahRPf3Oq6/C/EPEqL2n6uxxClJ1r1Xkh2J+TRkiksbD/1t+74ZPzHpJvpdCvvCT3cvgQqX+Zq2k3Tjq5E6cZeLWPQBPVBWnPImmp3RaIuEskH0EX28ntCAnqr9dmkq5irYJVWr3jCkHEflWHWQIGWj98bcBSyJyGCFkUmFiH46D8bwZxyTMo+VwZ2ghHeyaA2h3BlaTj6c+i7JPi0nDD4kd1YEcu5MfZlAuhn1qhNi08DI/jnvxl2O98+qV6dnHiElxyqcXhMfY3Qftd+Ki+wBMpk0f36txauaGaKV0esi0yDXic5MKnrhuDHHClxnzMmp+WfzUqXPsbttP9zkuT9UOJ/FM/PFb3VJ/JCXDGdyACsHjC4xfHjR3ysLmWoIT9AsWNXlh8MmZzM5UgvJ98sBj8TktY= 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, 21 Jun 2024 at 19:31, Liam R. Howlett wrote: > > * Marco Elver [240621 11:29]: > > [+Cc rcu folks] > > > > On Fri, 21 Jun 2024 at 15:29, syzbot > > wrote: > > > > > > Hello, > > > > > > syzbot found the following issue on: > > > > > > HEAD commit: 50736169ecc8 Merge tag 'for-6.10-rc4-tag' of git://git.ker.. > > > git tree: upstream > > > console output: https://syzkaller.appspot.com/x/log.txt?x=164ec02a980000 > > > kernel config: https://syzkaller.appspot.com/x/.config?x=704451bc2941bcb0 > > > dashboard link: https://syzkaller.appspot.com/bug?extid=9bb7d0f2fdb4229b9d67 > > > compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40 > > > > > > Unfortunately, I don't have any reproducer for this issue yet. > > > > > > Downloadable assets: > > > disk image: https://storage.googleapis.com/syzbot-assets/e4cbed12fec1/disk-50736169.raw.xz > > > vmlinux: https://storage.googleapis.com/syzbot-assets/d50b5dcae4cd/vmlinux-50736169.xz > > > kernel image: https://storage.googleapis.com/syzbot-assets/f2c14c5fcce2/bzImage-50736169.xz > > > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > > > Reported-by: syzbot+9bb7d0f2fdb4229b9d67@syzkaller.appspotmail.com > > > > > > ================================================================== > > > BUG: KCSAN: data-race in mtree_range_walk / rcu_segcblist_enqueue > > > > > > write to 0xffff888104077308 of 8 bytes by task 12265 on cpu 1: > > > rcu_segcblist_enqueue+0x67/0xb0 kernel/rcu/rcu_segcblist.c:345 > > > rcutree_enqueue kernel/rcu/tree.c:2940 [inline] > > > call_rcu_core kernel/rcu/tree.c:2957 [inline] > > > __call_rcu_common kernel/rcu/tree.c:3093 [inline] > > > call_rcu+0x1bd/0x430 kernel/rcu/tree.c:3176 > > > ma_free_rcu lib/maple_tree.c:197 [inline] > > > mas_free lib/maple_tree.c:1304 [inline] > > > mas_replace_node+0x2f8/0x440 lib/maple_tree.c:1741 > > > mas_wr_node_store lib/maple_tree.c:3956 [inline] > > > mas_wr_modify+0x2bc3/0x3c90 lib/maple_tree.c:4189 > > > mas_wr_store_entry+0x250/0x390 lib/maple_tree.c:4229 > > > mas_store_prealloc+0x151/0x2b0 lib/maple_tree.c:5485 > > > vma_iter_store mm/internal.h:1398 [inline] > > > vma_complete+0x3a7/0x760 mm/mmap.c:535 > > > __split_vma+0x623/0x690 mm/mmap.c:2440 > > > split_vma mm/mmap.c:2466 [inline] > > > vma_modify+0x198/0x1f0 mm/mmap.c:2507 > > > vma_modify_flags include/linux/mm.h:3347 [inline] > > > mprotect_fixup+0x335/0x610 mm/mprotect.c:637 > > > do_mprotect_pkey+0x673/0x9a0 mm/mprotect.c:820 > > > __do_sys_mprotect mm/mprotect.c:841 [inline] > > > __se_sys_mprotect mm/mprotect.c:838 [inline] > > > __x64_sys_mprotect+0x48/0x60 mm/mprotect.c:838 > > > x64_sys_call+0x26f5/0x2d70 arch/x86/include/generated/asm/syscalls_64.h:11 > > > do_syscall_x64 arch/x86/entry/common.c:52 [inline] > > > do_syscall_64+0xc9/0x1c0 arch/x86/entry/common.c:83 > > > entry_SYSCALL_64_after_hwframe+0x77/0x7f > > > > > > read to 0xffff888104077308 of 8 bytes by task 12266 on cpu 0: > > > mtree_range_walk+0x140/0x460 lib/maple_tree.c:2774 > > > mas_state_walk lib/maple_tree.c:3678 [inline] > > > mas_walk+0x16e/0x320 lib/maple_tree.c:4909 > > > lock_vma_under_rcu+0x84/0x260 mm/memory.c:5840 > > > do_user_addr_fault arch/x86/mm/fault.c:1329 [inline] > > > handle_page_fault arch/x86/mm/fault.c:1481 [inline] > > > exc_page_fault+0x150/0x650 arch/x86/mm/fault.c:1539 > > > asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:623 > > > > > > Reported by Kernel Concurrency Sanitizer on: > > > CPU: 0 PID: 12266 Comm: syz-executor.3 Not tainted 6.10.0-rc4-syzkaller-00148-g50736169ecc8 #0 > > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024 > > > ================================================================== > > > > This is not an ordinary data race. I suspect this to be an incorrect > > use of RCU, resulting in some kind of use-after-free / type-confusion. > > > > The access within rcu_segcblist_enqueue() is to maple_node::rcu (at > > offset 8 into maple_node). The racing access in mtree_range_walk() is > > to either maple_node::mr64::pivot[0] or maple_node::ma64::pivot[0] > > (both also offset 8 into maple_node). > > Since it's not freed and the reader holds the RCU read lock, there is no > use-after-free risk here. > > Both are at offset 8 of the node, but there is no type confusion. > > This is a false positive, which I can explain. > > The reader at mtree_range_walk() at 2774 reads piv[0] at offset 8, but > will validate the information by checking the parent pointer at offset 0 > prior to using the value. In this case the check is on line 2793: if > (unlikely(ma_dead_node(node)))... > > In the case of the reader having stale data, the data is thrown away and > the walk is started again. This node is already taken out of the tree > and will not be encountered again. > > Note that all types have the same parent pointer (of undefined type > struct maple_pnode *, to catch type confusion at compile time) at offset > 0. > > On the writer side, the struct maple_pnode *parent is set to the address > of the node itself. When this happens, > lib/maple_tree.c:mte_set_node_dead() is called to set the parent parent > pointer and smp_wmb(); This corresponds to ma_dead_node() or > mte_dead_node() that uses smp_rmb(); prior to reading the parent > pointer. Thanks for the explanation. > I ran though this all with Paul (embarrassingly, a while back), and I > believe (if my notes are correct..) the fix I need here is to use > rcu_assign_pointer() in mte_set_node_dead() to make the checks here > happy. I see - though rcu_assign_pointer() isn't directly affecting the data race reported here. The read of pivot[0] at lib/maple_tree.c:2774 will always remain data-racy against the write inside rcu_segcblist_enqueue() after a reuse. Assuming the read-then-revalidate pattern makes the data race benign, the only thing that may be helpful is explicitly mark the data-racy access (more documentation about it at [1]): /* * ... explanation ... */ if (data_race(pivots[0] >= mas->index)) { The only benefit would be to clearly document what is happening (helps tooling like KCSAN to shut up about it, but also humans trying to grok what's going on because it's not obvious). I wouldn't mind sending a patch, but would just end up copying your explanation, so I'll leave it to you what to do with it. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/memory-model/Documentation/access-marking.txt Thanks, -- Marco