lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 22 Feb 2021 11:06:06 +0000
From:   Kieran Bingham <kieran.bingham@...asonboard.com>
To:     Barry Song <song.bao.hua@...ilicon.com>, corbet@....net,
        linux-doc@...r.kernel.org, jan.kiszka@...mens.com
Cc:     linux-kernel@...r.kernel.org, linuxarm@...neuler.org
Subject: Re: [PATCH] scripts/gdb: document lx_current is only supported by x86

Hi Barry

On 21/02/2021 21:35, Barry Song wrote:
> lx_current depends on the per_cpu current_task which exists on x86 only:
> 
> 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 <class 'gdb.error'> 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.
> 
> Cc: Jan Kiszka <jan.kiszka@...mens.com>
> Signed-off-by: Barry Song <song.bao.hua@...ilicon.com>
> ---
>  Documentation/dev-tools/gdb-kernel-debugging.rst |  2 +-
>  scripts/gdb/linux/cpus.py                        | 10 ++++++++--
>  2 files changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/dev-tools/gdb-kernel-debugging.rst b/Documentation/dev-tools/gdb-kernel-debugging.rst
> index 4756f6b3a04e..1586901b683c 100644
> --- a/Documentation/dev-tools/gdb-kernel-debugging.rst
> +++ b/Documentation/dev-tools/gdb-kernel-debugging.rst
> @@ -114,7 +114,7 @@ Examples of using the Linux-provided gdb helpers
>      [     0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
>      ....
>  
> -- Examine fields of the current task struct::
> +- Examine fields of the current task struct(supported by x86 only)::
>  
>      (gdb) p $lx_current().pid
>      $1 = 4998
> diff --git a/scripts/gdb/linux/cpus.py b/scripts/gdb/linux/cpus.py
> index 008e62f3190d..f382762509d3 100644
> --- a/scripts/gdb/linux/cpus.py
> +++ b/scripts/gdb/linux/cpus.py
> @@ -156,6 +156,13 @@ Note that VAR has to be quoted as string."""
>  
>  PerCpu()
>  
> +def get_current_task(cpu):
> +    if utils.is_target_arch("x86"):
> +         var_ptr = gdb.parse_and_eval("&current_task")
> +         return per_cpu(var_ptr, cpu).dereference()
> +    else:
> +        raise gdb.GdbError("Sorry, obtaining the current task is not yet "
> +                           "supported with this arch")

I've wondered in the past how we should handle the architecture specific
layers.

Perhaps we need to have an interface of functionality to implement on
each architecture so that we can create a per-arch set of helpers.

or break it up into arch specific subdirs at least...


>  class LxCurrentFunc(gdb.Function):
>      """Return current task.
> @@ -167,8 +174,7 @@ number. If CPU is omitted, the CPU of the current context is used."""
>          super(LxCurrentFunc, self).__init__("lx_current")
>  
>      def invoke(self, cpu=-1):
> -        var_ptr = gdb.parse_and_eval("&current_task")
> -        return per_cpu(var_ptr, cpu).dereference()
> +        return get_current_task(cpu)
>  

And then perhaps we simply shouldn't even expose commands which can not
be supported on those architectures?

Is it easy to disable this command if it's not supportable on the
architecture?

Presumably you are working on non-x86, have you investigated adding this
support for your architecture (arm/arm64?)?

The fact you have run the command implies it would be useful for you ?


>  LxCurrentFunc()
> 


-- 
Regards
--
Kieran

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ