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 990C6C64ED6 for ; Tue, 28 Feb 2023 05:59:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B433C6B0071; Tue, 28 Feb 2023 00:59:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AA66D6B0072; Tue, 28 Feb 2023 00:59:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 946FC6B0073; Tue, 28 Feb 2023 00:59:36 -0500 (EST) 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 82BEC6B0071 for ; Tue, 28 Feb 2023 00:59:36 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 4AD03121129 for ; Tue, 28 Feb 2023 05:59:36 +0000 (UTC) X-FDA: 80515648752.04.E50D2A1 Received: from mail-oi1-f174.google.com (mail-oi1-f174.google.com [209.85.167.174]) by imf10.hostedemail.com (Postfix) with ESMTP id 8C358C0005 for ; Tue, 28 Feb 2023 05:59:34 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=fKdLTBQm; spf=pass (imf10.hostedemail.com: domain of hughd@google.com designates 209.85.167.174 as permitted sender) smtp.mailfrom=hughd@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677563974; 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=jLwLNTb6WWaSOQmgH+fKmq+ah1/mTz0fYUzaz0JWEhI=; b=pdEImR2ApkcCz+117iUIbA6JePxAzrqktnqMVAL0B/G37dLc81eFzHiTjY2tPJ9AfzVWUh omMjVtYJ1GfHrU/+yvMv3K27OgUtV2OAcXO63E+GT5ErWT2np/v9P3NaonWOAtt1nFvXzr LTKS1AvVaEerA2OLde6fWRrPYMrGHC4= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=fKdLTBQm; spf=pass (imf10.hostedemail.com: domain of hughd@google.com designates 209.85.167.174 as permitted sender) smtp.mailfrom=hughd@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677563974; a=rsa-sha256; cv=none; b=WV8U+sJJJfRrJ5IIIL+JHSJbCBXSdoXryoCLhf2qHXYhLOzW92oew5zeNkrQ2dhKxDTS89 B860fUQfLu5aN9gInGe3wS9jBTSgwh3caydJ6n6STN9oiBq2RgT9iliqOaVbenipbRFH5L UNN52NgwzRrTzecfgUV6SF4vOmw76Wc= Received: by mail-oi1-f174.google.com with SMTP id t22so7122475oiw.12 for ; Mon, 27 Feb 2023 21:59:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1677563973; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=jLwLNTb6WWaSOQmgH+fKmq+ah1/mTz0fYUzaz0JWEhI=; b=fKdLTBQmsXWF4hi32F0onYmpDRUFHMArs1+yBQnwz8Y63NyqIbZJZgk+GtqFAcNR/U oO8u83YPQnZv/keE9/fjtR6oZIDlsmJ3T2U6f1jBSNpM+ZVH61YmVQRysPUZ2dhLBgqi EXjMDWIZbI+tIfSF62VIBU3pMkPfzv8yuAwRMDgfnaWjASXBYXmlB/zKh2LJOIIOM/Ij 2EtdWkdzYYgliCnUPlWRWk7ju6hq/eXqS4Za/g543u0aWV1coPJpvQfWjihuV2Fzd6Uq swEAOaA4ffWcyTyvXtVmkaRyybC3c5tcUA74+Ykj48o9LsMsjA5lhtpJOZrFtvQwwiVt xqVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677563973; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=jLwLNTb6WWaSOQmgH+fKmq+ah1/mTz0fYUzaz0JWEhI=; b=K5ci1NfzARf50EK6U/LC4ptgJ2JTyF1YKTQ0w21dMpNS8dTBn2xZe6YFZX9+XvXq+Y 8VMeHUHZcdLu9iEEOsV0TVGTgKPPgi3ViCWSO+s0CSO88DjCmt69jn3Xp3z5tHq4qXoX zHII8Nz2bTyQ5+adJghZKUQJPMxyPnmUppo4HJyIK5f7HBstSybxPIUvGv9XOX9bU8Bs G3XsA4aDdJkyigN2oZT+B+MGGxFOd1gntpHFSzlgciRlt5eFkbGnvZcukoP4XFDsiN+p XEZl6lqYnphPkNm/J+cwUsXuOg1vr6NiEqfx5xdQHNMXBQNvQde6lUrwD4uNJE0sQmEB jc5w== X-Gm-Message-State: AO0yUKW/5bA483bIAxIap2vXORsTD/ckr4kIuNLVULCwpR1/Jrn1fnGf yLYQBFePLNNi+PZBdxDorMwetw== X-Google-Smtp-Source: AK7set/L7jDr9GHJfIs4WSgKvyphWigdahaYdbtA0Nh6w5RisSSCFHAkVlA+R8Wd3HYYsbjrCvHkzQ== X-Received: by 2002:aca:1214:0:b0:383:ca99:c70e with SMTP id 20-20020aca1214000000b00383ca99c70emr933488ois.59.1677563973507; Mon, 27 Feb 2023 21:59:33 -0800 (PST) Received: from ripple.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id r7-20020acaf307000000b00383ef567cfdsm3954400oih.21.2023.02.27.21.59.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Feb 2023 21:59:29 -0800 (PST) Date: Mon, 27 Feb 2023 21:59:17 -0800 (PST) From: Hugh Dickins X-X-Sender: hugh@ripple.attlocal.net To: "Huang, Ying" cc: Jan Kara , Hugh Dickins , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Zi Yan , Yang Shi , Baolin Wang , Oscar Salvador , Matthew Wilcox , Bharata B Rao , Alistair Popple , Xin Hao , Minchan Kim , Mike Kravetz , Hyeonggon Yoo <42.hyeyoo@gmail.com> Subject: Re: [PATCH -v5 0/9] migrate_pages(): batch TLB flushing In-Reply-To: <87pm9ubnih.fsf@yhuang6-desk2.ccr.corp.intel.com> Message-ID: <46f82df2-c925-e3f9-b185-69b3f0b6e366@google.com> References: <20230213123444.155149-1-ying.huang@intel.com> <87a6c8c-c5c1-67dc-1e32-eb30831d6e3d@google.com> <20230227110614.dngdub2j3exr6dfp@quack3> <87pm9ubnih.fsf@yhuang6-desk2.ccr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Stat-Signature: wbokcw4f3tubpb8dtre9y9zjdriec61o X-Rspam-User: X-Rspamd-Queue-Id: 8C358C0005 X-Rspamd-Server: rspam06 X-HE-Tag: 1677563974-156223 X-HE-Meta: U2FsdGVkX18YJ01zC0jcMIKMjZ2aWqHKW6mK3//oosQkQ8imwQppDIkLxiKGSq6xk+Hejt4H7nQG3WMTIDxyO00jP4wyf6xtk1ktRKF6Y2xi5lyv5R4K/N3uMowbLsVo/WaPHoT5AEcZ5wdNE7gtiVGylfjhR+pW+Rcw151c0S9w9eqsfwt8klz1B18i2AZMdj8T7RkUC37bi0pe6neO/TVS5DSe16UEUcyB6ol7y9wJEoki62MitNWz7dOL9NmNlXA8EK5TCIRHmG16k+2FU+k8uiRsquhOpPRb/dIImE7K/O8ZLhmf/ke4A0GZFQPJPHZyDxdW/OXbahywk6oE/3ItB9DEWE0E79HaJz00XLO/r9X3TMsuRPl68hL7PF34QmQ5LsgAxob/t8P53RhEK1o2L5jpzJq2K0eGkX33fP6aAPzQI5VM3irwAsWnuZWAAG/IwHeHCzZ9nvBNEYVGGLrO0IVG6lZqgqxLL0CuSlSC1gWCYZ1nI9CxHlg6u1od7Z7Habf+hu9iZNcmPymx5B4tUkKZex5hGjRUjzIMdPQX1UMnAoETr+WZGQ3yQewbXyRuYSw7BokMnzZxOHFB2F2rN9Ueh7lOleoo2UNSqI2GCSpeSXUGjFmPp4h8c6BlxQg7uoRyMgWp1yNyzXbzhqwSf7yj+Q3i7dYTRTHUCF56tcWYe3G71mZCnfym3ALutbP+CxDHODX7vJvRjgc3x4jTHS5AmmJQ0UQ54KSnr85FNMAlw764fhay40mLxTu+1OEp90neJ0e03a8HfZZuDvqz72gg0mLHm8KT/wnFTLcRUHmrcHu8QmSWdiYFeeCd8CTy5Nc4nxicggIAeshmtJtK4A7TF1t+iVk2hQYXeYA12x/NxYhKo1iFjlt5aaRdZ2mvwKVpXdQJhr3xWNvm5tpIYLc0jNVgs/jdWmWClchHpCOEUkmI2aai3UicYEjm6JPg/J8/oeE0bFCvnCy sbsJLqb9 Iss3TjNaJQBlh0fIH/dfKvLWFDO+NBqIRHUvxsL2KNNEiQIDeHjMy/g56yvrHHr03NDg9kbqWjHLRebOqq7YQDhj3AIUTPPzLJgUDD3dABpi3XwUFbfT/MvjMMGp6XPimHGr+F99syf406KMgr/6xFgNvmqWX2A+C4nG5irbwuqP6rcXzxMxP9LK1eBjwy8FCGVxX2AIm+74BJ7fGWEegP5gXNkZnyI1Pw1BKm8RvR2ppyO8WMlW7xKmZFp23WynKi18fQCR7Z0icGXs/6fC698JFmURWrwKsMV/IYKDbF5HPRIneKk2NzvVH97c2fXn5jre0jL1mEdyBHGAJ56P4qRTww9q87qE818KV2bq9YDRDNvv9FRY4VtVCnrstOLENY9lekN9NiHh/fMlchkRi9Y4hSlGX4SHm3r09sfOQdtGoZaxfMwVZtrmhtf0GJvs2RheiY12o9c8Rojvxz4GnxUsY1SS7NZ0AuuWiNoO5NMWI4B0B3ZML02TX9Q== 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: On Tue, 28 Feb 2023, Huang, Ying wrote: > Jan Kara writes: > > On Fri 17-02-23 13:47:48, Hugh Dickins wrote: > >> > >> Cc'ing Jan Kara, who knows buffer_migrate_folio_norefs() and jbd2 > >> very well, and I hope can assure us that there is an understandable > >> deadlock here, from holding several random folio locks, then trying > >> to lock buffers. Cc'ing fsdevel, because there's a risk that mm > >> folk think something is safe, when it's not sufficient to cope with > >> the diversity of filesystems. I hope nothing more than the below is > >> needed (and I've had no other problems with the patchset: good job), > >> but cannot be sure. > > > > I suspect it can indeed be caused by the presence of the loop device as > > Huang Ying has suggested. What filesystems using buffer_heads do is a > > pattern like: > > > > bh = page_buffers(loop device page cache page); > > lock_buffer(bh); > > submit_bh(bh); > > - now on loop dev this ends up doing: > > lo_write_bvec() > > vfs_iter_write() > > ... > > folio_lock(backing file folio); > > > > So if migration code holds "backing file folio" lock and at the same time > > waits for 'bh' lock (while trying to migrate loop device page cache page), it > > is a deadlock. > > > > Proposed solution of never waiting for locks in batched mode looks like a > > sensible one to me... > > Thank you very much for detail explanation! Yes, thanks a lot, Jan, for elucidating the deadlocks. I was running with the 1/3,2/3,3/3 series for 48 hours on two machines at the weekend, and hit no problems with all of them on. I did try to review them this evening, but there's too much for me to take in there to give an Acked-by: but I'll ask a couple of questions. Hugh