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 0F6FAC36010 for ; Tue, 8 Apr 2025 19:13:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AE34928001D; Tue, 8 Apr 2025 15:13:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A6A37280020; Tue, 8 Apr 2025 15:13:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 93B6D28001D; Tue, 8 Apr 2025 15:13:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 74CF328001D for ; Tue, 8 Apr 2025 15:13:09 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id A91DBBB537 for ; Tue, 8 Apr 2025 19:13:10 +0000 (UTC) X-FDA: 83311824540.21.6FCB93D Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by imf04.hostedemail.com (Postfix) with ESMTP id 2FD724000A for ; Tue, 8 Apr 2025 19:13:09 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ghNAaHlG; spf=pass (imf04.hostedemail.com: domain of mcgrof@kernel.org designates 172.105.4.254 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=1744139589; 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=tAi7R3amSpw0zVgHznHGv1wuOTfLPq0rymrzo3fv4ng=; b=rJu+x7ZHFaccLqW/FH0Iz8ekvTUp2GXe2sc4sMuC7gAPKmx6coIbNMOyJRftu+HUwdbYNU PBTqo69Zw3fhb3l/F3L55x22XKc+lwgt/g5LIMItlm0kTNzgpNB43QFbpKvgKRZsMOXGo5 HnOQxHpCLSJS7sORjaQiXDiEt9EPLn4= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ghNAaHlG; spf=pass (imf04.hostedemail.com: domain of mcgrof@kernel.org designates 172.105.4.254 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=1744139589; a=rsa-sha256; cv=none; b=U/FVMQPcRvxc9RxJ/CBKI34i9f5I2ONclNdhnr+NrGkNjlrG/rWelDRtIIOKCyNZntELCR JBkGkBRYmtpZRyrv+iN9S8sDnSIENRVqWShK8OUpszDZENKKvST9nTC7Dtc92pd7h7/v0q SYRcp2vY9kForSTBQuHCexVRSNM/5XU= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 5ADF461166; Tue, 8 Apr 2025 19:12:59 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 78B25C4CEE5; Tue, 8 Apr 2025 19:13:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1744139588; bh=epQh/gaUaDDW5jnc7/qOqV5jwYTP+Jz/mj3glQvJiQg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ghNAaHlG7bqqdTxG3szwAUndPLZmKSaKqmZSGG4kJL/NidXNlCj+Y1zKbb1AfYUZh u3l6Ml0jksUXqEqFqVVlIVrdweI9ZKdypmpH5OEuIqw74C2giSqyp8L1wZ3MDUfVu4 lPXocc1BiOdbt77c5T7nHbZ4ctkLeYmyZmhQ+1GIx93+91m7HQSr5vmSEJJMz6Tftr 7vzlMGvyrH3zlAQdsqgPCuYf97ErAmCjzFBVEtK5SYzpYTSzCfxIpNm+WdYf1Tl/E8 oennVE7UltJetxq322Q45lj2emq2/buAZozulh4s7ml32uOAqTV+Bj5p6KSo1dPjT3 ZWQEFmVjdTaXQ== Date: Tue, 8 Apr 2025 12:13:06 -0700 From: Luis Chamberlain To: Matthew Wilcox Cc: "Darrick J. Wong" , David Bueso , Jan Kara , Kefeng Wang , Tso Ted , Ritesh Harjani , Johannes Weiner , Oliver Sang , 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, linux-fsdevel Subject: Re: [linux-next:master] [block/bdev] 3c20917120: BUG:sleeping_function_called_from_invalid_context_at_mm/util.c Message-ID: References: <20250331074541.gK4N_A2Q@linutronix.de> <20250408164307.GK6266@frogsfrogsfrogs> <20250408174855.GI6307@frogsfrogsfrogs> <20250408180240.GM6266@frogsfrogsfrogs> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 2FD724000A X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: g95o7y7xuywbwh6bhj1b6aoms3s48j73 X-HE-Tag: 1744139589-619558 X-HE-Meta: U2FsdGVkX1+cgw2js1rCQ9ulPHMqF5m5f906K26eQySKB1tByUSHVaBwnP3dq/mPE+U18XCbyGUd/o+KI7MLoZ1Qrw8ZMkdhbCBeoCUPJQm5PHqhWiodfKvmJ8CeRZh82McCeAeResPhpvwForT0SzNKsYP8SXoMtp5oA3qXOjPNnpFw4kwjm0swtddjvSYCRD2kY5ggbdi40T8ZJWlToCOLq6qVteTupzHmdQz2jfOfInIsUl0+Y0izU9SqfDyi++cBcbtwc+IsK2uGL5hy1FSAu9z46gpcypNyp7xcYOi8tbPYotaUkxwhJNl7luu2AHnVoK/wIsq6kOAOIHH7rHFP8HQvHYTzgY9wlejSuGa00RzuC3zokoZgyYnLTAi78Y45g0ptpEuWGdUS+XkrthvzdKD8fjq4dycGjh4aE7tfuvA1Obw1X2Zvb6pNVIx+Cb2+cNFzqx+RYAocuGMiYHtdMrYWnnJhypb/CzeSDWvgkxCamfXGS5nCy2boAQ+NxiPPHNVRwAiFg4u4JbWtXRu/juvx1BgHnP/PKC9Er5wY8jpD6MDcWhRk/d4uc9GaEzX64U5tHBwc2QF66Eeo7Q4bZ0wuo1kGF9k4zC9m3bSQV5t82KXux/0vbH8yFU/41wlTpmK6LQtFydYfAffKPty1nJeCkAZlcO6iw8cScTHnDiCi/Q6M/pHqchwHii4LWMUoK4dR21/6mbNsheFJiwXorUSv3Tq8I5XGvkzwZA2oE8Ea1yAID8zh36pxL/VblrpFoqMjr7nO0nqkGC0j1LLaMVv166x2UjiSS2SIq0/VBJ2tG+0+M9h/ww5RPB68CdsiavvvUEoklFO5fCoS5qXZy3KFteXLrsn3PGmA9gr6kj7UgKsaoKQceafK3aE4UdQgRyrXw+kpEOVb5LVQNPW/uhJfMTpRNyua9SiKQoskGT47sTPGqeHzKB6oJPMrn4WhzGuWQQ+U/GwY8l0 Klspwpmi 3zIGQCLSHVsWXJG90y56VzKQAaCKKv8uqao7x 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 Tue, Apr 08, 2025 at 07:51:03PM +0100, Matthew Wilcox wrote: > On Tue, Apr 08, 2025 at 11:02:40AM -0700, Darrick J. Wong wrote: > > On Tue, Apr 08, 2025 at 06:51:14PM +0100, Matthew Wilcox wrote: > > > On Tue, Apr 08, 2025 at 10:48:55AM -0700, Darrick J. Wong wrote: > > > > On Tue, Apr 08, 2025 at 10:24:40AM -0700, Luis Chamberlain wrote: > > > > > On Tue, Apr 8, 2025 at 10:06 AM Luis Chamberlain wrote: > > > > > > Fun > > > > > > puzzle for the community is figuring out *why* oh why did a large folio > > > > > > end up being used on buffer-heads for your use case *without* an LBS > > > > > > device (logical block size) being present, as I assume you didn't have > > > > > > one, ie say a nvme or virtio block device with logical block size > > > > > > > PAGE_SIZE. The area in question would trigger on folio migration *only* > > > > > > if you are migrating large buffer-head folios. We only create those > > > > > > > > > > To be clear, large folios for buffer-heads. > > > > > > if > > > > > > you have an LBS device and are leveraging the block device cache or a > > > > > > filesystem with buffer-heads with LBS (they don't exist yet other than > > > > > > the block device cache). > > > > > > > > My guess is that udev or something tries to read the disk label in > > > > response to some uevent (mkfs, mount, unmount, etc), which creates a > > > > large folio because min_order > 0, and attaches a buffer head. There's > > > > a separate crash report that I'll cc you on. > > > > > > But you said: > > > > > > > the machine is arm64 with 64k basepages and 4k fsblock size: > > > > > > so that shouldn't be using large folios because you should have set the > > > order to 0. Right? Or did you mis-speak and use a 4K PAGE_SIZE kernel > > > with a 64k fsblocksize? > > > > This particular kernel warning is arm64 with 64k base pages and a 4k > > fsblock size, and my suspicion is that udev/libblkid are creating the > > buffer heads or something weird like that. > > > > On x64 with 4k base pages, xfs/032 creates a filesystem with 64k sector > > size and there's an actual kernel crash resulting from a udev worker: > > https://lore.kernel.org/linux-fsdevel/20250408175125.GL6266@frogsfrogsfrogs/T/#u > > > > So I didn't misspeak, I just have two problems. I actually have four > > problems, but the others are loop device behavior changes. > > Right, but this warning only triggers for large folios. So somehow > we've got a multi-page folio in the bdev's page cache. > > Ah. I see. > > block/bdev.c: mapping_set_folio_min_order(BD_INODE(bdev)->i_mapping, > > so we're telling the bdev that it can go up to MAX_PAGECACHE_ORDER. Ah yes silly me that would explain the large folios without LBS devices. > And then we call readahead, which will happily put order-2 folios > in the pagecache because of my bug that we've never bothered fixing. > > We should probably fix that now, but as a temporary measure if > you'd like to put: > > mapping_set_folio_order_range(BD_INODE(bdev)->i_mapping, min, min) > > instead of the mapping_set_folio_min_order(), that would make the bug > no longer appear for you. Agreed. Luis