Date: Wed, 19 Nov 2025 16:23:46 +0530
From: Shivang Upadhyay <shivangu@linux.ibm.com>
Subject: [Crash-utility] [PATCH] make the MAX_MALLOC_BUFS customizable
To: k-hagio-ab@nec.com, lijiang@redhat.com
Cc: shivangu@linux.ibm.com, devel@lists.crash-utility.osci.io
Message-ID: <20251119105346.24902-1-shivangu@linux.ibm.com>
default value is kept to 2000, but can be changed with
command line with flag `--max-malloc-bufs`.
Signed-off-by: Shivang Upadhyay <shivangu@linux.ibm.com>
---
defs.h | 1 +
main.c | 4 ++++
tools.c | 9 ++++++---
3 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/defs.h b/defs.h
index ab4aee8..863baf9 100644
--- a/defs.h
+++ b/defs.h
@@ -5608,6 +5608,7 @@ void exec_args_input_file(struct command_table_entry *, struct args_input_file *
/*
* tools.c
*/
+extern int MAX_MALLOC_BUFS;
FILE *set_error(char *);
int __error(int, char *, ...);
#define error __error /* avoid conflict with gdb error() */
diff --git a/main.c b/main.c
index 71bcc15..e986792 100644
--- a/main.c
+++ b/main.c
@@ -46,6 +46,7 @@ static struct option long_options[] = {
{"version", 0, 0, 0},
{"buildinfo", 0, 0, 0},
{"cpus", required_argument, 0, 0},
+ {"max-malloc-bufs", required_argument, 0, 0},
{"no_ikconfig", 0, 0, 0},
{"hyper", 0, 0, 0},
{"p2m_mfn", required_argument, 0, 0},
@@ -163,6 +164,9 @@ main(int argc, char **argv)
else if (STREQ(long_options[option_index].name, "cpus"))
kt->cpus_override = optarg;
+ else if (STREQ(long_options[option_index].name, "max-malloc-bufs"))
+ MAX_MALLOC_BUFS = atoi(optarg);
+
else if (STREQ(long_options[option_index].name, "hyper"))
pc->flags |= XEN_HYPER;
diff --git a/tools.c b/tools.c
index a9ad18d..c9867e1 100644
--- a/tools.c
+++ b/tools.c
@@ -5698,7 +5698,7 @@ ll_power(long long base, long long exp)
#define B32K (4)
#define SHARED_BUF_SIZES (B32K+1)
-#define MAX_MALLOC_BUFS (2000)
+int MAX_MALLOC_BUFS = 2000; /* can be changed from command line args */
Think it again and discuss with customers, that should be good to fold these two patches into one patch:
That is to say, increase the default MAX_MALLOC_BUFS and also introduce the --max-malloc-bufs options, which can handle both cases:
1. most customers never hit the max limit
2. deal with large vmcores without blocking analysis
What do you think?
Thank
Lianbo
#define MAX_CACHE_SIZE (KILOBYTES(32))
struct shared_bufs {
@@ -5723,7 +5723,7 @@ struct shared_bufs {
long buf_8K_ovf;
long buf_32K_ovf;
int buf_inuse[SHARED_BUF_SIZES];
- char *malloc_bp[MAX_MALLOC_BUFS];
+ char **malloc_bp;
long smallest;
long largest;
long embedded;
@@ -5744,6 +5744,7 @@ buf_init(void)
bp->smallest = 0x7fffffff;
bp->total = 0.0;
+ bp->malloc_bp = (char**) calloc(MAX_MALLOC_BUFS * sizeof(char*), 1);
#ifdef VALGRIND
VALGRIND_MAKE_MEM_NOACCESS(&bp->buf_1K, sizeof(bp->buf_1K));
@@ -6130,7 +6131,9 @@ getbuf(long reqsize)
dump_shared_bufs();
return ((char *)(long)
- error(FATAL, "cannot allocate any more memory!\n"));
+ error(FATAL, "cannot allocate any more memory!\n"
+ "try increasing --max-malloc-bufs (current value : %d)\n",
+ MAX_MALLOC_BUFS));
}
/*
--
2.51.0