On Wed, Nov 30, 2022 at 8:46 PM Ilya Maximets <[email protected]> wrote:
>
> On 11/30/22 20:11, Mike Pattrick wrote:
> > On Wed, Nov 30, 2022 at 7:27 AM Ilya Maximets <[email protected]> wrote:
> >>
> >> On 11/25/22 18:19, Adrian Moreno wrote:
> >>> Hi Mike,
> >>>
> >>> Sorry it took that long to review this patch.
> >>>
> >>> On 3/25/22 23:17, Mike Pattrick wrote:
> >>>> Add new option --dump-hugepages option in ovs-ctl to enable the addition
> >>>> of hugepages in the core dump filter.
> >>>>
> >>>> Signed-off-by: Mike Pattrick <[email protected]>
> >>>> ---
> >>>> NEWS | 4 ++++
> >>>> utilities/ovs-ctl.in | 15 +++++++++++----
> >>>> 2 files changed, 15 insertions(+), 4 deletions(-)
> >>>>
> >>>> diff --git a/NEWS b/NEWS
> >>>> index 8fa57836a..7af60dce3 100644
> >>>> --- a/NEWS
> >>>> +++ b/NEWS
> >>>> @@ -3,6 +3,10 @@ Post-v2.17.0
> >>>> - OVSDB:
> >>>> * 'relay' service model now supports transaction history, i.e.
> >>>> honors the
> >>>> 'last-txn-id' field in 'monitor_cond_since' requests from
> >>>> clients.
> >>>> + - ovs-ctl:
> >>>> + * New option '--dump-hugepages' to include hugepages in core
> >>>> dumps. This
> >>>> + can assist with postmortem analysis involving DPDK, but may also
> >>>> produce
> >>>> + significantly larger core dump files.
> >>>>
> >>>
> >>> I'm afraid this part needs rebasing.
> >>>
> >>>> v2.17.0 - 17 Feb 2022
> >>>> diff --git a/utilities/ovs-ctl.in b/utilities/ovs-ctl.in
> >>>> index e6e07f476..8f900314b 100644
> >>>> --- a/utilities/ovs-ctl.in
> >>>> +++ b/utilities/ovs-ctl.in
> >>>> @@ -103,8 +103,13 @@ set_system_ids () {
> >>>> action "Configuring Open vSwitch system IDs" "$@" $extra_ids
> >>>> }
> >>>> -check_force_cores () {
> >>>> - if test X"$FORCE_COREFILES" = Xyes; then
> >>>> +check_core_config () {
> >>>> + if test X"$DUMP_HUGEPAGES" = Xyes; then
> >>>> + echo 0x3f > /proc/self/coredump_filter
> >>
> >> Shouldn't this be 0x7f instead?
> >> 0x3f doesn't enable bit #6, which is responsible for dumping
> >> shared huge pages. Or am I missing something?
> >
> > That's a good point, the hugepage may or may not be private. I'll send
> > in a new one.
>
> OK. One thing to think about though is that we'll grab
> VM memory, I guess, in case we have vhost-user ports.
> So, the core dump size can become insanely huge.
>
> The downside of not having them is inability to inspect
> virtqueues and stuff in the dump.
Did you consider madvise()?
MADV_DONTDUMP (since Linux 3.4)
Exclude from a core dump those pages in the range
specified by addr and length. This is useful in applications that
have large areas of memory that are known not to be useful in a core
dump. The effect of MADV_DONT‐
DUMP takes precedence over the bit mask that is set via
the /proc/[pid]/coredump_filter file (see core(5)).
MADV_DODUMP (since Linux 3.4)
Undo the effect of an earlier MADV_DONTDUMP.
--
David Marchand
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
