All of lore.kernel.org
 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: 11+ 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  6:47 kernel test robot
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.