From: Christian Schoenebeck <qemu_oss@crudebyte.com>
To: qemu-devel@nongnu.org
Cc: Greg Kurz <groug@kaod.org>
Subject: Re: [PATCH v8 4/7] 9pfs: add new function v9fs_co_readdir_many()
Date: Thu, 06 Aug 2020 11:38:43 +0200 [thread overview]
Message-ID: <3328213.rmLSzsAABv@silver> (raw)
In-Reply-To: <3580376.WKbgaEJolQ@silver>
On Donnerstag, 30. Juli 2020 12:08:33 CEST Christian Schoenebeck wrote:
> > @@ -52,6 +56,167 @@ int coroutine_fn v9fs_co_readdir(V9fsPDU *pdu,
> > V9fsFidState *fidp, return err;
> >
> > }
> >
> > +/*
> > + * This is solely executed on a background IO thread.
> > + *
> > + * See v9fs_co_readdir_many() (as its only user) below for details.
> > + */
> > +static int do_readdir_many(V9fsPDU *pdu, V9fsFidState *fidp,
> > + struct V9fsDirEnt **entries, off_t offset,
> > + int32_t maxsize, bool dostat)
> > +{
> > + V9fsState *s = pdu->s;
> > + V9fsString name;
> > + int len, err = 0;
> > + int32_t size = 0;
> > + off_t saved_dir_pos;
> > + struct dirent *dent;
> > + struct V9fsDirEnt *e = NULL;
> > + V9fsPath path;
> > + struct stat stbuf;
> > +
> > + *entries = NULL;
> > + v9fs_path_init(&path);
> > +
> > + /*
> > + * TODO: Here should be a warn_report_once() if lock failed.
> > + *
> > + * With a good 9p client we should not get into concurrency here,
> > + * because a good client would not use the same fid for concurrent
> > + * requests. We do the lock here for safety reasons though. However
> > + * the client would then suffer performance issues, so better log
> > that
> > + * issue here.
> > + */
> > + v9fs_readdir_lock(&fidp->fs.dir);
> > +
> > + /* seek directory to requested initial position */
> > + if (offset == 0) {
> > + s->ops->rewinddir(&s->ctx, &fidp->fs);
> > + } else {
> > + s->ops->seekdir(&s->ctx, &fidp->fs, offset);
> > + }
> > +
> > + /* save the directory position */
> > + saved_dir_pos = s->ops->telldir(&s->ctx, &fidp->fs);
> > + if (saved_dir_pos < 0) {
> > + err = saved_dir_pos;
> > + goto out;
> > + }
> > +
> > + while (true) {
>
> To address your concern about aborting a readdir request, one could add
> here:
>
> if (v9fs_request_cancelled(pdu)) {
> err = -EINTR;
> break;
> }
>
> That's a minimal invasive change, so it would be Ok to add it to this patch
> already, or at any time later as a separate patch in future, as you like.
I've applied this change now, as well as the minor comment change in patch 3
and pushed this overall patch set onto my queue:
https://github.com/cschoenebeck/qemu/commits/master
My plan is to send a PR once 5.1 is released (in presumably ~1-2 weeks),
unless I hear back from you on anything else on this patch set.
Best regards
Christian Schoenebeck
next prev parent reply other threads:[~2020-08-06 11:52 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-29 8:53 [PATCH v8 0/7] 9pfs: readdir optimization Christian Schoenebeck
2020-07-29 8:10 ` [PATCH v8 1/7] tests/virtio-9p: added split readdir tests Christian Schoenebeck
2020-07-29 15:42 ` Greg Kurz
2020-07-29 17:24 ` Christian Schoenebeck
2020-07-29 8:11 ` [PATCH v8 2/7] 9pfs: make v9fs_readdir_response_size() public Christian Schoenebeck
2020-07-29 15:44 ` Greg Kurz
2020-07-29 8:11 ` [PATCH v8 3/7] 9pfs: split out fs driver core of v9fs_co_readdir() Christian Schoenebeck
2020-07-29 16:02 ` Greg Kurz
2020-07-29 17:38 ` Christian Schoenebeck
2020-07-29 8:12 ` [PATCH v8 4/7] 9pfs: add new function v9fs_co_readdir_many() Christian Schoenebeck
2020-07-30 10:08 ` Christian Schoenebeck
2020-08-06 9:38 ` Christian Schoenebeck [this message]
2020-07-29 8:13 ` [PATCH v8 5/7] 9pfs: T_readdir latency optimization Christian Schoenebeck
2020-07-29 8:39 ` [PATCH v8 6/7] 9pfs: differentiate readdir lock between 9P2000.u vs. 9P2000.L Christian Schoenebeck
2020-07-29 8:42 ` [PATCH v8 7/7] 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=3328213.rmLSzsAABv@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 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).