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 E2C88C3DA64 for ; Sun, 28 Jul 2024 19:50:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5320C6B0085; Sun, 28 Jul 2024 15:50:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4E23B6B0088; Sun, 28 Jul 2024 15:50:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3D0A16B0089; Sun, 28 Jul 2024 15:50:11 -0400 (EDT) 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 1F33D6B0085 for ; Sun, 28 Jul 2024 15:50:11 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 7EAC71401D9 for ; Sun, 28 Jul 2024 19:50:10 +0000 (UTC) X-FDA: 82390202580.19.8712429 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf26.hostedemail.com (Postfix) with ESMTP id A310E140015 for ; Sun, 28 Jul 2024 19:50:08 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=zvDWUXZo; spf=pass (imf26.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722196182; a=rsa-sha256; cv=none; b=2rh7hXPmevBiaa7ZMwoP/TbPd6JfVLt7d7ByQ6KE6ecnbrNV5p3INFojWyS4SNx759NDeT bfAe/BRIAvitjqFCVD2n3s5KeIzD/L0roa6A0ipjuwzF7eBRBx4bd8R4k8S6bx8s/eFCpX mZ3XDSRnS4PD6xS5WEUdJXe9wGVimqA= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=zvDWUXZo; spf=pass (imf26.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722196182; 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=52QMxU/ZhkQ079JwJOech8aH0/6FQ6u3+6MvAnMp91w=; b=QK+w6yajCAwTAT/zeuxwM8vah6NxOvKZgoObrk3VzWZ4ZFiA8EBUbzIQWQ1TFkhm8Y+jYn xsXqfJnMenlt4t5GDtde+yCzbOTWqFfY3K2+9GK6+1unmRZSUDhBJ5Re/dBVtfCZYQgQn8 TwNmT2Zo+nb3IKZZyecs7hPF9eEl3jI= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 3F646611B9; Sun, 28 Jul 2024 19:50:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8F893C116B1; Sun, 28 Jul 2024 19:50:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1722196206; bh=3zYYk2gZpRrTYvS8E7E1kX6+mmTOOnlrqkv4ofQ+hmY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=zvDWUXZo9JIljZUWqLj1FDg0RthuRBkQDLcGSeF+2b+tOBCclBdQ4vepOFB4hUGVp pMUxkO//FpK+gZtK12U6VhsiIdBl23vM92k2aQHKtwf2a/MJ3+3hlksAZL5pMOF89j 14U90GfH/22azoE+tMpT72wU6DaWUjYWgEoeDSEw= Date: Sun, 28 Jul 2024 12:50:05 -0700 From: Andrew Morton To: Gao Xiang Cc: Huang Ying , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm/migrate: fix deadlock in migrate_pages_batch() on large folios Message-Id: <20240728125005.c1171fa2d1beb6c1fe867d48@linux-foundation.org> In-Reply-To: <20240728154913.4023977-1-hsiangkao@linux.alibaba.com> References: <20240728154913.4023977-1-hsiangkao@linux.alibaba.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Stat-Signature: bku3s763czamepdy659py3nzwe6kzzr8 X-Rspamd-Queue-Id: A310E140015 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1722196208-367589 X-HE-Meta: U2FsdGVkX19JS9F2pOSTEuRLQX23q0fpW7ncjXMIS4+Cw0+BkgPEzLCLbma/ZE8GdOpSVQpoE1QCW2ZobeyPsOKF4qa1vR3KsqOAINccMVGVkjmAtWh9FtvMQaUU1VFuT7GWue1YtxoUM0U3oqu6hylQGhB1nCkIbP5Ald3eVOVXHztijjBd13RduaMTrIaooFpV2p+S3YpbaQWQ0eiRVyBzjbnwoeNOc0IXXYgj9kuVK7uwTz7AB1MQE1C2A+m4wyfYRIRTYgvtbRgPU19GgXnOJQxIn/UCNr9nRjgKh0O0LVrTIjmDL96SqJBablWG35YT7nOTYmSd23rScYO9f8DHrRbFV65o5eB6T0dIWsO4AAMmBVBTBo5npfBgEekTpys5VctP9/a1wulbGMRccDLGnin9GwSc7AIVDAx5A5m9BlooyiKxySrEvO7u9qkJPtF/VdTUcXd4jklFWONzW/UYvrpSvG1ka29Lw6IQwgOm0U1OJMrnfqAnBVUpfHomKNf0QptovrJMpY5ysmEFzELsw83Zm+41uyNciUUG4QsjD6J1RgwJQSoE4SRFlJMskQlpMAmx3XAdKSwX0BP6PbTNQ9BegvGcL8B3DH+gSXTygKgsONVjKSsN82PRjKvUo0UTqYqmE9N7UvSAuPcGbh1bf+L8xmjd3gLBFMhLo/GpV2EC3TB0XJcgYL1KT9E/0480j7eC9Yc46J9ANmzsAf/b2Y1583jbMj0H07NGJ4vDO91tCJjHxFZ2cZgs6lmtocyzSfc6LWY0u5A80VthIH2qjOYwX6dYjU/aHNyUP7bqUoq0GCF4kQIXmW7Y+BoOrBB7epVENxkY8HzmkI5gEaFd5hxuvcSPcE6H+dxMAtEP9iLTWlw0KVQtRiEB5RgVuPbOyjh0kvJ5iemhu2w2/3sHXqVzxclfadQWye3swlXdQkOe+nLFc6aQLWvbqaqpH9GQ5dflcJ2R0k8LUSV BbXK1ZFk DxbvaI3pI2Olko4FziPrYQcivz1nXHOikGzsQeLPnDF4vUoUiswh0zV/8hyrC7A2/SSyg6GEoDHCNFhTVF8EeFmdYStlV33jSwzezWvwn2MURplqENsJg7tFudp1epYtqWZbPAdUsBVED41hUQVU7B/6nxs6vW9FZVr16ZKJQIB+2MKcTT+qT2iONc5uU00/SB5RURdZVBD3dkOe7hp1a4gKKuvDa3lpxxQCpftJACHLTI+fCE1f1yRS2j7fBngXkqmpE/oxdSuRG0RwwkDynwYjOhACeIT+2ovuDVWds4mDTUYEJxTooG1Y+uGJJYdrra5V9zWNIpCFyKEZWIpV+2SYJhsSNv56c1Ted 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, 28 Jul 2024 23:49:13 +0800 Gao Xiang wrote: > Currently, migrate_pages_batch() can lock multiple locked folios > with an arbitrary order. Although folio_trylock() is used to avoid > deadlock as commit 2ef7dbb26990 ("migrate_pages: try migrate in batch > asynchronously firstly") mentioned, it seems try_split_folio() is > still missing. Am I correct in believing that folio_lock() doesn't have lockdep coverage? > It was found by compaction stress test when I explicitly enable EROFS > compressed files to use large folios, which case I cannot reproduce with > the same workload if large folio support is off (current mainline). > Typically, filesystem reads (with locked file-backed folios) could use > another bdev/meta inode to load some other I/Os (e.g. inode extent > metadata or caching compressed data), so the locking order will be: Which kernels need fixing. Do we expect that any code paths in 6.10 or earlier are vulnerable to this?