From patchwork Tue Sep 15 14:12:25 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 309733 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=-15.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, 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 A6AB1C433E2 for ; Tue, 15 Sep 2020 14:38:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 659AD206B5 for ; Tue, 15 Sep 2020 14:38:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1600180682; bh=jFs0Sz+sEpFY5xXgoP8wsxu+kifj4dt4TaFrRZotE2Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=l5m41nWYvl3VYEDBUQ1Y6N+F6n2mv/L8GFwVcGm849V6b3SeVWTo2iTNBwY2FcGNP FXufBj7GqJWWaGOBAIYbsq6inHIxntY81B7NPe+4b39Deu7eT9L1h4LRSoAgU1c42D xH3O80bMhPVXWx9kJhQmDZ+d0m/22S7+ywDc9G3U= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727195AbgIOOhz (ORCPT ); Tue, 15 Sep 2020 10:37:55 -0400 Received: from mail.kernel.org ([198.145.29.99]:48030 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726995AbgIOOhi (ORCPT ); Tue, 15 Sep 2020 10:37:38 -0400 Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id BBDEE22404; Tue, 15 Sep 2020 14:26:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1600180015; bh=jFs0Sz+sEpFY5xXgoP8wsxu+kifj4dt4TaFrRZotE2Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=0wSYqpCZTooJHihen6BzxoOdqm6XLSU4IHVhV6Ut6O5n2tA8xi+eLQB71zmOF7oqb xpVYkkFW02YS8OYAFahY17QV3ZVVNAxji2//YhzQOfCDCnR9IoUzZEIiYhVOZDSL+g z+tKMICGN7qZv+10eW12ZrEkiGR9E+jvlY/FB1Xw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Brian Foster , "Darrick J. Wong" , Sasha Levin Subject: [PATCH 5.8 074/177] xfs: fix off-by-one in inode alloc block reservation calculation Date: Tue, 15 Sep 2020 16:12:25 +0200 Message-Id: <20200915140657.185084329@linuxfoundation.org> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20200915140653.610388773@linuxfoundation.org> References: <20200915140653.610388773@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Brian Foster [ Upstream commit 657f101930bc6c5b41bd7d6c22565c4302a80d33 ] The inode chunk allocation transaction reserves inobt_maxlevels-1 blocks to accommodate a full split of the inode btree. A full split requires an allocation for every existing level and a new root block, which means inobt_maxlevels is the worst case block requirement for a transaction that inserts to the inobt. This can lead to a transaction block reservation overrun when tmpfile creation allocates an inode chunk and expands the inobt to its maximum depth. This problem has been observed in conjunction with overlayfs, which makes frequent use of tmpfiles internally. The existing reservation code goes back as far as the Linux git repo history (v2.6.12). It was likely never observed as a problem because the traditional file/directory creation transactions also include worst case block reservation for directory modifications, which most likely is able to make up for a single block deficiency in the inode allocation portion of the calculation. tmpfile support is relatively more recent (v3.15), less heavily used, and only includes the inode allocation block reservation as tmpfiles aren't linked into the directory tree on creation. Fix up the inode alloc block reservation macro and a couple of the block allocator minleft parameters that enforce an allocation to leave enough free blocks in the AG for a full inobt split. Signed-off-by: Brian Foster Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Sasha Levin --- fs/xfs/libxfs/xfs_ialloc.c | 4 ++-- fs/xfs/libxfs/xfs_trans_space.h | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/xfs/libxfs/xfs_ialloc.c b/fs/xfs/libxfs/xfs_ialloc.c index 7fcf62b324b0d..8c1a7cc484b65 100644 --- a/fs/xfs/libxfs/xfs_ialloc.c +++ b/fs/xfs/libxfs/xfs_ialloc.c @@ -688,7 +688,7 @@ xfs_ialloc_ag_alloc( args.minalignslop = igeo->cluster_align - 1; /* Allow space for the inode btree to split. */ - args.minleft = igeo->inobt_maxlevels - 1; + args.minleft = igeo->inobt_maxlevels; if ((error = xfs_alloc_vextent(&args))) return error; @@ -736,7 +736,7 @@ xfs_ialloc_ag_alloc( /* * Allow space for the inode btree to split. */ - args.minleft = igeo->inobt_maxlevels - 1; + args.minleft = igeo->inobt_maxlevels; if ((error = xfs_alloc_vextent(&args))) return error; } diff --git a/fs/xfs/libxfs/xfs_trans_space.h b/fs/xfs/libxfs/xfs_trans_space.h index c6df01a2a1585..7ad3659c5d2a9 100644 --- a/fs/xfs/libxfs/xfs_trans_space.h +++ b/fs/xfs/libxfs/xfs_trans_space.h @@ -58,7 +58,7 @@ #define XFS_IALLOC_SPACE_RES(mp) \ (M_IGEO(mp)->ialloc_blks + \ ((xfs_sb_version_hasfinobt(&mp->m_sb) ? 2 : 1) * \ - (M_IGEO(mp)->inobt_maxlevels - 1))) + M_IGEO(mp)->inobt_maxlevels)) /* * Space reservation values for various transactions.