From nobody Fri Nov 1 00:06:51 2024 Received: from dggsgout11.his.huawei.com (dggsgout11.his.huawei.com [45.249.212.51]) (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 4390D139CEB; Wed, 24 Apr 2024 03:43:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.51 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713930208; cv=none; b=Qm6nkDD3MR8S84GyKh8qbaa0kBP+bXKth2rmbVbc/N5uZzdZs469PSimgeCUJTIPp8zn4bRLh0kXDFq2rNc5mxDaDcffsvCcyPeyvUwuBR3/SZ0obbHdgDye/SKWIj9kVbo87/TZEDYHugC2ltyEk8iHviFoHl3XWRub/eJHNrE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713930208; c=relaxed/simple; bh=klE7ewnkfYNzuZ52pxanOrEsvUoVVsXNsM1uSrsVQ1o=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=JP8E9Nx3hMV+lvhnbkuCx/ESS5kEiXIZOeCbGv+/8tujvPCFMHopiCFGGkddSk266tDy0c4FLQP77nJ3pfUASAZnsv1sYJFPSojFVj0SGxAkFHBmEkub82WuKIgrRJoJPTzDkbXmd75jJA2SaiNNZ9JxhvxES5suXV5jCCg2IIk= 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.51 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.163.235]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTP id 4VPPw309Hhz4f3nbg; Wed, 24 Apr 2024 11:43:15 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.112]) by mail.maildlp.com (Postfix) with ESMTP id 359071A0572; Wed, 24 Apr 2024 11:43:24 +0800 (CST) Received: from huaweicloud.com (unknown [10.175.104.67]) by APP1 (Coremail) with SMTP id cCh0CgBHGBHafyhmuSA4Kw--.57541S5; Wed, 24 Apr 2024 11:43:23 +0800 (CST) From: libaokun@huaweicloud.com To: netfs@lists.linux.dev Cc: dhowells@redhat.com, jlayton@kernel.org, zhujia.zj@bytedance.com, jefflexu@linux.alibaba.com, linux-cachefs@redhat.com, linux-erofs@lists.ozlabs.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, libaokun@huaweicloud.com, Baokun Li Subject: [PATCH 1/5] cachefiles: stop sending new request when dropping object Date: Wed, 24 Apr 2024 11:34:05 +0800 Message-Id: <20240424033409.2735257-2-libaokun@huaweicloud.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20240424033409.2735257-1-libaokun@huaweicloud.com> References: <20240424033409.2735257-1-libaokun@huaweicloud.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-CM-TRANSID: cCh0CgBHGBHafyhmuSA4Kw--.57541S5 X-Coremail-Antispam: 1UD129KBjvJXoWxAF47Zw1DXw4rurW3Xw17GFg_yoW5AFW5pF WayFy3Kry8ur17GrZ7Za95GrySy3ykZrnFga4Yq3WUAanIqr4rZr1ktr1DuF1Uu3yxXr43 tw48Casxt3y2y3DanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUQ014x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWUWVWUuwAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_Jr4l82xGYIkIc2 x26xkF7I0E14v26r4j6ryUM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2z4x0 Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F4UJw A2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq3wAS 0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7IYx2 IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0 Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2kIc2 xKxwAKzVCY07xG64k0F24lc7CjxVAKzI0EY4vE52x082I5MxAIw28IcxkI7VAKI48JMxC2 0s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI 0_JrI_JrWlx4CE17CEb7AF67AKxVWUtVW8ZwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE 14v26r1I6r4UMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWxJVW8Jr1lIxAIcVCF04k26cxKx2 IYs7xG6r1j6r1xMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_ Gr1j6F4UJbIYCTnIWIevJa73UjIFyTuYvjTRR7KVUUUUU X-CM-SenderInfo: 5olet0hnxqqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Baokun Li Added CACHEFILES_ONDEMAND_OBJSTATE_DROPPING indicates that the cachefiles object is being dropped, and is set after the close request for the dropped object completes, and no new requests are allowed to be sent after this state. Signed-off-by: Baokun Li --- fs/cachefiles/internal.h | 2 ++ fs/cachefiles/ondemand.c | 10 ++++++++-- 2 files changed, 10 insertions(+), 2 deletions(-) diff --git a/fs/cachefiles/internal.h b/fs/cachefiles/internal.h index d33169f0018b..8ecd296cc1c4 100644 --- a/fs/cachefiles/internal.h +++ b/fs/cachefiles/internal.h @@ -48,6 +48,7 @@ enum cachefiles_object_state { CACHEFILES_ONDEMAND_OBJSTATE_CLOSE, /* Anonymous fd closed by daemon or i= nitial state */ CACHEFILES_ONDEMAND_OBJSTATE_OPEN, /* Anonymous fd associated with object= is available */ CACHEFILES_ONDEMAND_OBJSTATE_REOPENING, /* Object that was closed and is = being reopened. */ + CACHEFILES_ONDEMAND_OBJSTATE_DROPPING, /* Object is being dropped. */ }; =20 struct cachefiles_ondemand_info { @@ -332,6 +333,7 @@ cachefiles_ondemand_set_object_##_state(struct cachefil= es_object *object) \ CACHEFILES_OBJECT_STATE_FUNCS(open, OPEN); CACHEFILES_OBJECT_STATE_FUNCS(close, CLOSE); CACHEFILES_OBJECT_STATE_FUNCS(reopening, REOPENING); +CACHEFILES_OBJECT_STATE_FUNCS(dropping, DROPPING); =20 static inline bool cachefiles_ondemand_is_reopening_read(struct cachefiles= _req *req) { diff --git a/fs/cachefiles/ondemand.c b/fs/cachefiles/ondemand.c index 4ba42f1fa3b4..73da4d4eaa9b 100644 --- a/fs/cachefiles/ondemand.c +++ b/fs/cachefiles/ondemand.c @@ -422,7 +422,8 @@ static int cachefiles_ondemand_send_req(struct cachefil= es_object *object, */ xas_lock(&xas); =20 - if (test_bit(CACHEFILES_DEAD, &cache->flags)) { + if (test_bit(CACHEFILES_DEAD, &cache->flags) || + cachefiles_ondemand_object_is_dropping(object)) { xas_unlock(&xas); ret =3D -EIO; goto out; @@ -463,7 +464,8 @@ static int cachefiles_ondemand_send_req(struct cachefil= es_object *object, * If error occurs after creating the anonymous fd, * cachefiles_ondemand_fd_release() will set object to close. */ - if (opcode =3D=3D CACHEFILES_OP_OPEN) + if (opcode =3D=3D CACHEFILES_OP_OPEN && + !cachefiles_ondemand_object_is_dropping(object)) cachefiles_ondemand_set_object_close(object); kfree(req); return ret; @@ -562,8 +564,12 @@ int cachefiles_ondemand_init_object(struct cachefiles_= object *object) =20 void cachefiles_ondemand_clean_object(struct cachefiles_object *object) { + if (!object->ondemand) + return; + cachefiles_ondemand_send_req(object, CACHEFILES_OP_CLOSE, 0, cachefiles_ondemand_init_close_req, NULL); + cachefiles_ondemand_set_object_dropping(object); } =20 int cachefiles_ondemand_init_obj_info(struct cachefiles_object *object, --=20 2.39.2 From nobody Fri Nov 1 00:06:51 2024 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 93A5213A269; Wed, 24 Apr 2024 03:43:27 +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=1713930210; cv=none; b=Y5pB8o1TcIsyLK5BM/FhdKsBHXWHNDkmpfBiTUZY6qm6MKj780c+OxtIMBMboYCciZmpqPGgQAYGdlt+cx8NdxFdUaEy/7KSEcelW2VpoIT/Lt2PfIpco9MnZPCXCUtUVE6eVrld1jIuxesvxLfnb0vkOq0yJTPhevTUQR4uPrM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713930210; c=relaxed/simple; bh=FWPnk36V1OK9PX17AcxLnoB+X4xnXfKi61b03aCPTDM=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=ku0BxgbUhAZJaUTclMp6ALAxhDsWtM67KNartdGLQmUR8z+2A5dYxuPYyiml9I9ke66HQ59Hm8FcQWCciTbpFH1vQlf2XtkMMvdtX34ZlLVLzJFP+/IR/hwD5SjRtcWMnMoNQyYbOpi4RbNpCyoKzH7mwGzrzlNVqWinf6la8ts= 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.163.216]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTP id 4VPPw51R9Nz4f3kjD; Wed, 24 Apr 2024 11:43:17 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.112]) by mail.maildlp.com (Postfix) with ESMTP id B748E1A08D9; Wed, 24 Apr 2024 11:43:24 +0800 (CST) Received: from huaweicloud.com (unknown [10.175.104.67]) by APP1 (Coremail) with SMTP id cCh0CgBHGBHafyhmuSA4Kw--.57541S6; Wed, 24 Apr 2024 11:43:24 +0800 (CST) From: libaokun@huaweicloud.com To: netfs@lists.linux.dev Cc: dhowells@redhat.com, jlayton@kernel.org, zhujia.zj@bytedance.com, jefflexu@linux.alibaba.com, linux-cachefs@redhat.com, linux-erofs@lists.ozlabs.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, libaokun@huaweicloud.com, Baokun Li Subject: [PATCH 2/5] cachefiles: flush all requests for the object that is being dropped Date: Wed, 24 Apr 2024 11:34:06 +0800 Message-Id: <20240424033409.2735257-3-libaokun@huaweicloud.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20240424033409.2735257-1-libaokun@huaweicloud.com> References: <20240424033409.2735257-1-libaokun@huaweicloud.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-CM-TRANSID: cCh0CgBHGBHafyhmuSA4Kw--.57541S6 X-Coremail-Antispam: 1UD129KBjvJXoW7ur18JF1DXF1rZF17Jr4kXrb_yoW8Xr1rpF WayFy3Kry8WF47CrZ3AF9YqrySy3ykuFnrX3WaqayrArn8XrWrZr15twn8ZFyUA3yfXr4f tw4FkasxK34qy3DanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUQY14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWUWVWUuwAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_Jryl82xGYIkIc2 x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2z4x0 Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F4UJw A2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq3wAS 0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7IYx2 IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0 Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2kIc2 xKxwAKzVCY07xG64k0F24lc7CjxVAKzI0EY4vE52x082I5MxAIw28IcxkI7VAKI48JMxC2 0s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI 0_JrI_JrWlx4CE17CEb7AF67AKxVWUtVW8ZwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE 14v26r1I6r4UMIIF0xvE2Ix0cI8IcVCY1x0267AKxVW8Jr0_Cr1UMIIF0xvE42xK8VAvwI 8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v2 6r4UJVWxJrUvcSsGvfC2KfnxnUUI43ZEXa7VUj3ku7UUUUU== X-CM-SenderInfo: 5olet0hnxqqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Baokun Li Because after an object is dropped, requests for that object are useless, flush them to avoid causing other problems. Signed-off-by: Baokun Li --- fs/cachefiles/ondemand.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/fs/cachefiles/ondemand.c b/fs/cachefiles/ondemand.c index 73da4d4eaa9b..d24bff43499b 100644 --- a/fs/cachefiles/ondemand.c +++ b/fs/cachefiles/ondemand.c @@ -564,12 +564,31 @@ int cachefiles_ondemand_init_object(struct cachefiles= _object *object) =20 void cachefiles_ondemand_clean_object(struct cachefiles_object *object) { + unsigned long index; + struct cachefiles_req *req; + struct cachefiles_cache *cache; + if (!object->ondemand) return; =20 cachefiles_ondemand_send_req(object, CACHEFILES_OP_CLOSE, 0, cachefiles_ondemand_init_close_req, NULL); + + if (!object->ondemand->ondemand_id) + return; + + /* Flush all requests for the object that is being dropped. */ + cache =3D object->volume->cache; + xa_lock(&cache->reqs); cachefiles_ondemand_set_object_dropping(object); + xa_for_each(&cache->reqs, index, req) { + if (req->object =3D=3D object) { + req->error =3D -EIO; + complete(&req->done); + __xa_erase(&cache->reqs, index); + } + } + xa_unlock(&cache->reqs); } =20 int cachefiles_ondemand_init_obj_info(struct cachefiles_object *object, --=20 2.39.2 From nobody Fri Nov 1 00:06:51 2024 Received: from dggsgout11.his.huawei.com (unknown [45.249.212.51]) (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 3E42213B2BF; Wed, 24 Apr 2024 03:43:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.51 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713930209; cv=none; b=odfhzyzpPYHd6TVjfDaH6ydeAW163QEHt39Rw2qeRMRrzGT6CR7FsEFRNG/GvSxF+r7LaRhZdwvQoq87I74N0zo3Ajssnyty1RwIksgNqdcVn1bH/sOZD48ZL787XoOzMqtmxpqn9a/4PkJbVUDz/LAdfEm8IjCh+hpg2Qor528= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713930209; c=relaxed/simple; bh=A5BHeR7uHc2t+fnupZkgPH4mwvlVSQRTKeIrm4tSUbU=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=TAiVBXSGGvkAsYIiXh5k+zYsW5RhffpdjS4fwf4mi47kvC06FAECczY8QIXVPOJAPCNaTL0nnx4BKEk917kTSo/SiMFq8dqRqqw+iuQ0fUxpIwTg3nRcNcJGhD3ZtgJJy47xD570wqlk/EGjaLf5uTNFAFHpOoVq0+NEwr3gj5k= 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.51 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.163.235]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTP id 4VPPw40bslz4f3p0v; Wed, 24 Apr 2024 11:43:16 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.112]) by mail.maildlp.com (Postfix) with ESMTP id 464BC1A0572; Wed, 24 Apr 2024 11:43:25 +0800 (CST) Received: from huaweicloud.com (unknown [10.175.104.67]) by APP1 (Coremail) with SMTP id cCh0CgBHGBHafyhmuSA4Kw--.57541S7; Wed, 24 Apr 2024 11:43:25 +0800 (CST) From: libaokun@huaweicloud.com To: netfs@lists.linux.dev Cc: dhowells@redhat.com, jlayton@kernel.org, zhujia.zj@bytedance.com, jefflexu@linux.alibaba.com, linux-cachefs@redhat.com, linux-erofs@lists.ozlabs.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, libaokun@huaweicloud.com, Hou Tao , Baokun Li Subject: [PATCH 3/5] cachefiles: flush ondemand_object_worker during clean object Date: Wed, 24 Apr 2024 11:34:07 +0800 Message-Id: <20240424033409.2735257-4-libaokun@huaweicloud.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20240424033409.2735257-1-libaokun@huaweicloud.com> References: <20240424033409.2735257-1-libaokun@huaweicloud.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-CM-TRANSID: cCh0CgBHGBHafyhmuSA4Kw--.57541S7 X-Coremail-Antispam: 1UD129KBjvJXoW7Ww4kur4fJF1DXFy7Zw1UKFg_yoW8Cw4rpF WakFy7KrWxWF4DCrWkZFs5JryrK3ykuFnFgFyYq398Ar90qr4rZr12y3ZxXF15Jw4SgrZr tr4UCr9xt34qy3DanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUQY14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWUWVWUuwAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JrWl82xGYIkIc2 x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2z4x0 Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F4UJw A2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq3wAS 0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7IYx2 IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0 Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2kIc2 xKxwAKzVCY07xG64k0F24lc7CjxVAKzI0EY4vE52x082I5MxAIw28IcxkI7VAKI48JMxC2 0s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI 0_JrI_JrWlx4CE17CEb7AF67AKxVWUtVW8ZwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE 14v26r1I6r4UMIIF0xvE2Ix0cI8IcVCY1x0267AKxVW8Jr0_Cr1UMIIF0xvE42xK8VAvwI 8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67AKxVW8JVWxJwCI42IY6I8E87Iv6xkF7I0E14v2 6r4UJVWxJrUvcSsGvfC2KfnxnUUI43ZEXa7VUjfHUDUUUUU== X-CM-SenderInfo: 5olet0hnxqqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Hou Tao When queuing ondemand_object_worker() to re-open the object, cachefiles_object is not pinned. The cachefiles_object may be freed when the pending read request is completed intentionally and the related erofs is umounted. If ondemand_object_worker() runs after the object is freed, it will incur use-after-free problem as shown below. process A processs B process C process D cachefiles_ondemand_send_req() // send a read req X // wait for its completion // close ondemand fd cachefiles_ondemand_fd_release() // set object as CLOSE cachefiles_ondemand_daemon_read() // set object as REOPENING queue_work(fscache_wq, &info->ondemand_work) // close /dev/cachefiles cachefiles_daemon_release cachefiles_flush_reqs complete(&req->done) // read req X is completed // umount the erofs fs cachefiles_put_object() // object will be freed cachefiles_ondemand_deinit_obj_info() kmem_cache_free(object) // both info and object are freed ondemand_object_worker() When dropping an object, it is no longer necessary to reopen the object, so use cancel_work_sync() to cancel or wait for ondemand_object_worker() to complete. Signed-off-by: Hou Tao Signed-off-by: Baokun Li Reviewed-by: Jia Zhu --- fs/cachefiles/ondemand.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/cachefiles/ondemand.c b/fs/cachefiles/ondemand.c index d24bff43499b..f6440b3e7368 100644 --- a/fs/cachefiles/ondemand.c +++ b/fs/cachefiles/ondemand.c @@ -589,6 +589,9 @@ void cachefiles_ondemand_clean_object(struct cachefiles= _object *object) } } xa_unlock(&cache->reqs); + + /* Wait for ondemand_object_worker() to finish to avoid UAF. */ + cancel_work_sync(&object->ondemand->ondemand_work); } =20 int cachefiles_ondemand_init_obj_info(struct cachefiles_object *object, --=20 2.39.2 From nobody Fri Nov 1 00:06:51 2024 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 89F6A13C8F3; Wed, 24 Apr 2024 03:43:28 +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=1713930210; cv=none; b=MZgVdkF9u9+xdhfm+xO8Kj+V8CR6SZQ+PEmtz3S4nofbQm1fCNIxCNPizkEaEvc97zhBvWiNvln8/XMJgboTGx6NlIl0t77D2MrTHgDKSYg8r32Fhi6zwxxvrvZc/sGpiPMoIbDZbwTuKBNU5fpsbWWC4s3nRUMhpZnqa4B13JY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713930210; c=relaxed/simple; bh=D27V7j9H6zmJjtvGLBwi9QEzYwV3vIfj7n5EnJTujdY=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=ohHtqbwilfV3lEXTQBBvIBa6oAoaEhMv39z3TzoQ3yMjMfB8DHFkelVVofFqkZl87Z0vvg3Ft+mHKiNyzDiE2DkE1QRSsmxObqTNOeyrJSE0cg7ODXD5wWRD4Srmb/Q6IMimbU9NeFf4TND3oUGdwhlUYpsYy/gmUGLZo+nH1MU= 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 4VPPw6267Gz4f3knl; Wed, 24 Apr 2024 11:43:18 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.112]) by mail.maildlp.com (Postfix) with ESMTP id CC23B1A0179; Wed, 24 Apr 2024 11:43:25 +0800 (CST) Received: from huaweicloud.com (unknown [10.175.104.67]) by APP1 (Coremail) with SMTP id cCh0CgBHGBHafyhmuSA4Kw--.57541S8; Wed, 24 Apr 2024 11:43:25 +0800 (CST) From: libaokun@huaweicloud.com To: netfs@lists.linux.dev Cc: dhowells@redhat.com, jlayton@kernel.org, zhujia.zj@bytedance.com, jefflexu@linux.alibaba.com, linux-cachefs@redhat.com, linux-erofs@lists.ozlabs.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, libaokun@huaweicloud.com, Baokun Li Subject: [PATCH 4/5] cachefiles: cyclic allocation of msg_id to avoid reuse Date: Wed, 24 Apr 2024 11:34:08 +0800 Message-Id: <20240424033409.2735257-5-libaokun@huaweicloud.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20240424033409.2735257-1-libaokun@huaweicloud.com> References: <20240424033409.2735257-1-libaokun@huaweicloud.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-CM-TRANSID: cCh0CgBHGBHafyhmuSA4Kw--.57541S8 X-Coremail-Antispam: 1UD129KBjvJXoW3Jr1fAF1xurWkur4xuryfWFg_yoW7Xr4rpF WakFy2kry8WF1v9rykZFZ5Jr4fK34kZFsrWrySqry0ywn0vr45Zr1jyr1FqFyUArZ3WF47 tr48WF9rKa42v3DanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUQI14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWUWVWUuwAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F 4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq 3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7 IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4U M4x0Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2 kIc2xKxwAKzVCY07xG64k0F24lc7CjxVAKzI0EY4vE52x082I5MxAIw28IcxkI7VAKI48J MxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwV AFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUtVW8ZwCIc40Y0x0EwIxGrwCI42IY6xIIjxv2 0xvE14v26r4j6ryUMIIF0xvE2Ix0cI8IcVCY1x0267AKxVW8Jr0_Cr1UMIIF0xvE42xK8V AvwI8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67AKxVW8JVWxJwCI42IY6I8E87Iv6xkF7I0E 14v26r4UJVWxJrUvcSsGvfC2KfnxnUUI43ZEXa7VUjs2-5UUUUU== X-CM-SenderInfo: 5olet0hnxqqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Baokun Li Reusing the msg_id after a maliciously completed reopen request may cause a read request to remain unprocessed and result in a hung, as shown below: t1 | t2 | t3 ------------------------------------------------- cachefiles_ondemand_select_req cachefiles_ondemand_object_is_close(A) cachefiles_ondemand_set_object_reopening(A) queue_work(fscache_object_wq, &info->work) ondemand_object_worker cachefiles_ondemand_init_object(A) cachefiles_ondemand_send_req(OPEN) // get msg_id 6 wait_for_completion(&req_A->done) cachefiles_ondemand_daemon_read // read msg_id 6 req_A cachefiles_ondemand_get_fd copy_to_user // Malicious completion msg_id 6 copen 6,-1 // reopen fails, want daemon to close fd, // then set object to close, retrigger reopen cachefiles_ondemand_init_object(B) cachefiles_ondemand_send_req(OPEN) // new open req_B reuse msg_id 6 // daemon successfully copen msg_id 6, so it won't close the fd. // object is always reopening, so read requests are not processed // resulting in a hung Therefore allocate the msg_id cyclically to avoid reusing the msg_id for a very short duration of time causing the above problem. Fixes: c8383054506c ("cachefiles: notify the user daemon when looking up co= okie") Signed-off-by: Baokun Li --- fs/cachefiles/internal.h | 1 + fs/cachefiles/ondemand.c | 92 +++++++++++++++++++++++----------------- 2 files changed, 54 insertions(+), 39 deletions(-) diff --git a/fs/cachefiles/internal.h b/fs/cachefiles/internal.h index 8ecd296cc1c4..9200c00f3e98 100644 --- a/fs/cachefiles/internal.h +++ b/fs/cachefiles/internal.h @@ -128,6 +128,7 @@ struct cachefiles_cache { unsigned long req_id_next; struct xarray ondemand_ids; /* xarray for ondemand_id allocation */ u32 ondemand_id_next; + u32 msg_id_next; }; =20 static inline bool cachefiles_in_ondemand_mode(struct cachefiles_cache *ca= che) diff --git a/fs/cachefiles/ondemand.c b/fs/cachefiles/ondemand.c index f6440b3e7368..6171e1a8cfa1 100644 --- a/fs/cachefiles/ondemand.c +++ b/fs/cachefiles/ondemand.c @@ -404,51 +404,65 @@ static int cachefiles_ondemand_send_req(struct cachef= iles_object *object, if (ret) goto out; =20 - do { - /* - * Stop enqueuing the request when daemon is dying. The - * following two operations need to be atomic as a whole. - * 1) check cache state, and - * 2) enqueue request if cache is alive. - * Otherwise the request may be enqueued after xarray has been - * flushed, leaving the orphan request never being completed. - * - * CPU 1 CPU 2 - * =3D=3D=3D=3D=3D =3D=3D=3D=3D=3D - * test CACHEFILES_DEAD bit - * set CACHEFILES_DEAD bit - * flush requests in the xarray - * enqueue the request - */ - xas_lock(&xas); - - if (test_bit(CACHEFILES_DEAD, &cache->flags) || - cachefiles_ondemand_object_is_dropping(object)) { - xas_unlock(&xas); - ret =3D -EIO; - goto out; - } +retry: + /* + * Stop enqueuing the request when daemon is dying. The + * following two operations need to be atomic as a whole. + * 1) check cache state, and + * 2) enqueue request if cache is alive. + * Otherwise the request may be enqueued after xarray has been + * flushed, leaving the orphan request never being completed. + * + * CPU 1 CPU 2 + * =3D=3D=3D=3D=3D =3D=3D=3D=3D=3D + * test CACHEFILES_DEAD bit + * set CACHEFILES_DEAD bit + * flush requests in the xarray + * enqueue the request + */ + xas_lock(&xas); =20 - /* coupled with the barrier in cachefiles_flush_reqs() */ - smp_mb(); + if (test_bit(CACHEFILES_DEAD, &cache->flags) || + cachefiles_ondemand_object_is_dropping(object)) { + xas_unlock(&xas); + ret =3D -EIO; + goto out; + } =20 - if (opcode =3D=3D CACHEFILES_OP_CLOSE && - !cachefiles_ondemand_object_is_open(object)) { - WARN_ON_ONCE(object->ondemand->ondemand_id =3D=3D 0); - xas_unlock(&xas); - ret =3D -EIO; - goto out; - } + /* coupled with the barrier in cachefiles_flush_reqs() */ + smp_mb(); + + if (opcode =3D=3D CACHEFILES_OP_CLOSE && + !cachefiles_ondemand_object_is_open(object)) { + WARN_ON_ONCE(object->ondemand->ondemand_id =3D=3D 0); + xas_unlock(&xas); + ret =3D -EIO; + goto out; + } =20 + /* + * Cyclically find a free xas to avoid msg_id reuse that would + * cause the daemon to successfully copen a stale msg_id. + */ + xas.xa_index =3D cache->msg_id_next; + xas_find_marked(&xas, UINT_MAX, XA_FREE_MARK); + if (xas.xa_node =3D=3D XAS_RESTART) { xas.xa_index =3D 0; - xas_find_marked(&xas, UINT_MAX, XA_FREE_MARK); - if (xas.xa_node =3D=3D XAS_RESTART) - xas_set_err(&xas, -EBUSY); - xas_store(&xas, req); + xas_find_marked(&xas, cache->msg_id_next - 1, XA_FREE_MARK); + } + if (xas.xa_node =3D=3D XAS_RESTART) + xas_set_err(&xas, -EBUSY); + + xas_store(&xas, req); + if (xas_valid(&xas)) { + cache->msg_id_next =3D xas.xa_index + 1; xas_clear_mark(&xas, XA_FREE_MARK); xas_set_mark(&xas, CACHEFILES_REQ_NEW); - xas_unlock(&xas); - } while (xas_nomem(&xas, GFP_KERNEL)); + } + + xas_unlock(&xas); + if (xas_nomem(&xas, GFP_KERNEL)) + goto retry; =20 ret =3D xas_error(&xas); if (ret) --=20 2.39.2 From nobody Fri Nov 1 00:06:51 2024 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 3F63314265E; Wed, 24 Apr 2024 03:43:28 +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=1713930210; cv=none; b=VOia3K1+qa616Ti8AxucPxl+HNXve2lIwn1QABaCPm86Mbt8LbdPWXN47OLn24vRsn0u9j+NHtWNdrd+qrH56mtItQkUN63lhivsbwvz/4ZQ+4NH4p5aLwH2jF7NUnL5B6qAmd9M4fXKvtaWYnxX3ePKVMSmLvGiJ8AKEkkS8/o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713930210; c=relaxed/simple; bh=5R4vmUl2Os6oBqdql/2NCKIR1BOUmNtB4sSAUTZoF3Q=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=DuI2GsQwZAc1BoR6SbS0L0AgiyeudH2vECNmNC0ygcJN4Ew/I6Z7vOVSVhlGFpWuzIr0F28vwnjyw0FdFxsupSbapVnsKNBmjYfLIEmUn8EWU3DQB2PnaSAocjHfjppmfEQodoHsIWi4lYXYJrRqps1fHAfKRKS6Z3erm/NAHRE= 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.163.216]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTP id 4VPPw66DqZz4f3kGH; Wed, 24 Apr 2024 11:43:18 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.112]) by mail.maildlp.com (Postfix) with ESMTP id 6794E1A08D9; Wed, 24 Apr 2024 11:43:26 +0800 (CST) Received: from huaweicloud.com (unknown [10.175.104.67]) by APP1 (Coremail) with SMTP id cCh0CgBHGBHafyhmuSA4Kw--.57541S9; Wed, 24 Apr 2024 11:43:26 +0800 (CST) From: libaokun@huaweicloud.com To: netfs@lists.linux.dev Cc: dhowells@redhat.com, jlayton@kernel.org, zhujia.zj@bytedance.com, jefflexu@linux.alibaba.com, linux-cachefs@redhat.com, linux-erofs@lists.ozlabs.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, libaokun@huaweicloud.com, Joseph Qi , Gao Xiang , Baokun Li Subject: [PATCH 5/5] cachefiles: add missing lock protection when polling Date: Wed, 24 Apr 2024 11:34:09 +0800 Message-Id: <20240424033409.2735257-6-libaokun@huaweicloud.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20240424033409.2735257-1-libaokun@huaweicloud.com> References: <20240424033409.2735257-1-libaokun@huaweicloud.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-CM-TRANSID: cCh0CgBHGBHafyhmuSA4Kw--.57541S9 X-Coremail-Antispam: 1UD129KBjvJXoW7tF4rWr4Dtr4furW3uw4rZrb_yoW8Wr17pF WSya4Utry8ur48uF1jva4kJ34SyayDWa4DX3ykXwsFvwnrXr1FqFnak34Ygrn5Jw1kJF42 yw1UGF9xAFWUA3DanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUQI14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWUWVWUuwAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JF0E3s1l82xGYI kIc2x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2 z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F 4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq 3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7 IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4U M4x0Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2 kIc2xKxwAKzVCY07xG64k0F24lc7CjxVAKzI0EY4vE52x082I5MxAIw28IcxkI7VAKI48J MxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwV AFwI0_JrI_JrWlx4CE17CEb7AF67AKxVW8ZVWrXwCIc40Y0x0EwIxGrwCI42IY6xIIjxv2 0xvE14v26r4j6ryUMIIF0xvE2Ix0cI8IcVCY1x0267AKxVW8Jr0_Cr1UMIIF0xvE42xK8V AvwI8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67AKxVW8JVWxJwCI42IY6I8E87Iv6xkF7I0E 14v26r4UJVWxJrUvcSsGvfC2KfnxnUUI43ZEXa7VUjs2-5UUUUU== X-CM-SenderInfo: 5olet0hnxqqx5xdzvxpfor3voofrz/ Content-Type: text/plain; charset="utf-8" From: Jingbo Xu Add missing lock protection in poll routine when iterating xarray, otherwise: Even with RCU read lock held, only the slot of the radix tree is ensured to be pinned there, while the data structure (e.g. struct cachefiles_req) stored in the slot has no such guarantee. The poll routine will iterate the radix tree and dereference cachefiles_req accordingly. Thus RCU read lock is not adequate in this case and spinlock is needed here. Fixes: b817e22b2e91 ("cachefiles: narrow the scope of triggering EPOLLIN ev= ents in ondemand mode") Signed-off-by: Jingbo Xu Reviewed-by: Joseph Qi Reviewed-by: Gao Xiang Signed-off-by: Baokun Li Reviewed-by: Jia Zhu --- fs/cachefiles/daemon.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/cachefiles/daemon.c b/fs/cachefiles/daemon.c index 6465e2574230..73ed2323282a 100644 --- a/fs/cachefiles/daemon.c +++ b/fs/cachefiles/daemon.c @@ -365,14 +365,14 @@ static __poll_t cachefiles_daemon_poll(struct file *f= ile, =20 if (cachefiles_in_ondemand_mode(cache)) { if (!xa_empty(&cache->reqs)) { - rcu_read_lock(); + xas_lock(&xas); xas_for_each_marked(&xas, req, ULONG_MAX, CACHEFILES_REQ_NEW) { if (!cachefiles_ondemand_is_reopening_read(req)) { mask |=3D EPOLLIN; break; } } - rcu_read_unlock(); + xas_unlock(&xas); } } else { if (test_bit(CACHEFILES_STATE_CHANGED, &cache->flags)) --=20 2.39.2