user/sven/linux.git/kernel/debug/kdb/kdb_private.h, branch v5.13

kdb: Simplify kdb commands registration

2021-03-19T16:51:59Z

Simplify kdb commands registration via using linked list instead of static array for commands storage. Signed-off-by: Sumit Garg Link: https://lore.kernel.org/r/20210224070827.408771-1-sumit.garg@linaro.org Reviewed-by: Douglas Anderson [daniel.thompson@linaro.org: Removed a bunch of .cmd_minline = 0 initializers] Signed-off-by: Daniel Thompson

kdb: Remove redundant function definitions/prototypes

2021-03-19T16:34:52Z

Cleanup kdb code to get rid of unused function definitions/prototypes. Signed-off-by: Sumit Garg Link: https://lore.kernel.org/r/20210224071653.409150-1-sumit.garg@linaro.org Reviewed-by: Douglas Anderson Signed-off-by: Daniel Thompson

kdb: Make memory allocations more robust

2021-02-08T13:42:50Z

Currently kdb uses in_interrupt() to determine whether its library code has been called from the kgdb trap handler or from a saner calling context such as driver init. This approach is broken because in_interrupt() alone isn't able to determine kgdb trap handler entry from normal task context. This can happen during normal use of basic features such as breakpoints and can also be trivially reproduced using: echo g > /proc/sysrq-trigger We can improve this by adding check for in_dbg_master() instead which explicitly determines if we are running in debugger context. Cc: stable@vger.kernel.org Signed-off-by: Sumit Garg Link: https://lore.kernel.org/r/1611313556-4004-1-git-send-email-sumit.garg@linaro.org Signed-off-by: Daniel Thompson

kdb: kdb_support: Fix debugging information problem

2021-02-04T15:55:04Z

There are several common patterns. 0: kdb_printf("...",...); which is the normal one. 1: kdb_printf("%s: "...,__func__,...) We could improve '1' to this : #define kdb_func_printf(format, args...) \ kdb_printf("%s: " format, __func__, ## args) 2: if(KDB_DEBUG(AR)) kdb_printf("%s "...,__func__,...); We could improve '2' to this : #define kdb_dbg_printf(mask, format, args...) \ do { \ if (KDB_DEBUG(mask)) \ kdb_func_printf(format, ## args); \ } while (0) In addition, we changed the format code of size_t to %zu. Signed-off-by: Stephen Zhang Link: https://lore.kernel.org/r/1612440429-6391-1-git-send-email-stephenzhangzsd@gmail.com Reviewed-by: Douglas Anderson [daniel.thompson@linaro.org: Minor typo and line length fixes in the patch description] Signed-off-by: Daniel Thompson

kdb: Use newer api for tasklist scanning

2020-09-08T13:36:46Z

This kills using the do_each_thread/while_each_thread combo to iterate all threads and uses for_each_process_thread() instead, maintaining semantics. while_each_thread() is ultimately racy and deprecated; although in this particular case there is no concurrency so it doesn't matter. Still lets trivially get rid of two more users. Acked-by: Oleg Nesterov Signed-off-by: Davidlohr Bueso Link: https://lore.kernel.org/r/20200907203206.21293-1-dave@stgolabs.net Signed-off-by: Daniel Thompson

kdb: Gid rid of implicit setting of the current task / regs

2020-01-31T17:34:00Z

Some (but not all?) of the kdb backtrace paths would cause the kdb_current_task and kdb_current_regs to remain changed. As discussed in a review of a previous patch [1], this doesn't seem intuitive, so let's fix that. ...but, it turns out that there's actually no longer any reason to set the current task / current regs while backtracing anymore anyway. As of commit 2277b492582d ("kdb: Fix stack crawling on 'running' CPUs that aren't the master") if we're backtracing on a task running on a CPU we ask that CPU to do the backtrace itself. Linux can do that without anything fancy. If we're doing backtrace on a sleeping task we can also do that fine without updating globals. So this patch mostly just turns into deleting a bunch of code. [1] https://lore.kernel.org/r/20191010150735.dhrj3pbjgmjrdpwr@holly.lan Signed-off-by: Douglas Anderson Link: https://lore.kernel.org/r/20191109111624.4.Ibc3d982bbeb9e46872d43973ba808cd4c79537c7@changeid Signed-off-by: Daniel Thompson

kdb: kdb_current_regs should be private

2020-01-31T17:33:54Z

As of the patch ("MIPS: kdb: Remove old workaround for backtracing on other CPUs") there is no reason for kdb_current_regs to be in the public "kdb.h". Let's move it next to kdb_current_task. Signed-off-by: Douglas Anderson Link: https://lore.kernel.org/r/20191109111623.2.Iadbfb484e90b557cc4b5ac9890bfca732cd99d77@changeid Signed-off-by: Daniel Thompson

kdb: Remove special case logic from kdb_read()

2019-10-28T12:07:57Z

kdb_read() contains special case logic to force it exit after reading a single character. We can remove all the special case logic by directly calling the function to read a single character instead. This also allows us to tidy up the function prototype which, because it now matches getchar(), we can also rename in order to make its role clearer. This does involve some extra code to handle btaprompt properly but we don't mind the new lines of code here because the old code had some interesting problems (bad newline handling, treating unexpected characters like ). Signed-off-by: Daniel Thompson Reviewed-by: Douglas Anderson Link: https://lore.kernel.org/r/20191025073328.643-4-daniel.thompson@linaro.org

kdb: Use strscpy with destination buffer size

2018-11-13T20:27:53Z

gcc 8.1.0 warns with: kernel/debug/kdb/kdb_support.c: In function ‘kallsyms_symbol_next’: kernel/debug/kdb/kdb_support.c:239:4: warning: ‘strncpy’ specified bound depends on the length of the source argument [-Wstringop-overflow=] strncpy(prefix_name, name, strlen(name)+1); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ kernel/debug/kdb/kdb_support.c:239:31: note: length computed here Use strscpy() with the destination buffer size, and use ellipses when displaying truncated symbols. v2: Use strscpy() Signed-off-by: Prarit Bhargava Cc: Jonathan Toppins Cc: Jason Wessel Cc: Daniel Thompson Cc: kgdb-bugreport@lists.sourceforge.net Reviewed-by: Daniel Thompson Signed-off-by: Daniel Thompson

signal: Simplify and fix kdb_send_sig

2018-01-04T00:01:08Z

- Rename from kdb_send_sig_info to kdb_send_sig As there is no meaningful siginfo sent - Use SEND_SIG_PRIV instead of generating a siginfo for a kdb signal. The generated siginfo had a bogus rationale and was not correct in the face of pid namespaces. SEND_SIG_PRIV is simpler and actually correct. - As the code grabs siglock just send the signal with siglock held instead of dropping siglock and attempting to grab it again. - Move the sig_valid test into kdb_kill where it can generate a good error message. Signed-off-by: Eric W. Biederman