* [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.