On Thu, Mar 7, 2024 at 1:02 PM Miklos Szeredi <mszeredi@xxxxxxxxxx> wrote:
>
> The only reason parallel readdirs cannot run on the same inode is shared
> access to the readdir cache.
I did not see a cover letter, so I am assuming that the reason for this change
is to improve concurrent readdir.
If I am reading this correctly users can only iterate pure real dirs in parallel
but not merged and impure dirs. Right?
Is there a reason why a specific cached readdir version cannot be iterated
in parallel?
>
> Move lock/unlock to only protect the cache. Exception is the refcount
> which now uses atomic ops.
>
> Signed-off-by: Miklos Szeredi <mszeredi@xxxxxxxxxx>
> ---
> fs/overlayfs/readdir.c | 34 ++++++++++++++++++++--------------
> 1 file changed, 20 insertions(+), 14 deletions(-)
>
> diff --git a/fs/overlayfs/readdir.c b/fs/overlayfs/readdir.c
> index edee9f86f469..b98e0d17f40e 100644
> --- a/fs/overlayfs/readdir.c
> +++ b/fs/overlayfs/readdir.c
> @@ -245,8 +245,10 @@ static void ovl_cache_put(struct ovl_dir_file *od, struct inode *inode)
> struct ovl_dir_cache *cache = od->cache;
>
> if (refcount_dec_and_test(&cache->refcount)) {
What is stopping ovl_cache_get() to be called now, find a valid cache
and increment its refcount and use it while it is being freed?
Do we need refcount_inc_not_zero() in ovl_cache_get()?
> + ovl_inode_lock(inode);
> if (ovl_dir_cache(inode) == cache)
> ovl_set_dir_cache(inode, NULL);
> + ovl_inode_unlock(inode);
>
> ovl_cache_free(&cache->entries);
> kfree(cache);
P.S. A guard for ovl_inode_lock() would have been useful in this patch set,
but it's up to you if you want to define one and use it.
Thanks,
Amir.
