Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp4729931iob; Sun, 8 May 2022 23:32:01 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzo32r0hO8+wJF6Y7hsvh+qBTkvqUtzdGWbJZ8QwPex17b/n3zXtKOr1j0gX2Udn8dZLh4O X-Received: by 2002:a17:903:32c9:b0:15e:a1b8:c1ef with SMTP id i9-20020a17090332c900b0015ea1b8c1efmr15075923plr.173.1652077920799; Sun, 08 May 2022 23:32:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652077920; cv=none; d=google.com; s=arc-20160816; b=XvS7h0TAPs6B+eyG/ep9kt0CYRg+oHzodiRDFsfvCJTm45vQxtMIRp93Zlq0fcMSCG V1a39ZGjqnw9sN4pdK8Tzr8t8o/54eBbiDMGO88BQn2Cl/jho2D9RWTH++Mks2DcxrSf jisTAP7LojidKuyHyPUD27efzJYQGXJRoqruB7iaH1L3UyhrV0ypytVyqKbGIA5pt9Vs xZOS0VODdse0zeLTvYdUR1v5YossyVyd7su2OWbXTic2q6ZOoDbOFpMK+DADZA7327ot V9i8BFKDjyw7pAt/Y7XgbCiRktr5dBQr8g67gIDiipakdXmiD1qF/niE7lPVgckPzNWY Wibg== 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=dtfcGu+TKEYCUlB4PbagbmR9dq7rOBCcemm37DLVwGM=; b=liu0jIUDtK4rMHlfSlamM4U+qPKQMahV+lkXBelwaGSubvzQOeRvOkyuAJ12PiYE32 2EJCMT5DgD03xNjE713p0pCP3ctxvShRf5eZJClvF4iMKPeF3+/Qy+tlTgN/rIm5NJ8a dGIqsHiN4U9/N1dTRyWPlPs/YU4k5Ink9nJfMF3sw23/Sd7mKuOOJUPD4usI0K2+oylI NTDprDE1GEoVIuk9JXIc4Rj05rqVDinIuOkiZcK0bcjjNHysiI85LOuonP5KPQ5cV/Bs Qv0eYmPnH/So2O6bRlEzTUKC7sRNt1iW219YecvFOPt4QIXUMoeAFb7OgiAhUOVEwONr K6nA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=u2zb+Crr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 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. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id a15-20020a63cd4f000000b003816043f10bsi13249385pgj.768.2022.05.08.23.32.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 08 May 2022 23:32:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=u2zb+Crr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 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 2828816D12C; Sun, 8 May 2022 23:27:37 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359318AbiEDRwA (ORCPT + 99 others); Wed, 4 May 2022 13:52:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54994 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1357361AbiEDRPA (ORCPT ); Wed, 4 May 2022 13:15:00 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BFF19541A0; Wed, 4 May 2022 09:58:28 -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 BC584B827B3; Wed, 4 May 2022 16:58:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6B739C385B3; Wed, 4 May 2022 16:58:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1651683505; bh=/1yeXMa6uf99VEUn8qt+TxYPCMGa6OAgd4dvwWp1OYA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=u2zb+CrrBKNVkTXD2iOjzHmYL9C0usj0lInp78q2ZEDnyDXlGMV1TcePzUu4iDuSZ ojRUwy0GpTXvw/dD6YGdjXCzIZDxhsTmGBJ1BX1kuteRQpJ9OulCRUQlq01sCluHyM C52slhzlgpzhT83bzkKTmsjnrh9ZYXcyPTMMOOd0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Damien Le Moal , Johannes Thumshirn , Hans Holmberg Subject: [PATCH 5.17 180/225] zonefs: Fix management of open zones Date: Wed, 4 May 2022 18:46:58 +0200 Message-Id: <20220504153126.579432514@linuxfoundation.org> X-Mailer: git-send-email 2.36.0 In-Reply-To: <20220504153110.096069935@linuxfoundation.org> References: <20220504153110.096069935@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.6 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=unavailable 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: Damien Le Moal commit 1da18a296f5ba4f99429e62a7cf4fdbefa598902 upstream. The mount option "explicit_open" manages the device open zone resources to ensure that if an application opens a sequential file for writing, the file zone can always be written by explicitly opening the zone and accounting for that state with the s_open_zones counter. However, if some zones are already open when mounting, the device open zone resource usage status will be larger than the initial s_open_zones value of 0. Ensure that this inconsistency does not happen by closing any sequential zone that is open when mounting. Furthermore, with ZNS drives, closing an explicitly open zone that has not been written will change the zone state to "closed", that is, the zone will remain in an active state. Since this can then cause failures of explicit open operations on other zones if the drive active zone resources are exceeded, we need to make sure that the zone is not active anymore by resetting it instead of closing it. To address this, zonefs_zone_mgmt() is modified to change a REQ_OP_ZONE_CLOSE request into a REQ_OP_ZONE_RESET for sequential zones that have not been written. Fixes: b5c00e975779 ("zonefs: open/close zone on file open/close") Cc: Signed-off-by: Damien Le Moal Reviewed-by: Johannes Thumshirn Reviewed-by: Hans Holmberg Signed-off-by: Greg Kroah-Hartman --- fs/zonefs/super.c | 45 ++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 40 insertions(+), 5 deletions(-) --- a/fs/zonefs/super.c +++ b/fs/zonefs/super.c @@ -35,6 +35,17 @@ static inline int zonefs_zone_mgmt(struc lockdep_assert_held(&zi->i_truncate_mutex); + /* + * With ZNS drives, closing an explicitly open zone that has not been + * written will change the zone state to "closed", that is, the zone + * will remain active. Since this can then cause failure of explicit + * open operation on other zones if the drive active zone resources + * are exceeded, make sure that the zone does not remain active by + * resetting it. + */ + if (op == REQ_OP_ZONE_CLOSE && !zi->i_wpoffset) + op = REQ_OP_ZONE_RESET; + trace_zonefs_zone_mgmt(inode, op); ret = blkdev_zone_mgmt(inode->i_sb->s_bdev, op, zi->i_zsector, zi->i_zone_size >> SECTOR_SHIFT, GFP_NOFS); @@ -1295,12 +1306,13 @@ static void zonefs_init_dir_inode(struct inc_nlink(parent); } -static void zonefs_init_file_inode(struct inode *inode, struct blk_zone *zone, - enum zonefs_ztype type) +static int zonefs_init_file_inode(struct inode *inode, struct blk_zone *zone, + enum zonefs_ztype type) { struct super_block *sb = inode->i_sb; struct zonefs_sb_info *sbi = ZONEFS_SB(sb); struct zonefs_inode_info *zi = ZONEFS_I(inode); + int ret = 0; inode->i_ino = zone->start >> sbi->s_zone_sectors_shift; inode->i_mode = S_IFREG | sbi->s_perm; @@ -1325,6 +1337,22 @@ static void zonefs_init_file_inode(struc sb->s_maxbytes = max(zi->i_max_size, sb->s_maxbytes); sbi->s_blocks += zi->i_max_size >> sb->s_blocksize_bits; sbi->s_used_blocks += zi->i_wpoffset >> sb->s_blocksize_bits; + + /* + * For sequential zones, make sure that any open zone is closed first + * to ensure that the initial number of open zones is 0, in sync with + * the open zone accounting done when the mount option + * ZONEFS_MNTOPT_EXPLICIT_OPEN is used. + */ + if (type == ZONEFS_ZTYPE_SEQ && + (zone->cond == BLK_ZONE_COND_IMP_OPEN || + zone->cond == BLK_ZONE_COND_EXP_OPEN)) { + mutex_lock(&zi->i_truncate_mutex); + ret = zonefs_zone_mgmt(inode, REQ_OP_ZONE_CLOSE); + mutex_unlock(&zi->i_truncate_mutex); + } + + return ret; } static struct dentry *zonefs_create_inode(struct dentry *parent, @@ -1334,6 +1362,7 @@ static struct dentry *zonefs_create_inod struct inode *dir = d_inode(parent); struct dentry *dentry; struct inode *inode; + int ret; dentry = d_alloc_name(parent, name); if (!dentry) @@ -1344,10 +1373,16 @@ static struct dentry *zonefs_create_inod goto dput; inode->i_ctime = inode->i_mtime = inode->i_atime = dir->i_ctime; - if (zone) - zonefs_init_file_inode(inode, zone, type); - else + if (zone) { + ret = zonefs_init_file_inode(inode, zone, type); + if (ret) { + iput(inode); + goto dput; + } + } else { zonefs_init_dir_inode(dir, inode, type); + } + d_add(dentry, inode); dir->i_size++;