From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from heian.cn.fujitsu.com (mail.cn.fujitsu.com [183.91.158.132]) by smtp.subspace.kernel.org (Postfix) with ESMTP id C85B572 for ; Fri, 24 Sep 2021 13:11:16 +0000 (UTC) IronPort-Data: =?us-ascii?q?A9a23=3AolVQ0qz4hX4Tw8pDpAN6t+dcxyrEfRIJ4+MujC/?= =?us-ascii?q?XYbTApD0k1zADmmcbXjiEOfneajbyfYp0Odmy8BtSscfUn9ZhHQtv/xmBbVoQ9?= =?us-ascii?q?5OdWo7xwmQcns+qBpSaChohtq3yU/GYRCwPZiKa9krF3oTJ9yEmjPnZHOakUYY?= =?us-ascii?q?oBwgqLeNaYHZ44f5cs75h6mJYqYDR7zKl4bsekeWGULOW82Ic3lYv1k62gEgHU?= =?us-ascii?q?MIeF98vlgdWifhj5DcynpSOZX4VDfnZw3DQGuG4EgMmLtsvwo1V/kuBl/ssIti?= =?us-ascii?q?j1LjmcEwWWaOUNg+L4pZUc/H6xEEc+WppieBmXBYfQR4/ZzGhhc14zs5c85K2U?= =?us-ascii?q?hsBMLDOmfgGTl9TFCQW0ahuoeabcCHg7ZfKp6HBWz62qxl0N2k6NJMZ9s55G2Z?= =?us-ascii?q?L8uYSKSxLZReG78q2y7KTS+9inM0vIcDneoQFtRlIwTjfS/RgXpHHR6TD4MRw3?= =?us-ascii?q?TEsi8QIFvHbD+IVayVoahvoYBBVPFoTTpUkk4+Agnj5bi0drVe9prQ+6GuVyxZ?= =?us-ascii?q?+uJDrLtbUf9miQcROgl3eomPA4nS/DhwEXPSdwDyItHmsm8fIhyrwXI9UH7q9n?= =?us-ascii?q?tZugVuO1ikdExEbS1a/iee2h1T4WN9FLUEQvC00osAa8E2tU8m4XBCipnOAlgA?= =?us-ascii?q?TVsAWEOAg7gyJjK3O7G6xAmkCUy4EeNI9nNE5SCZs1VKTmd7tQzt1v9Wopdi1n?= =?us-ascii?q?luPhWrqf3FLcilZPmlZJTbpKuLL+Okb5i8jhP45eEJtsuDIJA=3D=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AaPMaSq/yNYeb73tciMBuk+DkI+orL9Y04lQ7?= =?us-ascii?q?vn2ZKCYlFvBw8vrCoB1173HJYUkqMk3I9ergBEDiewK4yXcW2/hzAV7KZmCP11?= =?us-ascii?q?dAR7sSj7cKrQeBJwTOssZZ1YpFN5N1EcDMCzFB5vrS0U2VFMkBzbC8nJyVuQ?= =?us-ascii?q?=3D=3D?= X-IronPort-AV: E=Sophos;i="5.85,319,1624291200"; d="scan'208";a="114917431" Received: from unknown (HELO cn.fujitsu.com) ([10.167.33.5]) by heian.cn.fujitsu.com with ESMTP; 24 Sep 2021 21:10:06 +0800 Received: from G08CNEXMBPEKD04.g08.fujitsu.local (unknown [10.167.33.201]) by cn.fujitsu.com (Postfix) with ESMTP id 4DEFC4D0DC77; Fri, 24 Sep 2021 21:10:02 +0800 (CST) Received: from G08CNEXCHPEKD09.g08.fujitsu.local (10.167.33.85) by G08CNEXMBPEKD04.g08.fujitsu.local (10.167.33.201) with Microsoft SMTP Server (TLS) id 15.0.1497.23; Fri, 24 Sep 2021 21:10:03 +0800 Received: from irides.mr.mr.mr (10.167.225.141) by G08CNEXCHPEKD09.g08.fujitsu.local (10.167.33.209) with Microsoft SMTP Server id 15.0.1497.23 via Frontend Transport; Fri, 24 Sep 2021 21:10:00 +0800 From: Shiyang Ruan To: , , , , CC: , , , , Subject: [PATCH v7 0/8] [PATCH v7 0/8] fsdax: introduce fs query to support reflink Date: Fri, 24 Sep 2021 21:09:51 +0800 Message-ID: <20210924130959.2695749-1-ruansy.fnst@fujitsu.com> X-Mailer: git-send-email 2.33.0 Precedence: bulk X-Mailing-List: nvdimm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-yoursite-MailScanner-ID: 4DEFC4D0DC77.A232F X-yoursite-MailScanner: Found to be clean X-yoursite-MailScanner-From: ruansy.fnst@fujitsu.com X-Spam-Status: No This patchset is aimed to support shared pages tracking for fsdax. Changes from [V6 RESEND]: - Move ->memory_failure() into the patch who implements it - Change the parameter of ->memory_failure(): unsigned long nr_pfns -> size_t size - Remove changes(2 patches) for mapped device - Add some necessary comments for functions or interfaces - P1: Make a pre-patch for changes for dax_{read,write}_lock() - P2: Change the parameter of ->notify_failure(): void *data -> int flags - P3: keep the original dax_lock_page() logic - P5: Rewrite the lock function for file's mapping and index: dax_lock_mapping_entry() - P6: use the new dax_lock_mapping_entry() to lock dax entry, and add size parameter to handle a range of failure - P7: add a cross range calculation between memory_failure range and founded extent range - Rebased to v5.15-rc1 This patchset moves owner tracking from dax_assocaite_entry() to pmem device driver, by introducing an interface ->memory_failure() for struct pagemap. This interface is called by memory_failure() in mm, and implemented by pmem device. Then call holder operations to find the filesystem which the corrupted data located in, and call filesystem handler to track files or metadata associated with this page. Finally we are able to try to fix the corrupted data in filesystem and do other necessary processing, such as killing processes who are using the files affected. The call trace is like this: memory_failure() |* fsdax case |------------ |pgmap->ops->memory_failure() => pmem_pgmap_memory_failure() | dax_holder_notify_failure() => | dax_device->holder_ops->notify_failure() => | - xfs_dax_notify_failure() | |* xfs_dax_notify_failure() | |-------------------------- | | xfs_rmap_query_range() | | xfs_dax_notify_failure_fn() | | * corrupted on metadata | | try to recover data, call xfs_force_shutdown() | | * corrupted on file data | | try to recover data, call mf_dax_kill_procs() |* normal case |------------- mf_generic_kill_procs() The fsdax & reflink support for XFS is not contained in this patchset. (Rebased on v5.15-rc1) == Shiyang Ruan (8): dax: Use rwsem for dax_{read,write}_lock() dax: Introduce holder for dax_device mm: factor helpers for memory_failure_dev_pagemap pagemap,pmem: Introduce ->memory_failure() fsdax: Introduce dax_lock_mapping_entry() mm: Introduce mf_dax_kill_procs() for fsdax case xfs: Implement ->notify_failure() for XFS fsdax: add exception for reflinked files drivers/dax/device.c | 11 +- drivers/dax/super.c | 121 +++++++++++++++++--- drivers/md/dm-writecache.c | 7 +- drivers/nvdimm/pmem.c | 11 ++ fs/dax.c | 115 ++++++++++++++----- fs/xfs/xfs_fsops.c | 3 + fs/xfs/xfs_mount.h | 1 + fs/xfs/xfs_super.c | 188 +++++++++++++++++++++++++++++++ include/linux/dax.h | 80 ++++++++++++- include/linux/memremap.h | 9 ++ include/linux/mm.h | 2 + mm/memory-failure.c | 225 ++++++++++++++++++++++++++----------- 12 files changed, 643 insertions(+), 130 deletions(-) -- 2.33.0