[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240617173426.7.Ie8aa2af2df12c2e9dc510f003a301401a1ac97fb@changeid>
Date: Mon, 17 Jun 2024 17:34:41 -0700
From: Douglas Anderson <dianders@...omium.org>
To: Daniel Thompson <daniel.thompson@...aro.org>
Cc: kgdb-bugreport@...ts.sourceforge.net,
Douglas Anderson <dianders@...omium.org>,
Christophe JAILLET <christophe.jaillet@...adoo.fr>,
Jason Wessel <jason.wessel@...driver.com>,
Thorsten Blum <thorsten.blum@...lux.com>,
Yuran Pereira <yuran.pereira@...mail.com>,
linux-kernel@...r.kernel.org
Subject: [PATCH 07/13] kdb: Tweak "repeat" handling code for "mdW" and "mdWcN"
In general, "md"-style commands are meant to be "repeated". This is a
feature of kdb and "md"-style commands get it enabled because they
have the flag KDB_REPEAT_NO_ARGS. What this means is that if you type
"md4c2 0xffffff808ef05400" and then keep hitting return on the "kdb>"
prompt that you'll read more and more memory. For instance:
[5]kdb> md4c2 0xffffff808ef05400
0xffffff808ef05400 00000204 00000000 ........
[5]kdb>
0xffffff808ef05408 8235e000 00000000 ..5.....
[5]kdb>
0xffffff808ef05410 00000003 00000001 ........
As a side effect of the way kdb works is implemented, you can get the
same behavior as the above by typing the command again with no
arguments. Though it seems unlikely anyone would do this it shouldn't
really hurt:
[5]kdb> md4c2 0xffffff808ef05400
0xffffff808ef05400 00000204 00000000 ........
[5]kdb> md4c2
0xffffff808ef05408 8235e000 00000000 ..5.....
[5]kdb> md4c2
0xffffff808ef05410 00000003 00000001 ........
In general supporting "repeat" should be easy. If argc is 0 then we
just copy the results of the arg parsing from the last time, making
sure that the address has been updated. This is all handled nicely in
the "if (argc == 0)" clause in kdb_md().
Oddly, the "mdW" and "mdWcN" code seems to update "last_bytesperword"
and "last_repeat", which doesn't seem like it should be necessary. It
appears that this code is needed to make this use case work, though
it's a bit unclear if this is truly an important feature to support:
[1]kdb> md2c3 0xffffff80c8e2b280
0xffffff80c8e2b280 0200 0000 0000 ...
[1]kdb> md2c4
0xffffff80c8e2b286 0000 e000 8235 0000 ...
In order to abstract the code better, remove the code updating
"last_bytesperword" and "last_repeat" from the "mdW" and "mdWcN"
handling. This breaks the above case where the user tweaked "argv[0]"
and then tried to somehow leverage the "repeat" code to do something
smart, but that feels like it was a misfeature anyway.
Signed-off-by: Douglas Anderson <dianders@...omium.org>
---
kernel/debug/kdb/kdb_main.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/kernel/debug/kdb/kdb_main.c b/kernel/debug/kdb/kdb_main.c
index 700b4e355545..3c6fffa8509a 100644
--- a/kernel/debug/kdb/kdb_main.c
+++ b/kernel/debug/kdb/kdb_main.c
@@ -1611,7 +1611,6 @@ static int kdb_md(int argc, const char **argv)
if (isdigit(argv[0][2])) {
bytesperword = (int)(argv[0][2] - '0');
- last_bytesperword = bytesperword;
repeat = mdcount * 16 / bytesperword;
if (!argv[0][3])
valid = true;
@@ -1621,7 +1620,6 @@ static int kdb_md(int argc, const char **argv)
mdcount = ((repeat * bytesperword) + 15) / 16;
valid = !*p;
}
- last_repeat = repeat;
} else if (strcmp(argv[0], "md") == 0)
valid = true;
else if (strcmp(argv[0], "mds") == 0)
--
2.45.2.627.g7a2c4fd464-goog
Powered by blists - more mailing lists