All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christian Schoenebeck <qemu_oss@crudebyte.com>
To: qemu-devel@nongnu.org
Cc: Greg Kurz <groug@kaod.org>
Subject: Re: [PATCH v7 5/6] 9pfs: differentiate readdir lock between 9P2000.u vs. 9P2000.L
Date: Tue, 28 Jul 2020 11:46:09 +0200	[thread overview]
Message-ID: <5466858.CMtu22SHpU@silver> (raw)
In-Reply-To: <abccfcad6764986c8442f2163de618af11232475.1595166227.git.qemu_oss@crudebyte.com>

On Sonntag, 19. Juli 2020 15:20:11 CEST Christian Schoenebeck wrote:
> Previous patch suggests that it might make sense to use a different mutex
> type now while handling readdir requests, depending on the precise
> protocol variant, as v9fs_do_readdir_with_stat() (used by 9P2000.u) uses
> a CoMutex to avoid deadlocks that might happen with QemuMutex otherwise,
> whereas do_readdir_many() (used by 9P2000.L) should better use a
> QemuMutex, as the precise behaviour of a failed CoMutex lock on fs driver
> side would not be clear.
> 
> This patch is just intended as transitional measure, as currently 9P2000.u
> vs. 9P2000.L implementations currently differ where the main logic of
> fetching directory entries is located at (9P2000.u still being more top
> half focused, while 9P2000.L already being bottom half focused in regards
> to fetching directory entries that is).
> 
> Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
> ---
>  hw/9pfs/9p.c |  4 ++--
>  hw/9pfs/9p.h | 27 ++++++++++++++++++++++-----
>  2 files changed, 24 insertions(+), 7 deletions(-)
> 
> diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
> index cc4094b971..a0881ddc88 100644
> --- a/hw/9pfs/9p.c
> +++ b/hw/9pfs/9p.c
> @@ -314,8 +314,8 @@ static V9fsFidState *alloc_fid(V9fsState *s, int32_t
> fid) f->next = s->fid_list;
>      s->fid_list = f;
> 
> -    v9fs_readdir_init(&f->fs.dir);
> -    v9fs_readdir_init(&f->fs_reclaim.dir);
> +    v9fs_readdir_init(s->proto_version, &f->fs.dir);
> +    v9fs_readdir_init(s->proto_version, &f->fs_reclaim.dir);
> 
>      return f;
>  }
> diff --git a/hw/9pfs/9p.h b/hw/9pfs/9p.h
> index 93b7030edf..3dd1b50b1a 100644
> --- a/hw/9pfs/9p.h
> +++ b/hw/9pfs/9p.h
> @@ -197,22 +197,39 @@ typedef struct V9fsXattr
> 
>  typedef struct V9fsDir {
>      DIR *stream;
> -    CoMutex readdir_mutex;
> +    P9ProtoVersion proto_version;
> +    /* readdir mutex type used for 9P2000.u protocol variant */
> +    CoMutex readdir_mutex_u;
> +    /* readdir mutex type used for 9P2000.L protocol variant */
> +    QemuMutex readdir_mutex_L;
>  } V9fsDir;
> 
>  static inline void v9fs_readdir_lock(V9fsDir *dir)
>  {
> -    qemu_co_mutex_lock(&dir->readdir_mutex);
> +    if (dir->proto_version == V9FS_PROTO_2000U) {
> +        qemu_co_mutex_lock(&dir->readdir_mutex_u);
> +    } else {
> +        qemu_mutex_lock(&dir->readdir_mutex_L);
> +    }
>  }

I wonder whether I should make a minor addition to this patch: returnig an 
error to client if client sends T_readdir while not having opened the session 
as 9P2000.L, and likewise returning an error if client sends T_read on a 
directory while not using a 9P2000.u session. That would prevent the 
thoretical issue of a broken client using the wrong mutex type.

It's maybe overkill, since the plan was actually to bury this patch in git 
history by subsequently removing the lock entirely, but as I am preparing a v8 
anyway, and this is like 2 lines more, so probably not a big deal to add it.

>  static inline void v9fs_readdir_unlock(V9fsDir *dir)
>  {
> -    qemu_co_mutex_unlock(&dir->readdir_mutex);
> +    if (dir->proto_version == V9FS_PROTO_2000U) {
> +        qemu_co_mutex_unlock(&dir->readdir_mutex_u);
> +    } else {
> +        qemu_mutex_unlock(&dir->readdir_mutex_L);
> +    }
>  }
> 
> -static inline void v9fs_readdir_init(V9fsDir *dir)
> +static inline void v9fs_readdir_init(P9ProtoVersion proto_version, V9fsDir
> *dir) {
> -    qemu_co_mutex_init(&dir->readdir_mutex);
> +    dir->proto_version = proto_version;
> +    if (proto_version == V9FS_PROTO_2000U) {
> +        qemu_co_mutex_init(&dir->readdir_mutex_u);
> +    } else {
> +        qemu_mutex_init(&dir->readdir_mutex_L);
> +    }
>  }
> 
>  /**

Best regards,
Christian Schoenebeck




  reply	other threads:[~2020-07-28  9:46 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-19 13:43 [PATCH v7 0/6] 9pfs: readdir optimization Christian Schoenebeck
2020-07-19 11:20 ` [PATCH v7 1/6] tests/virtio-9p: added split readdir tests Christian Schoenebeck
2020-07-19 11:24 ` [PATCH v7 2/6] 9pfs: make v9fs_readdir_response_size() public Christian Schoenebeck
2020-07-19 12:29 ` [PATCH v7 3/6] 9pfs: add new function v9fs_co_readdir_many() Christian Schoenebeck
2020-07-28  8:33   ` Christian Schoenebeck
2020-07-28  8:46     ` Greg Kurz
2020-07-28  9:34       ` Christian Schoenebeck
2020-07-28  9:46         ` Greg Kurz
2020-07-19 13:11 ` [PATCH v7 4/6] 9pfs: T_readdir latency optimization Christian Schoenebeck
2020-07-19 13:20 ` [PATCH v7 5/6] 9pfs: differentiate readdir lock between 9P2000.u vs. 9P2000.L Christian Schoenebeck
2020-07-28  9:46   ` Christian Schoenebeck [this message]
2020-07-19 13:39 ` [PATCH v7 6/6] 9pfs: clarify latency of v9fs_co_run_in_worker() Christian Schoenebeck

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=5466858.CMtu22SHpU@silver \
    --to=qemu_oss@crudebyte.com \
    --cc=groug@kaod.org \
    --cc=qemu-devel@nongnu.org \
    /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.