linux-toradex.git/scripts/gdb, branch v6.0-rc1

Merge tag 'mm-nonmm-stable-2022-08-06-2' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm

2022-08-07T17:03:24+00:00

Pull misc updates from Andrew Morton:
 "Updates to various subsystems which I help look after. lib, ocfs2,
  fatfs, autofs, squashfs, procfs, etc. A relatively small amount of
  material this time"

* tag 'mm-nonmm-stable-2022-08-06-2' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: (72 commits)
  scripts/gdb: ensure the absolute path is generated on initial source
  MAINTAINERS: kunit: add David Gow as a maintainer of KUnit
  mailmap: add linux.dev alias for Brendan Higgins
  mailmap: update Kirill's email
  profile: setup_profiling_timer() is moslty not implemented
  ocfs2: fix a typo in a comment
  ocfs2: use the bitmap API to simplify code
  ocfs2: remove some useless functions
  lib/mpi: fix typo 'the the' in comment
  proc: add some (hopefully) insightful comments
  bdi: remove enum wb_congested_state
  kernel/hung_task: fix address space of proc_dohung_task_timeout_secs
  lib/lzo/lzo1x_compress.c: replace ternary operator with min() and min_t()
  squashfs: support reading fragments in readahead call
  squashfs: implement readahead
  squashfs: always build "file direct" version of page actor
  Revert "squashfs: provide backing_dev_info in order to disable read-ahead"
  fs/ocfs2: Fix spelling typo in comment
  ia64: old_rr4 added under CONFIG_HUGETLB_PAGE
  proc: fix test for "vsyscall=xonly" boot option
  ...

Merge tag 'printk-for-5.20-sane' of git://git.kernel.org/pub/scm/linux/kernel/git/printk/linux

2022-08-05T16:54:36+00:00

Pull printk updates from Petr Mladek:

 - Allow reading kernel log in gdb even on 32 bits systems

 - More granular check of the buffer usage in printf selftest

 - Clang warning fix

* tag 'printk-for-5.20-sane' of git://git.kernel.org/pub/scm/linux/kernel/git/printk/linux:
  lib/test_printf.c: fix clang -Wformat warnings
  scripts/gdb: fix 'lx-dmesg' on 32 bits arch
  lib/test_printf.c: split write-beyond-buffer check in two

scripts/gdb: ensure the absolute path is generated on initial source

2022-07-30T01:12:37+00:00

Post 'make scripts_gdb' a symbolic link to scripts/gdb/vmlinux-gdb.py is
created.  Currently 'os.path.dirname(__file__)' does not generate the
absolute path to scripts/gdb resulting in the following:

    (gdb) source vmlinux-gdb.py
    Traceback (most recent call last):
      File "scripts/gdb/vmlinux-gdb.py", line 25, in 
	import linux.utils
    ModuleNotFoundError: No module named 'linux'

This patch ensures that the absolute path to scripts/gdb in relation to
the given file is generated so each module can be located accordingly.

Link: https://lkml.kernel.org/r/20220712110248.1404125-1-atomlin@redhat.com
Signed-off-by: Aaron Tomlin 
Reviewed-by: Douglas Anderson 
Cc: Jan Kiszka 
Cc: Kieran Bingham 
Signed-off-by: Andrew Morton

scripts/gdb: Fix gdb 'lx-symbols' command

2022-07-21T17:40:55+00:00

Currently the command 'lx-symbols' in gdb exits with the error`Function
"do_init_module" not defined in "kernel/module.c"`. This occurs because
the file kernel/module.c was moved to kernel/module/main.c.

Fix this breakage by changing the path to "kernel/module/main.c" in
LoadModuleBreakpoint.

Signed-off-by: Khalid Masum 
Acked-by: Luis Chamberlain 
Fixes: cfc1d277891e ("module: Move all into module/")
Reviewed-by: Douglas Anderson 
Signed-off-by: Linus Torvalds

scripts/gdb: fix 'lx-dmesg' on 32 bits arch

2022-07-21T13:32:52+00:00

The type atomic_long_t can have size 4 or 8 bytes, depending on
CONFIG_64BIT; it's only content, the field 'counter', is either an
int or a s64 value.

Current code incorrectly uses the fixed size utils.read_u64() to
read the field 'counter' inside atomic_long_t.

On 32 bits architectures reading the last element 'tail_id' of the
struct prb_desc_ring:
	struct prb_desc_ring {
		...
		atomic_long_t tail_id;
	};
causes the utils.read_u64() to access outside the boundary of the
struct and the gdb command 'lx-dmesg' exits with error:
	Python Exception : index out of range
	Error occurred in Python: index out of range

Query the really used atomic_long_t counter type size.

Link: https://lore.kernel.org/r/20220617143758.137307-1-antonio.borneo@foss.st.com
Fixes: e60768311af8 ("scripts/gdb: update for lockless printk ringbuffer")
Signed-off-by: Antonio Borneo 
[pmladek@suse.com: Query the really used atomic_long_t counter type size]
Tested-by: Antonio Borneo 
Reviewed-by: John Ogness 
Signed-off-by: Petr Mladek 
Link: https://lore.kernel.org/r/20220719122831.19890-1-pmladek@suse.com

scripts/gdb: change kernel config dumping method

2022-06-11T09:31:53+00:00

MAGIC_START("IKCFG_ST") and MAGIC_END("IKCFG_ED") are moved out
from the kernel_config_data variable.

Thus, we parse kernel_config_data directly instead of considering
offset of MAGIC_START and MAGIC_END.

Fixes: 13610aa908dc ("kernel/configs: use .incbin directive to embed config_data.gz")
Signed-off-by: Kuan-Ying Lee 
Signed-off-by: Masahiro Yamada

scripts/gdb: lx-dmesg: read records individually

2021-12-16T14:52:38+00:00

For the gdb command lx-dmesg, the entire descriptor, info, and text
data regions are read into memory before printing any records. For
large kernel log buffers, this not only causes a huge delay before
seeing any records, but it may also lead to python errors of too
much memory allocation.

Rather than reading in all these regions in advance, read them as
needed and only read the regions for the particular record that is
being printed.

The gdb macro "dmesg" in Documentation/admin-guide/kdump/gdbmacros.txt
already prints out the kernel log buffer like this.

Signed-off-by: John Ogness 
Signed-off-by: Petr Mladek 
Link: https://lore.kernel.org/r/874k79c3a9.fsf@jogness.linutronix.de

scripts/gdb: handle split debug for vmlinux

2021-11-09T18:02:52+00:00

This is related to two previous changes.  Commit dfe4529ee4d3
("scripts/gdb: find vmlinux where it was before") and commit da036ae14762
("scripts/gdb: handle split debug").

Although Chrome OS has been using the debug suffix for modules for a
while, it has just recently started using it for vmlinux as well.  That
means we've now got to improve the detection of "vmlinux" to also handle
that it might end with ".debug".

Link: https://lkml.kernel.org/r/20211028151120.v2.1.Ie6bd5a232f770acd8c9ffae487a02170bad3e963@changeid
Signed-off-by: Douglas Anderson 
Reviewed-by: Stephen Boyd 
Cc: Jan Kiszka 
Cc: Kieran Bingham 
Cc: Johannes Berg 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

scripts/gdb: add lx_current support for arm64

2021-05-07T07:26:33+00:00

arm64 uses SP_EL0 to save the current task_struct address.  While running
in EL0, SP_EL0 is clobbered by userspace.  So if the upper bit is not 1
(not TTBR1), the current address is invalid.  This patch checks the upper
bit of SP_EL0, if the upper bit is 1, lx_current() of arm64 will return
the derefrence of current task.  Otherwise, lx_current() will tell users
they are running in userspace(EL0).

While arm64 is running in EL0, it is actually pointless to print current
task as the memory of kernel space is not accessible in EL0.

Link: https://lkml.kernel.org/r/20210314203444.15188-3-song.bao.hua@hisilicon.com
Signed-off-by: Barry Song 
Cc: Jan Kiszka 
Cc: Jonathan Corbet 
Cc: Kieran Bingham 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

scripts/gdb: document lx_current is only supported by x86

2021-05-07T07:26:33+00:00

Patch series "scripts/gdb: clarify the platforms supporting lx_current and add arm64 support", v2.

lx_current depends on per_cpu current_task variable which exists on x86
only.  so it actually works on x86 only.  the 1st patch documents this
clearly; the 2nd patch adds support for arm64.

This patch (of 2):

x86 is the only architecture which has per_cpu current_task:

  arch$ git grep current_task | grep -i per_cpu
  x86/include/asm/current.h:DECLARE_PER_CPU(struct task_struct *, current_task);
  x86/kernel/cpu/common.c:DEFINE_PER_CPU(struct task_struct *, current_task) ____cacheline_aligned =
  x86/kernel/cpu/common.c:EXPORT_PER_CPU_SYMBOL(current_task);
  x86/kernel/cpu/common.c:DEFINE_PER_CPU(struct task_struct *, current_task) = &init_task;
  x86/kernel/cpu/common.c:EXPORT_PER_CPU_SYMBOL(current_task);
  x86/kernel/smpboot.c:	per_cpu(current_task, cpu) = idle;

On other architectures, lx_current() will lead to a python exception:

  (gdb) p $lx_current().pid
  Python Exception  No symbol "current_task" in current context.:
  Error occurred in Python: No symbol "current_task" in current context.

To avoid more people struggling and wasting time in other architectures,
document it.

Link: https://lkml.kernel.org/r/20210314203444.15188-1-song.bao.hua@hisilicon.com
Link: https://lkml.kernel.org/r/20210314203444.15188-2-song.bao.hua@hisilicon.com
Signed-off-by: Barry Song 
Cc: Jan Kiszka 
Cc: Kieran Bingham 
Cc: Jonathan Corbet 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds