Received: by 2002:a19:f614:0:0:0:0:0 with SMTP id x20csp61917lfe; Fri, 15 Apr 2022 19:34:44 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwhPuYnVhum5MWVBzIXrUsMLkAuxgzAyNi0VvXXZlQLGKQevqcMk5Hn7MHq/R+VLn9h4l8p X-Received: by 2002:a17:902:f64c:b0:156:4349:7e9b with SMTP id m12-20020a170902f64c00b0015643497e9bmr1728499plg.139.1650076484673; Fri, 15 Apr 2022 19:34:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650076484; cv=none; d=google.com; s=arc-20160816; b=Rqi5+MDpavONp7L2PV7M4By/G/l1MUV7leXmRWqWbMhKd4TPljWoa/1CPDYNtXiqU4 5bFDC1VyAsAPHoBwqgpcq7bOWSmUwZQNN3dR/X4YeRXUdVgAQ/UrnHh27f73mvfK06VH Fm0zHYii1E38X7PTERWruEEov8JClfemdm4upCQ5fPVJoZSLpsLE02djEoOMzfW4H6ar WqEDCSsn33IdxU7PWDUkUyxaw2JPLj6eboI3uU8lhlSn7Z5lCSZ/bJRvK7aO5hbx6UDN hRrrN266yqFSHrbuh6PeCWPlirrrczldAvqHcI4gKElRi6Wo+GWrKgJacTsq1hdZNVIy RtUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=ylmNJxIYflaJYhTlQEkwWhGk+E4vn5ZGdSHK68b/xsk=; b=QaBo2Azh3vKgo/KFuB/GRW5DP87Err6kjoWk1rWRFRRSRfJRhEzIxiav5UCcSEDf14 J68M6mi5oAo0r9S3obbK3bou+xYMl0qCMK/yQRNWuDSQC6zVFe+e9BmQMKgDEhPn4pK1 zFw/gG9vqIsL0aDYQMTuQXOF26sR25G/+fJRQUEVqu7I1qTirOiWQiYfqnbtCedNydPc ibDLmhQHGAXxgxTzbuHZnZj29N12R99GFiymrvE6Ztr6lHLUHvAsoBNX5NjMTjY68Sed Pz5eCLYZV/Hgj6aZHvILATdH5GwiLDWWVbecnKlMk/DfpY7RDTufjS53Tg0D1lusDqTQ SOSQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=AeOSvDbp; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id bk11-20020a056a02028b00b0039d2ffc2de2si2933343pgb.789.2022.04.15.19.34.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Apr 2022 19:34:44 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=AeOSvDbp; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 80CC61EC60; Fri, 15 Apr 2022 18:44:18 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245494AbiDNNso (ORCPT + 99 others); Thu, 14 Apr 2022 09:48:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57344 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344012AbiDNNaO (ORCPT ); Thu, 14 Apr 2022 09:30:14 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6936E92870; Thu, 14 Apr 2022 06:26:13 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 15E03B8296A; Thu, 14 Apr 2022 13:26:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7B8CFC385A1; Thu, 14 Apr 2022 13:26:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1649942770; bh=ZnHTmTtesLWyh9h2bGNI4sFy/7BjPSJ1hU3Je25sBCY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=AeOSvDbpzonn8JAb8lSVOJgblw/8TP80gXqOpF9PL3++PthFe/dPfeW3kCTfApNWF 9c1CwRt62e3eUSfrKpegoZSiKTgFc1P7hvrp6aONv7gaRn3/P04X2d8rxFDeX9WriN y6h53v7iWs608NH2WQk7iFaJ2oJddz+SeIzWNQMA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Zhihao Cheng , Richard Weinberger , Sasha Levin Subject: [PATCH 4.19 256/338] ubifs: Rectify space amount budget for mkdir/tmpfile operations Date: Thu, 14 Apr 2022 15:12:39 +0200 Message-Id: <20220414110846.177631773@linuxfoundation.org> X-Mailer: git-send-email 2.35.2 In-Reply-To: <20220414110838.883074566@linuxfoundation.org> References: <20220414110838.883074566@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Zhihao Cheng [ Upstream commit a6dab6607d4681d227905d5198710b575dbdb519 ] UBIFS should make sure the flash has enough space to store dirty (Data that is newer than disk) data (in memory), space budget is exactly designed to do that. If space budget calculates less data than we need, 'make_reservation()' will do more work(return -ENOSPC if no free space lelf, sometimes we can see "cannot reserve xxx bytes in jhead xxx, error -28" in ubifs error messages) with ubifs inodes locked, which may effect other syscalls. A simple way to decide how much space do we need when make a budget: See how much space is needed by 'make_reservation()' in ubifs_jnl_xxx() function according to corresponding operation. It's better to report ENOSPC in ubifs_budget_space(), as early as we can. Fixes: 474b93704f32163 ("ubifs: Implement O_TMPFILE") Fixes: 1e51764a3c2ac05 ("UBIFS: add new flash file system") Signed-off-by: Zhihao Cheng Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin --- fs/ubifs/dir.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/fs/ubifs/dir.c b/fs/ubifs/dir.c index 9e466eb30dcb..111905ddbfc2 100644 --- a/fs/ubifs/dir.c +++ b/fs/ubifs/dir.c @@ -373,15 +373,18 @@ static int do_tmpfile(struct inode *dir, struct dentry *dentry, { struct inode *inode; struct ubifs_info *c = dir->i_sb->s_fs_info; - struct ubifs_budget_req req = { .new_ino = 1, .new_dent = 1}; + struct ubifs_budget_req req = { .new_ino = 1, .new_dent = 1, + .dirtied_ino = 1}; struct ubifs_budget_req ino_req = { .dirtied_ino = 1 }; struct ubifs_inode *ui, *dir_ui = ubifs_inode(dir); int err, instantiated = 0; struct fscrypt_name nm; /* - * Budget request settings: new dirty inode, new direntry, - * budget for dirtied inode will be released via writeback. + * Budget request settings: new inode, new direntry, changing the + * parent directory inode. + * Allocate budget separately for new dirtied inode, the budget will + * be released via writeback. */ dbg_gen("dent '%pd', mode %#hx in dir ino %lu", @@ -973,7 +976,8 @@ static int ubifs_mkdir(struct inode *dir, struct dentry *dentry, umode_t mode) struct ubifs_inode *dir_ui = ubifs_inode(dir); struct ubifs_info *c = dir->i_sb->s_fs_info; int err, sz_change; - struct ubifs_budget_req req = { .new_ino = 1, .new_dent = 1 }; + struct ubifs_budget_req req = { .new_ino = 1, .new_dent = 1, + .dirtied_ino = 1}; struct fscrypt_name nm; /* -- 2.35.1