DPDK patches and discussions
 help / color / mirror / Atom feed
From: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
To: dev@dpdk.org
Cc: Anatoly Burakov <anatoly.burakov@intel.com>,
	Lewis Donzis <lew@perftech.com>,
	Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
Subject: [PATCH v2 1/2] contigmem: support including mapped buffers in core dump
Date: Fri, 25 Oct 2024 23:26:14 +0300	[thread overview]
Message-ID: <20241025202615.2581513-2-dmitry.kozliuk@gmail.com> (raw)
In-Reply-To: <20241025202615.2581513-1-dmitry.kozliuk@gmail.com>

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-25 20:26 UTC|newest]

Thread overview: 13+ 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   ` Dmitry Kozlyuk [this message]
2024-10-25 20:26   ` [PATCH v2 2/2] doc: add instruction for including hugepages " Dmitry Kozlyuk

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=20241025202615.2581513-2-dmitry.kozliuk@gmail.com \
    --to=dmitry.kozliuk@gmail.com \
    --cc=anatoly.burakov@intel.com \
    --cc=dev@dpdk.org \
    --cc=lew@perftech.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).