Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp2331296ybz; Thu, 23 Apr 2020 16:10:23 -0700 (PDT) X-Google-Smtp-Source: APiQypLAB0BBnEjkDqDnZuy+ahJmgejGvViK82JrIo0HFnlcyFXZAmkL4K31tJi9lDhFlH30U/03 X-Received: by 2002:aa7:d60a:: with SMTP id c10mr5076541edr.66.1587683423531; Thu, 23 Apr 2020 16:10:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587683423; cv=none; d=google.com; s=arc-20160816; b=VqtcYGofk6uUt/xij1sAkGnT4Hq1/2hMko932bCxuSMiDw76kRwJMGmszJVJF1UF5k OAbli0RMtwyuGbefYiMJfcoTrHlcY2fE+fm8KMvBI3FHzPKEGoUfqmBOZRyJZwfUZDK0 eZBOwUpwpo/y058OR2IQNjs72QSbgxw5FCRG4aPlBSXWRJfIv5xjq4uGnVfiRbl2RGz9 0yuvm7mFWnXfoGcJyLnEJ2EghGsIGh8WhD67We1rzXWE4hVRWu35k1rc1EuTOxf9GfMe ptTL38eiIY40temC4fEXVtmrTdI5jdfHNuannycEICanDZO39ryidgMOHTCyojxg8ElO WvaQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition; bh=iYxBSg8jjufDMpbOtvoXR+wq9SDP9xOq5Rhx+meseAM=; b=XDVI12B6CPhwKB0X40OiWLSSEmIoXzJ731cxu/t9J4UUxZjq8Va3TLt9ruHB1OVKiJ FgdtU632OX0tjJa52lKuQ773nv6jVIkXU+B60p9RABpdBtYd9hdXK9DljpYB8Riwe/Lh 5iG9mq6FAW4jQyW19Fa8Uq/YRoiVNsr1VqLZ2sOrCC7pLBGrx08LhesjCpOMTz5jWaeb SAQETyhGDI8haCEj8emuX0JV0QWIYac9qG3WhWduObW6xmPE0sfOymseSwntrtHQpQCl uY6ECXR0PiVOD4JSQiL2Jbl3ThG9rs0NQwcTz/UsRGiYRxTlTK5DUWzSezI7c4MIy/qd jqtg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b9si1913532edx.31.2020.04.23.16.10.00; Thu, 23 Apr 2020 16:10:23 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728321AbgDWXGl (ORCPT + 99 others); Thu, 23 Apr 2020 19:06:41 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:48150 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727879AbgDWXG1 (ORCPT ); Thu, 23 Apr 2020 19:06:27 -0400 Received: from [192.168.4.242] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1jRkvI-0004ZR-4F; Fri, 24 Apr 2020 00:06:24 +0100 Received: from ben by deadeye with local (Exim 4.93) (envelope-from ) id 1jRkvH-00E6eu-L4; Fri, 24 Apr 2020 00:06:23 +0100 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, Denis Kirjanov , "Theodore Ts'o" , "Lukas Czerner" Date: Fri, 24 Apr 2020 00:03:57 +0100 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) X-Patchwork-Hint: ignore Subject: [PATCH 3.16 010/245] ext4: wait for existing dio workers in ext4_alloc_file_blocks() In-Reply-To: X-SA-Exim-Connect-IP: 192.168.4.242 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.83-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Lukas Czerner commit 0d306dcf86e8f065dff42a4a934ae9d99af35ba5 upstream. Currently existing dio workers can jump in and potentially increase extent tree depth while we're allocating blocks in ext4_alloc_file_blocks(). This may cause us to underestimate the number of credits needed for the transaction because the extent tree depth can change after our estimation. Fix this by waiting for all the existing dio workers in the same way as we do it in ext4_punch_hole. We've seen errors caused by this in xfstest generic/299, however it's really hard to reproduce. Signed-off-by: Lukas Czerner Signed-off-by: Theodore Ts'o Signed-off-by: Ben Hutchings --- fs/ext4/extents.c | 6 ++++++ 1 file changed, 6 insertions(+) --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -4707,6 +4707,10 @@ static int ext4_alloc_file_blocks(struct if (len <= EXT_UNWRITTEN_MAX_LEN) flags |= EXT4_GET_BLOCKS_NO_NORMALIZE; + /* Wait all existing dio workers, newcomers will block on i_mutex */ + ext4_inode_block_unlocked_dio(inode); + inode_dio_wait(inode); + /* * credits to insert 1 extent into extent tree */ @@ -4756,6 +4760,8 @@ retry: goto retry; } + ext4_inode_resume_unlocked_dio(inode); + return ret > 0 ? ret2 : ret; }