From: Hao Xu <hao.xu@linux.dev>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: "Alex Bennée" <alex.bennee@linaro.org>,
virtio-fs@redhat.com,
"Erik Schilling" <erik.schilling@linaro.org>,
"QEMU Developers" <qemu-devel@nongnu.org>,
"Stefan Hajnoczi" <stefanha@redhat.com>,
"Vivek Goyal" <vgoyal@redhat.com>
Subject: Re: [Virtio-fs] Status of DAX for virtio-fs/virtiofsd?
Date: Thu, 7 Sep 2023 12:19:50 +0800 [thread overview]
Message-ID: <8a8321ba-3ad3-49e2-41bc-d8ee42c0f0fc@linux.dev> (raw)
In-Reply-To: <CAJSP0QUZ51y4bBTRgp_g6AO_6iEFamhOqMbcfFi5UiWBCkJQJQ@mail.gmail.com>
On 9/6/23 21:57, Stefan Hajnoczi wrote:
> On Wed, 6 Sept 2023 at 09:07, Hao Xu <hao.xu@linux.dev> wrote:
>> On 5/18/23 00:26, Stefan Hajnoczi wrote:
>>> On Wed, 17 May 2023 at 11:54, Alex Bennée <alex.bennee@linaro.org> wrote:
>>> Hi Alex,
>>> There were two unresolved issues:
>>>
>>> 1. How to inject SIGBUS when the guest accesses a page that's beyond
>>> the end-of-file.
>> Hi Stefan,
>> Does this SIGBUS issue exist if the guest kernel can be trusted? Since in
>>
>> that case, we can check the offset value in guest kernel.
> The scenario is:
> 1. A guest userspace process has a DAX file mmapped.
> 2. The host or another guest that is also sharing the directory
> truncates the file. The pages mmapped by our guest are no longer
> valid.
> 3. The guest loads from an mmapped page and a vmexit occurs.
> 4. Now the host must inject a SIGBUS into the guest. There is
> currently no way to do this.
>
> I believe this scenario doesn't happen within a single guest, because
> the guest kernel will raise SIGBUS itself without a vmexit if another
> process inside that same guest truncates the file.
>
> Another scenario is when the guest kernel access the DAX pages. A
> vmexit can occur here too.
>
> If you trust the host and all guests sharing the directory not to
> truncate files that are mmapped, then this issue will not occur.
>
> Stefan
I see, my use case should be fine since the directory is not shared and
fs is read-only.
Thanks for detail explanation.
Regards,
Hao
prev parent reply other threads:[~2023-09-07 4:19 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-17 15:23 [Virtio-fs] Status of DAX for virtio-fs/virtiofsd? Alex Bennée
2023-05-17 15:23 ` Alex Bennée
2023-05-17 16:26 ` [Virtio-fs] " Stefan Hajnoczi
2023-05-17 16:26 ` Stefan Hajnoczi
2023-05-18 19:45 ` [Virtio-fs] " Vivek Goyal
2023-05-18 19:45 ` Vivek Goyal
2023-05-22 12:54 ` [Virtio-fs] " Alex Bennée
2023-05-22 12:54 ` Alex Bennée
2023-09-06 13:07 ` [Virtio-fs] " Hao Xu
2023-09-06 13:57 ` Stefan Hajnoczi
2023-09-07 4:19 ` Hao Xu [this message]
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=8a8321ba-3ad3-49e2-41bc-d8ee42c0f0fc@linux.dev \
--to=hao.xu@linux.dev \
--cc=alex.bennee@linaro.org \
--cc=erik.schilling@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
--cc=stefanha@redhat.com \
--cc=vgoyal@redhat.com \
--cc=virtio-fs@redhat.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 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.