linux-cifs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Aurélien Aptel" <aaptel@suse.com>
To: Ronnie Sahlberg <lsahlber@redhat.com>,
	linux-cifs <linux-cifs@vger.kernel.org>
Cc: Steve French <smfrench@gmail.com>
Subject: Re: [PATCH 3/3] cifs: cache the directory content for shroot
Date: Wed, 07 Oct 2020 14:21:42 +0200	[thread overview]
Message-ID: <878scii5ux.fsf@suse.com> (raw)
In-Reply-To: <20201005211622.18097-1-lsahlber@redhat.com>

Hi Ronnie,

I'm assuming this is the latest V4:

Can you document which functions require a lock to be held when calling?

Would it work properly if in any of the patched functions we have this scenario:

TASK A                              DEMULTIPLEX THREAD
------                              ------------------
open_shroot()                           
...                                    oplock break on shroot
                                       ...close/reopen shroot, fid and ptr gets updated...
...                                       
do stuff with dirents (with old fid/ptr?)
...
close_shroot()

More comments below:

Ronnie Sahlberg <lsahlber@redhat.com> writes:
> +
> +static bool cifs_dir_emit(struct dir_context *ctx,
> +			  const char *name, int namelen,
> +			  u64 ino, unsigned type,
> +			  struct cached_fid *cfid)
> +{
> +	bool rc;
> +
> +	rc = dir_emit(ctx, name, namelen, ino, type);
> +	if (!rc)
> +		return rc;
> +
> +	if (cfid) {
> +		mutex_lock(&cfid->dirents.de_mutex);
> +		add_cached_dirent(&cfid->dirents, ctx, name, namelen, ino,
> +				  type);
> +		mutex_unlock(&cfid->dirents.de_mutex);
> +	}
> +
> +	return rc;
> +}

Should return cfid->dirents.is_failed?

> -
>  int cifs_readdir(struct file *file, struct dir_context *ctx)
>  {
>  	int rc = 0;
>  	unsigned int xid;
>  	int i;
> -	struct cifs_tcon *tcon;
> +	struct cifs_tcon *tcon, *mtcon;
>  	struct cifsFileInfo *cifsFile = NULL;
>  	char *current_entry;
>  	int num_to_fill = 0;
> @@ -920,15 +1021,59 @@ int cifs_readdir(struct file *file, struct dir_context *ctx)
>  	char *end_of_smb;
>  	unsigned int max_len;
>  	char *full_path = NULL;
> +	struct cached_fid *cfid = NULL;
> +	struct cifs_sb_info *cifs_sb = CIFS_FILE_SB(file);
>  
>  	xid = get_xid();
> -
>  	full_path = build_path_from_dentry(file_dentry(file));
>  	if (full_path == NULL) {
>  		rc = -ENOMEM;
>  		goto rddir2_exit;
>  	}
>  
> +	mtcon = cifs_sb_master_tcon(cifs_sb);

Why using the master tcon? The rest of the code is using the user
tcon.


> +	if (!is_smb1_server(mtcon->ses->server) && !strcmp(full_path, "")) {
> +		rc = open_shroot(xid, mtcon, cifs_sb, &cfid);
> +		if (rc)
> +			goto cache_not_found;
> +
> +		mutex_lock(&cfid->dirents.de_mutex);
> +		/*
> +		 * If this was reading from the start of the directory
> +		 * we need to initialize scanning and storing the
> +		 * directory content.
> +		 */
> +		if (ctx->pos == 0 && cfid->dirents.ctx == NULL) {
> +			cfid->dirents.ctx = ctx;
> +			cfid->dirents.pos = 2;
> +		}
> +		/*
> +		 * If we already have the entire directory cached then
> +		 * we can just serve the cache.
> +		 */
> +		if (cfid->dirents.is_valid) {
> +			if (!dir_emit_dots(file, ctx)){
> +				mutex_unlock(&cfid->dirents.de_mutex);
> +				goto rddir2_exit;
> +			}
> +			emit_cached_dirents(&cfid->dirents, ctx);
> +			mutex_unlock(&cfid->dirents.de_mutex);
> +			goto rddir2_exit;
> +		}
> +		mutex_unlock(&cfid->dirents.de_mutex);
> +	}
> + cache_not_found:
> +
> +	/* Drop the cache while calling initiate_cifs_search and
> +	 * find_cifs_entry in case there will be reconnects during
> +	 * query_directory.
> +	 */

comment style

Cheers,
-- 
Aurélien Aptel / SUSE Labs Samba Team
GPG: 1839 CB5F 9F5B FB9B AA97  8C99 03C8 A49B 521B D5D3
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 247165 (AG München)

  reply	other threads:[~2020-10-07 12:21 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-05 21:16 [PATCH 3/3] cifs: cache the directory content for shroot Ronnie Sahlberg
2020-10-07 12:21 ` Aurélien Aptel [this message]
  -- strict thread matches above, loose matches on Subject: below --
2020-10-05  2:37 [PATCH 0/3 V1] " Ronnie Sahlberg
2020-10-05  2:37 ` [PATCH 3/3] " Ronnie Sahlberg
2020-10-04 23:37 [PATCH 0/3 V2]: cifs: cache " Ronnie Sahlberg
2020-10-04 23:37 ` [PATCH 3/3] cifs: cache the " Ronnie Sahlberg
2020-10-01 20:50 [PATCH 0/3] cifs: cache " Ronnie Sahlberg
2020-10-01 20:50 ` [PATCH 3/3] cifs: cache the " Ronnie Sahlberg
2020-10-01 22:24   ` Steve French
2020-10-02 15:29   ` Aurélien Aptel
2020-10-04 23:19     ` ronnie sahlberg
     [not found]       ` <CAH2r5mvijc=-JdmPMUxAUqmJKy0-x3o72NsHx+QcByBnggGXMA@mail.gmail.com>
2020-10-05  0:20         ` ronnie sahlberg
2020-10-20 10:28   ` Shyam Prasad N

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=878scii5ux.fsf@suse.com \
    --to=aaptel@suse.com \
    --cc=linux-cifs@vger.kernel.org \
    --cc=lsahlber@redhat.com \
    --cc=smfrench@gmail.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).