From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B017820E71F; Tue, 18 Mar 2025 14:37:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742308668; cv=none; b=bnMLoEUA92jXxQ5LamO6E+3/xpHim37Ln9VJ9GbIRFfE3VmJeApXkTbuHEBeqNpgoR8aIMnB/6I+3bdEtlrDtrMBsqlpZEndcWLFdMwA88/9m6LOyMZsM5wCnxNw8jIXexhUuc8Q86PZqQFAu7OwgTjJvVqfNmQDeacWP6B4fnM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742308668; c=relaxed/simple; bh=S+SzAoV4VkJbQdrV5rI2W5YoxVeT10+1jkVRW/tgTNo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=qD4Yry29eUt9gqCqh9jXWbhBKbMAHW+swCNHiU++FcYtvsg0ho0tgGpMWLhq1dBSlea+9TezJ5QegYowUDuVI9VJPioi6ys3CGCw0GvrSnmQ5jJi/aB7HdBxInlMPE551ZXXPyqemwBmbd+2ruFzTtnEu6WJOwycxIMVbPwFrqM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=dihRr+6G; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="dihRr+6G" 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=krQ2w5oa/13hMp5s6oxgij/ARPZRgCl2Yz1Oc/B1BiM=; b=dihRr+6GFa0fYkK/zEqisXpphV w20Af9RuL7TboUER/FV/IdfJaZ8Uj32O0DPAyNTbB4t739KOQ/+19zOR8+4VGmdtcet6MD5QimEFd JSDK8NR44hOStMM/yG9EkSHFYcDnLx+9fIVLXRhDE6koD5km4iuWm+KfrO62Sl3Rh06exJHle/8UM jF+Y5e9bQsf5mhZRe7dBLfVzxvMWefg2wmljqR8u/SKW4zSqtMUOBFRdKbXVksD8rEl/K4e4Xppjg dPjgsG8Hk8CI6TLB08JsS/MuCq83CrPOlVTrubGWhRnJdVasRZrK/qu1jw3CYee+YesBmdCobz79K fPDqTaYw==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1tuY4Q-0000000FLpE-0DTl; Tue, 18 Mar 2025 14:37:30 +0000 Date: Tue, 18 Mar 2025 14:37:29 +0000 From: Matthew Wilcox To: Luis Chamberlain , Jan Kara Cc: 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 Subject: Re: [linux-next:master] [block/bdev] 3c20917120: BUG:sleeping_function_called_from_invalid_context_at_mm/util.c Message-ID: References: <202503101536.27099c77-lkp@intel.com> <20250311-testphasen-behelfen-09b950bbecbf@brauner> Precedence: bulk X-Mailing-List: linux-block@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Tue, Mar 18, 2025 at 01:15:33AM -0700, Luis Chamberlain wrote: > I also can't see how the patch ("("block/bdev: enable large folio > support for large logical block sizes") would trigger this. Easy enough to see by checking the backtrace. > [ 218.454517][ T51] folio_mc_copy+0xca/0x1f0 > [ 218.454532][ T51] __migrate_folio+0x11a/0x2d0 > [ 218.454541][ T51] __buffer_migrate_folio+0x558/0x660 folio_mc_copy() calls cond_resched() for large folios only. __buffer_migrate_folio() calls spin_lock(&mapping->i_private_lock) so for folios without buffer heads attached, we never take the spinlock, and for small folios we never call cond_resched(). It's only the compaction path for large folios with buffer_heads attached that calls cond_resched() while holding a spinlock. Jan was the one who extended the spinlock to be held over the copy in ebdf4de5642f so adding him for thoughts. 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 picard.linux.it (picard.linux.it [213.254.12.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 26BCFC282EC for ; Tue, 18 Mar 2025 14:38:02 +0000 (UTC) Received: from picard.linux.it (localhost [IPv6:::1]) by picard.linux.it (Postfix) with ESMTP id 1F57C3CAB0D for ; Tue, 18 Mar 2025 15:38:00 +0100 (CET) Received: from in-4.smtp.seeweb.it (in-4.smtp.seeweb.it [IPv6:2001:4b78:1:20::4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1)) (No client certificate requested) by picard.linux.it (Postfix) with ESMTPS id 6C1583CAB0D for ; Tue, 18 Mar 2025 15:37:43 +0100 (CET) Authentication-Results: in-4.smtp.seeweb.it; spf=none (no SPF record) smtp.mailfrom=infradead.org (client-ip=2001:8b0:10b:1236::1; helo=casper.infradead.org; envelope-from=willy@infradead.org; receiver=lists.linux.it) Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by in-4.smtp.seeweb.it (Postfix) with ESMTPS id 59FC21000A46 for ; Tue, 18 Mar 2025 15:37:42 +0100 (CET) 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=krQ2w5oa/13hMp5s6oxgij/ARPZRgCl2Yz1Oc/B1BiM=; b=dihRr+6GFa0fYkK/zEqisXpphV w20Af9RuL7TboUER/FV/IdfJaZ8Uj32O0DPAyNTbB4t739KOQ/+19zOR8+4VGmdtcet6MD5QimEFd JSDK8NR44hOStMM/yG9EkSHFYcDnLx+9fIVLXRhDE6koD5km4iuWm+KfrO62Sl3Rh06exJHle/8UM jF+Y5e9bQsf5mhZRe7dBLfVzxvMWefg2wmljqR8u/SKW4zSqtMUOBFRdKbXVksD8rEl/K4e4Xppjg dPjgsG8Hk8CI6TLB08JsS/MuCq83CrPOlVTrubGWhRnJdVasRZrK/qu1jw3CYee+YesBmdCobz79K fPDqTaYw==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1tuY4Q-0000000FLpE-0DTl; Tue, 18 Mar 2025 14:37:30 +0000 Date: Tue, 18 Mar 2025 14:37:29 +0000 From: Matthew Wilcox To: Luis Chamberlain , Jan Kara Message-ID: References: <202503101536.27099c77-lkp@intel.com> <20250311-testphasen-behelfen-09b950bbecbf@brauner> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Virus-Scanned: clamav-milter 1.0.3 at in-4.smtp.seeweb.it X-Virus-Status: Clean Subject: Re: [LTP] [linux-next:master] [block/bdev] 3c20917120: BUG:sleeping_function_called_from_invalid_context_at_mm/util.c X-BeenThere: ltp@lists.linux.it X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux Test Project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Pankaj Raghav , Daniel Gomez , Christian Brauner , lkp@intel.com, David Hildenbrand , Alistair Popple , linux-block@vger.kernel.org, linux-mm@kvack.org, Oliver Sang , Hannes Reinecke , John Garry , oe-lkp@lists.linux.dev, ltp@lists.linux.it Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ltp-bounces+ltp=archiver.kernel.org@lists.linux.it Sender: "ltp" On Tue, Mar 18, 2025 at 01:15:33AM -0700, Luis Chamberlain wrote: > I also can't see how the patch ("("block/bdev: enable large folio > support for large logical block sizes") would trigger this. Easy enough to see by checking the backtrace. > [ 218.454517][ T51] folio_mc_copy+0xca/0x1f0 > [ 218.454532][ T51] __migrate_folio+0x11a/0x2d0 > [ 218.454541][ T51] __buffer_migrate_folio+0x558/0x660 folio_mc_copy() calls cond_resched() for large folios only. __buffer_migrate_folio() calls spin_lock(&mapping->i_private_lock) so for folios without buffer heads attached, we never take the spinlock, and for small folios we never call cond_resched(). It's only the compaction path for large folios with buffer_heads attached that calls cond_resched() while holding a spinlock. Jan was the one who extended the spinlock to be held over the copy in ebdf4de5642f so adding him for thoughts. -- Mailing list info: https://lists.linux.it/listinfo/ltp