[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACGkMEvtBQg5fTTzSaMRwZH7P3WiDx0=eov9RdCtSFaHVtbh1w@mail.gmail.com>
Date: Fri, 21 Apr 2023 15:08:59 +0800
From: Jason Wang <jasowang@...hat.com>
To: Peter Xu <peterx@...hat.com>
Cc: Maxime Coquelin <maxime.coquelin@...hat.com>,
xieyongji@...edance.com, mst@...hat.com, david.marchand@...hat.com,
linux-kernel@...r.kernel.org,
virtualization@...ts.linux-foundation.org, netdev@...r.kernel.org,
xuanzhuo@...ux.alibaba.com, eperezma@...hat.com
Subject: Re: [RFC 0/2] vduse: add support for networking devices
On Fri, Apr 21, 2023 at 2:39 AM Peter Xu <peterx@...hat.com> 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@linux.ibm.com/
This seems similar to the case of VDUSE.
Thanks
>
> Thanks,
>
> --
> Peter Xu
>
Powered by blists - more mailing lists