Re: [PATCH] 9pfs: Fix potential deadlock of QEMU mainloop

2020-05-07 Thread Greg Kurz
On Thu, 07 May 2020 17:03:46 +0200 Christian Schoenebeck wrote: > On Donnerstag, 7. Mai 2020 16:33:28 CEST Greg Kurz wrote: > > > I also haven't reviewed QEMU's lock implementations in very detail, but > > > IIRC CoMutexes are completely handled in user space, while QemuMutex uses > > > regular

Re: [PATCH] 9pfs: Fix potential deadlock of QEMU mainloop

2020-05-07 Thread Christian Schoenebeck
On Donnerstag, 7. Mai 2020 16:33:28 CEST Greg Kurz wrote: > > I also haven't reviewed QEMU's lock implementations in very detail, but > > IIRC CoMutexes are completely handled in user space, while QemuMutex uses > > regular OS mutexes and hence might cost context switches. > > ... since the

Re: [PATCH] 9pfs: Fix potential deadlock of QEMU mainloop

2020-05-07 Thread Greg Kurz
On Thu, 07 May 2020 13:37:30 +0200 Christian Schoenebeck wrote: > On Mittwoch, 6. Mai 2020 19:49:10 CEST Greg Kurz wrote: > > > Ok, but why not both? Moving locks to worker thread and QemuMutex -> > > > CoMutex? > > Using CoMutex would be mandatory if we leave the locking where it sits > >

Re: [PATCH] 9pfs: Fix potential deadlock of QEMU mainloop

2020-05-07 Thread Greg Kurz
On Thu, 07 May 2020 13:46:50 +0200 Christian Schoenebeck wrote: > On Mittwoch, 6. Mai 2020 19:54:15 CEST Greg Kurz wrote: > > On Wed, 06 May 2020 15:36:16 +0200 > > > > Christian Schoenebeck wrote: > > > On Mittwoch, 6. Mai 2020 15:05:23 CEST Christian Schoenebeck wrote: > > > > > diff --git

Re: [PATCH] 9pfs: Fix potential deadlock of QEMU mainloop

2020-05-07 Thread Christian Schoenebeck
On Mittwoch, 6. Mai 2020 19:54:15 CEST Greg Kurz wrote: > On Wed, 06 May 2020 15:36:16 +0200 > > Christian Schoenebeck wrote: > > On Mittwoch, 6. Mai 2020 15:05:23 CEST Christian Schoenebeck wrote: > > > > diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c > > > > index 9e046f7acb51..ac84ae804496 100644 >

Re: [PATCH] 9pfs: Fix potential deadlock of QEMU mainloop

2020-05-07 Thread Christian Schoenebeck
On Mittwoch, 6. Mai 2020 19:49:10 CEST Greg Kurz wrote: > > Ok, but why not both? Moving locks to worker thread and QemuMutex -> > > CoMutex? > Using CoMutex would be mandatory if we leave the locking where it sits > today, so that the main thread can switch to other coroutines instead > of

Re: [PATCH] 9pfs: Fix potential deadlock of QEMU mainloop

2020-05-06 Thread Greg Kurz
On Wed, 06 May 2020 15:36:16 +0200 Christian Schoenebeck wrote: > On Mittwoch, 6. Mai 2020 15:05:23 CEST Christian Schoenebeck wrote: > > > diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c > > > index 9e046f7acb51..ac84ae804496 100644 > > > --- a/hw/9pfs/9p.c > > > +++ b/hw/9pfs/9p.c > > > @@ -2170,7

Re: [PATCH] 9pfs: Fix potential deadlock of QEMU mainloop

2020-05-06 Thread Greg Kurz
On Wed, 06 May 2020 15:05:23 +0200 Christian Schoenebeck wrote: > On Donnerstag, 30. April 2020 17:53:34 CEST Greg Kurz wrote: > > Locking was introduced 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

Re: [PATCH] 9pfs: Fix potential deadlock of QEMU mainloop

2020-05-06 Thread Christian Schoenebeck
On Mittwoch, 6. Mai 2020 15:05:23 CEST Christian Schoenebeck wrote: > > diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c > > index 9e046f7acb51..ac84ae804496 100644 > > --- a/hw/9pfs/9p.c > > +++ b/hw/9pfs/9p.c > > @@ -2170,7 +2170,7 @@ static int coroutine_fn > > v9fs_do_readdir_with_stat(V9fsPDU *pdu,

Re: [PATCH] 9pfs: Fix potential deadlock of QEMU mainloop

2020-05-06 Thread Christian Schoenebeck
On Donnerstag, 30. April 2020 17:53:34 CEST Greg Kurz wrote: > Locking was introduced 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

[PATCH] 9pfs: Fix potential deadlock of QEMU mainloop

2020-04-30 Thread Greg Kurz
Locking was introduced 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 control, waiting for the fsdev