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)
next prev parent 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).