On Mittwoch, 17. Juni 2020 00:46:26 CEST Michael Roth wrote:
> > > Indeed, for that particular stable branch I would see the following 9p
> > > fixes as additional candidates (chronologically top down):
> > >
> > > 841b8d099c [trivial] 9pfs: local: Fix possible memory leak in
> > > local_link()
>
Quoting Greg Kurz (2020-06-16 11:41:36)
> On Tue, 16 Jun 2020 18:09:04 +0200
> Christian Schoenebeck wrote:
>
> > On Dienstag, 16. Juni 2020 17:14:40 CEST Greg Kurz wrote:
> > > Cc'ing co-maintainer Christian Schoenebeck.
> > >
> > > Christian,
> > >
> > > If there are some more commits you
On Tue, 16 Jun 2020 18:09:04 +0200
Christian Schoenebeck wrote:
> On Dienstag, 16. Juni 2020 17:14:40 CEST Greg Kurz wrote:
> > Cc'ing co-maintainer Christian Schoenebeck.
> >
> > Christian,
> >
> > If there are some more commits you think are worth being cherry picked
> > for QEMU 4.2.1,
On Dienstag, 16. Juni 2020 17:14:40 CEST Greg Kurz wrote:
> Cc'ing co-maintainer Christian Schoenebeck.
>
> Christian,
>
> If there are some more commits you think are worth being cherry picked
> for QEMU 4.2.1, please inform Michael before freeze on 2020-06-22.
Indeed, for that particular
Cc'ing co-maintainer Christian Schoenebeck.
Christian,
If there are some more commits you think are worth being cherry picked
for QEMU 4.2.1, please inform Michael before freeze on 2020-06-22.
Cheers,
--
Greg
On Tue, 16 Jun 2020 09:15:41 -0500
Michael Roth wrote:
> From: Greg Kurz
>
>
From: Greg Kurz
Locking was introduced in QEMU 2.7 to address the deprecation of
readdir_r(3) in glibc 2.24. It turns out that the frontend code is
the worst place to handle a critical section with a pthread mutex:
the code runs in a coroutine on behalf of the QEMU mainloop and then
yields
