[Crash-utility] [PATCH] x86_64: Fix that Particular kvaddr is converted to wrong paddr (RHEL6 x86_64)

Nakajima Akira nakajima.akira at nttcom.co.jp
Tue Jan 5 09:46:32 UTC 2016


Thanks for your patch improvement.


+#define VSYSCALL_START             0xffffffffff600000
+#define VSYSCALL_END               0xffffffffffe00000

FIXADDR_START, FIXADDR_TOP look good for me.
But these are depended on kernel ver.
So VSYSCALL_START/END are reasonable.

2.6.9-89.ELsmp (RHEL 4.8)
2.6.18-398.el5 (RHEL 5.11)
FIXADDR_START = ffffffffff57c000
FIXADDR_TOP   = ffffffffffdff000

2.6.32-71.el6.x86_64 (RHEL 6.0)
2.6.32-504.el6.x86_64 (RHEL 6.6)
FIXADDR_START = ffffffffff577000
FIXADDR_TOP   = ffffffffffdff000

3.10.0-229.el7.x86_64 (RHEL 7.1)
3.10.0-329.el7.x86_64 (RHEL 7.2)
FIXADDR_START = ffffffffff525000
FIXADDR_TOP   = ffffffffffdff000

4.2.3-300.fc23.x86_64 (Fedora 23)
FIXADDR_START = ffffffffff567000
FIXADDR_TOP   = ffffffffff7ff000


On 2016/01/05 1:44, Dave Anderson wrote:
> 
> 
> ----- Original Message -----
>>> But because it is such a fundamental change that you are proposing, it might
>>> make sense to create a check/macro that is specific to the vsyscall region.
>>
>> What is check/macro? How do we check what?
>> Certainly, these addresses are vsyscall region.
>> After applying this patch, crash looks read vsyscall region correctly.
> 
> The vsyscall-region check fits more naturally in the x86_64_IS_VMALLOC_ADDR() function,
> along with all of the other checks for non-unity-mapped addresses.
> 
> Queued for crash-7.1.5:
>   
>   https://github.com/crash-utility/crash/commit/2e29d684a4583a45ae3c9b16014ab204eb6812fa
> 
> Thanks for the report,
>   Dave
> 
> 
>>
>>
>>
>> crash> sym vsyscall
>>     // abbreviation //
>>   ffffffffff600000 (t) .vsyscall_0
>>   ffffffffff600140 (t) .vsyscall_fn
>>   ffffffffff600180 (d) .vsyscall_gtod_data
>>   ffffffffff600180 (D) __vsyscall_gtod_data
>>   ffffffffff600400 (t) .vsyscall_1
>>   ffffffffff600800 (t) .vsyscall_2
>>   ffffffffff700680 (A) VDSO64_vsyscall_gtod_data
>>
>> crash> sym VDSO
>> symbol not found: VDSO
>> possible alternatives:
>>   ffffffffff700000 (A) VDSO64_PRELINK
>>   ffffffffff700670 (A) VDSO64_jiffies
>>   ffffffffff700678 (A) VDSO64_vgetcpu_mode
>>   ffffffffff700680 (A) VDSO64_vsyscall_gtod_data
>>
>>
>> //////// not patched /////////
>> crash> dis .vsyscall_0
>> 0xffffffffff600000 <.vsyscall_0>:       add    %al,(%rax)
>> 0xffffffffff600002 <vgettimeofday+2>:   add    %al,(%rax)
>> 0xffffffffff600004 <vgettimeofday+4>:   add    %al,(%rax)
>> 0xffffffffff600006 <vgettimeofday+6>:   add    %al,(%rax)
>> 0xffffffffff600008 <vgettimeofday+8>:   add    %al,(%rax)
>> 0xffffffffff60000a <vgettimeofday+10>:  add    %al,(%rax)
>>     // abbreviation //
>>
>>
>> //////// after applying this patch /////////
>> crash> dis .vsyscall_0
>> 0xffffffffff600000 <.vsyscall_0>:       push   %rbp
>> 0xffffffffff600001 <vgettimeofday+1>:   mov    %rsp,%rbp
>> 0xffffffffff600004 <vgettimeofday+4>:   push   %r13
>> 0xffffffffff600006 <vgettimeofday+6>:   push   %r12
>> 0xffffffffff600008 <vgettimeofday+8>:   mov    %rdi,%r12
>> 0xffffffffff60000b <vgettimeofday+11>:  push   %rbx
>> 0xffffffffff60000c <vgettimeofday+12>:  mov    %rsi,%rbx
>> 0xffffffffff60000f <vgettimeofday+15>:  sub    $0x8,%rsp
>> 0xffffffffff600013 <vgettimeofday+19>:  test   %rdi,%rdi
>> 0xffffffffff600016 <vgettimeofday+22>:  je     0xffffffffff6000d5
>> <vgettimeofday+213>
>>     // abbreviation //
>>
>>
>> On 2015/12/22 22:42, Dave Anderson wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> I didn't check XEN HYPER MODE, I don't have XEN.
>>>> If we need similar statement "if (kvaddr < MODULES_END)"
>>>>  please add inside in "if (XEN_HYPER_MODE())" (1859 at x86_64_kvtop)
>>>>
>>>>
>>>>
>>>>
>>>> >From ed300b74998e0923313e4fd14b9a41e305942b44 Mon Sep 17 00:00:00 2001
>>>> From: Nakajima Akira <nakajima.akira at nttcom.co.jp>
>>>> Date: Tue, 22 Dec 2015 15:46:42 +0900
>>>> Subject: [PATCH] Fix that particular kvaddr is converted to wrong paddr
>>>>
>>>> BUG INFO
>>>> Particular kvaddr is converted to wrong paddr.
>>>> You can see this bug on RHEL6_x86_64. (at present only RHEL6)
>>>>  (I checked RHEL5, RHEL7, Fedora21, Fedora23)
>>>
>>>
>>> I am out of the office until January 4th (only checking email until then),
>>> and will not
>>> be able to look into this until then.  But because it is such a fundamental
>>> change that
>>> you are proposing, it might make sense to create a check/macro that is
>>> specific to
>>> the vsyscall region.
>>>
>>> Thanks,
>>>   Dave
>>>  
>>>>
>>>> from /proc/kallsyms
>>>> ffffffffff6008c0 D __jiffies
>>>>
>>>> /////////// wrong ///////////
>>>> crash> vtop ffffffffff6008c0
>>>> VIRTUAL           PHYSICAL
>>>> ffffffffff6008c0  7f6008c0
>>>>
>>>>       PAGE        PHYSICAL      MAPPING       INDEX CNT FLAGS
>>>> ffffea00000623b8   1c11000                0        0  1 20000000000400
>>>> reserved
>>>>
>>>>
>>>> crash> rd ffffffffff6008c0
>>>> ffffffffff6008c0:  0000000000000000                    ........
>>>>
>>>>
>>>> /////////// correct ///////////
>>>> crash> vtop ffffffffff6008c0
>>>> VIRTUAL           PHYSICAL
>>>> ffffffffff6008c0  1c118c0
>>>>
>>>>       PAGE        PHYSICAL      MAPPING       INDEX CNT FLAGS
>>>> ffffea00000623b8   1c11000                0        0  1 20000000000400
>>>> reserved
>>>>
>>>>
>>>> crash> rd ffffffffff6008c0
>>>> ffffffffff6008c0:  00000000ffffe43a                    :.......
>>>>
>>>> Reported-by: Nakajima Akira <nakajima.akira at nttcom.co.jp>
>>>> Signed-off-by: Nakajima Akira <nakajima.akira at nttcom.co.jp>
>>>>
>>>> ---
>>>>  x86_64.c |   28 +++++++++++++++-------------
>>>>  1 files changed, 15 insertions(+), 13 deletions(-)
>>>>
>>>> diff --git a/x86_64.c b/x86_64.c
>>>> index ff6fdd5..dab4d43 100644
>>>> --- a/x86_64.c
>>>> +++ b/x86_64.c
>>>> @@ -1872,19 +1872,21 @@ x86_64_kvtop(struct task_context *tc, ulong
>>>> kvaddr,
>>>> physaddr_t *paddr, int verbo
>>>>                 		fprintf(fp, "PAGE DIRECTORY: %lx\n", *pml4);
>>>>  		}
>>>>  	} else {
>>>> -        	if (!vt->vmalloc_start) {
>>>> -                	*paddr = x86_64_VTOP(kvaddr);
>>>> -                	return TRUE;
>>>> -        	}
>>>> -
>>>> -        	if (!IS_VMALLOC_ADDR(kvaddr)) {
>>>> -                	*paddr = x86_64_VTOP(kvaddr);
>>>> -                	if (!verbose)
>>>> -                        	return TRUE;
>>>> -        	}
>>>> -
>>>> -		if (XEN() && (kt->xen_flags & WRITABLE_PAGE_TABLES))
>>>> -			return (x86_64_kvtop_xen_wpt(tc, kvaddr, paddr, verbose));
>>>> +		if (kvaddr < MODULES_END) {
>>>> +	        	if (!vt->vmalloc_start) {
>>>> +	                	*paddr = x86_64_VTOP(kvaddr);
>>>> +	                	return TRUE;
>>>> +	        	}
>>>> +
>>>> +	        	if (!IS_VMALLOC_ADDR(kvaddr)) {
>>>> +	                	*paddr = x86_64_VTOP(kvaddr);
>>>> +	                	if (!verbose)
>>>> +	                        	return TRUE;
>>>> +	        	}
>>>> +
>>>> +			if (XEN() && (kt->xen_flags & WRITABLE_PAGE_TABLES))
>>>> +				return (x86_64_kvtop_xen_wpt(tc, kvaddr, paddr, verbose));
>>>> +		}
>>>>  
>>>>   		/*
>>>>  		 *  pgd = pgd_offset_k(addr);
>>>> --
>>>> 1.7.1
>>>>
>>>>
>>>> --
>>>> Crash-utility mailing list
>>>> Crash-utility at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/crash-utility
>>>
>>> --
>>> Crash-utility mailing list
>>> Crash-utility at redhat.com
>>> https://www.redhat.com/mailman/listinfo/crash-utility
>>> .
>>>
>>
>> --
>> Crash-utility mailing list
>> Crash-utility at redhat.com
>> https://www.redhat.com/mailman/listinfo/crash-utility
>>
> 
> --
> Crash-utility mailing list
> Crash-utility at redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
> .
> 




More information about the Crash-utility mailing list