On Mon, May 12, 2025 at 12:09 AM Fuad Tabba <tabba@xxxxxxxxxx> wrote:
>
> Hi James.
>
> On Sun, 11 May 2025 at 09:03, David Hildenbrand <david@xxxxxxxxxx> wrote:
> >
> > On 09.05.25 22:54, James Houghton wrote:
> > > On Wed, Apr 30, 2025 at 9:57 AM Fuad Tabba <tabba@xxxxxxxxxx> wrote:
> > >> +static int kvm_gmem_mmap(struct file *file, struct vm_area_struct *vma)
> > >> +{
> > >> + struct kvm_gmem *gmem = file->private_data;
> > >> +
> > >> + if (!kvm_arch_gmem_supports_shared_mem(gmem->kvm))
> > >> + return -ENODEV;
> > >> +
> > >> + if ((vma->vm_flags & (VM_SHARED | VM_MAYSHARE)) !=
> > >> + (VM_SHARED | VM_MAYSHARE)) {
> > >> + return -EINVAL;
> > >> + }
> > >> +
> > >> + vm_flags_set(vma, VM_DONTDUMP);
> > >
> > > Hi Fuad,
> > >
> > > Sorry if I missed this, but why exactly do we set VM_DONTDUMP here?
> > > Could you leave a small comment? (I see that it seems to have
> > > originally come from Patrick? [1]) I get that guest memory VMAs
> > > generally should have VM_DONTDUMP; is there a bigger reason?
> >
> > (David replying)
> >
> > I assume because we might have inaccessible parts in there that SIGBUS
> > on access.
>
> That was my thinking.
>
> > get_dump_page() does ignore any errors, though (returning NULL), so
> > likely we don't need VM_DONTDUMP.
>
> In which case I'll remove this from the next respin.
SGTM, thanks!
Userspace could remove VM_DONTDUMP by doing MADV_DODUMP, which is why
I was curious about this.
And thanks for the extra context[1], Patrick. :)
[1]: https://lore.kernel.org/kvm/20250512074615.27394-1-roypat@xxxxxxxxxxxx/
