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 X-Spam-Level: X-Spam-Status: No, score=-12.0 required=3.0 tests=BAYES_00,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 95907C4361B for ; Mon, 14 Dec 2020 09:57:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 42A44225AC for ; Mon, 14 Dec 2020 09:57:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730225AbgLNJ5d (ORCPT ); Mon, 14 Dec 2020 04:57:33 -0500 Received: from mail.kernel.org ([198.145.29.99]:58710 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729399AbgLNJ5c (ORCPT ); Mon, 14 Dec 2020 04:57:32 -0500 From: fdmanana@kernel.org Authentication-Results: mail.kernel.org; dkim=permerror (bad message/signature format) To: linux-btrfs@vger.kernel.org Cc: josef@toxicpanda.com, Filipe Manana Subject: [PATCH 0/2] btrfs: fix races between clone, fallocate and memory mapped writes Date: Mon, 14 Dec 2020 09:56:40 +0000 Message-Id: X-Mailer: git-send-email 2.17.1 Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org From: Filipe Manana For a very long time there's been a race between clone/dedupe and memory mapped writes as well as between fallocate and memory mapped writes. For both cases the consequence of the race is that it can makes us deadlock when we are low on available metadata space, since clone/dedupe/fallocate start a transaction while holding file ranges locked, and allocating the metadata can result in the async reclaim task to flush the inodes being used by clone/dedupe/fallocate, if a memory mapped write happened before we locked the file ranges. For the dedupe case, Josef's recent fix [1] ("btrfs: fix race between dedupe and mmap") happens to fix this deadlock problem as well. The first patch in this patchset fixes the issue for both clone and dedupe, as it's centered on the shared extent locking function, and it is independent of Josef's fix (works both with and without that fix). [1] https://lore.kernel.org/linux-btrfs/afdc2109f83fff1a925d7a66a6a047d4400721d4.1607724668.git.josef@toxicpanda.com/ Filipe Manana (2): btrfs: fix race between cloning and memory mapped writes leading to deadlock btrfs: fix race between fallocate and memory mapped writes leading to deadlock fs/btrfs/extent_io.c | 2 +- fs/btrfs/file.c | 38 +++++--------------------------- fs/btrfs/inode.c | 4 ++-- fs/btrfs/ordered-data.c | 48 ++++++++++++++++++++++++++++++++--------- fs/btrfs/ordered-data.h | 6 +++--- fs/btrfs/reflink.c | 28 ++++++++++++++++++------ 6 files changed, 71 insertions(+), 55 deletions(-) -- 2.28.0