On Fri, Apr 21, 2023 at 2:39 AM Peter Xu <peterx@xxxxxxxxxx> wrote: > > On Thu, Apr 20, 2023 at 12:34:06PM +0800, Jason Wang wrote: > > > 3. Coredump: > > > In order to be able to perform post-mortem analysis, DPDK > > > Vhost library marks pages used for vrings and descriptors > > > buffers as MADV_DODUMP using madvise(). However with > > > VDUSE it fails with -EINVAL. My understanding is that we > > > set VM_DONTEXPAND flag to the VMAs and madvise's > > > MADV_DODUMP fails if it is present. I'm not sure to > > > understand why madvise would prevent MADV_DODUMP if > > > VM_DONTEXPAND is set. Any thoughts? > > > > Adding Peter who may know the answer. > > I don't.. but I had a quick look, it seems that VM_DONTEXPAND was kind of > reused (and I'm not sure whether it's an abuse or not so far..) to > represent device driver pages since removal of VM_RESERVED: Interesting, but there're indeed cases where VM_DONTEXPAND is used by non-driver codes. The pages mapped by VDUSE are not device driver pages but the IOTLB and virtqueue. Btw the definition of VM_SPECIAL doesn't say anything related to dump: /* * Special vmas that are non-mergable, non-mlock()able. */ #define VM_SPECIAL (VM_IO | VM_DONTEXPAND | VM_PFNMAP | VM_MIXEDMAP) > > https://lore.kernel.org/all/20120731103457.20182.88454.stgit@zurg/ > https://lore.kernel.org/all/20120731103503.20182.94365.stgit@zurg/ > > But I think that change at least breaks hugetlb once so there's the > explicit hugetlb check to recover that behavior back: > > https://lore.kernel.org/all/20180930054629.29150-1-daniel@xxxxxxxxxxxxx/ This seems similar to the case of VDUSE. Thanks > > Thanks, > > -- > Peter Xu > _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
