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 8E67BC3600C for ; Thu, 3 Apr 2025 12:35:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 84451280005; Thu, 3 Apr 2025 08:35:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7CD71280001; Thu, 3 Apr 2025 08:35:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 64556280005; Thu, 3 Apr 2025 08:35:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 458F6280001 for ; Thu, 3 Apr 2025 08:35:56 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 2F9C5C0604 for ; Thu, 3 Apr 2025 12:35:57 +0000 (UTC) X-FDA: 83292679554.12.59265E3 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf25.hostedemail.com (Postfix) with ESMTP id 1FDDCA000A for ; Thu, 3 Apr 2025 12:35:53 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=K6kQ3y70; spf=none (imf25.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1743683754; 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=XDDalKK9puNdBAK9PyYynmv0MinuUp52rgxCW3hxBWc=; b=bEn81zVLg7FVVnGtCVnnvJWll307fwJE8aEpehzP3WUEyzaLhwILNsOioRZtJ3kfq2yvjG LA8bgovWnor0PQVhgHL5q5PHV6OJJR4WUr1vTNl47XLEVZfIbU0WtIQW3vr4KkMg1Mxm+L DR3alnlT+isi5x0zTKNyvP/eLG5ybQ0= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=K6kQ3y70; spf=none (imf25.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1743683754; a=rsa-sha256; cv=none; b=kDK1PayXukHfzTI7eMpzPhjhZkVWS9xQuddIEMOxg2JjRxcm0E6y7B6Gdb5R/ydUajRR+p hW2CCk452bZjVDQjHfchYLuabM4osN2akqIA1VAHyvISXLYVbFxEUCrUdkFLqLOuiIXNVW IZ5PPm4Wg0YfUjgd+8WhefqiQ8PY8DY= 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=XDDalKK9puNdBAK9PyYynmv0MinuUp52rgxCW3hxBWc=; b=K6kQ3y70lA/NdDae9MJcVXv6Yu NLre97MUDStqPnJkk2EoG4BdybojZBDjdtjyFeobvfr1Fu7DgAu/01uZU4c/ax9MHpk3RfJIHQAof hEdndTL22bk92VKiovyMBBDanZVylU0nSM6H2riE36ki3wofTnw7fo7CsI8j5RJxqNaVr3IaFK3w8 zj3F7mmfAInrZfb+GUEIq1beASnQqzUT4kVWkG90klr0prNFXE6d4P8oFfpzvtk3AjauH77rU2iVO Xie3ifj30OL72dg6JSz6PNN2SrB5NTYOvFrOQBrehq+3E+nxdPgKdbB1i2aeKVrXoqdj98cUhkDeX 4S3xwYcQ==; Received: from willy by casper.infradead.org with local (Exim 4.98.1 #2 (Red Hat Linux)) id 1u0JnQ-0000000CksR-3LrO; Thu, 03 Apr 2025 12:35:49 +0000 Date: Thu, 3 Apr 2025 13:35:48 +0100 From: Matthew Wilcox To: Qu Wenruo Cc: Linux Memory Management List , "linux-fsdevel@vger.kernel.org" , linux-btrfs , vivek.kasireddy@intel.com, Andrew Morton Subject: Re: Large folios and filemap_get_folios_contig() Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 1FDDCA000A X-Stat-Signature: wcqzfdj7hq5d7jpcum7wqhmxfrewkkui X-HE-Tag: 1743683753-733522 X-HE-Meta: U2FsdGVkX18LIlSdlY7Cm47yuj3vCCxaH2SzS8/jVLCA+01L1LUnYwiOgnFtXFSFH4UqcQZGrD6xMoA5QqDjpWIbCOSjwkvA9BLfuXBTIiKuMqrBDel7jlEaVGzSyKChbd50YSjCj7geIffoQexqUZYx4Mu1SuJ1j9CXt9muQ5lAp0Ik6RZ/M/aYRwzXvYZExx11fJ8vcAOHSZdqYM5nhH+W2MyRb8FJavZnT3+4ZcHQEJOVnBsq2BiG8MknFGy73H9Q2fLVNhAhhNxcUoBfh1YNeKxavVnPWSC2rjqv9xCrtaMFqmXzlpwz6wlKKD/Net+LY4gW1VwtfCLheI1Woa4M84DtvfgXQbQu5RN8cKSACnL3caxll7kU6qqdRCGvNBCI4VRzZFIW9HoQOeWE+6GoyXkaHyDCxxTH9cxCf8PiYpUMUWsxVI4yXHQ7ef2a+Cjb+F0BbUJrrEeWHZe7woRwJr+gFqwCDSXxz/xnsAD68I1yLNEuPpmW4g550NGE3qLjCcw3jbCWu5IHZ3RkJOciPtp0v2s67uDg36hHQ5qce8xSFUx8Fzj5tr7qEwaoLoX4T/CTMmEGfElpvaAGy203cad11Vf7n+XOwhS/KuJ02b9MeVNgdrrAFYExonV51Mv11s28LsVLxFJnF6owj1kFT3qkUSeliEuyJyPyfwM0f88GhXnyj9PVfd/s136sBwEQpcaR9Uz/IshvN2D5jSgTPGjR0LePFiTpKYWo45MRugUVa+kwkWpkJgZGDw518WmWw4M7mDKoTOTFF/sMvMme/tODesMXU66oVVj10fFPnjlK5AMrnD/yws9NWBUA929Y46pe1Y/iodR9J8jlsmqbxe9gSsd4oRC50hXFL85jQVJdhloibnw5Dm982oUiF15BjhrrpqdNOnVn/iWgWxX7mfn6gGnXrExdymFjTceRxaDTzmKlqWm4THmEqO3TcRSuFVH9k0lG8ww/jH4 4q4avaew CekxCkbLFMMYn1EHUAqoFpAS7UvMpXyVaRpRDz+Wa9ueaP7Dl9piJ3XLhEatglaU/ah+QDJEM6kxw6MUACw46E9+XaKDjF3V/DexCf4K3/HAi/8nlsAXJrwRF660M3SDm7cKOif6HT10gSkOVeXwUgMKgLb5OW8IAgaJpjvmaRDcH2udN/XeYdL1UIqM0LAMpBZQZZ8oY0uLGR4u0u95DQyoyV+OhY3MV8FVcWztDeaMMw571Qz0D2NP33QJio/BzSWX38zNAjCwcFWE1Gx0DEXX9AeRb/mgYAt7nch4B1M23FHI4s6q5p6ifiPDEhz6RzhLx 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 Thu, Apr 03, 2025 at 08:06:53PM +1030, Qu Wenruo wrote: > Recently I hit a bug when developing the large folios support for btrfs. > > That we call filemap_get_folios_contig(), then lock each returned folio. > (We also have a case where we unlock each returned folio) > > However since a large folio can be returned several times in the batch, > this obviously makes a deadlock, as btrfs is trying to lock the same > folio more than once. Sorry, what? A large folio should only be returned once. xas_next() moves to the next folio. How is it possible that filemap_get_folios_contig() returns the same folio more than once? > Then I looked into the caller of filemap_get_folios_contig() inside > mm/gup, and it indeed does the correct skip. ... that code looks wrong to me.