DPDK patches and discussions
 help / color / mirror / Atom feed
From: Lewis Donzis <lew@perftech.com>
To: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
Cc: dev <dev@dpdk.org>, anatoly burakov <anatoly.burakov@intel.com>
Subject: Re: [PATCH v2 1/2] contigmem: support including mapped buffers in core dump
Date: Sat, 26 Oct 2024 06:43:08 -0500 (CDT)	[thread overview]
Message-ID: <1865717992.9940628.1729942988633.JavaMail.zimbra@donzis.com> (raw)
In-Reply-To: <20241025202615.2581513-2-dmitry.kozliuk@gmail.com>

Is the extra control necessary, i.e., why not just always do this and let the EAL option control whether the pages get dumped?

----- On Oct 25, 2024, at 3:26 PM, Dmitry Kozlyuk dmitry.kozliuk@gmail.com wrote:

> It was impossible to include mapped contigmem buffers in core dump.
> Add hw.contigmem.coredump_enable tunable to control the inclusion.
> 
> Mappings backed by OBJ_FICTITIOUS are excluded from core dump.
> While contigmem is a device and its OBJT_DEVICE mappings get this flag,
> they are actually backed by memory.
> Clear OBJ_FICTITIOUS mapping bit to include them in core dump.
> Do this only if hw.contigmem.coredump_enable=1.
> 
> Signed-off-by: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
> ---
> doc/guides/freebsd_gsg/build_dpdk.rst | 27 ++++++++++++++++++++-------
> kernel/freebsd/contigmem/contigmem.c  |  8 ++++++++
> 2 files changed, 28 insertions(+), 7 deletions(-)
> 
> diff --git a/doc/guides/freebsd_gsg/build_dpdk.rst
> b/doc/guides/freebsd_gsg/build_dpdk.rst
> index 86e8e5a805..387ec52820 100644
> --- a/doc/guides/freebsd_gsg/build_dpdk.rst
> +++ b/doc/guides/freebsd_gsg/build_dpdk.rst
> @@ -86,6 +86,22 @@ module loading using::
>     kenv hw.contigmem.num_buffers=n
>     kenv hw.contigmem.buffer_size=m
> 
> +Where n is the number of blocks and m is the size in bytes of each area of
> +contiguous memory.  A default of two buffers of size 1073741824 bytes (1
> Gigabyte)
> +each is set during module load if they are not specified in the environment.
> +
> +Buffers are excluded from core dump by default.
> +Mapped buffers can be included in core dump using the following tunable:
> +
> +    hw.contigmem.coredump_enable=1
> +
> +.. note::
> +
> +    Including contigmem buffers in core dump file increases its size,
> +    which may fill the storage or overload the transport.
> +    Buffers typically hold data processed by the application,
> +    like network packets, which may contain sensitive information.
> +
> The kernel environment variables can also be specified during boot by placing
> the
> following in ``/boot/loader.conf``:
> 
> @@ -93,15 +109,12 @@ following in ``/boot/loader.conf``:
> 
>     hw.contigmem.num_buffers=n
>     hw.contigmem.buffer_size=m
> +    hw.contigmem.coredump_enable=1
> 
> The variables can be inspected using the following command::
> 
>     sysctl -a hw.contigmem
> 
> -Where n is the number of blocks and m is the size in bytes of each area of
> -contiguous memory.  A default of two buffers of size 1073741824 bytes (1
> Gigabyte)
> -each is set during module load if they are not specified in the environment.
> -
> The module can then be loaded using kldload::
> 
>     kldload contigmem
> @@ -115,13 +128,13 @@ up time.  This can be achieved by placing lines similar to
> the following into
> 
>     hw.contigmem.num_buffers=1
>     hw.contigmem.buffer_size=1073741824
> +    hw.contigmem.coredump_enable=1
>     contigmem_load="YES"
> 
> .. note::
> 
> -    The contigmem_load directive should be placed after any definitions of
> -    ``hw.contigmem.num_buffers`` and ``hw.contigmem.buffer_size`` if the
> default values
> -    are not to be used.
> +    The ``contigmem_load`` directive should be placed after any definitions
> +    of ``hw.contigmem.*`` if the default values are not to be used.
> 
> An error such as::
> 
> diff --git a/kernel/freebsd/contigmem/contigmem.c
> b/kernel/freebsd/contigmem/contigmem.c
> index 7dd87599d9..591e46dded 100644
> --- a/kernel/freebsd/contigmem/contigmem.c
> +++ b/kernel/freebsd/contigmem/contigmem.c
> @@ -51,6 +51,7 @@ static d_close_t        contigmem_close;
> 
> static int              contigmem_num_buffers = RTE_CONTIGMEM_DEFAULT_NUM_BUFS;
> static int64_t          contigmem_buffer_size = RTE_CONTIGMEM_DEFAULT_BUF_SIZE;
> +static bool             contigmem_coredump_enable;
> 
> static eventhandler_tag contigmem_eh_tag;
> static struct contigmem_buffer contigmem_buffers[RTE_CONTIGMEM_MAX_NUM_BUFS];
> @@ -59,6 +60,7 @@ static int              contigmem_refcnt;
> 
> TUNABLE_INT("hw.contigmem.num_buffers", &contigmem_num_buffers);
> TUNABLE_QUAD("hw.contigmem.buffer_size", &contigmem_buffer_size);
> +TUNABLE_BOOL("hw.contigmem.coredump_enable", &contigmem_coredump_enable);
> 
> static SYSCTL_NODE(_hw, OID_AUTO, contigmem, CTLFLAG_RD, 0, "contigmem");
> 
> @@ -68,6 +70,8 @@ SYSCTL_QUAD(_hw_contigmem, OID_AUTO, buffer_size, CTLFLAG_RD,
> 	&contigmem_buffer_size, 0, "Size of each contiguous buffer");
> SYSCTL_INT(_hw_contigmem, OID_AUTO, num_references, CTLFLAG_RD,
> 	&contigmem_refcnt, 0, "Number of references to contigmem");
> +SYSCTL_BOOL(_hw_contigmem, OID_AUTO, coredump_enable, CTLFLAG_RD,
> +	&contigmem_coredump_enable, 0, "Include mapped buffers in core dump");
> 
> static SYSCTL_NODE(_hw_contigmem, OID_AUTO, physaddr, CTLFLAG_RD, 0,
> 	"physaddr");
> @@ -357,5 +361,9 @@ contigmem_mmap_single(struct cdev *cdev, vm_ooffset_t
> *offset, vm_size_t size,
> 	*obj = cdev_pager_allocate(vmh, OBJT_DEVICE, &contigmem_cdev_pager_ops,
> 			size, nprot, *offset, curthread->td_ucred);
> 
> +	/* Mappings backed by OBJ_FICTITIOUS are excluded from core dump. */
> +	if (contigmem_coredump_enable)
> +		(*obj)->flags &= ~OBJ_FICTITIOUS;
> +
> 	return 0;
> }
> --
> 2.38.4

  reply	other threads:[~2024-10-26 11:43 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-23 23:18 [PATCH] eal: support including mapped memory " Dmitry Kozlyuk
2024-10-24  2:19 ` Stephen Hemminger
2024-10-24  2:31 ` Stephen Hemminger
2024-10-24  7:07   ` Morten Brørup
2024-10-24  7:22 ` Morten Brørup
2024-10-24  8:25   ` Dmitry Kozlyuk
2024-10-24 12:55 ` Lewis Donzis
2024-10-24 16:38 ` Stephen Hemminger
2024-10-24 20:54   ` Dmitry Kozlyuk
2024-10-25  0:22     ` Dmitry Kozlyuk
2024-10-25 20:26 ` [PATCH v2 0/2] Hugepage inclusion " Dmitry Kozlyuk
2024-10-25 20:26   ` [PATCH v2 1/2] contigmem: support including mapped buffers " Dmitry Kozlyuk
2024-10-26 11:43     ` Lewis Donzis [this message]
2024-10-25 20:26   ` [PATCH v2 2/2] doc: add instruction for including hugepages " Dmitry Kozlyuk
2024-10-26  3:18   ` [PATCH v2 0/2] Hugepage inclusion " Morten Brørup

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1865717992.9940628.1729942988633.JavaMail.zimbra@donzis.com \
    --to=lew@perftech.com \
    --cc=anatoly.burakov@intel.com \
    --cc=dev@dpdk.org \
    --cc=dmitry.kozliuk@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).