From nobody Sun Nov 24 03:41:00 2024 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 4AB151E1325; Thu, 7 Nov 2024 11:30:23 +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=1730979026; cv=none; b=iAd6RbL6c+UaE8atfuXhXZF2KRxAJP6yed+dcS23jIG6aVSfpstvk0ND8hoZQYtjvcAM6rWy2KFEryHbXmR3dOVEZ8eMM3wyHgUi4AaTqygxtA+jVjTaOvzPpY0EF/MfRjmTgOG73+NRFVoJnn4JxwdCaYsxmm5jB7UoEQtbp/k= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730979026; c=relaxed/simple; bh=tycehnml7nIskV1IKhFmTrfCzq+GzAVvOOf7z24DQ6k=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=ZV4oQkk0156HYCp6on57juBQnKzHZSNMRQcJY1g9GCIcUfrE1Kc3Q7h+iOYal7Yp57o7Lt5YVxwwcE3jiHSnUMG+r1uxMyKusAEaGDWoRhrkcduGwIOQIbH3xFduly6BbNLQoL0+W8zlr0Ehx2kK6Ks/32hwMcPIf/9jv8bX+b4= 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.88.214]) by szxga06-in.huawei.com (SkyGuard) with ESMTP id 4XkfWD6Ng5z2gL16; Thu, 7 Nov 2024 19:10:32 +0800 (CST) Received: from kwepemf100017.china.huawei.com (unknown [7.202.181.16]) by mail.maildlp.com (Postfix) with ESMTPS id 8E6621A016C; Thu, 7 Nov 2024 19:10:22 +0800 (CST) Received: from huawei.com (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; Thu, 7 Nov 2024 19:10:21 +0800 From: Zizhi Wo To: , , , CC: , , , , , , , , , , Subject: [PATCH v2 1/5] cachefiles: Fix incorrect length return value in cachefiles_ondemand_fd_write_iter() Date: Thu, 7 Nov 2024 19:06:45 +0800 Message-ID: <20241107110649.3980193-2-wozizhi@huawei.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20241107110649.3980193-1-wozizhi@huawei.com> References: <20241107110649.3980193-1-wozizhi@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To kwepemf100017.china.huawei.com (7.202.181.16) Content-Type: text/plain; charset="utf-8" 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. But the modified len should not be used as the return value of cachefiles_ondemand_fd_write_iter() because the length we passed to __cachefiles_write() is the previous "len". 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/Fault injection), 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 co= okie") 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 k= iocb *kiocb, struct cachefiles_object *object =3D kiocb->ki_filp->private_data; struct cachefiles_cache *cache =3D object->volume->cache; struct file *file =3D object->file; - size_t len =3D iter->count; + size_t len =3D iter->count, aligned_len =3D len; loff_t pos =3D kiocb->ki_pos; const struct cred *saved_cred; int ret; @@ -70,7 +70,7 @@ static ssize_t cachefiles_ondemand_fd_write_iter(struct k= iocb *kiocb, return -ENOBUFS; =20 cachefiles_begin_secure(cache, &saved_cred); - ret =3D __cachefiles_prepare_write(object, file, &pos, &len, len, true); + ret =3D __cachefiles_prepare_write(object, file, &pos, &aligned_len, len,= true); cachefiles_end_secure(cache, saved_cred); if (ret < 0) return ret; --=20 2.39.2 From nobody Sun Nov 24 03:41:00 2024 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 D8CB31F472F; Thu, 7 Nov 2024 11:10:25 +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=1730977830; cv=none; b=dfv4jsr2V++LOEps/bGcRNIUy2PvkO1Vw+mSWOiHdaGxzEdACjHLem3ix+uSPWGPhf5egNXMJ9qoF5uTJNwQ11R5uH8r4DQMdm4ndsfRZlAw0pWyDAU60fcQNkSnG2qZjvpYhBoLC9InDzGJtI6Dqx02syahs9072N1jmygdxIc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730977830; c=relaxed/simple; bh=Ohm+oiB/qt3VEt9jKxU2Epk59biCI7J/0xVonQqAvas=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=aECai4xjccV+wFZ0O7ZnNKz9Vtk5N0JS+WeN4AMltV3DTnxtzp3P1HzviezwS9ZZhEIzQfwD+jCrpwbmTpRtmzO+oZ8Mk6xrr8BFS/fPgczsqonxa7ouOFcbSiOUxpGJa5PDjYgpcG1yosw76zqoXaRQ4K2PE1Qr+4D9Ozf3MR8= 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.88.105]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4XkfSL0W0fz10QlX; Thu, 7 Nov 2024 19:08:02 +0800 (CST) Received: from kwepemf100017.china.huawei.com (unknown [7.202.181.16]) by mail.maildlp.com (Postfix) with ESMTPS id 9D8A41400DC; Thu, 7 Nov 2024 19:10:23 +0800 (CST) Received: from huawei.com (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; Thu, 7 Nov 2024 19:10:22 +0800 From: Zizhi Wo To: , , , CC: , , , , , , , , , , Subject: [PATCH v2 2/5] cachefiles: Fix missing pos updates in cachefiles_ondemand_fd_write_iter() Date: Thu, 7 Nov 2024 19:06:46 +0800 Message-ID: <20241107110649.3980193-3-wozizhi@huawei.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20241107110649.3980193-1-wozizhi@huawei.com> References: <20241107110649.3980193-1-wozizhi@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To kwepemf100017.china.huawei.com (7.202.181.16) Content-Type: text/plain; charset="utf-8" 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 co= okie") 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, =20 trace_cachefiles_ondemand_fd_write(object, file_inode(file), pos, len); ret =3D __cachefiles_write(object, file, pos, iter, NULL, NULL); - if (!ret) + if (!ret) { ret =3D len; + kiocb->ki_pos +=3D ret; + } =20 return ret; } --=20 2.39.2 From nobody Sun Nov 24 03:41:00 2024 Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) (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 D654B1F6687; Thu, 7 Nov 2024 11:10:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.189 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730977834; cv=none; b=h8p6AavuLE1mv0IHfGcoiBm4RXJ4h3vA+fq7vKA3t8oSUJc8k3Tv8fYKMGRm+OJkApv0Qiv5uscSan0JSgxAY5NawC2MBBZL+c+KqqFfKQ8Sw4IMm62tQ3datvGHqvuutAu0AQDV0m7veznC3gUo732zB4HZeU7i5ozTTPF+2tg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730977834; c=relaxed/simple; bh=1WexRfGfAjCbZ7vpocIPygEkhF0DS+Vxup3A6fLnrzg=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=bDoAtJq9QjMGrUl+ySn85vlaIkAfIPuR0IuXaCZUrZ7KspesvRX8D21C+e0guXef5nlhmpRJ7KMfRiHiGrBRv/GrjaSlTMl7/V4n86a6L4BKOy/CL4BGrHOvqZ7WZY5pCXU/BFotgKgS08YqsJtVZAWZWiUNCgzEOi+s76+fcWw= 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.189 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.162.254]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4XkfTm39pBzQsf2; Thu, 7 Nov 2024 19:09:16 +0800 (CST) Received: from kwepemf100017.china.huawei.com (unknown [7.202.181.16]) by mail.maildlp.com (Postfix) with ESMTPS id AA6D9180105; Thu, 7 Nov 2024 19:10:24 +0800 (CST) Received: from huawei.com (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; Thu, 7 Nov 2024 19:10:23 +0800 From: Zizhi Wo To: , , , CC: , , , , , , , , , , Subject: [PATCH v2 3/5] cachefiles: Clean up in cachefiles_commit_tmpfile() Date: Thu, 7 Nov 2024 19:06:47 +0800 Message-ID: <20241107110649.3980193-4-wozizhi@huawei.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20241107110649.3980193-1-wozizhi@huawei.com> References: <20241107110649.3980193-1-wozizhi@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To kwepemf100017.china.huawei.com (7.202.181.16) Content-Type: text/plain; charset="utf-8" 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) =3D=3D 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 2b3f9935dbb4..7cf59713f0f7 100644 --- a/fs/cachefiles/namei.c +++ b/fs/cachefiles/namei.c @@ -691,11 +691,6 @@ bool cachefiles_commit_tmpfile(struct cachefiles_cache= *cache, } =20 if (!d_is_negative(dentry)) { - if (d_backing_inode(dentry) =3D=3D file_inode(object->file)) { - success =3D true; - goto out_dput; - } - ret =3D cachefiles_unlink(volume->cache, object, fan, dentry, FSCACHE_OBJECT_IS_STALE); if (ret < 0) --=20 2.39.2 From nobody Sun Nov 24 03:41:00 2024 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 D8D941F473B; Thu, 7 Nov 2024 11:10:27 +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=1730977830; cv=none; b=Xrwyh16EQltw3uehu0I4843KemR8O5KUOFZO9ScaDWXFZMnut1wOfE3jOi3zA50gINA+mZmL2Qm1kcQ5G1CoyORo9hqekbDE0WPnBb9OCU1nVkIl2no7Mnx7B7jK4+rYQrjO2Qk79GidMjyk4IETcyZFRsQIWofwXrPykc6xE/Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730977830; c=relaxed/simple; bh=oOOQlpxHRBpIsmicIcoxdHzfqDq12wkMpDouD22xBGU=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=omTEfLiSDsXHDWKPR5cuaqrGEQM6SbepUcaXI9Iqk3KpJA4X4vLavFSOiwn7qWuoMWlz4qXRoF+slhdIIHMoe31S5xZadOwLlUVJJQY2A83RygqDE6wOHWQDNNELcauZZlgPI0X/wCKTIfMj+/ot/zUcJYPoLgmTsmsuW4h4j9g= 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.88.105]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4XkfSN1F9mz10Qlh; Thu, 7 Nov 2024 19:08:04 +0800 (CST) Received: from kwepemf100017.china.huawei.com (unknown [7.202.181.16]) by mail.maildlp.com (Postfix) with ESMTPS id B7DF71400DC; Thu, 7 Nov 2024 19:10:25 +0800 (CST) Received: from huawei.com (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; Thu, 7 Nov 2024 19:10:24 +0800 From: Zizhi Wo To: , , , CC: , , , , , , , , , , Subject: [PATCH v2 4/5] cachefiles: Fix NULL pointer dereference in object->file Date: Thu, 7 Nov 2024 19:06:48 +0800 Message-ID: <20241107110649.3980193-5-wozizhi@huawei.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20241107110649.3980193-1-wozizhi@huawei.com> References: <20241107110649.3980193-1-wozizhi@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To kwepemf100017.china.huawei.com (7.202.181.16) Content-Type: text/plain; charset="utf-8" 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 =3D 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 co= okie") Signed-off-by: Zizhi Wo --- fs/cachefiles/interface.c | 14 ++++++++++---- fs/cachefiles/ondemand.c | 30 ++++++++++++++++++++++++------ 2 files changed, 34 insertions(+), 10 deletions(-) diff --git a/fs/cachefiles/interface.c b/fs/cachefiles/interface.c index 35ba2117a6f6..3e63cfe15874 100644 --- a/fs/cachefiles/interface.c +++ b/fs/cachefiles/interface.c @@ -327,6 +327,8 @@ static void cachefiles_commit_object(struct cachefiles_= object *object, static void cachefiles_clean_up_object(struct cachefiles_object *object, struct cachefiles_cache *cache) { + struct file *file; + if (test_bit(FSCACHE_COOKIE_RETIRED, &object->cookie->flags)) { if (!test_bit(CACHEFILES_OBJECT_USING_TMPFILE, &object->flags)) { cachefiles_see_object(object, cachefiles_obj_see_clean_delete); @@ -342,10 +344,14 @@ static void cachefiles_clean_up_object(struct cachefi= les_object *object, } =20 cachefiles_unmark_inode_in_use(object, object->file); - if (object->file) { - fput(object->file); - object->file =3D NULL; - } + + spin_lock(&object->lock); + file =3D object->file; + object->file =3D NULL; + spin_unlock(&object->lock); + + if (file) + fput(file); } =20 /* 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 =3D kiocb->ki_filp->private_data; struct cachefiles_cache *cache =3D object->volume->cache; - struct file *file =3D object->file; + struct file *file; size_t len =3D iter->count, aligned_len =3D len; loff_t pos =3D kiocb->ki_pos; const struct cred *saved_cred; int ret; =20 - if (!file) + spin_lock(&object->lock); + file =3D object->file; + if (!file) { + spin_unlock(&object->lock); return -ENOBUFS; + } + get_file(file); + spin_unlock(&object->lock); =20 cachefiles_begin_secure(cache, &saved_cred); ret =3D __cachefiles_prepare_write(object, file, &pos, &aligned_len, len,= true); cachefiles_end_secure(cache, saved_cred); if (ret < 0) - return ret; + goto out; =20 trace_cachefiles_ondemand_fd_write(object, file_inode(file), pos, len); ret =3D __cachefiles_write(object, file, pos, iter, NULL, NULL); @@ -82,6 +88,8 @@ static ssize_t cachefiles_ondemand_fd_write_iter(struct k= iocb *kiocb, kiocb->ki_pos +=3D ret; } =20 +out: + fput(file); return ret; } =20 @@ -89,12 +97,22 @@ static loff_t cachefiles_ondemand_fd_llseek(struct file= *filp, loff_t pos, int whence) { struct cachefiles_object *object =3D filp->private_data; - struct file *file =3D object->file; + struct file *file; + loff_t ret; =20 - if (!file) + spin_lock(&object->lock); + file =3D object->file; + if (!file) { + spin_unlock(&object->lock); return -ENOBUFS; + } + get_file(file); + spin_unlock(&object->lock); =20 - return vfs_llseek(file, pos, whence); + ret =3D vfs_llseek(file, pos, whence); + fput(file); + + return ret; } =20 static long cachefiles_ondemand_fd_ioctl(struct file *filp, unsigned int i= octl, --=20 2.39.2 From nobody Sun Nov 24 03:41:00 2024 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 93E871F6680; Thu, 7 Nov 2024 11:10:34 +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=1730977836; cv=none; b=skrWbP9bOkTrms3YwgNDaK6c9krYyofrTVWOplqQuelKk+USM2FwP37mOpdTcCgTxYIux7FxvA/lBIaUZyHnTGtdDYkNqRFp32iRTVIjqxAxfTTgZnu7rWHyHwiDWSFgMJ2kCpRBeXpoOhZrAoUcaoVVufrojD2IQAeoIHgk3kI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730977836; c=relaxed/simple; bh=qWDhbIEFWCOCwM370sGSBoKdqofWiHM85gaoBK1VQNk=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=fG5gELsDnbohBGPbxpG3B0U0NI6kMdJl+z7EesX022yI7r/9qbK94rG2WRf2En8DI84aoHB8RhyzGaETrJ8VUcJQDq4PIFIEyJsUOEU9EQmRE8ADXeOYdQsk4zEBWxD7l9GoHcJxswDBRu8ppgsF2hKGhmTOPVQEUz1jy9U1Gtw= 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.163.17]) by szxga07-in.huawei.com (SkyGuard) with ESMTP id 4XkfT7637Rz1SGC6; Thu, 7 Nov 2024 19:08:43 +0800 (CST) Received: from kwepemf100017.china.huawei.com (unknown [7.202.181.16]) by mail.maildlp.com (Postfix) with ESMTPS id C45F41A0188; Thu, 7 Nov 2024 19:10:26 +0800 (CST) Received: from huawei.com (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; Thu, 7 Nov 2024 19:10:25 +0800 From: Zizhi Wo To: , , , CC: , , , , , , , , , , Subject: [PATCH v2 5/5] netfs/fscache: Add a memory barrier for FSCACHE_VOLUME_CREATING Date: Thu, 7 Nov 2024 19:06:49 +0800 Message-ID: <20241107110649.3980193-6-wozizhi@huawei.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20241107110649.3980193-1-wozizhi@huawei.com> References: <20241107110649.3980193-1-wozizhi@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To kwepemf100017.china.huawei.com (7.202.181.16) Content-Type: text/plain; charset="utf-8" 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/crea= te/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 *volum= e, 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); } =20 /* --=20 2.39.2