From: Peter Lieven <pl@kamp.de>
To: Kevin Wolf <kwolf@redhat.com>
Cc: ronniesahlberg@gmail.com, qemu-devel@nongnu.org,
qemu-block@nongnu.org, mreitz@redhat.com
Subject: Re: [Qemu-devel] [PATCH] block/nfs: add support for nfs_umount
Date: Thu, 5 Sep 2019 11:43:46 +0200 [thread overview]
Message-ID: <d3d2014b-d57e-cff1-d605-859fe94f84fc@kamp.de> (raw)
In-Reply-To: <20190904093459.GA21246@localhost.localdomain>
Am 04.09.19 um 11:34 schrieb Kevin Wolf:
> Am 03.09.2019 um 21:52 hat Peter Lieven geschrieben:
>>
>>> Am 03.09.2019 um 16:56 schrieb Kevin Wolf <kwolf@redhat.com>:
>>>
>>> Am 03.09.2019 um 15:44 hat Peter Lieven geschrieben:
>>>> libnfs recently added support for unmounting. Add support
>>>> in Qemu too.
>>>>
>>>> Signed-off-by: Peter Lieven <pl@kamp.de>
>>> Looks trivial enough to review even for me. :-)
>>>
>>> Thanks, applied to the block branch.
>>>
>>> Kevin
>> I am not sure what the reason is, but with this patch I sometimes run
>> into nfs_process_read being called for a cdrom mounted from nfs after
>> I ejected it (and the whole nfs client context is already destroyed).
> Does this mean that nfs_umount() gets some response, but we don't
> properly wait for it? Or is some older request still in flight?
nfs_umount itself is a sync call and should only terminate when
the call is done. But there is an independent I/O handler in that
function polling on the fd. (wait_for_nfs_reply in libnfs-sync.c).
This is why I thought the right solution is to stop the Qemu I/O handler
before calling nfs_close and nfs_umount. nfs_close also uses this
sync I/O handler, but for some reason it seems not to make trouble.
The other solution would be to use the async versions of close and umount,
but that would make the code in Qemu more complex.
Peter
next prev parent reply other threads:[~2019-09-05 9:45 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-03 13:44 [Qemu-devel] [PATCH] block/nfs: add support for nfs_umount Peter Lieven
2019-09-03 14:56 ` Kevin Wolf
2019-09-03 19:52 ` Peter Lieven
2019-09-04 9:34 ` Kevin Wolf
2019-09-05 9:43 ` Peter Lieven [this message]
2019-09-05 10:05 ` ronnie sahlberg
2019-09-05 10:16 ` Peter Lieven
2019-09-05 10:28 ` ronnie sahlberg
2019-09-05 10:32 ` Peter Lieven
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d3d2014b-d57e-cff1-d605-859fe94f84fc@kamp.de \
--to=pl@kamp.de \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=ronniesahlberg@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).