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