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 0D0D8C28B20 for ; Fri, 28 Mar 2025 19:09:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 08C98280161; Fri, 28 Mar 2025 15:09:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 014D5280048; Fri, 28 Mar 2025 15:09:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DD111280161; Fri, 28 Mar 2025 15:09:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 24FF9280048 for ; Fri, 28 Mar 2025 15:09:08 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 81CCB120726 for ; Fri, 28 Mar 2025 19:09:09 +0000 (UTC) X-FDA: 83271897618.30.07A5A0B Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf17.hostedemail.com (Postfix) with ESMTP id B9AE04000D for ; Fri, 28 Mar 2025 19:09:07 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=dB3UELKK; spf=pass (imf17.hostedemail.com: domain of mcgrof@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=mcgrof@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1743188947; 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=Odl1FHTg/am9Lj9hua1/AvHp3EQjFRim8jP03gJevtE=; b=Rs3OFTAKptZJiK0z8AGB7NAclKOo60L27NSnvzvGgW9H7F+wzrzVqUGaASS4mE4t9z/TMz uFer6O8fw91aFA+BYedHOkgBYkXKvucM6NUhH01kIU7EB6JyDeru1UZmkX6qRe98deRuBo W7bugjbxTWJMxioeZI5MZhUrSBwthXk= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=dB3UELKK; spf=pass (imf17.hostedemail.com: domain of mcgrof@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=mcgrof@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1743188947; a=rsa-sha256; cv=none; b=SQjsHZZ+yHy4P/JJyri4hsrXpfRjTZzgIMZxmZWsk3E9Kpm7EJwum/1oSNz3hWa864w0Q9 sO8FfuKfh4X1NletTw5arq5seNveUNEagET0u8IX/d+7uD7bGQ/lfy2kpHHP+WhAxviIIZ eOQDYprG25YJxPwV5GlCE7xq82irsh8= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 976E25C6847; Fri, 28 Mar 2025 19:06:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id ADBB8C4CEE4; Fri, 28 Mar 2025 19:09:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1743188946; bh=nbVAbadFhwirIIc7wDc9emhsG/6sME7ykQ1kn6t6U48=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=dB3UELKKWurwo5YB6MHwFg/UZUce61fmOuW0NiU9qFlFdtoNv0aOf8YfAgXZPl/VK LnRc6mubqtAjjwkdjUQPZWkbXjEWwyo9K6zW6LAA74Be8JbsB91M+5435jttZzFU+z 2bYAnSgTaLkzS616JBBRVmk7K2lKc5/LqQ0dQZNqJo0vxu9km++GxxMOwPXezFu5OR Gmued/cHagZgMmn2Wkv3ONd2KESeVcsywtzTS0eYb5Qb3EEdRv00wIk3buiNm7b6sF WhlFhMw/njMC/KKbBSmHRNF2dXZoi/kG6jExwozgFY7EI9kQkXZo/PROy5tjNwBU2I mMPyKH3bTT/BQ== Date: Fri, 28 Mar 2025 12:09:04 -0700 From: Luis Chamberlain To: Jan Kara , Kefeng Wang , Sebastian Andrzej Siewior , David Bueso , Tso Ted , Ritesh Harjani Cc: Johannes Weiner , Oliver Sang , Matthew Wilcox , David Hildenbrand , Alistair Popple , linux-mm@kvack.org, Christian Brauner , Hannes Reinecke , oe-lkp@lists.linux.dev, lkp@intel.com, John Garry , linux-block@vger.kernel.org, ltp@lists.linux.it, Pankaj Raghav , Daniel Gomez , Dave Chinner , gost.dev@samsung.com, mcgrof@kernel.org Subject: Re: [linux-next:master] [block/bdev] 3c20917120: BUG:sleeping_function_called_from_invalid_context_at_mm/util.c Message-ID: References: <20250322231440.GA1894930@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: B9AE04000D X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: mbw93cfojp8biro4i6etnstgtxono8sm X-HE-Tag: 1743188947-318371 X-HE-Meta: U2FsdGVkX19bZXnwMRSpcFDi4V2TtI0d7Iog5tDO9QBSSBlGXy/DHAx5tzHKhdaLrld/EhohjETqVL6xp96IJ/Uq1jbciY6KSkmDw6YQhVk5nY+oV6vkb6rMNCNIb0tmufNIpuASq2DdZ6aVIL/LAHvF+cu1vvuLKyKy8rhLAviTBZDYf6WxDJcHvdtAMk8w9gIq/eIH8SFyjbkduRnAbw1maxDBFBdBoZkwu8REvCb3/Vd15k0KOB84CV/0yn7VYg7jMSJ8Cuh40DrZ6NHE/J0gOJHs9MqCwtMEH4hGc9/1riZWVlKXn15/pKjnKlQXxhg6ooMCAs43JXyJJciy2KHiMaRhywROht2wl4gP3uJUO7dv8g1E/O/vvqcLeXA0Ss6jHF54kKgypH5lFTOzbuK57Xo/LPjwVn7ZAY+Dbpr9TU77qLteGiXCE6iBaOz5t/w3oui+2Ir7OqYjhzpkYu7BdQPw0hR0IrOWswqkGD/7NbJfbczR5C8sWNcXulHpVaZDTxWAbjpnakmv51aquFXxQ1+SVVej1k0GvA4cSNjjeNSg4ajhOX9R4fcpdbR7f31DxxIafNDwAtIaynuUCdafDNWStKnhFNPotULsf/muu6AZdyRoTgp8dRsrdW2Juejvy0pI/94CiXV8sqIcSvoSg5Iyk9jZ1wAg6Pzd+2rMwrWnWRuz0EFPXY2j4vS+BxcvKa7AbFvp0HWZVoccaUK6SNuxT731NK3f1grrSdkjLbp5m3hgOkJeHOT8uJloBg2+9ThHnZI6YuqCgyOmUfy5Ojw2hmzj7N1KCTzdgaZrDkGYA8ZA2o2eVEK0NErBpeJMerKP75MNlXO6SWfftJzjdw4tq/8N2dytpgsxNvVAeRFDqQk6SGclIw6pvii2OqeX11OwOU7Kc+Uzp6/scOJ4hW4eE3hdGxTRz9KukNSW6buD682aB5mBytvGf5Xv6OafzshMDV566wOmbVx G7lNEGjF bT2i0aYypNFdaQCFKLe+bBCEVv63yhM45vzbM6mEQtndMEoSkvnvUoHBbhN66vCF+uiuUuAbzEkZ4vEhahvOrIlJRa7hUA1LD/9glkyGu+TWricxv9Fqurrwl3RwVK2W/jIhh/aKVhtD1hKLHrkdTWBFssIBsTCffP6r0Y2ri3pSVrDcdTkBTE3Cae+4uNy35GRbAqD4aI7+gos+daNiP0nKUV8LpmYWfuCkc5PEW+1DPii594epSwzAq6AkxSU/K0LoTrijcU1Qg4uR4GUzf+SFbmb2cB/1A1IILSX3Spe8AYqwNwT3aVCIBNxHXIgouJMPJFFOj/r+w7n6iRc1qsY+oJ7woJbxCTib/wVEdUfonT1w= 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, Mar 28, 2025 at 02:48:00AM -0700, Luis Chamberlain wrote: > On Thu, Mar 27, 2025 at 09:21:30PM -0700, Luis Chamberlain wrote: > > Would the extra ref check added via commit 060913999d7a9e50 ("mm: > > migrate: support poisoned recover from migrate folio") make the removal > > of the spin lock safe now given all the buffers are locked from the > > folio? This survives some basic sanity checks on my end with > > generic/750 against ext4 and also filling a drive at the same time with > > fio. I have a feeling is we are not sure, do we have a reproducer for > > the issue reported through ebdf4de5642fb6 ("mm: migrate: fix reference > > check race between __find_get_block() and migration")? I suspect the > > answer is no. Sebastian, David, is there a reason CONFIG_DEBUG_ATOMIC_SLEEP=y won't trigger a atomic sleeping context warning when cond_resched() is used? Syzbot and 0-day had ways to reproduce it a kernel warning under these conditions, but this config didn't, and require dan explicit might_sleep() CONFIG_PREEMPT_BUILD=y CONFIG_ARCH_HAS_PREEMPT_LAZY=y # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y # CONFIG_PREEMPT_LAZY is not set # CONFIG_PREEMPT_RT is not set CONFIG_PREEMPT_COUNT=y CONFIG_PREEMPTION=y CONFIG_PREEMPT_DYNAMIC=y CONFIG_PREEMPT_RCU=y CONFIG_HAVE_PREEMPT_DYNAMIC=y CONFIG_HAVE_PREEMPT_DYNAMIC_CALL=y CONFIG_PREEMPT_NOTIFIERS=y CONFIG_DEBUG_PREEMPT=y CONFIG_PREEMPTIRQ_TRACEPOINTS=y # CONFIG_PREEMPT_TRACER is not set # CONFIG_PREEMPTIRQ_DELAY_TEST is not set Are there some preemption configs under which cond_resched() won't trigger a kernel splat where expected so the only thing I can think of is perhaps some preempt configs don't implicate a sleep? If true, instead of adding might_sleep() to one piece of code (in this case foio_mc_copy()) I wonder if instead just adding it to cond_resched() may be useful. Note that the issue in question wouldn't trigger at all with ext4, that some reports suggset it happened with btrfs (0-day) with LTP, or another test from syzbot was just coincidence on any filesystem, the only way to reproduce this really was by triggering compaction with the block device cache and hitting compaction as we're now enabling large folios with the block device cache, and we've narrowed that down to a simple reproducer of running dd if=/dev/zero of=/dev/vde bs=1024M count=1024. and by adding the might_sleep() on folio_mc_copy() Then as for the issue we're analzying, now that I get back home I think its important to highlight then that generic/750 seems likely able to reproduce the original issue reported by commit ebdf4de5642fb6 ("mm: migrate: fix reference check race between __find_get_block() and migration") and that it takes about 3 hours to reproduce, which requires reverting that commit which added the spin lock: Mar 28 03:36:37 extra-ext4-4k unknown: run fstests generic/750 at 2025-03-28 03:36:37 <-- snip --> Mar 28 05:57:09 extra-ext4-4k kernel: EXT4-fs error (device loop5): ext4_get_first_dir_block:3538: inode #5174: comm fsstress: directory missing '.' Jan, can you confirm if the symptoms match the original report? It would be good for us to see if running the newly proposed generic/764 I am proposing [0] can reproduce that corruption faster than 3 hours. If we have a reproducer we can work on evaluating a fix for both the older ext4 issue reported by commit ebdf4de5642fb6 and also remove the spin lock from page migration to support large folios. And lastly, can __find_get_block() avoid running in case of page migration? Do we have semantics from a filesystem perspective to prevent work in filesystems going on when page migration on a folio is happening in atomic context? If not, do we need it? [0] https://lore.kernel.org/all/20250326185101.2237319-1-mcgrof@kernel.org/T/#u Luis