Received: by 2002:ab2:687:0:b0:1f4:6588:b3a7 with SMTP id s7csp185950lqe; Tue, 9 Apr 2024 20:51:09 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCXFAQG+p85oSBYyHixMb6oJttfgD+GEkwiGuqshWJInIfe6ER9bbng2pM9GnUPjj60LotMNSSSUdfoOKk3dME7mgrcEa3eiV7xR+ZqhZQ== X-Google-Smtp-Source: AGHT+IFOISOs6bWBquN4TDgI+4THUwzjxox9KS9KwC5kUoFbQDesaErEyk9hB6E7Uq6iZoJXZ/qK X-Received: by 2002:a05:620a:1914:b0:78d:6198:f07d with SMTP id bj20-20020a05620a191400b0078d6198f07dmr1973895qkb.31.1712721069695; Tue, 09 Apr 2024 20:51:09 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1712721069; cv=pass; d=google.com; s=arc-20160816; b=xeSoxGSStT0ixYmavOtjk3k0Gcagv02zfdwjWa0NbVRNKGOMvSm9AFXNUogMhPclow w0NaJb7vtx0HnzjJBe+XgrgEyjy6taibAo+ulQzq2lOVeqQ4cesuJO+N9N+OwG7odNG0 5I8wwXMOeI1UyGOx8u6FwxYOTwBUciktgrCz7PwzQlS57YCk7CfVpilXtpukOTwmWvnE PZeJfn2i0nSrCR+HrZKuzbYewplU+JFVXb7ynFC5DPNhsC8EXtRg8kscfucCqGQrrJLx Bxx1VSz2/2FOgBHHJhKfgoUF2fIolwQuuKfsTHIP0x9FvEol10/hK9rYNi2a2p9CLrmm C8Og== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from; bh=+W5KEpg2kUY6jwif517hChT/8NlMh2IK3EzSMnHViHw=; fh=dC1DNofMpo0fGa+HNNOiDPPA5M30OdZqJ1HdUJkde1U=; b=Hb0TFadtDi0vtQ6iCbsZekdX0RQZqM5fw5TZI+scYAv4GcQOpbh3iw9Gv54nfgVCnS vpT8omIZ3OyuwhJP7waQ5eFrWbfq5m7AQM9US/Sl8CbumKQ2yjUaPK7bUzYdjtPVUMPT J6k3HuLfBdsxV1Iqp2dI08oPWOTNsLFTb9UTKkbwbSoqPhE+yqmUIznNIyuExKHusmgN jr3u3Lc3+3TEpeCK4V8vt1hLYCSdfyJFuFBupkhbqMbxFmaw+j3M0ci/D2fdiK/2FPU5 m9TjXFHBOKvDhv+aORNo6qb+M0WVFcGerWetsBpK7NBdZK4C7WaY1uQf2Qr15Ri+nDb6 Kk7w==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=huaweicloud.com); spf=pass (google.com: domain of linux-ext4+bounces-1929-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-ext4+bounces-1929-linux.lists.archive=gmail.com@vger.kernel.org" Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id n20-20020a05620a295400b0078d6413b4basi7083554qkp.288.2024.04.09.20.51.09 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Apr 2024 20:51:09 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4+bounces-1929-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=huaweicloud.com); spf=pass (google.com: domain of linux-ext4+bounces-1929-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-ext4+bounces-1929-linux.lists.archive=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 6C9931C2189F for ; Wed, 10 Apr 2024 03:51:09 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id B8A9710961; Wed, 10 Apr 2024 03:50:53 +0000 (UTC) X-Original-To: linux-ext4@vger.kernel.org Received: from dggsgout12.his.huawei.com (unknown [45.249.212.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 10F67BA39; Wed, 10 Apr 2024 03:50:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.56 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712721053; cv=none; b=gCuvVXNT2AngwlOgeeSJoe1Mb7C9p17JoK533v7jhgfo/lSJIA/6AKVbAP52MYuTrApDDUJZZp60zeW7ngCtZDrQmgbgp93tbvQryHCFlmY7FNixOg4zjGil0ALNSlS3Z7GoYS6R9zo4cRwR5ZnmisxILKGc3+zE3qY89qxXVcg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712721053; c=relaxed/simple; bh=c8/cXUrvFUJxUje/2tuH5VU8S66kB4iU4lyFh2BZH+Y=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=X4FNSn9SfUL9GvDk3pwuc3RBU+3MARNq4kMJvIULJLkcBE03W68vKxwnoXiJsrVaknIsyQyiwpGgR2YzLQ0oHYX7g1RCyCoJ/lrl06YpMR61BOLDVn60oN9gffiZnyt25wfZCNY1G4971SiMqfac+FPag2d6hmDMrO5/2JmqGDY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=pass smtp.mailfrom=huaweicloud.com; arc=none smtp.client-ip=45.249.212.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huaweicloud.com Received: from mail.maildlp.com (unknown [172.19.93.142]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTP id 4VDpl464VQz4f3jHy; Wed, 10 Apr 2024 11:50:40 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.112]) by mail.maildlp.com (Postfix) with ESMTP id A80EC1A0175; Wed, 10 Apr 2024 11:50:47 +0800 (CST) Received: from huaweicloud.com (unknown [10.175.104.67]) by APP1 (Coremail) with SMTP id cCh0CgBHGBGADBZmy5ZTJg--.21880S6; Wed, 10 Apr 2024 11:50:47 +0800 (CST) From: Zhang Yi To: linux-ext4@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, jack@suse.cz, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, chengzhihao1@huawei.com, yukuai3@huawei.com Subject: [PATCH v2 2/9] ext4: check the extent status again before inserting delalloc block Date: Wed, 10 Apr 2024 11:41:56 +0800 Message-Id: <20240410034203.2188357-3-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20240410034203.2188357-1-yi.zhang@huaweicloud.com> References: <20240410034203.2188357-1-yi.zhang@huaweicloud.com> Precedence: bulk X-Mailing-List: linux-ext4@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID:cCh0CgBHGBGADBZmy5ZTJg--.21880S6 X-Coremail-Antispam: 1UD129KBjvJXoWxurykJF17GFWxuF48Jw1DZFb_yoW5Grykpa 9xCF15Cr48Wwn7Wa93XF12vr1rWa1rJrWUKFZxKr1UZFZ5JFySg3Z0vF1aqFyftrs3JFsY qFWjqry8ua1UKrDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU9m14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_Jryl82xGYIkIc2 x26xkF7I0E14v26r4j6ryUM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2z4x0 Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F4UJw A2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq3wAS 0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7IYx2 IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0 Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwCF04k20xvY0x0EwIxGrwCFx2 IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v2 6r106r1rMI8E67AF67kF1VAFwI0_Jw0_GFylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67 AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Gr0_Cr1lIxAIcVCF04k26cxKx2IY s7xG6r1j6r1xMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr 0_Gr1UYxBIdaVFxhVjvjDU0xZFpf9x0JUc6pPUUUUU= X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ From: Zhang Yi Now we lookup extent status entry without holding the i_data_sem before inserting delalloc block, it works fine in buffered write path and because it holds i_rwsem and folio lock, and the mmap path holds folio lock, so the found extent locklessly couldn't be modified concurrently. But it could be raced by fallocate since it allocate block whitout holding i_rwsem and folio lock. ext4_page_mkwrite() ext4_fallocate() block_page_mkwrite() ext4_da_map_blocks() //find hole in extent status tree ext4_alloc_file_blocks() ext4_map_blocks() //allocate block and unwritten extent ext4_insert_delayed_block() ext4_da_reserve_space() //reserve one more block ext4_es_insert_delayed_block() //drop unwritten extent and add delayed extent by mistake Then, the delalloc extent is wrong until writeback, the one more reserved block can't be release any more and trigger below warning: EXT4-fs (pmem2): Inode 13 (00000000bbbd4d23): i_reserved_data_blocks(1) not cleared! Hold i_data_sem in write mode directly can fix the problem, but it's expansive, we should keep the lockless check and check the extent again once we need to add an new delalloc block. Cc: stable@vger.kernel.org Signed-off-by: Zhang Yi --- fs/ext4/inode.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 6a41172c06e1..118b0497a954 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -1737,6 +1737,7 @@ static int ext4_da_map_blocks(struct inode *inode, sector_t iblock, if (ext4_es_is_hole(&es)) goto add_delayed; +found: /* * Delayed extent could be allocated by fallocate. * So we need to check it. @@ -1781,6 +1782,24 @@ static int ext4_da_map_blocks(struct inode *inode, sector_t iblock, add_delayed: down_write(&EXT4_I(inode)->i_data_sem); + /* + * Lookup extents tree again under i_data_sem, make sure this + * inserting delalloc range haven't been delayed or allocated + * whitout holding i_rwsem and folio lock. + */ + if (ext4_es_lookup_extent(inode, iblock, NULL, &es)) { + if (!ext4_es_is_hole(&es)) { + up_write(&EXT4_I(inode)->i_data_sem); + goto found; + } + } else if (!ext4_has_inline_data(inode)) { + retval = ext4_map_query_blocks(NULL, inode, map); + if (retval) { + up_write(&EXT4_I(inode)->i_data_sem); + return retval; + } + } + retval = ext4_insert_delayed_block(inode, map->m_lblk); up_write(&EXT4_I(inode)->i_data_sem); if (retval) -- 2.39.2