[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-dev] [PATCH v3 2/2] virtio-fs: add DAX window
On Tue, Jul 23, 2019 at 10:08:55AM -0400, Vivek Goyal wrote: > On Tue, Jul 23, 2019 at 02:32:27PM +0100, Stefan Hajnoczi wrote: > > On Wed, Jul 17, 2019 at 08:42:58AM -0400, Vivek Goyal wrote: > > > On Thu, Jun 27, 2019 at 10:09:16AM -0400, Michael S. Tsirkin wrote: > > > > > > [..] > > > > Well it allocates resources on the host. If you don't > > > > contain qemu then even just allocating virtual memory > > > > can make host swap, right? If you contain it then > > > > qemu will get killed instead but then you need to tell > > > > guest what not to do so as not to get qemu killed. > > > > > > How is it different than running a malicious unpriviliged process on host? > > > > > > Denial of service should be mitigated by per process resource limits which > > > will be true in this case as well. > > > > > > I am not sure I understand the concern here. > > > > There is a practical problem that the QEMU process may hit the mmap > > limit and be unable to perform its own mmaps due to the DAX Window. A > > limit must be enforced on the host so that QEMU's internal mmaps > > succeed. > > But number of mmaps are already limited by dax window size which is > controlled by virtiofsd. So all user has to do is start with smaller > dax window size if this ever becomes a concern. Yes, the DAX Window size sets a hard limit on the number of mappings (window_size / page_size). I think we should still communicate a maximum number of mappings to provide more control for cases where the page size and DAX Window size don't produce a desirable number. Consider that window_size = 8 GB and page_size = 4 KB already yields 2,097,152 maximum mappings. Oops, that number is too large! Stefan
Attachment:
signature.asc
Description: PGP signature
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]