From patchwork Wed Aug 21 02:42:54 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Zizhi Wo X-Patchwork-Id: 13770737 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) (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 D05D61537D6; Wed, 21 Aug 2024 02:47:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.188 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724208466; cv=none; b=NzYqu4gqkuOhzB33/gSe/2H4MrrKpVseaKQx9Rpl3Vm2djApmuBsVsY8CL2T3aE6QHFyPVAk2TkyVNoxmQDUhEfizM3AwLoWl6oY0AoyEFkEji/wOqnbmWuLTWTYqjeEynw/Rw23ol5WFMSNDZ8zu1Jo2MXQB8I4ttRKeLnoQWI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724208466; c=relaxed/simple; bh=zTLILwH9+sCPY3CmLrlqDHHP8wHNJs53W50thIqSaYM=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=fiLEXP3ZttNdJJHgtz1HbKucnCGwUh7nHGhF0/tno+cxIFIXmUsUec09yPBmMrobronSDNI5BTTE+1cqMAstwJ3NAUrWAhxYsK/PsZgqB6tpcj3W/N2G4JwuEorCiaWlazH0Vsu3H2sWFi/TIbvhhdnXXP7v+evySd9fBF92XKM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; arc=none smtp.client-ip=45.249.212.188 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Received: from mail.maildlp.com (unknown [172.19.88.194]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4WpW0g5B3kzhXs4; Wed, 21 Aug 2024 10:45:39 +0800 (CST) Received: from kwepemf100017.china.huawei.com (unknown [7.202.181.16]) by mail.maildlp.com (Postfix) with ESMTPS id 219B61401E0; Wed, 21 Aug 2024 10:47:40 +0800 (CST) Received: from localhost.localdomain (10.175.104.67) by kwepemf100017.china.huawei.com (7.202.181.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Wed, 21 Aug 2024 10:47:38 +0800 From: Zizhi Wo To: , , CC: , , , , , , , , , , Subject: [PATCH 1/8] cachefiles: Fix incorrect block calculations in __cachefiles_prepare_write() Date: Wed, 21 Aug 2024 10:42:54 +0800 Message-ID: <20240821024301.1058918-2-wozizhi@huawei.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20240821024301.1058918-1-wozizhi@huawei.com> References: <20240821024301.1058918-1-wozizhi@huawei.com> Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To kwepemf100017.china.huawei.com (7.202.181.16) In the __cachefiles_prepare_write function, DIO aligns blocks using PAGE_SIZE as the unit. And currently cachefiles_add_cache() binds cache->bsize with the requirement that it must not exceed PAGE_SIZE. However, if cache->bsize is smaller than PAGE_SIZE, the calculated block count will be incorrect in __cachefiles_prepare_write(). Set the block size to cache->bsize to resolve this issue. Fixes: 047487c947e8 ("cachefiles: Implement the I/O routines") Signed-off-by: Zizhi Wo --- fs/cachefiles/io.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/fs/cachefiles/io.c b/fs/cachefiles/io.c index a91acd03ee12..59c5c08f921a 100644 --- a/fs/cachefiles/io.c +++ b/fs/cachefiles/io.c @@ -524,10 +524,10 @@ int __cachefiles_prepare_write(struct cachefiles_object *object, struct cachefiles_cache *cache = object->volume->cache; loff_t start = *_start, pos; size_t len = *_len; - int ret; + int ret, block_size = cache->bsize; /* Round to DIO size */ - start = round_down(*_start, PAGE_SIZE); + start = round_down(*_start, block_size); if (start != *_start || *_len > upper_len) { /* Probably asked to cache a streaming write written into the * pagecache when the cookie was temporarily out of service to @@ -537,7 +537,7 @@ int __cachefiles_prepare_write(struct cachefiles_object *object, return -ENOBUFS; } - *_len = round_up(len, PAGE_SIZE); + *_len = round_up(len, block_size); /* We need to work out whether there's sufficient disk space to perform * the write - but we can skip that check if we have space already @@ -563,7 +563,7 @@ int __cachefiles_prepare_write(struct cachefiles_object *object, * space, we need to see if it's fully allocated. If it's not, we may * want to cull it. */ - if (cachefiles_has_space(cache, 0, *_len / PAGE_SIZE, + if (cachefiles_has_space(cache, 0, *_len / block_size, cachefiles_has_space_check) == 0) return 0; /* Enough space to simply overwrite the whole block */ @@ -595,7 +595,7 @@ int __cachefiles_prepare_write(struct cachefiles_object *object, return ret; check_space: - return cachefiles_has_space(cache, 0, *_len / PAGE_SIZE, + return cachefiles_has_space(cache, 0, *_len / block_size, cachefiles_has_space_for_write); } From patchwork Wed Aug 21 02:42:55 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Zizhi Wo X-Patchwork-Id: 13770738 Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [45.249.212.190]) (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 856C31547C2; Wed, 21 Aug 2024 02:47:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.190 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724208466; cv=none; b=RX8nqKjwlLBwdrH5cBZDICFGfcYgVqqvqU6Gl3HrLPeDOhFPkXlTGsgM5xIYaw4cBjmgMC/q5E8eLk8kIo38uCIon4RDrEfm80nWyWOsMp0IV4yKZVeM6D6ZyrAiyVdsRIUr7pS93clzFJgNOCf+VWPprpQ7k07OFHlxR1uf6c0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724208466; c=relaxed/simple; bh=cBQs7GAprml/9QGERSnA/aBz9jiB2O4GPRaHBdajv3A=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=fMSxYRn7XLy9xICKDOQy7H0Fj4I281A8JCy1GWr4Z5xAmeja4s2waraWHp1waxXobjPi6TpOzzJyZ7+Ij85H85zRHD9cGkxc6X9A3wQQHjKafb/KsCEl8knbBL30T5BiuTtuXqE49m/yssPFFETW/P7LUy+9K4PNxwL66tL3ckA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; arc=none smtp.client-ip=45.249.212.190 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Received: from mail.maildlp.com (unknown [172.19.163.17]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4WpW2z226tz2CmxZ; Wed, 21 Aug 2024 10:47:39 +0800 (CST) Received: from kwepemf100017.china.huawei.com (unknown [7.202.181.16]) by mail.maildlp.com (Postfix) with ESMTPS id 285F31A0188; Wed, 21 Aug 2024 10:47:41 +0800 (CST) Received: from localhost.localdomain (10.175.104.67) by kwepemf100017.china.huawei.com (7.202.181.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Wed, 21 Aug 2024 10:47:39 +0800 From: Zizhi Wo To: , , CC: , , , , , , , , , , Subject: [PATCH 2/8] cachefiles: Fix incorrect length return value in cachefiles_ondemand_fd_write_iter() Date: Wed, 21 Aug 2024 10:42:55 +0800 Message-ID: <20240821024301.1058918-3-wozizhi@huawei.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20240821024301.1058918-1-wozizhi@huawei.com> References: <20240821024301.1058918-1-wozizhi@huawei.com> Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To kwepemf100017.china.huawei.com (7.202.181.16) In the current on-demand loading mode, cachefiles_ondemand_fd_write_iter() function first aligns "pos" and "len" to block boundaries. When calling __cachefiles_write(), the aligned "pos" is passed in, but "len" is the original unaligned value(iter->count). Additionally, the returned length of the write operation is the modified "len" aligned by block size, which is unreasonable. The alignment of "pos" and "len" is intended only to check whether the cache has enough space in erofs ondemand mode. But the modified len should not be used as the return value of cachefiles_ondemand_fd_write_iter(). Doing so would result in a mismatch in the data written on-demand. For example, if the length of the user state passed in is not aligned to the block size (the preread scene / DIO writes only need 512 alignment), the length of the write will differ from the actual length of the return. To solve this issue, since the __cachefiles_prepare_write() modifies the size of "len", we pass "aligned_len" to __cachefiles_prepare_write() to calculate the free blocks and use the original "len" as the return value of cachefiles_ondemand_fd_write_iter(). Fixes: c8383054506c ("cachefiles: notify the user daemon when looking up cookie") Signed-off-by: Zizhi Wo --- fs/cachefiles/ondemand.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/cachefiles/ondemand.c b/fs/cachefiles/ondemand.c index 470c96658385..bdd321017f1c 100644 --- a/fs/cachefiles/ondemand.c +++ b/fs/cachefiles/ondemand.c @@ -61,7 +61,7 @@ static ssize_t cachefiles_ondemand_fd_write_iter(struct kiocb *kiocb, struct cachefiles_object *object = kiocb->ki_filp->private_data; struct cachefiles_cache *cache = object->volume->cache; struct file *file = object->file; - size_t len = iter->count; + size_t len = iter->count, aligned_len = len; loff_t pos = kiocb->ki_pos; const struct cred *saved_cred; int ret; @@ -70,7 +70,7 @@ static ssize_t cachefiles_ondemand_fd_write_iter(struct kiocb *kiocb, return -ENOBUFS; cachefiles_begin_secure(cache, &saved_cred); - ret = __cachefiles_prepare_write(object, file, &pos, &len, len, true); + ret = __cachefiles_prepare_write(object, file, &pos, &aligned_len, len, true); cachefiles_end_secure(cache, saved_cred); if (ret < 0) return ret; From patchwork Wed Aug 21 02:42:56 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Zizhi Wo X-Patchwork-Id: 13770736 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) (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 F1489153BF9; Wed, 21 Aug 2024 02:47:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.188 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724208465; cv=none; b=prnHi5DSz1TRzMbjIxUVOWUNCWe14aLULnPYWJpwxxH5BCHZaXBzI9kgJVPuSR5UUFGJIPSuEsJdsLZKUu6YftgUEo7K80HlGB7Wm1pZOQHQ6klI5U4PqQlYYI+NzwY/C23StHFIyE7n7ZPpFJFitz31Qgjw41magV4HUfhqIgc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724208465; c=relaxed/simple; bh=oR86lsSjRYREQ6YFGkWLXCqh3JSmHKvNTAllmQAgw2M=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=BixKCUgdWOTB7HjeKweCcMqMYI3sTW+95WKC/SnJ5e143+j7ulKe0BxDCBGwGaAdrvrEHgIOTppHq61ucJxo3pChmclWVFw0tmtO4+ke0Ju+VySAc52pxazCoUV4FyXLmJ1Eezv1TqPNoGNu0/+uFWRwo53GtEUTnG22J2xrYws= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; arc=none smtp.client-ip=45.249.212.188 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Received: from mail.maildlp.com (unknown [172.19.163.174]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4WpW0j5V5TzhXty; Wed, 21 Aug 2024 10:45:41 +0800 (CST) Received: from kwepemf100017.china.huawei.com (unknown [7.202.181.16]) by mail.maildlp.com (Postfix) with ESMTPS id 2BB841401F4; Wed, 21 Aug 2024 10:47:42 +0800 (CST) Received: from localhost.localdomain (10.175.104.67) by kwepemf100017.china.huawei.com (7.202.181.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Wed, 21 Aug 2024 10:47:40 +0800 From: Zizhi Wo To: , , CC: , , , , , , , , , , Subject: [PATCH 3/8] cachefiles: Fix missing pos updates in cachefiles_ondemand_fd_write_iter() Date: Wed, 21 Aug 2024 10:42:56 +0800 Message-ID: <20240821024301.1058918-4-wozizhi@huawei.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20240821024301.1058918-1-wozizhi@huawei.com> References: <20240821024301.1058918-1-wozizhi@huawei.com> Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To kwepemf100017.china.huawei.com (7.202.181.16) In the erofs on-demand loading scenario, read and write operations are usually delivered through "off" and "len" contained in read req in user mode. Naturally, pwrite is used to specify a specific offset to complete write operations. However, if the write(not pwrite) syscall is called multiple times in the read-ahead scenario, we need to manually update ki_pos after each write operation to update file->f_pos. This step is currently missing from the cachefiles_ondemand_fd_write_iter function, added to address this issue. Fixes: c8383054506c ("cachefiles: notify the user daemon when looking up cookie") Signed-off-by: Zizhi Wo Acked-by: David Howells --- fs/cachefiles/ondemand.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/fs/cachefiles/ondemand.c b/fs/cachefiles/ondemand.c index bdd321017f1c..38ca6dce8ef2 100644 --- a/fs/cachefiles/ondemand.c +++ b/fs/cachefiles/ondemand.c @@ -77,8 +77,10 @@ static ssize_t cachefiles_ondemand_fd_write_iter(struct kiocb *kiocb, trace_cachefiles_ondemand_fd_write(object, file_inode(file), pos, len); ret = __cachefiles_write(object, file, pos, iter, NULL, NULL); - if (!ret) + if (!ret) { ret = len; + kiocb->ki_pos += ret; + } return ret; } From patchwork Wed Aug 21 02:42:57 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Zizhi Wo X-Patchwork-Id: 13770740 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) (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 366DC166305; Wed, 21 Aug 2024 02:47:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.187 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724208469; cv=none; b=sPjYvOK28rQDj5cQZgAtgurP12b0OkxrUasc5YCH1Q6GAAw5RPuP5+Ci7ex74ad5mHQyOeyxSXZyf5Tsicb3d/gI581PWUF5Sbu0pBiKfiRK5qiIfsPidzkQ6bEOvqe8fJkrgbNqsmboLGYFCW2/0Ojy0sWC0sG5tHhRdp57CG8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724208469; c=relaxed/simple; bh=hjf2E9hEQtfxbtL+lBJAXhyw6RPX4xxR1BAZo0HAKdo=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=X3ijKpFVKf5pB4GGh+LHo2muLFpazIV0RiGO/n7YOCcygETOlalwB1YNPYgkkmoq1dNHtNEP+pAyfzPKLbE44+SSJu8eMi1RYi0o9XlxVd4v1WBESPGT+BwczRySDyXGNq0DNWZN1Lob3pYhleJO522cF/LWjqIWzg7JSJEraTo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; arc=none smtp.client-ip=45.249.212.187 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Received: from mail.maildlp.com (unknown [172.19.163.174]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4WpW2J2y81zyQDd; Wed, 21 Aug 2024 10:47:04 +0800 (CST) Received: from kwepemf100017.china.huawei.com (unknown [7.202.181.16]) by mail.maildlp.com (Postfix) with ESMTPS id 375D01401F4; Wed, 21 Aug 2024 10:47:43 +0800 (CST) Received: from localhost.localdomain (10.175.104.67) by kwepemf100017.china.huawei.com (7.202.181.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Wed, 21 Aug 2024 10:47:42 +0800 From: Zizhi Wo To: , , CC: , , , , , , , , , , Subject: [PATCH 4/8] cachefiles: Clear invalid cache data in advance Date: Wed, 21 Aug 2024 10:42:57 +0800 Message-ID: <20240821024301.1058918-5-wozizhi@huawei.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20240821024301.1058918-1-wozizhi@huawei.com> References: <20240821024301.1058918-1-wozizhi@huawei.com> Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To kwepemf100017.china.huawei.com (7.202.181.16) In the current on-demand loading scenario, when umount is called, the cachefiles_commit_tmpfile() is invoked. When checking the inode corresponding to object->file is inconsistent with the dentry, cachefiles_unlink() is called to perform cleanup to prevent invalid data from occupying space. The above operation does not apply to the first mount, because the cache dentry generated by the first mount must be negative. Moreover, there is no need to clear it during the first umount because this part of the data may be reusable in the future. But the problem is that, the clean operation can currently only be called through cachefiles_withdraw_cookie(), in other words the redundant data does not cleaned until the second umount. This means that during the second mount, the old cache data generated from the first mount still occupies space. So if the user does not manually clean up the previous cache before the next mount, it may return insufficient space during the second mount phase. This patch adds an additional cleanup process in the cachefiles_open_file() function. When the auxdata check fails, the remaining old cache data is no longer needed, the file and dentry corresponding to the object are also put. As there is no need to clear it until umount, we can directly clear it during the mount process. Signed-off-by: Zizhi Wo --- fs/cachefiles/namei.c | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/fs/cachefiles/namei.c b/fs/cachefiles/namei.c index f53977169db4..70b0b3477085 100644 --- a/fs/cachefiles/namei.c +++ b/fs/cachefiles/namei.c @@ -542,7 +542,7 @@ static bool cachefiles_create_file(struct cachefiles_object *object) * stale. */ static bool cachefiles_open_file(struct cachefiles_object *object, - struct dentry *dentry) + struct dentry *dir, struct dentry *dentry) { struct cachefiles_cache *cache = object->volume->cache; struct file *file; @@ -601,10 +601,18 @@ static bool cachefiles_open_file(struct cachefiles_object *object, check_failed: fscache_cookie_lookup_negative(object->cookie); cachefiles_unmark_inode_in_use(object, file); - fput(file); - dput(dentry); - if (ret == -ESTALE) + __fput_sync(file); + if (ret == -ESTALE) { + /* When the auxdata check fails, the remaining old cache data + * is no longer needed, and we will clear it here first. + */ + inode_lock_nested(d_inode(dir), I_MUTEX_PARENT); + cachefiles_unlink(cache, object, dir, dentry, FSCACHE_OBJECT_IS_STALE); + inode_unlock(d_inode(dir)); + dput(dentry); return cachefiles_create_file(object); + } + dput(dentry); return false; error_fput: @@ -654,7 +662,7 @@ bool cachefiles_look_up_object(struct cachefiles_object *object) goto new_file; } - if (!cachefiles_open_file(object, dentry)) + if (!cachefiles_open_file(object, fan, dentry)) return false; _leave(" = t [%lu]", file_inode(object->file)->i_ino); From patchwork Wed Aug 21 02:42:58 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Zizhi Wo X-Patchwork-Id: 13770741 Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) (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 7A41E16B390; Wed, 21 Aug 2024 02:47:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.255 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724208470; cv=none; b=uFnDTEFyvK3/+C9v8Lj0btYvyIYWUVyWJrr4B5qR95K28Jz0W0JUCxO7HD0AT6ihddqRJ5ODmvwKKJVQwsc7ZxOMtf9x6h6cjL5l2o6xtxlfepWn0VikuFP/NdHhE4+9EvKsFQIB3aUG75l8ph7epXDML+20H+Yubg/zlQVLh0k= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724208470; c=relaxed/simple; bh=fNpQdqiYafe+uT164m+atZ9+6PBDTWdvrJXj+Ayo99o=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=JXjqUHLScxEytSMQOjeTJx27bQntHRjRnU9/+TneUlAqQg7DlYph2ghzdg3OuIKNXMAhio7ict4UpBmMDHyFSW2TadWty7iuXKj/BioW/ZfcuHe6JSV9rYnEjlot9YPgkp6bnQctSJdEotcfWMGnQvNRNzLrd4mxmFwTlpWW1A0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; arc=none smtp.client-ip=45.249.212.255 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Received: from mail.maildlp.com (unknown [172.19.163.252]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4WpW2K4xBHz13cQg; Wed, 21 Aug 2024 10:47:05 +0800 (CST) Received: from kwepemf100017.china.huawei.com (unknown [7.202.181.16]) by mail.maildlp.com (Postfix) with ESMTPS id 3370D1800D4; Wed, 21 Aug 2024 10:47:44 +0800 (CST) Received: from localhost.localdomain (10.175.104.67) by kwepemf100017.china.huawei.com (7.202.181.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Wed, 21 Aug 2024 10:47:43 +0800 From: Zizhi Wo To: , , CC: , , , , , , , , , , Subject: [PATCH 5/8] cachefiles: Clean up in cachefiles_commit_tmpfile() Date: Wed, 21 Aug 2024 10:42:58 +0800 Message-ID: <20240821024301.1058918-6-wozizhi@huawei.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20240821024301.1058918-1-wozizhi@huawei.com> References: <20240821024301.1058918-1-wozizhi@huawei.com> Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To kwepemf100017.china.huawei.com (7.202.181.16) Currently, cachefiles_commit_tmpfile() will only be called if object->flags is set to CACHEFILES_OBJECT_USING_TMPFILE. Only cachefiles_create_file() and cachefiles_invalidate_cookie() set this flag. Both of these functions replace object->file with the new tmpfile, and both are called by fscache_cookie_state_machine(), so there are no concurrency issues. So the equation "d_backing_inode(dentry) == file_inode(object->file)" in cachefiles_commit_tmpfile() will never hold true according to the above conditions. This patch removes this part of the redundant code and does not involve any other logical changes. Signed-off-by: Zizhi Wo Acked-by: David Howells --- fs/cachefiles/namei.c | 5 ----- 1 file changed, 5 deletions(-) diff --git a/fs/cachefiles/namei.c b/fs/cachefiles/namei.c index 70b0b3477085..ce9d558ae4fa 100644 --- a/fs/cachefiles/namei.c +++ b/fs/cachefiles/namei.c @@ -700,11 +700,6 @@ bool cachefiles_commit_tmpfile(struct cachefiles_cache *cache, } if (!d_is_negative(dentry)) { - if (d_backing_inode(dentry) == file_inode(object->file)) { - success = true; - goto out_dput; - } - ret = cachefiles_unlink(volume->cache, object, fan, dentry, FSCACHE_OBJECT_IS_STALE); if (ret < 0) From patchwork Wed Aug 21 02:42:59 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Zizhi Wo X-Patchwork-Id: 13770739 Received: from szxga05-in.huawei.com (szxga05-in.huawei.com [45.249.212.191]) (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 6177C166F28; Wed, 21 Aug 2024 02:47:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.191 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724208469; cv=none; b=YFHXXCR/YM75I06dt/XlijeMyENbDqWPifMYHm5AKryOQZiSjBd8EjDseYyUtqWTuBwHhkvxBzVb4wnKQEQSxvyns1nH47w8taiZqnS2R42YFOv7H6ItR8tevN8SfbsqMIRzAnaLWMfGEd/JZqnNmffttvlC2daaOLGidpoHqoU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724208469; c=relaxed/simple; bh=tVveER0WYmKJopDytIISrqD/UJRAUusARo2DVEQ9CxM=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Gi8OYWdQK5PYrzlxodThnLUcqcZTEo5py0TfVLFWKOkgosMmCW6c4G1UfFPDYpDQNblw2qroPvnSKJDEu+FsSJDBL1ykB97nvHZEN6DDse5KSWtHzD/23SSQ/wQaj4sbX6xACNr0ZFXyluzuWKuCIAz097lYunG8uGBNsWEh6bw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; arc=none smtp.client-ip=45.249.212.191 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Received: from mail.maildlp.com (unknown [172.19.88.163]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4WpW333xTCz1j6hF; Wed, 21 Aug 2024 10:47:43 +0800 (CST) Received: from kwepemf100017.china.huawei.com (unknown [7.202.181.16]) by mail.maildlp.com (Postfix) with ESMTPS id 3B80C180019; Wed, 21 Aug 2024 10:47:45 +0800 (CST) Received: from localhost.localdomain (10.175.104.67) by kwepemf100017.china.huawei.com (7.202.181.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Wed, 21 Aug 2024 10:47:44 +0800 From: Zizhi Wo To: , , CC: , , , , , , , , , , Subject: [PATCH 6/8] cachefiles: Modify inappropriate error return value in cachefiles_daemon_secctx() Date: Wed, 21 Aug 2024 10:42:59 +0800 Message-ID: <20240821024301.1058918-7-wozizhi@huawei.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20240821024301.1058918-1-wozizhi@huawei.com> References: <20240821024301.1058918-1-wozizhi@huawei.com> Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To kwepemf100017.china.huawei.com (7.202.181.16) In cachefiles_daemon_secctx(), if it is detected that secctx has been written to the cache, the error code returned is -EINVAL, which is inappropriate and does not distinguish the situation well. Like cachefiles_daemon_dir(), fix this issue by return -EEXIST to the user if it has already been defined once. Fixes: 8667d434b2a9 ("cachefiles: Register a miscdev and parse commands over it") Signed-off-by: Zizhi Wo --- fs/cachefiles/daemon.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/cachefiles/daemon.c b/fs/cachefiles/daemon.c index 89b11336a836..59e576951c68 100644 --- a/fs/cachefiles/daemon.c +++ b/fs/cachefiles/daemon.c @@ -587,7 +587,7 @@ static int cachefiles_daemon_secctx(struct cachefiles_cache *cache, char *args) if (cache->secctx) { pr_err("Second security context specified\n"); - return -EINVAL; + return -EEXIST; } secctx = kstrdup(args, GFP_KERNEL); From patchwork Wed Aug 21 02:43:00 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Zizhi Wo X-Patchwork-Id: 13770743 Received: from szxga06-in.huawei.com (szxga06-in.huawei.com [45.249.212.32]) (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 6531016ABF3; Wed, 21 Aug 2024 02:47:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.32 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724208471; cv=none; b=QM3lXPxdJev+sKg8LQ3NKJu5ru36QDPQFKy7XYzcwYQRgAB5Js2HTXKP3ZBPWfQkiCNRB8gWnVKJyqEfvRUXOvyN+kx5k9rxTuFiUojsyIN9EuJFY63pPRMalQsYbdpRyNXafixe1hMnrSJ9eiCP+pa3LFoIEK5fVmgYDZ80p58= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724208471; c=relaxed/simple; bh=pJrvBxxIy3tS56y8Ap1fp3i7CuiUCYHHvkiH/ap6QVI=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=nJFtzWD17J9Uo2fRfe42po3H25uAw5Bu/J+Y/vW6jTOdlnbTfDunI+NzAqSFdh9QZFIx4sCABYjO5NiPzWaEHN+eyekBHWV6WJBXiBOgLtMZoJdl+ggabpsYNkpTkMSLoXVC0QK0dGHCeAhKEBIJhHj+rlwsD0ypj9os/ZL1wuA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; arc=none smtp.client-ip=45.249.212.32 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Received: from mail.maildlp.com (unknown [172.19.163.17]) by szxga06-in.huawei.com (SkyGuard) with ESMTP id 4WpW0v6Dsrz1xvKZ; Wed, 21 Aug 2024 10:45:51 +0800 (CST) Received: from kwepemf100017.china.huawei.com (unknown [7.202.181.16]) by mail.maildlp.com (Postfix) with ESMTPS id 3E9D51A0188; Wed, 21 Aug 2024 10:47:46 +0800 (CST) Received: from localhost.localdomain (10.175.104.67) by kwepemf100017.china.huawei.com (7.202.181.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Wed, 21 Aug 2024 10:47:45 +0800 From: Zizhi Wo To: , , CC: , , , , , , , , , , Subject: [PATCH 7/8] cachefiles: Fix NULL pointer dereference in object->file Date: Wed, 21 Aug 2024 10:43:00 +0800 Message-ID: <20240821024301.1058918-8-wozizhi@huawei.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20240821024301.1058918-1-wozizhi@huawei.com> References: <20240821024301.1058918-1-wozizhi@huawei.com> Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To kwepemf100017.china.huawei.com (7.202.181.16) At present, the object->file has the NULL pointer dereference problem in ondemand-mode. The root cause is that the allocated fd and object->file lifetime are inconsistent, and the user-space invocation to anon_fd uses object->file. Following is the process that triggers the issue: [write fd] [umount] cachefiles_ondemand_fd_write_iter fscache_cookie_state_machine cachefiles_withdraw_cookie if (!file) return -ENOBUFS cachefiles_clean_up_object cachefiles_unmark_inode_in_use fput(object->file) object->file = NULL // file NULL pointer dereference! __cachefiles_write(..., file, ...) Fix this issue by add an additional reference count to the object->file before write/llseek, and decrement after it finished. Fixes: c8383054506c ("cachefiles: notify the user daemon when looking up cookie") Signed-off-by: Zizhi Wo --- fs/cachefiles/interface.c | 3 +++ fs/cachefiles/ondemand.c | 30 ++++++++++++++++++++++++------ 2 files changed, 27 insertions(+), 6 deletions(-) diff --git a/fs/cachefiles/interface.c b/fs/cachefiles/interface.c index 35ba2117a6f6..d30127ead911 100644 --- a/fs/cachefiles/interface.c +++ b/fs/cachefiles/interface.c @@ -342,10 +342,13 @@ static void cachefiles_clean_up_object(struct cachefiles_object *object, } cachefiles_unmark_inode_in_use(object, object->file); + + spin_lock(&object->lock); if (object->file) { fput(object->file); object->file = NULL; } + spin_unlock(&object->lock); } /* diff --git a/fs/cachefiles/ondemand.c b/fs/cachefiles/ondemand.c index 38ca6dce8ef2..fe3de9ad57bf 100644 --- a/fs/cachefiles/ondemand.c +++ b/fs/cachefiles/ondemand.c @@ -60,20 +60,26 @@ static ssize_t cachefiles_ondemand_fd_write_iter(struct kiocb *kiocb, { struct cachefiles_object *object = kiocb->ki_filp->private_data; struct cachefiles_cache *cache = object->volume->cache; - struct file *file = object->file; + struct file *file; size_t len = iter->count, aligned_len = len; loff_t pos = kiocb->ki_pos; const struct cred *saved_cred; int ret; - if (!file) + spin_lock(&object->lock); + file = object->file; + if (!file) { + spin_unlock(&object->lock); return -ENOBUFS; + } + get_file(file); + spin_unlock(&object->lock); cachefiles_begin_secure(cache, &saved_cred); ret = __cachefiles_prepare_write(object, file, &pos, &aligned_len, len, true); cachefiles_end_secure(cache, saved_cred); if (ret < 0) - return ret; + goto out; trace_cachefiles_ondemand_fd_write(object, file_inode(file), pos, len); ret = __cachefiles_write(object, file, pos, iter, NULL, NULL); @@ -82,6 +88,8 @@ static ssize_t cachefiles_ondemand_fd_write_iter(struct kiocb *kiocb, kiocb->ki_pos += ret; } +out: + fput(file); return ret; } @@ -89,12 +97,22 @@ static loff_t cachefiles_ondemand_fd_llseek(struct file *filp, loff_t pos, int whence) { struct cachefiles_object *object = filp->private_data; - struct file *file = object->file; + struct file *file; + loff_t ret; - if (!file) + spin_lock(&object->lock); + file = object->file; + if (!file) { + spin_unlock(&object->lock); return -ENOBUFS; + } + get_file(file); + spin_unlock(&object->lock); - return vfs_llseek(file, pos, whence); + ret = vfs_llseek(file, pos, whence); + fput(file); + + return ret; } static long cachefiles_ondemand_fd_ioctl(struct file *filp, unsigned int ioctl, From patchwork Wed Aug 21 02:43:01 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Zizhi Wo X-Patchwork-Id: 13770742 Received: from szxga07-in.huawei.com (szxga07-in.huawei.com [45.249.212.35]) (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 8D84616B75C; Wed, 21 Aug 2024 02:47:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.35 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724208471; cv=none; b=rIYDbsakSBCQVVSmSFWfrEMV1IP1HRCAeIdBiBq6ISnJqxpl0zToG5G4tPaO2s2ctJ/Nx1jAPwsvzdZcEpVVlhW0rF0guRDOVwu0Q12+7DzgDKLAKgoscJAcYVbRj2TTnzTcIZW9LjVg2u/JeSu2QxzVVixPKhAeFN29OWT5Ktc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724208471; c=relaxed/simple; bh=w703GJBiRakD5YiiL/tpRpWDMUnq32ojEGAp0ZbBnJ4=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=n0DMvX3oboDBGw3FFZBdBQ4eFp/NZAQL3wJdSGmOgTOARBasEkEmBD9At8xpfjRlfzPvInMEJUtC2+l/v3cxZeiSrtNz7a1VQNp/UgjmTccSUCHHJuGe7Yxt2B949zEN9h6yVjyTBv12giYz2XBrAsn9bLkXEyGwj/20tOaotO4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; arc=none smtp.client-ip=45.249.212.35 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Received: from mail.maildlp.com (unknown [172.19.88.214]) by szxga07-in.huawei.com (SkyGuard) with ESMTP id 4WpW345j9Cz1S8Nd; Wed, 21 Aug 2024 10:47:44 +0800 (CST) Received: from kwepemf100017.china.huawei.com (unknown [7.202.181.16]) by mail.maildlp.com (Postfix) with ESMTPS id 4132F1A016C; Wed, 21 Aug 2024 10:47:47 +0800 (CST) Received: from localhost.localdomain (10.175.104.67) by kwepemf100017.china.huawei.com (7.202.181.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Wed, 21 Aug 2024 10:47:46 +0800 From: Zizhi Wo To: , , CC: , , , , , , , , , , Subject: [PATCH 8/8] netfs/fscache: Add a memory barrier for FSCACHE_VOLUME_CREATING Date: Wed, 21 Aug 2024 10:43:01 +0800 Message-ID: <20240821024301.1058918-9-wozizhi@huawei.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20240821024301.1058918-1-wozizhi@huawei.com> References: <20240821024301.1058918-1-wozizhi@huawei.com> Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To kwepemf100017.china.huawei.com (7.202.181.16) In fscache_create_volume(), there is a missing memory barrier between the bit-clearing operation and the wake-up operation. This may cause a situation where, after a wake-up, the bit-clearing operation hasn't been detected yet, leading to an indefinite wait. The triggering process is as follows: [cookie1] [cookie2] [volume_work] fscache_perform_lookup fscache_create_volume fscache_perform_lookup fscache_create_volume fscache_create_volume_work cachefiles_acquire_volume clear_and_wake_up_bit test_and_set_bit test_and_set_bit goto maybe_wait goto no_wait In the above process, cookie1 and cookie2 has the same volume. When cookie1 enters the -no_wait- process, it will clear the bit and wake up the waiting process. If a barrier is missing, it may cause cookie2 to remain in the -wait- process indefinitely. In commit 3288666c7256 ("fscache: Use clear_and_wake_up_bit() in fscache_create_volume_work()"), barriers were added to similar operations in fscache_create_volume_work(), but fscache_create_volume() was missed. By combining the clear and wake operations into clear_and_wake_up_bit() to fix this issue. Fixes: bfa22da3ed65 ("fscache: Provide and use cache methods to lookup/create/free a volume") Signed-off-by: Zizhi Wo Acked-by: David Howells --- fs/netfs/fscache_volume.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/fs/netfs/fscache_volume.c b/fs/netfs/fscache_volume.c index cb75c07b5281..ced14ac78cc1 100644 --- a/fs/netfs/fscache_volume.c +++ b/fs/netfs/fscache_volume.c @@ -322,8 +322,7 @@ void fscache_create_volume(struct fscache_volume *volume, bool wait) } return; no_wait: - clear_bit_unlock(FSCACHE_VOLUME_CREATING, &volume->flags); - wake_up_bit(&volume->flags, FSCACHE_VOLUME_CREATING); + clear_and_wake_up_bit(FSCACHE_VOLUME_CREATING, &volume->flags); } /*