Messages in this thread | | | Date | Wed, 29 Jan 2020 15:23:40 +0000 | From | Daniel Thompson <> | Subject | Re: [PATCH 0/5] kdb: Don't implicitly change tasks; plus misc fixups |
| |
On Tue, Jan 28, 2020 at 05:42:48PM -0800, Andrew Morton wrote: > On Tue, 28 Jan 2020 08:59:01 -0800 Doug Anderson <dianders@chromium.org> wrote: > > > Hi > > > > On Sat, Nov 9, 2019 at 11:17 AM Douglas Anderson <dianders@chromium.org> wrote: > > > > > > This started out as just a follow-up to Daniel's post [1]. I wanted > > > to stop implicitly changing the current task in kdb. ...but, of > > > course, everywhere you look in kdb there are things to cleanup, so > > > this gets a few misc cleanups I found along the way. Enjoy. > > > > > > [1] https://lore.kernel.org/r/20191010150735.dhrj3pbjgmjrdpwr@holly.lan > > > > > > > > > Douglas Anderson (5): > > > MIPS: kdb: Remove old workaround for backtracing on other CPUs > > > kdb: kdb_current_regs should be private > > > kdb: kdb_current_task shouldn't be exported > > > kdb: Gid rid of implicit setting of the current task / regs > > > kdb: Get rid of confusing diag msg from "rd" if current task has no > > > regs > > > > > > arch/mips/kernel/traps.c | 5 ----- > > > include/linux/kdb.h | 2 -- > > > kernel/debug/kdb/kdb_bt.c | 8 +------- > > > kernel/debug/kdb/kdb_main.c | 31 ++++++++++++++----------------- > > > kernel/debug/kdb/kdb_private.h | 2 +- > > > 5 files changed, 16 insertions(+), 32 deletions(-) > > > > I noticed that this series doesn't seem to be in linux-next, but I > > think it was supposed to target v5.6? Do you know if there is > > anything outstanding or if it'll be queued up sometime soon? > > > > I grabbed them. > > Are there any updates on the testing status, particularly on MIPS?
I put in a fair bit of work earlier this dev cycle to add MIPS to the kgdb test suite. Unfortunately that left me catching up on a few other things... or putting it another way I am late putting together the kgdb tree for v5.6. It will be done by the weekend.
The first patch never got a formal Acked-by from the MIPS folks but they commented positively so we can probably go ahead.
Daniel.
| |