Hi,
The root cause has been found out finally. It's caused by code bug in
sync_global_pgds which is wrong for loop count calculation.
Will post patch.
Thanks
Baoquan
On 04/07/17 at 10:41am, Jeff Moyer wrote:
> Hi,
>
> commit 021182e52fe01 ("x86/mm: Enable KASLR for physical mapping memory
>
Hi,
The root cause has been found out finally. It's caused by code bug in
sync_global_pgds which is wrong for loop count calculation.
Will post patch.
Thanks
Baoquan
On 04/07/17 at 10:41am, Jeff Moyer wrote:
> Hi,
>
> commit 021182e52fe01 ("x86/mm: Enable KASLR for physical mapping memory
>
On 04/24/17 at 05:41pm, Thomas Garnier wrote:
> On Mon, Apr 24, 2017 at 4:07 PM, Baoquan He wrote:
> > Yeah, according to my debugging tracking, it goes as Dan said. And the
> > is_ram is REGION_DISJOINT. And till arch_add_memory, the parameters
> > passed to arch_add_memory are
On 04/24/17 at 05:41pm, Thomas Garnier wrote:
> On Mon, Apr 24, 2017 at 4:07 PM, Baoquan He wrote:
> > Yeah, according to my debugging tracking, it goes as Dan said. And the
> > is_ram is REGION_DISJOINT. And till arch_add_memory, the parameters
> > passed to arch_add_memory are "arch_add_memory,
On Mon, Apr 24, 2017 at 4:07 PM, Baoquan He wrote:
> Yeah, according to my debugging tracking, it goes as Dan said. And the
> is_ram is REGION_DISJOINT. And till arch_add_memory, the parameters
> passed to arch_add_memory are "arch_add_memory, align_start:0x100,
>
On Mon, Apr 24, 2017 at 4:07 PM, Baoquan He wrote:
> Yeah, according to my debugging tracking, it goes as Dan said. And the
> is_ram is REGION_DISJOINT. And till arch_add_memory, the parameters
> passed to arch_add_memory are "arch_add_memory, align_start:0x100,
>
On 04/24/17 at 04:18pm, Dan Williams wrote:
> On Mon, Apr 24, 2017 at 4:07 PM, Baoquan He wrote:
> > On 04/24/17 at 01:52pm, Dan Williams wrote:
> [..]
> >> When using the memmap= parameter we're using this call by default:
> >>
> >> } else if (pmem_should_map_pages(dev))
On 04/24/17 at 04:18pm, Dan Williams wrote:
> On Mon, Apr 24, 2017 at 4:07 PM, Baoquan He wrote:
> > On 04/24/17 at 01:52pm, Dan Williams wrote:
> [..]
> >> When using the memmap= parameter we're using this call by default:
> >>
> >> } else if (pmem_should_map_pages(dev)) {
> >>
On Mon, Apr 24, 2017 at 4:07 PM, Baoquan He wrote:
> On 04/24/17 at 01:52pm, Dan Williams wrote:
[..]
>> When using the memmap= parameter we're using this call by default:
>>
>> } else if (pmem_should_map_pages(dev)) {
>> addr = devm_memremap_pages(dev,
On Mon, Apr 24, 2017 at 4:07 PM, Baoquan He wrote:
> On 04/24/17 at 01:52pm, Dan Williams wrote:
[..]
>> When using the memmap= parameter we're using this call by default:
>>
>> } else if (pmem_should_map_pages(dev)) {
>> addr = devm_memremap_pages(dev, >res,
>>
On 04/24/17 at 01:52pm, Dan Williams wrote:
> On Mon, Apr 24, 2017 at 1:37 PM, Thomas Garnier wrote:
> > )
> >
> > On Thu, Apr 20, 2017 at 6:26 AM, Baoquan He wrote:
> >> On 04/19/17 at 07:27am, Thomas Garnier wrote:
> >>> On Wed, Apr 19, 2017 at 6:36 AM,
On 04/24/17 at 01:52pm, Dan Williams wrote:
> On Mon, Apr 24, 2017 at 1:37 PM, Thomas Garnier wrote:
> > )
> >
> > On Thu, Apr 20, 2017 at 6:26 AM, Baoquan He wrote:
> >> On 04/19/17 at 07:27am, Thomas Garnier wrote:
> >>> On Wed, Apr 19, 2017 at 6:36 AM, Baoquan He wrote:
> >>> > Hi all,
>
On Mon, Apr 24, 2017 at 1:37 PM, Thomas Garnier wrote:
> )
>
> On Thu, Apr 20, 2017 at 6:26 AM, Baoquan He wrote:
>> On 04/19/17 at 07:27am, Thomas Garnier wrote:
>>> On Wed, Apr 19, 2017 at 6:36 AM, Baoquan He wrote:
>>> > Hi all,
>>> >
On Mon, Apr 24, 2017 at 1:37 PM, Thomas Garnier wrote:
> )
>
> On Thu, Apr 20, 2017 at 6:26 AM, Baoquan He wrote:
>> On 04/19/17 at 07:27am, Thomas Garnier wrote:
>>> On Wed, Apr 19, 2017 at 6:36 AM, Baoquan He wrote:
>>> > Hi all,
>>> >
>>> > I login in Jeff's system, and added debug code, no
On 04/19/17 at 07:34am, Dan Williams wrote:
> On Wed, Apr 19, 2017 at 7:27 AM, Thomas Garnier wrote:
> > On Wed, Apr 19, 2017 at 6:36 AM, Baoquan He wrote:
> >> Hi all,
> >>
> >> I login in Jeff's system, and added debug code, no clue found. However
> >>
On 04/19/17 at 07:34am, Dan Williams wrote:
> On Wed, Apr 19, 2017 at 7:27 AM, Thomas Garnier wrote:
> > On Wed, Apr 19, 2017 at 6:36 AM, Baoquan He wrote:
> >> Hi all,
> >>
> >> I login in Jeff's system, and added debug code, no clue found. However
> >> DaveY found he disabled page_offset
On Wed, Apr 19, 2017 at 7:34 AM, Dan Williams wrote:
> Does the randomization ever cross a pgd boundary?
Yes, it can cross a pgd boundary. The original physical memory mapping
might as well but you would need almost 550Gb of memory.
>
> These crashes look very similar
On Wed, Apr 19, 2017 at 7:34 AM, Dan Williams wrote:
> Does the randomization ever cross a pgd boundary?
Yes, it can cross a pgd boundary. The original physical memory mapping
might as well but you would need almost 550Gb of memory.
>
> These crashes look very similar to the crashes caused by
>
On 04/19/17 at 07:27am, Thomas Garnier wrote:
> On Wed, Apr 19, 2017 at 6:36 AM, Baoquan He wrote:
> > Hi all,
> >
> > I login in Jeff's system, and added debug code, no clue found. However
> > DaveY found he disabled page_offset randomization only and the efi issue
> > won't be
On 04/19/17 at 07:27am, Thomas Garnier wrote:
> On Wed, Apr 19, 2017 at 6:36 AM, Baoquan He wrote:
> > Hi all,
> >
> > I login in Jeff's system, and added debug code, no clue found. However
> > DaveY found he disabled page_offset randomization only and the efi issue
> > won't be seen on his
On Wed, Apr 19, 2017 at 7:27 AM, Thomas Garnier wrote:
> On Wed, Apr 19, 2017 at 6:36 AM, Baoquan He wrote:
>> Hi all,
>>
>> I login in Jeff's system, and added debug code, no clue found. However
>> DaveY found he disabled page_offset randomization only and
On Wed, Apr 19, 2017 at 7:27 AM, Thomas Garnier wrote:
> On Wed, Apr 19, 2017 at 6:36 AM, Baoquan He wrote:
>> Hi all,
>>
>> I login in Jeff's system, and added debug code, no clue found. However
>> DaveY found he disabled page_offset randomization only and the efi issue
>> won't be seen on his
Dave Young writes:
> On 04/12/17 at 04:24pm, Dave Young wrote:
>> I did some tests about emulated pmem via memmap=, kdump kernel hangs or
>> just reboots early during compressing kernel, no clue how to handle it.
>> Since for kdump kernel kaslr is pointless a workaround is use
Dave Young writes:
> On 04/12/17 at 04:24pm, Dave Young wrote:
>> I did some tests about emulated pmem via memmap=, kdump kernel hangs or
>> just reboots early during compressing kernel, no clue how to handle it.
>> Since for kdump kernel kaslr is pointless a workaround is use "nokaslr"
>>
>>
On 04/12/17 at 04:24pm, Dave Young wrote:
> On 04/07/17 at 10:41am, Jeff Moyer wrote:
> > Hi,
> >
> > commit 021182e52fe01 ("x86/mm: Enable KASLR for physical mapping memory
> > regions") causes some of my systems with persistent memory (whether real
> > or emulated) to fail to boot with a couple
On 04/12/17 at 04:24pm, Dave Young wrote:
> On 04/07/17 at 10:41am, Jeff Moyer wrote:
> > Hi,
> >
> > commit 021182e52fe01 ("x86/mm: Enable KASLR for physical mapping memory
> > regions") causes some of my systems with persistent memory (whether real
> > or emulated) to fail to boot with a couple
On 04/12/17 at 04:24pm, Dave Young wrote:
> On 04/07/17 at 10:41am, Jeff Moyer wrote:
> > Hi,
> >
> > commit 021182e52fe01 ("x86/mm: Enable KASLR for physical mapping memory
> > regions") causes some of my systems with persistent memory (whether real
> > or emulated) to fail to boot with a couple
On 04/12/17 at 04:24pm, Dave Young wrote:
> On 04/07/17 at 10:41am, Jeff Moyer wrote:
> > Hi,
> >
> > commit 021182e52fe01 ("x86/mm: Enable KASLR for physical mapping memory
> > regions") causes some of my systems with persistent memory (whether real
> > or emulated) to fail to boot with a couple
On 04/07/17 at 10:41am, Jeff Moyer wrote:
> Hi,
>
> commit 021182e52fe01 ("x86/mm: Enable KASLR for physical mapping memory
> regions") causes some of my systems with persistent memory (whether real
> or emulated) to fail to boot with a couple of different crash
> signatures. The first signature
On 04/07/17 at 10:41am, Jeff Moyer wrote:
> Hi,
>
> commit 021182e52fe01 ("x86/mm: Enable KASLR for physical mapping memory
> regions") causes some of my systems with persistent memory (whether real
> or emulated) to fail to boot with a couple of different crash
> signatures. The first signature
Kees Cook writes:
> On Mon, Apr 10, 2017 at 11:22 AM, Jeff Moyer wrote:
>> Kees Cook writes:
>>
>>> On Mon, Apr 10, 2017 at 8:49 AM, Jeff Moyer wrote:
Kees Cook writes:
>
Kees Cook writes:
> On Mon, Apr 10, 2017 at 11:22 AM, Jeff Moyer wrote:
>> Kees Cook writes:
>>
>>> On Mon, Apr 10, 2017 at 8:49 AM, Jeff Moyer wrote:
Kees Cook writes:
> On Fri, Apr 7, 2017 at 7:41 AM, Jeff Moyer wrote:
>> Hi,
>>
>> commit 021182e52fe01 ("x86/mm:
On Mon, Apr 10, 2017 at 11:22 AM, Jeff Moyer wrote:
> Kees Cook writes:
>
>> On Mon, Apr 10, 2017 at 8:49 AM, Jeff Moyer wrote:
>>> Kees Cook writes:
>>>
On Fri, Apr 7, 2017 at 7:41 AM, Jeff Moyer
On Mon, Apr 10, 2017 at 11:22 AM, Jeff Moyer wrote:
> Kees Cook writes:
>
>> On Mon, Apr 10, 2017 at 8:49 AM, Jeff Moyer wrote:
>>> Kees Cook writes:
>>>
On Fri, Apr 7, 2017 at 7:41 AM, Jeff Moyer wrote:
> Hi,
>
> commit 021182e52fe01 ("x86/mm: Enable KASLR for physical
Kees Cook writes:
> On Mon, Apr 10, 2017 at 8:49 AM, Jeff Moyer wrote:
>> Kees Cook writes:
>>
>>> On Fri, Apr 7, 2017 at 7:41 AM, Jeff Moyer wrote:
Hi,
commit 021182e52fe01 ("x86/mm: Enable
Kees Cook writes:
> On Mon, Apr 10, 2017 at 8:49 AM, Jeff Moyer wrote:
>> Kees Cook writes:
>>
>>> On Fri, Apr 7, 2017 at 7:41 AM, Jeff Moyer wrote:
Hi,
commit 021182e52fe01 ("x86/mm: Enable KASLR for physical mapping memory
regions") causes some of my systems with
On Mon, Apr 10, 2017 at 8:49 AM, Jeff Moyer wrote:
> Kees Cook writes:
>
>> On Fri, Apr 7, 2017 at 7:41 AM, Jeff Moyer wrote:
>>> Hi,
>>>
>>> commit 021182e52fe01 ("x86/mm: Enable KASLR for physical mapping memory
>>> regions") causes
On Mon, Apr 10, 2017 at 8:49 AM, Jeff Moyer wrote:
> Kees Cook writes:
>
>> On Fri, Apr 7, 2017 at 7:41 AM, Jeff Moyer wrote:
>>> Hi,
>>>
>>> commit 021182e52fe01 ("x86/mm: Enable KASLR for physical mapping memory
>>> regions") causes some of my systems with persistent memory (whether real
>>>
Baoquan He writes:
> On 04/07/17 at 10:41am, Jeff Moyer wrote:
>> Hi,
>>
>> commit 021182e52fe01 ("x86/mm: Enable KASLR for physical mapping memory
>> regions") causes some of my systems with persistent memory (whether real
>> or emulated) to fail to boot with a couple of
Baoquan He writes:
> On 04/07/17 at 10:41am, Jeff Moyer wrote:
>> Hi,
>>
>> commit 021182e52fe01 ("x86/mm: Enable KASLR for physical mapping memory
>> regions") causes some of my systems with persistent memory (whether real
>> or emulated) to fail to boot with a couple of different crash
>>
Kees Cook writes:
> On Fri, Apr 7, 2017 at 7:41 AM, Jeff Moyer wrote:
>> Hi,
>>
>> commit 021182e52fe01 ("x86/mm: Enable KASLR for physical mapping memory
>> regions") causes some of my systems with persistent memory (whether real
>> or emulated) to
Kees Cook writes:
> On Fri, Apr 7, 2017 at 7:41 AM, Jeff Moyer wrote:
>> Hi,
>>
>> commit 021182e52fe01 ("x86/mm: Enable KASLR for physical mapping memory
>> regions") causes some of my systems with persistent memory (whether real
>> or emulated) to fail to boot with a couple of different crash
Hi Dan,
Thanks!
On 04/08/17 at 12:02am, Dan Williams wrote:
> > I got below problem when configure ndctl, didn't find a package named
> > libkmod:
> >
> > ~
> > configure: error: Package requirements (libkmod) were not met:
> >
> > No package 'libkmod' found
>
> kmod-devel provides that
Hi Dan,
Thanks!
On 04/08/17 at 12:02am, Dan Williams wrote:
> > I got below problem when configure ndctl, didn't find a package named
> > libkmod:
> >
> > ~
> > configure: error: Package requirements (libkmod) were not met:
> >
> > No package 'libkmod' found
>
> kmod-devel provides that
On Fri, Apr 7, 2017 at 9:08 PM, Baoquan He wrote:
> On 04/07/17 at 10:41am, Jeff Moyer wrote:
>> Hi,
>>
>> commit 021182e52fe01 ("x86/mm: Enable KASLR for physical mapping memory
>> regions") causes some of my systems with persistent memory (whether real
>> or emulated) to fail
On Fri, Apr 7, 2017 at 9:08 PM, Baoquan He wrote:
> On 04/07/17 at 10:41am, Jeff Moyer wrote:
>> Hi,
>>
>> commit 021182e52fe01 ("x86/mm: Enable KASLR for physical mapping memory
>> regions") causes some of my systems with persistent memory (whether real
>> or emulated) to fail to boot with a
On Fri, Apr 7, 2017 at 7:41 AM, Jeff Moyer wrote:
> Hi,
>
> commit 021182e52fe01 ("x86/mm: Enable KASLR for physical mapping memory
> regions") causes some of my systems with persistent memory (whether real
> or emulated) to fail to boot with a couple of different crash
>
On Fri, Apr 7, 2017 at 7:41 AM, Jeff Moyer wrote:
> Hi,
>
> commit 021182e52fe01 ("x86/mm: Enable KASLR for physical mapping memory
> regions") causes some of my systems with persistent memory (whether real
> or emulated) to fail to boot with a couple of different crash
> signatures. The first
Thomas Garnier writes:
> CCing Kees for information.
>
> On Fri, Apr 7, 2017 at 7:41 AM, Jeff Moyer wrote:
>> Hi,
>>
>> commit 021182e52fe01 ("x86/mm: Enable KASLR for physical mapping memory
>> regions") causes some of my systems with persistent memory
Thomas Garnier writes:
> CCing Kees for information.
>
> On Fri, Apr 7, 2017 at 7:41 AM, Jeff Moyer wrote:
>> Hi,
>>
>> commit 021182e52fe01 ("x86/mm: Enable KASLR for physical mapping memory
>> regions") causes some of my systems with persistent memory (whether real
>> or emulated) to fail to
CCing Kees for information.
On Fri, Apr 7, 2017 at 7:41 AM, Jeff Moyer wrote:
> Hi,
>
> commit 021182e52fe01 ("x86/mm: Enable KASLR for physical mapping memory
> regions") causes some of my systems with persistent memory (whether real
> or emulated) to fail to boot with a
CCing Kees for information.
On Fri, Apr 7, 2017 at 7:41 AM, Jeff Moyer wrote:
> Hi,
>
> commit 021182e52fe01 ("x86/mm: Enable KASLR for physical mapping memory
> regions") causes some of my systems with persistent memory (whether real
> or emulated) to fail to boot with a couple of different
52 matches
Mail list logo