* [Virtio-fs] [PATCH] virtiofsd: Prevent multiply running with same vhost_user_socket @ 2019-08-01 15:13 Masayoshi Mizuma 2019-08-02 15:39 ` Stefan Hajnoczi 0 siblings, 1 reply; 6+ messages in thread From: Masayoshi Mizuma @ 2019-08-01 15:13 UTC (permalink / raw) To: virtio-fs; +Cc: Masayoshi Mizuma From: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com> virtiofsd can run multiply even if the vhost_user_socket is same path. ]# ./virtiofsd -o vhost_user_socket=/tmp/vhostqemu -o source=/tmp/share & [1] 244965 virtio_session_mount: Waiting for vhost-user socket connection... ]# ./virtiofsd -o vhost_user_socket=/tmp/vhostqemu -o source=/tmp/share & [2] 244966 virtio_session_mount: Waiting for vhost-user socket connection... ]# The file access from the guest works because the second virtiofsd handles that, however, the user will get confused the situation and may be the cause of unexpected problem. So it's better to prevent the multiple running. Change unlink() of the socket to the exit of virtiofsd so that the latter virtiofsd can fail on bind() as EADDRINUSE. Signed-off-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com> --- contrib/virtiofsd/fuse_lowlevel.c | 1 + contrib/virtiofsd/fuse_virtio.c | 1 - 2 files changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/virtiofsd/fuse_lowlevel.c b/contrib/virtiofsd/fuse_lowlevel.c index 8adc4b1ab8..0624d26ffc 100644 --- a/contrib/virtiofsd/fuse_lowlevel.c +++ b/contrib/virtiofsd/fuse_lowlevel.c @@ -2584,6 +2584,7 @@ void fuse_session_destroy(struct fuse_session *se) virtio_session_close(se); } + unlink(se->vu_socket_path); free(se->vu_socket_path); se->vu_socket_path = NULL; diff --git a/contrib/virtiofsd/fuse_virtio.c b/contrib/virtiofsd/fuse_virtio.c index 083e4fc317..54ba7cbbcb 100644 --- a/contrib/virtiofsd/fuse_virtio.c +++ b/contrib/virtiofsd/fuse_virtio.c @@ -879,7 +879,6 @@ static int fv_create_listen_socket(struct fuse_session *se) /* Create the Unix socket to communicate with qemu * based on QEMU's vhost-user-bridge */ - unlink(se->vu_socket_path); strcpy(un.sun_path, se->vu_socket_path); size_t addr_len = sizeof(un.sun_family) + strlen(se->vu_socket_path); -- 2.18.1 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [Virtio-fs] [PATCH] virtiofsd: Prevent multiply running with same vhost_user_socket 2019-08-01 15:13 [Virtio-fs] [PATCH] virtiofsd: Prevent multiply running with same vhost_user_socket Masayoshi Mizuma @ 2019-08-02 15:39 ` Stefan Hajnoczi 2019-08-02 16:22 ` Masayoshi Mizuma 0 siblings, 1 reply; 6+ messages in thread From: Stefan Hajnoczi @ 2019-08-02 15:39 UTC (permalink / raw) To: Masayoshi Mizuma; +Cc: virtio-fs, Masayoshi Mizuma On Thu, Aug 01, 2019 at 11:13:48AM -0400, Masayoshi Mizuma wrote: > From: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com> > > virtiofsd can run multiply even if the vhost_user_socket is > same path. > > ]# ./virtiofsd -o vhost_user_socket=/tmp/vhostqemu -o source=/tmp/share & > [1] 244965 > virtio_session_mount: Waiting for vhost-user socket connection... > ]# ./virtiofsd -o vhost_user_socket=/tmp/vhostqemu -o source=/tmp/share & > [2] 244966 > virtio_session_mount: Waiting for vhost-user socket connection... > ]# > > The file access from the guest works because the second virtiofsd > handles that, however, the user will get confused the situation > and may be the cause of unexpected problem. So it's better to > prevent the multiple running. > > Change unlink() of the socket to the exit of virtiofsd so that the > latter virtiofsd can fail on bind() as EADDRINUSE. > > Signed-off-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com> > --- > contrib/virtiofsd/fuse_lowlevel.c | 1 + > contrib/virtiofsd/fuse_virtio.c | 1 - > 2 files changed, 1 insertion(+), 1 deletion(-) This patch makes the UNIX domain socket act similar to a pidfile or lockfile. Does the user need to clean up the UNIX domain socket manually before virtiofsd can restart again after a crash? This can be a robustness/reliability problem because we must assume that crashes happen and recovery should not require human intervention. On the other hand, there are plenty of daemons that have long-lived UNIX domain socket paths. How do they handle crash recovery? Stefan ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Virtio-fs] [PATCH] virtiofsd: Prevent multiply running with same vhost_user_socket 2019-08-02 15:39 ` Stefan Hajnoczi @ 2019-08-02 16:22 ` Masayoshi Mizuma 2019-08-04 2:48 ` piaojun 0 siblings, 1 reply; 6+ messages in thread From: Masayoshi Mizuma @ 2019-08-02 16:22 UTC (permalink / raw) To: Stefan Hajnoczi; +Cc: virtio-fs, Masayoshi Mizuma Hi Stefan, On Fri, Aug 02, 2019 at 04:39:30PM +0100, Stefan Hajnoczi wrote: > On Thu, Aug 01, 2019 at 11:13:48AM -0400, Masayoshi Mizuma wrote: > > From: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com> > > > > virtiofsd can run multiply even if the vhost_user_socket is > > same path. > > > > ]# ./virtiofsd -o vhost_user_socket=/tmp/vhostqemu -o source=/tmp/share & > > [1] 244965 > > virtio_session_mount: Waiting for vhost-user socket connection... > > ]# ./virtiofsd -o vhost_user_socket=/tmp/vhostqemu -o source=/tmp/share & > > [2] 244966 > > virtio_session_mount: Waiting for vhost-user socket connection... > > ]# > > > > The file access from the guest works because the second virtiofsd > > handles that, however, the user will get confused the situation > > and may be the cause of unexpected problem. So it's better to > > prevent the multiple running. > > > > Change unlink() of the socket to the exit of virtiofsd so that the > > latter virtiofsd can fail on bind() as EADDRINUSE. > > > > Signed-off-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com> > > --- > > contrib/virtiofsd/fuse_lowlevel.c | 1 + > > contrib/virtiofsd/fuse_virtio.c | 1 - > > 2 files changed, 1 insertion(+), 1 deletion(-) > > This patch makes the UNIX domain socket act similar to a pidfile or > lockfile. Does the user need to clean up the UNIX domain socket > manually before virtiofsd can restart again after a crash? > > This can be a robustness/reliability problem because we must assume that > crashes happen and recovery should not require human intervention. > > On the other hand, there are plenty of daemons that have long-lived UNIX > domain socket paths. How do they handle crash recovery? It's good point, thanks. I think if the socket ramains due to the former crash, then the socket should be unlinked by virtiofsd, not manualy. virtiofsd should detect whether the socket is in use by the other virtiofsd or just remains by crash. I'll try to implement that... Thanks! Masa ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Virtio-fs] [PATCH] virtiofsd: Prevent multiply running with same vhost_user_socket 2019-08-02 16:22 ` Masayoshi Mizuma @ 2019-08-04 2:48 ` piaojun 2019-08-06 2:08 ` Masayoshi Mizuma 0 siblings, 1 reply; 6+ messages in thread From: piaojun @ 2019-08-04 2:48 UTC (permalink / raw) To: Masayoshi Mizuma, Stefan Hajnoczi; +Cc: virtio-fs, Masayoshi Mizuma Hi, On 2019/8/3 0:22, Masayoshi Mizuma wrote: > Hi Stefan, > > On Fri, Aug 02, 2019 at 04:39:30PM +0100, Stefan Hajnoczi wrote: >> On Thu, Aug 01, 2019 at 11:13:48AM -0400, Masayoshi Mizuma wrote: >>> From: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com> >>> >>> virtiofsd can run multiply even if the vhost_user_socket is >>> same path. >>> >>> ]# ./virtiofsd -o vhost_user_socket=/tmp/vhostqemu -o source=/tmp/share & >>> [1] 244965 >>> virtio_session_mount: Waiting for vhost-user socket connection... >>> ]# ./virtiofsd -o vhost_user_socket=/tmp/vhostqemu -o source=/tmp/share & >>> [2] 244966 >>> virtio_session_mount: Waiting for vhost-user socket connection... >>> ]# >>> >>> The file access from the guest works because the second virtiofsd >>> handles that, however, the user will get confused the situation >>> and may be the cause of unexpected problem. So it's better to >>> prevent the multiple running. >>> >>> Change unlink() of the socket to the exit of virtiofsd so that the >>> latter virtiofsd can fail on bind() as EADDRINUSE. >>> >>> Signed-off-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com> >>> --- >>> contrib/virtiofsd/fuse_lowlevel.c | 1 + >>> contrib/virtiofsd/fuse_virtio.c | 1 - >>> 2 files changed, 1 insertion(+), 1 deletion(-) >> >> This patch makes the UNIX domain socket act similar to a pidfile or >> lockfile. Does the user need to clean up the UNIX domain socket >> manually before virtiofsd can restart again after a crash? >> >> This can be a robustness/reliability problem because we must assume that >> crashes happen and recovery should not require human intervention. >> >> On the other hand, there are plenty of daemons that have long-lived UNIX >> domain socket paths. How do they handle crash recovery? > > It's good point, thanks. > I think if the socket ramains due to the former crash, then the socket > should be unlinked by virtiofsd, not manualy. > > virtiofsd should detect whether the socket is in use by the other > virtiofsd or just remains by crash. > I'll try to implement that... Do you mean that we need handle these two situations? 1. The socket in use now; 2. The socket remains by the former crashed virtiofsd. I guess it's a little hard to distinguish one from the other, as user can start up virtiofsd simultaneously. If our goal is preventing multiple instances, why not using file lock to guarantee single-instance? Thanks, Jun > > Thanks! > Masa > > _______________________________________________ > Virtio-fs mailing list > Virtio-fs@redhat.com > https://www.redhat.com/mailman/listinfo/virtio-fs > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Virtio-fs] [PATCH] virtiofsd: Prevent multiply running with same vhost_user_socket 2019-08-04 2:48 ` piaojun @ 2019-08-06 2:08 ` Masayoshi Mizuma 2019-08-06 2:11 ` piaojun 0 siblings, 1 reply; 6+ messages in thread From: Masayoshi Mizuma @ 2019-08-06 2:08 UTC (permalink / raw) To: piaojun; +Cc: virtio-fs, m.mizuma Hi Jun, On 8/3/19 10:48 PM, piaojun wrote: > Hi, > > On 2019/8/3 0:22, Masayoshi Mizuma wrote: >> Hi Stefan, >> >> On Fri, Aug 02, 2019 at 04:39:30PM +0100, Stefan Hajnoczi wrote: >>> On Thu, Aug 01, 2019 at 11:13:48AM -0400, Masayoshi Mizuma wrote: >>>> From: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com> >>>> >>>> virtiofsd can run multiply even if the vhost_user_socket is >>>> same path. >>>> >>>> ]# ./virtiofsd -o vhost_user_socket=/tmp/vhostqemu -o source=/tmp/share & >>>> [1] 244965 >>>> virtio_session_mount: Waiting for vhost-user socket connection... >>>> ]# ./virtiofsd -o vhost_user_socket=/tmp/vhostqemu -o source=/tmp/share & >>>> [2] 244966 >>>> virtio_session_mount: Waiting for vhost-user socket connection... >>>> ]# >>>> >>>> The file access from the guest works because the second virtiofsd >>>> handles that, however, the user will get confused the situation >>>> and may be the cause of unexpected problem. So it's better to >>>> prevent the multiple running. >>>> >>>> Change unlink() of the socket to the exit of virtiofsd so that the >>>> latter virtiofsd can fail on bind() as EADDRINUSE. >>>> >>>> Signed-off-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com> >>>> --- >>>> contrib/virtiofsd/fuse_lowlevel.c | 1 + >>>> contrib/virtiofsd/fuse_virtio.c | 1 - >>>> 2 files changed, 1 insertion(+), 1 deletion(-) >>> >>> This patch makes the UNIX domain socket act similar to a pidfile or >>> lockfile. Does the user need to clean up the UNIX domain socket >>> manually before virtiofsd can restart again after a crash? >>> >>> This can be a robustness/reliability problem because we must assume that >>> crashes happen and recovery should not require human intervention. >>> >>> On the other hand, there are plenty of daemons that have long-lived UNIX >>> domain socket paths. How do they handle crash recovery? >> >> It's good point, thanks. >> I think if the socket ramains due to the former crash, then the socket >> should be unlinked by virtiofsd, not manualy. >> >> virtiofsd should detect whether the socket is in use by the other >> virtiofsd or just remains by crash. >> I'll try to implement that... > > Do you mean that we need handle these two situations? > 1. The socket in use now; > 2. The socket remains by the former crashed virtiofsd. > > I guess it's a little hard to distinguish one from the other, as user > can start up virtiofsd simultaneously. If our goal is preventing > multiple instances, why not using file lock to guarantee single-instance? > Thank you for your comments. Yes, I'm trying to implement that by using file lock. The unix domain socket cannot be locked because the open() fails as ENXIO, so I'm thinking that creates a regular file corresponding the socket name, and locks the file when virtiofsd boots. If the lock fails, then the socket is in use. If the lock successes, then the socket is available. I'll post the v2 patch... Thanks! Masa ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Virtio-fs] [PATCH] virtiofsd: Prevent multiply running with same vhost_user_socket 2019-08-06 2:08 ` Masayoshi Mizuma @ 2019-08-06 2:11 ` piaojun 0 siblings, 0 replies; 6+ messages in thread From: piaojun @ 2019-08-06 2:11 UTC (permalink / raw) To: Masayoshi Mizuma; +Cc: virtio-fs, m.mizuma Hi Masayoshi, On 2019/8/6 10:08, Masayoshi Mizuma wrote: > Hi Jun, > > On 8/3/19 10:48 PM, piaojun wrote: >> Hi, >> >> On 2019/8/3 0:22, Masayoshi Mizuma wrote: >>> Hi Stefan, >>> >>> On Fri, Aug 02, 2019 at 04:39:30PM +0100, Stefan Hajnoczi wrote: >>>> On Thu, Aug 01, 2019 at 11:13:48AM -0400, Masayoshi Mizuma wrote: >>>>> From: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com> >>>>> >>>>> virtiofsd can run multiply even if the vhost_user_socket is >>>>> same path. >>>>> >>>>> ]# ./virtiofsd -o vhost_user_socket=/tmp/vhostqemu -o source=/tmp/share & >>>>> [1] 244965 >>>>> virtio_session_mount: Waiting for vhost-user socket connection... >>>>> ]# ./virtiofsd -o vhost_user_socket=/tmp/vhostqemu -o source=/tmp/share & >>>>> [2] 244966 >>>>> virtio_session_mount: Waiting for vhost-user socket connection... >>>>> ]# >>>>> >>>>> The file access from the guest works because the second virtiofsd >>>>> handles that, however, the user will get confused the situation >>>>> and may be the cause of unexpected problem. So it's better to >>>>> prevent the multiple running. >>>>> >>>>> Change unlink() of the socket to the exit of virtiofsd so that the >>>>> latter virtiofsd can fail on bind() as EADDRINUSE. >>>>> >>>>> Signed-off-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com> >>>>> --- >>>>> contrib/virtiofsd/fuse_lowlevel.c | 1 + >>>>> contrib/virtiofsd/fuse_virtio.c | 1 - >>>>> 2 files changed, 1 insertion(+), 1 deletion(-) >>>> >>>> This patch makes the UNIX domain socket act similar to a pidfile or >>>> lockfile. Does the user need to clean up the UNIX domain socket >>>> manually before virtiofsd can restart again after a crash? >>>> >>>> This can be a robustness/reliability problem because we must assume that >>>> crashes happen and recovery should not require human intervention. >>>> >>>> On the other hand, there are plenty of daemons that have long-lived UNIX >>>> domain socket paths. How do they handle crash recovery? >>> >>> It's good point, thanks. >>> I think if the socket ramains due to the former crash, then the socket >>> should be unlinked by virtiofsd, not manualy. >>> >>> virtiofsd should detect whether the socket is in use by the other >>> virtiofsd or just remains by crash. >>> I'll try to implement that... >> >> Do you mean that we need handle these two situations? >> 1. The socket in use now; >> 2. The socket remains by the former crashed virtiofsd. >> >> I guess it's a little hard to distinguish one from the other, as user >> can start up virtiofsd simultaneously. If our goal is preventing >> multiple instances, why not using file lock to guarantee single-instance? >> > > Thank you for your comments. > Yes, I'm trying to implement that by using file lock. > The unix domain socket cannot be locked because the open() fails as ENXIO, > so I'm thinking that creates a regular file corresponding the socket name, > and locks the file when virtiofsd boots. If the lock fails, then the socket > is in use. If the lock successes, then the socket is available. > I'll post the v2 patch... That sounds reasonable. Thanks, Jun > > Thanks! > Masa > . > ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-08-06 2:11 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2019-08-01 15:13 [Virtio-fs] [PATCH] virtiofsd: Prevent multiply running with same vhost_user_socket Masayoshi Mizuma 2019-08-02 15:39 ` Stefan Hajnoczi 2019-08-02 16:22 ` Masayoshi Mizuma 2019-08-04 2:48 ` piaojun 2019-08-06 2:08 ` Masayoshi Mizuma 2019-08-06 2:11 ` piaojun
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.