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 6467CD75E5D for ; Sun, 24 Nov 2024 21:27:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 707C86B007B; Sun, 24 Nov 2024 16:27:01 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6B7D06B0083; Sun, 24 Nov 2024 16:27:01 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 57F4D6B0085; Sun, 24 Nov 2024 16:27:01 -0500 (EST) 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 39F616B007B for ; Sun, 24 Nov 2024 16:27:01 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id C353B1604EB for ; Sun, 24 Nov 2024 21:27:00 +0000 (UTC) X-FDA: 82822273800.14.A9CEC9D Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf17.hostedemail.com (Postfix) with ESMTP id C17D240006 for ; Sun, 24 Nov 2024 21:26:56 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=tm7XtDTo; dmarc=none; spf=none (imf17.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732483618; a=rsa-sha256; cv=none; b=fzdCbV05Zl+FdZojHxMoA+ZmhEgIROSNJgbNOLuknzrEMcBdqI4En0vlPcCM8sIdZYdqz4 oeMgzObKqrw5Y/3qClwkVzU7VSHVA4YHyKFv7Fk/DnAGQNLg7JYHo2KfhJVjUhlrN6urtM leeFdpfiv8+m7rK8H3M/mLc9l0048fk= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=tm7XtDTo; dmarc=none; spf=none (imf17.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1732483618; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=FUIkB0nu6kVu8Kh8kg7nHVT5DQReYZ3ZBRdCsxIWzDQ=; b=t1Bz1YIfhwz6ICxoNCideIL0bCllWwy9nZdON4wo9sSUeIsCmdIVQlZznZYT+a8WVZpj9U uFUR7/e3SAMFCVhEAZcT703ZJcD0iVxQKw+Iq1qsQRlpi1BpjAqakCxJ5Ip8tlzZtSr4DG cz7/OAC5nCauh2sW6iFAU9nhLP8KFMQ= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=FUIkB0nu6kVu8Kh8kg7nHVT5DQReYZ3ZBRdCsxIWzDQ=; b=tm7XtDTooTSDxUSCSm73zsVteU xNt1bxswAxTe1kUbhDqRSsyw4BqsSMOgY6R/MoZBbnu4Gk0Nw6Dx2v15m13pfQF6suCXsjqGZj2+n pOL4RQ0ohNtn7o/Te8+EjTMA/LFadHLAmmmHy6efDsu/5I2Aj4vNsqF1bi7B8SIwEbtX8Mn5mrYaq n/CHXbj9vStw0VwSLOziTJoqYZZ3k9+/fIP8pFE2pMhl1MH6OIZ3lUEXU96VjJVs8qvQqRHYuYOEj wlfhwGgt3OQJUb37navH3TrkKkKRiN3B4yvYpkO2SGRIhTutILInHoOrRo5MaTno6/1JU/9mvAPdV vQYqwPaw==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1tFK85-0000000Awx1-2C4n; Sun, 24 Nov 2024 21:26:53 +0000 Date: Sun, 24 Nov 2024 21:26:53 +0000 From: Matthew Wilcox To: syzbot Cc: akpm@linux-foundation.org, clm@fb.com, dsterba@suse.com, josef@toxicpanda.com, linux-btrfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, syzkaller-bugs@googlegroups.com Subject: Re: [syzbot] [btrfs?] kernel BUG in __folio_start_writeback Message-ID: References: <67432dee.050a0220.1cc393.0041.GAE@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <67432dee.050a0220.1cc393.0041.GAE@google.com> X-Rspam-User: X-Rspamd-Queue-Id: C17D240006 X-Rspamd-Server: rspam11 X-Stat-Signature: cnnhyw89obwffjnfbrrrgnkc4o9w74zr X-HE-Tag: 1732483616-398066 X-HE-Meta: U2FsdGVkX1+HO75gamSaJQrWOBmMD4kZGTwWXBIfitNmamfyfc//TEsbA3N3XDONaHd09CVCsAaq8o2IiPOyx19vACmE4g+VcYOEbzQVrfy+5JSTPaF7NXr8AB7IqwELl8bNOsVQir1dHd0dT+fxhgFys1a4J6fy7iuznmzRjSTpRxx3QVH3DzvgHAi8uEVBEVne/J48DaBcqW7TpTZupmIAOHQkx+FcD1yUP6iWQz6sk4PFz2BGKGf+1bNih60yKzldb2RJfckcCzx5Tx/x6IBGenp32EK3/EgpMbmM4yrJ760rNwU6X5x5u6AqfAUFF4RwfMs7g+bpvSG9a3bRXxp9WJxRL4aCHpuW8Neva18Z0YIOrjIEx8N0wi6LRCUiAh/8PdkxOKvyeemXNuVPbo0fkwOINZWVDvO3I5hNbn2hERVxuaF27FQhuWifIdtfyzY2TLlTtY3ESQ97SAFf/YJoCrj4GTerlAy31mITXGnrB8YjPZ4rwXVdJD0boBKYq9jW1e8o+OCGabPmmfPEgbZ0vbhFY/uk0QYr461BH2qRJOstZQdRitVyPcO0Qu7FYqJuY47zTBRa+xEHAYwSX2hfcpo/WZUmjnmd1qWvmVPLmFl2xGz6cBwIU1YJyxgovaNbAR6OW0UqAHFpiKyuwoGjbm+E5u0VGgCwjRDjakXgsKW9UKMFmfY6DflwoZl4/DbAp5sJcVZpZrceksKnxG9e/sIMTHgvHbuG78+x+HbP9wJ3DQjB5F+NvN0n9PeFrGzG5TCzzc75wYSsXnwjBXekilIzNfj3i+xNIfmiR0dlzYxRyH17cuDuNn1AqSgYHaG9kX2uLATct7nsjaNIXulGVVsn3p53fwtpK2lmBxMAuzR78xuHzX7ckqktW0Cp83jayEPtsbWLQUNQz+PiHl1Y4K1kxW/nqPZ3o8uS6zhSGl/g6BUq2NEPsUDIHKZGxBUeV0+3eDPIljqQZDT 3gOgYtgc txuMX1i3d4qM67hOCEgvq5xfQbr3o6tYF3QQ3lZshbSMhNlgwNAytRm9jFHTnpGHphELXxKbcqTBVWgWc+euosFkMD4scEFWZNwuK1mLL/k9TJb7DW1qPDawlcAsRD+k4M3BanWlnYPAiJCiHx5lev34qMH+JD3mmkNF9w1FXkLpYSOivO6SRwVaKYFNbx1yDuCBhxrsfkbG5nyDeCLBCSQr6A8DyZaZUKb9+eMFTtYqAPPi61l+WgcgYUifF/qrrU/ido/+X8dGlxH6U3u6T1YYsACY+gpz1AKSK3a7/+a8XmODEHcpvoxKkGdiHSp0hXgy+/TNJI3N4kv7klITUKx6BXK1wHvYvaolESGHF0LL8IhU5wS5dgLyr8Q6foiOHsgLtQIKtzrdwdfNeV0HFDAcb+sBx9ejH8ldO 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 Sun, Nov 24, 2024 at 05:45:18AM -0800, syzbot wrote: > > __fput+0x5ba/0xa50 fs/file_table.c:458 > task_work_run+0x24f/0x310 kernel/task_work.c:239 > resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] > exit_to_user_mode_loop kernel/entry/common.c:114 [inline] > exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline] > __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] > syscall_exit_to_user_mode+0x13f/0x340 kernel/entry/common.c:218 > do_syscall_64+0x100/0x230 arch/x86/entry/common.c:89 > entry_SYSCALL_64_after_hwframe+0x77/0x7f This is: VM_BUG_ON_FOLIO(folio_test_writeback(folio), folio); ie we've called __folio_start_writeback() on a folio which is already under writeback. Higher up in the trace, we have the useful information: page: refcount:6 mapcount:0 mapping:ffff888077139710 index:0x3 pfn:0x72ae5 memcg:ffff888140adc000 aops:btrfs_aops ino:105 dentry name(?):"file2" flags: 0xfff000000040ab(locked|waiters|uptodate|lru|private|writeback|node=0|zone=1|lastcpupid=0x7ff) raw: 00fff000000040ab ffffea0001c8f408 ffffea0000939708 ffff888077139710 raw: 0000000000000003 0000000000000001 00000006ffffffff ffff888140adc000 page dumped because: VM_BUG_ON_FOLIO(folio_test_writeback(folio)) page_owner tracks the page as allocated The interesting part of the page_owner stacktrace is: filemap_alloc_folio_noprof+0xdf/0x500 __filemap_get_folio+0x446/0xbd0 prepare_one_folio+0xb6/0xa20 btrfs_buffered_write+0x6bd/0x1150 btrfs_direct_write+0x52d/0xa30 btrfs_do_write_iter+0x2a0/0x760 do_iter_readv_writev+0x600/0x880 vfs_writev+0x376/0xba0 (ie not very interesting) > Workqueue: btrfs-delalloc btrfs_work_helper > RIP: 0010:__folio_start_writeback+0xc06/0x1050 mm/page-writeback.c:3119 > Call Trace: > > process_one_folio fs/btrfs/extent_io.c:187 [inline] > __process_folios_contig+0x31c/0x540 fs/btrfs/extent_io.c:216 > submit_one_async_extent fs/btrfs/inode.c:1229 [inline] > submit_compressed_extents+0xdb3/0x16e0 fs/btrfs/inode.c:1632 > run_ordered_work fs/btrfs/async-thread.c:245 [inline] > btrfs_work_helper+0x56b/0xc50 fs/btrfs/async-thread.c:324 > process_one_work kernel/workqueue.c:3229 [inline] This looks like a race? process_one_folio() calls btrfs_folio_clamp_set_writeback calls btrfs_subpage_set_writeback: spin_lock_irqsave(&subpage->lock, flags); bitmap_set(subpage->bitmaps, start_bit, len >> fs_info->sectorsize_bits) ; if (!folio_test_writeback(folio)) folio_start_writeback(folio); spin_unlock_irqrestore(&subpage->lock, flags); so somebody else set writeback after we tested for writeback here. One thing that comes to mind is that _usually_ we take folio_lock() first, then start writeback, then call folio_unlock() and btrfs isn't doing that here (afaict). Maybe that's not the source of the bug? If it is, should we have a VM_BUG_ON_FOLIO(!folio_test_locked(folio), folio) in __folio_start_writeback()? Or is there somewhere that can't lock the folio before starting writeback?