Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1406495 > unrolled thread

[PATCH 4/7] x86/dumpstack: If addr_limit is non-default, display it

Started byAndy Lutomirski <luto@kernel.org>
First post2016-05-25 00:50 +0200
Last post2016-05-29 18:50 +0200
Articles 8 — 4 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH 4/7] x86/dumpstack: If addr_limit is non-default, display it Andy Lutomirski <luto@kernel.org> - 2016-05-25 00:50 +0200
    Re: [PATCH 4/7] x86/dumpstack: If addr_limit is non-default, display  it Borislav Petkov <bp@alien8.de> - 2016-05-25 13:40 +0200
      Re: [PATCH 4/7] x86/dumpstack: If addr_limit is non-default, display it Andy Lutomirski <luto@amacapital.net> - 2016-05-29 18:50 +0200
        Re: [PATCH 4/7] x86/dumpstack: If addr_limit is non-default, display it Boris Petkov <bp@alien8.de> - 2016-05-29 20:50 +0200
          Re: [PATCH 4/7] x86/dumpstack: If addr_limit is non-default, display it Andy Lutomirski <luto@amacapital.net> - 2016-05-29 21:10 +0200
            Re: [PATCH 4/7] x86/dumpstack: If addr_limit is non-default, display  it Borislav Petkov <bp@alien8.de> - 2016-05-30 09:50 +0200
    Re: [PATCH 4/7] x86/dumpstack: If addr_limit is non-default, display  it Borislav Petkov <bp@alien8.de> - 2016-05-25 13:40 +0200
      Re: [PATCH 4/7] x86/dumpstack: If addr_limit is non-default, display it Andy Lutomirski <luto@amacapital.net> - 2016-05-29 18:50 +0200

#1406495 — [PATCH 4/7] x86/dumpstack: If addr_limit is non-default, display it

FromAndy Lutomirski <luto@kernel.org>
Date2016-05-25 00:50 +0200
Subject[PATCH 4/7] x86/dumpstack: If addr_limit is non-default, display it
Message-ID<rCtjc-Ur-17@gated-at.bofh.it>
This will help debug OOPSes related to USER_DS vs KERNEL_DS.

Signed-off-by: Andy Lutomirski <luto@kernel.org>
---
 arch/x86/kernel/dumpstack_32.c | 4 ++++
 arch/x86/kernel/dumpstack_64.c | 5 +++++
 2 files changed, 9 insertions(+)

diff --git a/arch/x86/kernel/dumpstack_32.c b/arch/x86/kernel/dumpstack_32.c
index 464ffd69b92e..5dbb08fd8291 100644
--- a/arch/x86/kernel/dumpstack_32.c
+++ b/arch/x86/kernel/dumpstack_32.c
@@ -124,8 +124,12 @@ show_stack_log_lvl(struct task_struct *task, struct pt_regs *regs,
 void show_regs(struct pt_regs *regs)
 {
 	int i;
+	struct thread_info *ti = current_thread_info();
 
 	show_regs_print_info(KERN_EMERG);
+	if (ti->addr_limit.seg != TASK_SIZE_MAX)
+		printk(KERN_DEFAULT "task.addr_limit: 0x%lx\n",
+		       ti->addr_limit.seg);
 	__show_regs(regs, !user_mode(regs));
 
 	/*
diff --git a/arch/x86/kernel/dumpstack_64.c b/arch/x86/kernel/dumpstack_64.c
index 5f1c6266eb30..2fdeb64dfed0 100644
--- a/arch/x86/kernel/dumpstack_64.c
+++ b/arch/x86/kernel/dumpstack_64.c
@@ -301,9 +301,14 @@ void show_regs(struct pt_regs *regs)
 {
 	int i;
 	unsigned long sp;
+	struct thread_info *ti = current_thread_info();
 
 	sp = regs->sp;
+
 	show_regs_print_info(KERN_DEFAULT);
+	if (ti->addr_limit.seg != TASK_SIZE_MAX)
+		printk(KERN_DEFAULT "task.addr_limit: 0x%lx\n",
+		       ti->addr_limit.seg);
 	__show_regs(regs, 1);
 
 	/*
-- 
2.5.5

[toc] | [next] | [standalone]

#1406850 — Re: [PATCH 4/7] x86/dumpstack: If addr_limit is non-default, display it

FromBorislav Petkov <bp@alien8.de>
Date2016-05-25 13:40 +0200
SubjectRe: [PATCH 4/7] x86/dumpstack: If addr_limit is non-default, display it
Message-ID<rCFkl-qt-7@gated-at.bofh.it>
In reply to#1406495
On Tue, May 24, 2016 at 03:48:41PM -0700, Andy Lutomirski wrote:
> This will help debug OOPSes related to USER_DS vs KERNEL_DS.
> 
> Signed-off-by: Andy Lutomirski <luto@kernel.org>
> ---
>  arch/x86/kernel/dumpstack_32.c | 4 ++++
>  arch/x86/kernel/dumpstack_64.c | 5 +++++
>  2 files changed, 9 insertions(+)
> 
> diff --git a/arch/x86/kernel/dumpstack_32.c b/arch/x86/kernel/dumpstack_32.c
> index 464ffd69b92e..5dbb08fd8291 100644
> --- a/arch/x86/kernel/dumpstack_32.c
> +++ b/arch/x86/kernel/dumpstack_32.c
> @@ -124,8 +124,12 @@ show_stack_log_lvl(struct task_struct *task, struct pt_regs *regs,
>  void show_regs(struct pt_regs *regs)
>  {
>  	int i;
> +	struct thread_info *ti = current_thread_info();
>  
>  	show_regs_print_info(KERN_EMERG);
> +	if (ti->addr_limit.seg != TASK_SIZE_MAX)
> +		printk(KERN_DEFAULT "task.addr_limit: 0x%lx\n",
> +		       ti->addr_limit.seg);

And, of course, that printk should be part of the printk in
show_regs_print_info() and not duplicated here and in dumpstack_64.c

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

[toc] | [prev] | [next] | [standalone]

#1408605

FromAndy Lutomirski <luto@amacapital.net>
Date2016-05-29 18:50 +0200
Message-ID<rEc4y-h4-31@gated-at.bofh.it>
In reply to#1406850
On Wed, May 25, 2016 at 4:39 AM, Borislav Petkov <bp@alien8.de> wrote:
> On Tue, May 24, 2016 at 03:48:41PM -0700, Andy Lutomirski wrote:
>> This will help debug OOPSes related to USER_DS vs KERNEL_DS.
>>
>> Signed-off-by: Andy Lutomirski <luto@kernel.org>
>> ---
>>  arch/x86/kernel/dumpstack_32.c | 4 ++++
>>  arch/x86/kernel/dumpstack_64.c | 5 +++++
>>  2 files changed, 9 insertions(+)
>>
>> diff --git a/arch/x86/kernel/dumpstack_32.c b/arch/x86/kernel/dumpstack_32.c
>> index 464ffd69b92e..5dbb08fd8291 100644
>> --- a/arch/x86/kernel/dumpstack_32.c
>> +++ b/arch/x86/kernel/dumpstack_32.c
>> @@ -124,8 +124,12 @@ show_stack_log_lvl(struct task_struct *task, struct pt_regs *regs,
>>  void show_regs(struct pt_regs *regs)
>>  {
>>       int i;
>> +     struct thread_info *ti = current_thread_info();
>>
>>       show_regs_print_info(KERN_EMERG);
>> +     if (ti->addr_limit.seg != TASK_SIZE_MAX)
>> +             printk(KERN_DEFAULT "task.addr_limit: 0x%lx\n",
>> +                    ti->addr_limit.seg);
>
> And, of course, that printk should be part of the printk in
> show_regs_print_info() and not duplicated here and in dumpstack_64.c

Easier said than done.  struct thread_info doesn't have addr_limit on
sensible architectures (e.g. sparc), and I'd rather not stick a bunch
of ifdefs in generic code.

--Andy

[toc] | [prev] | [next] | [standalone]

#1408641

FromBoris Petkov <bp@alien8.de>
Date2016-05-29 20:50 +0200
Message-ID<rEdWG-1tA-11@gated-at.bofh.it>
In reply to#1408605
Andy Lutomirski <luto@amacapital.net> wrote:
>Easier said than done.  struct thread_info doesn't have addr_limit on
>sensible architectures (e.g. sparc), and I'd rather not stick a bunch
>of ifdefs in generic code.

It's not like it doesn't have an actual address limit though - I'm guessing it is something like the max userspace address on the arch... UINT_MAX or somesuch.
-- 
Sent from a small device: formatting sux and brevity is inevitable.

[toc] | [prev] | [next] | [standalone]

#1408646

FromAndy Lutomirski <luto@amacapital.net>
Date2016-05-29 21:10 +0200
Message-ID<rEeg1-1Ra-1@gated-at.bofh.it>
In reply to#1408641
On May 29, 2016 11:42 AM, "Boris Petkov" <bp@alien8.de> wrote:
>
> Andy Lutomirski <luto@amacapital.net> wrote:
> >Easier said than done.  struct thread_info doesn't have addr_limit on
> >sensible architectures (e.g. sparc), and I'd rather not stick a bunch
> >of ifdefs in generic code.
>
> It's not like it doesn't have an actual address limit though - I'm guessing it is something like the max userspace address on the arch... UINT_MAX or somesuch.

Sure, but how do I implement that?  There's no "does this arch have
addr_limit in thread_info" general flag that I know of.

--Andy

[toc] | [prev] | [next] | [standalone]

#1408826 — Re: [PATCH 4/7] x86/dumpstack: If addr_limit is non-default, display it

FromBorislav Petkov <bp@alien8.de>
Date2016-05-30 09:50 +0200
SubjectRe: [PATCH 4/7] x86/dumpstack: If addr_limit is non-default, display it
Message-ID<rEq7w-1cH-3@gated-at.bofh.it>
In reply to#1408646
On Sun, May 29, 2016 at 12:08:29PM -0700, Andy Lutomirski wrote:
> Sure, but how do I implement that?  There's no "does this arch have
> addr_limit in thread_info" general flag that I know of.

What about get_fs()? Looks like all arches implement that and on sparc
it is something called thread_info.current_ds...

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

[toc] | [prev] | [next] | [standalone]

#1406853 — Re: [PATCH 4/7] x86/dumpstack: If addr_limit is non-default, display it

FromBorislav Petkov <bp@alien8.de>
Date2016-05-25 13:40 +0200
SubjectRe: [PATCH 4/7] x86/dumpstack: If addr_limit is non-default, display it
Message-ID<rCFkm-qt-9@gated-at.bofh.it>
In reply to#1406495
On Tue, May 24, 2016 at 03:48:41PM -0700, Andy Lutomirski wrote:
> This will help debug OOPSes related to USER_DS vs KERNEL_DS.
> 
> Signed-off-by: Andy Lutomirski <luto@kernel.org>
> ---
>  arch/x86/kernel/dumpstack_32.c | 4 ++++
>  arch/x86/kernel/dumpstack_64.c | 5 +++++
>  2 files changed, 9 insertions(+)
> 
> diff --git a/arch/x86/kernel/dumpstack_32.c b/arch/x86/kernel/dumpstack_32.c
> index 464ffd69b92e..5dbb08fd8291 100644
> --- a/arch/x86/kernel/dumpstack_32.c
> +++ b/arch/x86/kernel/dumpstack_32.c
> @@ -124,8 +124,12 @@ show_stack_log_lvl(struct task_struct *task, struct pt_regs *regs,
>  void show_regs(struct pt_regs *regs)
>  {
>  	int i;
> +	struct thread_info *ti = current_thread_info();
>  
>  	show_regs_print_info(KERN_EMERG);
> +	if (ti->addr_limit.seg != TASK_SIZE_MAX)
> +		printk(KERN_DEFAULT "task.addr_limit: 0x%lx\n",
> +		       ti->addr_limit.seg);

I guess we can dump that unconditionally just to be consistent and so
that all oopses look the same, i.e., with that line always present.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

[toc] | [prev] | [next] | [standalone]

#1408610

FromAndy Lutomirski <luto@amacapital.net>
Date2016-05-29 18:50 +0200
Message-ID<rEc4z-h4-53@gated-at.bofh.it>
In reply to#1406853
On Wed, May 25, 2016 at 4:32 AM, Borislav Petkov <bp@alien8.de> wrote:
> On Tue, May 24, 2016 at 03:48:41PM -0700, Andy Lutomirski wrote:
>> This will help debug OOPSes related to USER_DS vs KERNEL_DS.
>>
>> Signed-off-by: Andy Lutomirski <luto@kernel.org>
>> ---
>>  arch/x86/kernel/dumpstack_32.c | 4 ++++
>>  arch/x86/kernel/dumpstack_64.c | 5 +++++
>>  2 files changed, 9 insertions(+)
>>
>> diff --git a/arch/x86/kernel/dumpstack_32.c b/arch/x86/kernel/dumpstack_32.c
>> index 464ffd69b92e..5dbb08fd8291 100644
>> --- a/arch/x86/kernel/dumpstack_32.c
>> +++ b/arch/x86/kernel/dumpstack_32.c
>> @@ -124,8 +124,12 @@ show_stack_log_lvl(struct task_struct *task, struct pt_regs *regs,
>>  void show_regs(struct pt_regs *regs)
>>  {
>>       int i;
>> +     struct thread_info *ti = current_thread_info();
>>
>>       show_regs_print_info(KERN_EMERG);
>> +     if (ti->addr_limit.seg != TASK_SIZE_MAX)
>> +             printk(KERN_DEFAULT "task.addr_limit: 0x%lx\n",
>> +                    ti->addr_limit.seg);
>
> I guess we can dump that unconditionally just to be consistent and so
> that all oopses look the same, i.e., with that line always present.
>

I thought about doing that, but I always hate when things scroll off
the screen, and 99% of the time the addr_limit will be TASK_SIZE_MAX
and the line won't be interesting.

--Andy

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web