linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: libaokun@huaweicloud.com, netfs@lists.linux.dev, dhowells@redhat.com
Cc: hsiangkao@linux.alibaba.com, jefflexu@linux.alibaba.com,
	 zhujia.zj@bytedance.com, linux-erofs@lists.ozlabs.org,
	 linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	 yangerkun@huawei.com, houtao1@huawei.com, yukuai3@huawei.com,
	wozizhi@huawei.com,  Baokun Li <libaokun1@huawei.com>
Subject: Re: [PATCH v2 2/5] cachefiles: flush all requests for the object that is being dropped
Date: Thu, 27 Jun 2024 07:01:37 -0400	[thread overview]
Message-ID: <5bb711c4bbc59ea9fff486a86acce13880823e7b.camel@kernel.org> (raw)
In-Reply-To: <20240515125136.3714580-3-libaokun@huaweicloud.com>

On Wed, 2024-05-15 at 20:51 +0800, libaokun@huaweicloud.com wrote:
> From: Baokun Li <libaokun1@huawei.com>
> 
> Because after an object is dropped, requests for that object are
> useless,
> flush them to avoid causing other problems.
> 
> This prepares for the later addition of cancel_work_sync(). After the
> reopen requests is generated, flush it to avoid cancel_work_sync()
> blocking by waiting for daemon to complete the reopen requests.
> 
> Signed-off-by: Baokun Li <libaokun1@huawei.com>
> ---
>  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)
>  
>  void cachefiles_ondemand_clean_object(struct cachefiles_object
> *object)
>  {
> +	unsigned long index;
> +	struct cachefiles_req *req;
> +	struct cachefiles_cache *cache;
> +
>  	if (!object->ondemand)
>  		return;
>  
>  	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.
> */

I wouldn't call this a "Flush". In the context of writeback, that
usually means that we're writing out pages now in order to do something
else. In this case, it looks like you're more canceling these requests
since you're marking them with an error and declaring them complete.

> +	cache = object->volume->cache;
> +	xa_lock(&cache->reqs);
>  	cachefiles_ondemand_set_object_dropping(object);
> +	xa_for_each(&cache->reqs, index, req) {
> +		if (req->object == object) {
> +			req->error = -EIO;
> +			complete(&req->done);
> +			__xa_erase(&cache->reqs, index);
> +		}
> +	}
> +	xa_unlock(&cache->reqs);
>  }
>  
>  int cachefiles_ondemand_init_obj_info(struct cachefiles_object
> *object,

-- 
Jeff Layton <jlayton@kernel.org>

  reply	other threads:[~2024-06-27 11:01 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-15 12:51 [PATCH v2 0/5] cachefiles: some bugfixes for clean object/send req/poll libaokun
2024-05-15 12:51 ` [PATCH v2 1/5] cachefiles: stop sending new request when dropping object libaokun
2024-05-15 12:51 ` [PATCH v2 2/5] cachefiles: flush all requests for the object that is being dropped libaokun
2024-06-27 11:01   ` Jeff Layton [this message]
2024-06-27 11:20     ` Baokun Li
2024-06-27 15:18       ` Christian Brauner
2024-06-28  1:09         ` Baokun Li
2024-05-15 12:51 ` [PATCH v2 3/5] cachefiles: flush ondemand_object_worker during clean object libaokun
2024-05-15 12:51 ` [PATCH v2 4/5] cachefiles: cyclic allocation of msg_id to avoid reuse libaokun
2024-05-19 11:11   ` Jeff Layton
2024-05-20  4:06     ` Baokun Li
2024-05-20 10:04       ` Jeff Layton
2024-05-20 12:42         ` Baokun Li
2024-05-20 12:54           ` Gao Xiang
2024-05-20 13:24             ` Baokun Li
2024-05-20 14:56               ` Gao Xiang
2024-05-21  2:36                 ` Baokun Li
2024-05-21  2:53                   ` Gao Xiang
2024-05-20 13:24           ` Jeff Layton
2024-05-15 12:51 ` [PATCH v2 5/5] cachefiles: add missing lock protection when polling libaokun
2024-06-26  3:04 ` [PATCH v2 0/5] cachefiles: some bugfixes for clean object/send req/poll Baokun Li
2024-06-26  3:28   ` Gao Xiang
2024-06-27  1:49     ` Baokun Li
2024-06-27  2:08       ` Gao Xiang
2024-06-27  2:18         ` Baokun Li
2024-06-27 11:03 ` Jeff Layton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5bb711c4bbc59ea9fff486a86acce13880823e7b.camel@kernel.org \
    --to=jlayton@kernel.org \
    --cc=dhowells@redhat.com \
    --cc=houtao1@huawei.com \
    --cc=hsiangkao@linux.alibaba.com \
    --cc=jefflexu@linux.alibaba.com \
    --cc=libaokun1@huawei.com \
    --cc=libaokun@huaweicloud.com \
    --cc=linux-erofs@lists.ozlabs.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netfs@lists.linux.dev \
    --cc=wozizhi@huawei.com \
    --cc=yangerkun@huawei.com \
    --cc=yukuai3@huawei.com \
    --cc=zhujia.zj@bytedance.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).