Hi Fan Du,
I think we should change the print in mminit_verify_zonelist too.
This patch changes the order of ZONELIST_FALLBACK, so the default numa policy
can
alloc DRAM first, then PMEM, right?
Thanks,
Xishi Qiu
> On system with heterogeneous memory, reasonable fall back lists w
e info,
so how about do not clear the flag after setup_vmalloc_vm, and just
update the print in s_show.
...
if (v->flags & VM_ALLOC)
seq_puts(m, " vmalloc");
+ if (v->flags & VM_MAP_RAM) // add a new flag for vm_map_ram?
+
e info,
so how about do not clear the flag after setup_vmalloc_vm, and just
update the print in s_show.
...
if (v->flags & VM_ALLOC)
seq_puts(m, " vmalloc");
+ if (v->flags & VM_MAP_RAM) // add a new flag for vm_map_ram?
+
Hi, I find the active file + inactive file is larger than cached + buffers,
about 5G,
and can not free it by "echo 3 > /proc/sys/vm/drop_caches"
The meminfo shows that the mapped is also very small, so maybe some get the
page? (e.g. get_user_pages())
Then it will dec the count of NR_FILE_PAGES
Hi, I find the active file + inactive file is larger than cached + buffers,
about 5G,
and can not free it by "echo 3 > /proc/sys/vm/drop_caches"
The meminfo shows that the mapped is also very small, so maybe some get the
page? (e.g. get_user_pages())
Then it will dec the count of NR_FILE_PAGES
On 2018/4/12 9:49, Xishi Qiu wrote:
> Hi, I find CONFIG_X86_RESERVE_LOW=64 in my system, so trim_low_memory_range()
> will reserve low 64kb memory. But efi_free_boot_services() will free it to
> buddy system again later because BIOS set the type to EFI_BOOT_SERVICES_CODE.
>
>
On 2018/4/12 9:49, Xishi Qiu wrote:
> Hi, I find CONFIG_X86_RESERVE_LOW=64 in my system, so trim_low_memory_range()
> will reserve low 64kb memory. But efi_free_boot_services() will free it to
> buddy system again later because BIOS set the type to EFI_BOOT_SERVICES_CODE.
>
>
Hi, I find CONFIG_X86_RESERVE_LOW=64 in my system, so trim_low_memory_range()
will reserve low 64kb memory. But efi_free_boot_services() will free it to
buddy system again later because BIOS set the type to EFI_BOOT_SERVICES_CODE.
Here is the log:
...
efi: mem03: type=3, attr=0xf,
Hi, I find CONFIG_X86_RESERVE_LOW=64 in my system, so trim_low_memory_range()
will reserve low 64kb memory. But efi_free_boot_services() will free it to
buddy system again later because BIOS set the type to EFI_BOOT_SERVICES_CODE.
Here is the log:
...
efi: mem03: type=3, attr=0xf,
On 2018/1/17 17:16, Vlastimil Babka wrote:
> On 12/29/2017 09:58 AM, Xishi Qiu wrote:
>> When calling vfree(), it calls unmap_vmap_area() to clear page table,
>> but do not free the memory of page table, why? just for performance?
>
> I guess it's expected that t
On 2018/1/17 17:16, Vlastimil Babka wrote:
> On 12/29/2017 09:58 AM, Xishi Qiu wrote:
>> When calling vfree(), it calls unmap_vmap_area() to clear page table,
>> but do not free the memory of page table, why? just for performance?
>
> I guess it's expected that t
On 2017/12/29 16:58, Xishi Qiu wrote:
> When calling vfree(), it calls unmap_vmap_area() to clear page table,
> but do not free the memory of page table, why? just for performance?
>
> If a driver use vmalloc() and vfree() frequently, we will lost much
> page table memory,
On 2017/12/29 16:58, Xishi Qiu wrote:
> When calling vfree(), it calls unmap_vmap_area() to clear page table,
> but do not free the memory of page table, why? just for performance?
>
> If a driver use vmalloc() and vfree() frequently, we will lost much
> page table memory,
On 2018/1/6 2:33, Jiri Kosina wrote:
> On Fri, 5 Jan 2018, Xishi Qiu wrote:
>
>> I run the latest RHEL 7.2 with the KAISER/KPTI patch, and boot failed.
>>
>> ...
>> [0.00] PM: Registered nosave memory: [mem
>> 0x810-0x8ff]
>> [
On 2018/1/6 2:33, Jiri Kosina wrote:
> On Fri, 5 Jan 2018, Xishi Qiu wrote:
>
>> I run the latest RHEL 7.2 with the KAISER/KPTI patch, and boot failed.
>>
>> ...
>> [0.00] PM: Registered nosave memory: [mem
>> 0x810-0x8ff]
>> [
I run the latest RHEL 7.2 with the KAISER/KPTI patch, and boot failed.
...
[0.00] PM: Registered nosave memory: [mem 0x810-0x8ff]
[0.00] PM: Registered nosave memory: [mem 0x910-0xfff]
[0.00] PM: Registered nosave memory: [mem
I run the latest RHEL 7.2 with the KAISER/KPTI patch, and boot failed.
...
[0.00] PM: Registered nosave memory: [mem 0x810-0x8ff]
[0.00] PM: Registered nosave memory: [mem 0x910-0xfff]
[0.00] PM: Registered nosave memory: [mem
When calling vfree(), it calls unmap_vmap_area() to clear page table,
but do not free the memory of page table, why? just for performance?
If a driver use vmalloc() and vfree() frequently, we will lost much
page table memory, maybe oom later.
Thanks,
Xishi Qiu
When calling vfree(), it calls unmap_vmap_area() to clear page table,
but do not free the memory of page table, why? just for performance?
If a driver use vmalloc() and vfree() frequently, we will lost much
page table memory, maybe oom later.
Thanks,
Xishi Qiu
On 2017/12/21 16:55, Xishi Qiu wrote:
> When we use iounmap() to free the mapping, it calls unmap_vmap_area() to
> clear page table,
> but do not free the memory of page table, right?
>
> So when use ioremap() to mapping another area(incluce the area before), it
> may use
&
On 2017/12/21 16:55, Xishi Qiu wrote:
> When we use iounmap() to free the mapping, it calls unmap_vmap_area() to
> clear page table,
> but do not free the memory of page table, right?
>
> So when use ioremap() to mapping another area(incluce the area before), it
> may use
&
memory(e.g. pte memory)
will be lost, it cause memory leak, right?
Thanks,
Xishi Qiu
memory(e.g. pte memory)
will be lost, it cause memory leak, right?
Thanks,
Xishi Qiu
rk for memory hotplug because it requires
>> MIGRATE_MOVABLE.
>
> Unfortunately, alloc_contig_range() can be called with
> MIGRATE_MOVABLE so this patch cannot perfectly fix the problem.
>
> I did a more thinking and found that it's strange to check if there is
> unmovable page in the pageblock during the set_migratetype_isolate().
> set_migratetype_isolate() should be just for setting the migratetype
> of the pageblock. Checking other things should be done by another
> place, for example, before calling the start_isolate_page_range() in
> __offline_pages().
>
> Thanks.
>
Hi Joonsoo,
How about add a flag to skip or not has_unmovable_pages() in
set_migratetype_isolate()?
Something like the skip_hwpoisoned_pages.
Thanks,
Xishi Qiu
>
> .
>
because it requires
>> MIGRATE_MOVABLE.
>
> Unfortunately, alloc_contig_range() can be called with
> MIGRATE_MOVABLE so this patch cannot perfectly fix the problem.
>
> I did a more thinking and found that it's strange to check if there is
> unmovable page in the pageblock during the set_migratetype_isolate().
> set_migratetype_isolate() should be just for setting the migratetype
> of the pageblock. Checking other things should be done by another
> place, for example, before calling the start_isolate_page_range() in
> __offline_pages().
>
> Thanks.
>
Hi Joonsoo,
How about add a flag to skip or not has_unmovable_pages() in
set_migratetype_isolate()?
Something like the skip_hwpoisoned_pages.
Thanks,
Xishi Qiu
>
> .
>
On 2017/10/10 2:26, Michal Hocko wrote:
> On Wed 27-09-17 13:51:09, Xishi Qiu wrote:
>> On 2017/9/26 19:00, Michal Hocko wrote:
>>
>>> On Tue 26-09-17 11:45:16, Vlastimil Babka wrote:
>>>> On 09/26/2017 11:22 AM, Xishi Qiu wrote:
>>>>> On 2017
On 2017/10/10 2:26, Michal Hocko wrote:
> On Wed 27-09-17 13:51:09, Xishi Qiu wrote:
>> On 2017/9/26 19:00, Michal Hocko wrote:
>>
>>> On Tue 26-09-17 11:45:16, Vlastimil Babka wrote:
>>>> On 09/26/2017 11:22 AM, Xishi Qiu wrote:
>>>>> On 2017
On 2017/9/26 19:00, Michal Hocko wrote:
> On Tue 26-09-17 11:45:16, Vlastimil Babka wrote:
>> On 09/26/2017 11:22 AM, Xishi Qiu wrote:
>>> On 2017/9/26 17:13, Xishi Qiu wrote:
>>>>> This is still very fuzzy. What are you actually trying to achieve?
>>>
On 2017/9/26 19:00, Michal Hocko wrote:
> On Tue 26-09-17 11:45:16, Vlastimil Babka wrote:
>> On 09/26/2017 11:22 AM, Xishi Qiu wrote:
>>> On 2017/9/26 17:13, Xishi Qiu wrote:
>>>>> This is still very fuzzy. What are you actually trying to achieve?
>>>
On 2017/9/26 17:13, Xishi Qiu wrote:
> On 2017/9/26 17:02, Michal Hocko wrote:
>
>> On Tue 26-09-17 16:39:56, Xishi Qiu wrote:
>>> On 2017/9/26 16:17, Michal Hocko wrote:
>>>
>>>> On Tue 26-09-17 15:56:55, Xishi Qiu wrote:
>>>>>
On 2017/9/26 17:13, Xishi Qiu wrote:
> On 2017/9/26 17:02, Michal Hocko wrote:
>
>> On Tue 26-09-17 16:39:56, Xishi Qiu wrote:
>>> On 2017/9/26 16:17, Michal Hocko wrote:
>>>
>>>> On Tue 26-09-17 15:56:55, Xishi Qiu wrote:
>>>>>
On 2017/9/26 17:02, Michal Hocko wrote:
> On Tue 26-09-17 16:39:56, Xishi Qiu wrote:
>> On 2017/9/26 16:17, Michal Hocko wrote:
>>
>>> On Tue 26-09-17 15:56:55, Xishi Qiu wrote:
>>>> When we call mlockall(), we will add VM_LOCKED to the vma,
>>>> if
On 2017/9/26 17:02, Michal Hocko wrote:
> On Tue 26-09-17 16:39:56, Xishi Qiu wrote:
>> On 2017/9/26 16:17, Michal Hocko wrote:
>>
>>> On Tue 26-09-17 15:56:55, Xishi Qiu wrote:
>>>> When we call mlockall(), we will add VM_LOCKED to the vma,
>>>> if
On 2017/9/26 16:17, Michal Hocko wrote:
> On Tue 26-09-17 15:56:55, Xishi Qiu wrote:
>> When we call mlockall(), we will add VM_LOCKED to the vma,
>> if the vma prot is ---p,
>
> not sure what you mean here. apply_mlockall_flags will set the flag on
> all vmas exc
On 2017/9/26 16:17, Michal Hocko wrote:
> On Tue 26-09-17 15:56:55, Xishi Qiu wrote:
>> When we call mlockall(), we will add VM_LOCKED to the vma,
>> if the vma prot is ---p,
>
> not sure what you mean here. apply_mlockall_flags will set the flag on
> all vmas exc
Ignore errors */
(void) __mm_populate(addr, len, 1);
}
And later we call mprotect() to change the prot, then it is
still not alloc memory for the mlocked vma.
My question is that, shall we alloc memory if the prot changed,
and who(kernel, glibc, user) should alloc the memory?
Thanks,
Xishi Qiu
Ignore errors */
(void) __mm_populate(addr, len, 1);
}
And later we call mprotect() to change the prot, then it is
still not alloc memory for the mlocked vma.
My question is that, shall we alloc memory if the prot changed,
and who(kernel, glibc, user) should alloc the memory?
Thanks,
Xishi Qiu
LES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
parent_tidptr=0x7fca226a69d0, tls=0x7fca226a6700, child_tidptr=0x7fca226a69d0)
= 21043
...
Thanks,
Xishi Qiu
LES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
parent_tidptr=0x7fca226a69d0, tls=0x7fca226a6700, child_tidptr=0x7fca226a69d0)
= 21043
...
Thanks,
Xishi Qiu
On 2017/9/4 17:01, Michal Hocko wrote:
> On Mon 04-09-17 16:58:30, Xishi Qiu wrote:
>> On 2017/9/4 16:21, Michal Hocko wrote:
>>
>>> From: Michal Hocko <mho...@suse.com>
>>>
>>> We have a hardcoded 120s timeout after which the memory offline f
On 2017/9/4 17:01, Michal Hocko wrote:
> On Mon 04-09-17 16:58:30, Xishi Qiu wrote:
>> On 2017/9/4 16:21, Michal Hocko wrote:
>>
>>> From: Michal Hocko
>>>
>>> We have a hardcoded 120s timeout after which the memory offline fails
>>>
eration is interruptible by a signal so if userspace wants
Hi Michal,
If the user know what he should do if migration for a long time,
it is OK, but I don't think all the users know this operation
(e.g. ctrl + c) and the affect.
Thanks,
Xishi Qiu
> some timeout based termination this c
by a signal so if userspace wants
Hi Michal,
If the user know what he should do if migration for a long time,
it is OK, but I don't think all the users know this operation
(e.g. ctrl + c) and the affect.
Thanks,
Xishi Qiu
> some timeout based termination this can be done trivially by sending a
On 2017/7/19 16:40, Vlastimil Babka wrote:
> On 07/18/2017 12:59 PM, Xishi Qiu wrote:
>> Hi,
>>
>> Unfortunately, this patch(mm: thp: fix SMP race condition between
>> THP page fault and MADV_DONTNEED) didn't help, I got the panic again.
>
> Too bad then. I don'
On 2017/7/19 16:40, Vlastimil Babka wrote:
> On 07/18/2017 12:59 PM, Xishi Qiu wrote:
>> Hi,
>>
>> Unfortunately, this patch(mm: thp: fix SMP race condition between
>> THP page fault and MADV_DONTNEED) didn't help, I got the panic again.
>
> Too bad then. I don'
On 2017/6/8 21:59, Vlastimil Babka wrote:
> On 06/08/2017 03:44 PM, Xishi Qiu wrote:
>> On 2017/5/23 17:33, Vlastimil Babka wrote:
>>
>>> On 05/23/2017 11:21 AM, zhong jiang wrote:
>>>> On 2017/5/23 0:51, Vlastimil Babka wrote:
>>>>> On 05/20/20
On 2017/6/8 21:59, Vlastimil Babka wrote:
> On 06/08/2017 03:44 PM, Xishi Qiu wrote:
>> On 2017/5/23 17:33, Vlastimil Babka wrote:
>>
>>> On 05/23/2017 11:21 AM, zhong jiang wrote:
>>>> On 2017/5/23 0:51, Vlastimil Babka wrote:
>>>>> On 05/20/20
On 2017/6/29 16:22, Xishi Qiu wrote:
> centos 7.2，I got some oops form my production line,
> Anybody has seen these errors before?
>
Here is another one
[ 703.025737] BUG: unable to handle kernel NULL pointer dereference at
0d68
[ 703.026008] IP: [] mlx4_en_QUERY_PORT+0
On 2017/6/29 16:22, Xishi Qiu wrote:
> centos 7.2，I got some oops form my production line,
> Anybody has seen these errors before?
>
Here is another one
[ 703.025737] BUG: unable to handle kernel NULL pointer dereference at
0d68
[ 703.026008] IP: [] mlx4_en_QUERY_PORT+0
centos 7.2，I got some oops form my production line,
Anybody has seen these errors before?
1)
2017-06-28T02:18:16.461384+08:00[880983.488036] do nothing after die!
2017-06-28T02:18:16.462068+08:00[880983.488723] Modules linked in: fuse
iptable_filter sha512_generic icp_qa_al_vf(OVE) vfat fat
centos 7.2，I got some oops form my production line,
Anybody has seen these errors before?
1)
2017-06-28T02:18:16.461384+08:00[880983.488036] do nothing after die!
2017-06-28T02:18:16.462068+08:00[880983.488723] Modules linked in: fuse
iptable_filter sha512_generic icp_qa_al_vf(OVE) vfat fat
On 2017/6/24 19:12, Greg KH wrote:
> On Sat, Jun 24, 2017 at 05:52:23PM +0800, Yisheng Xie wrote:
>> hi all,
>>
>> I met an Oops problem with linux-3.10. The RIP is sysfs_open_file+0x46/0x2b0
>> (I will and the full
>> crash log in the end of this mail).
>
> 3.10 is _very_ old and obsolete, can
On 2017/6/24 19:12, Greg KH wrote:
> On Sat, Jun 24, 2017 at 05:52:23PM +0800, Yisheng Xie wrote:
>> hi all,
>>
>> I met an Oops problem with linux-3.10. The RIP is sysfs_open_file+0x46/0x2b0
>> (I will and the full
>> crash log in the end of this mail).
>
> 3.10 is _very_ old and obsolete, can
On 2017/5/23 17:33, Vlastimil Babka wrote:
> On 05/23/2017 11:21 AM, zhong jiang wrote:
>> On 2017/5/23 0:51, Vlastimil Babka wrote:
>>> On 05/20/2017 05:01 AM, zhong jiang wrote:
>>>> On 2017/5/20 10:40, Hugh Dickins wrote:
>>>>> On Sat, 20 May 2017,
On 2017/5/23 17:33, Vlastimil Babka wrote:
> On 05/23/2017 11:21 AM, zhong jiang wrote:
>> On 2017/5/23 0:51, Vlastimil Babka wrote:
>>> On 05/20/2017 05:01 AM, zhong jiang wrote:
>>>> On 2017/5/20 10:40, Hugh Dickins wrote:
>>>>> On Sat, 20 May 2017,
On 2017/6/4 23:06, Thomas Gleixner wrote:
> On Thu, 1 Jun 2017, Xishi Qiu wrote:
>
> Cc'ed John Stultz
>
>> Hi, this is the test case, and then I got ubsan error
>> (signed integer overflow) report, so the root cause is from
>> user or kernel? Shall we cha
On 2017/6/4 23:06, Thomas Gleixner wrote:
> On Thu, 1 Jun 2017, Xishi Qiu wrote:
>
> Cc'ed John Stultz
>
>> Hi, this is the test case, and then I got ubsan error
>> (signed integer overflow) report, so the root cause is from
>> user or kernel? Shall we cha
I got some error report during boot from ubsan,
kernel version is v4.12
[0.001000]
[0.001000] UBSAN: Undefined behaviour in
arch/x86/kernel/apic/apic_flat_64.c:49:11
[0.001000] shift exponent 64 is too
I got some error report during boot from ubsan,
kernel version is v4.12
[0.001000]
[0.001000] UBSAN: Undefined behaviour in
arch/x86/kernel/apic/apic_flat_64.c:49:11
[0.001000] shift exponent 64 is too
Hi, this is the test case, and then I got ubsan error
(signed integer overflow) report, so the root cause is from
user or kernel? Shall we change something in timeval_valid()?
struct itimerval new_value;
int ret;
new_value.it_interval.tv_sec = 140673496649799L;
new_value.it_interval.tv_usec =
Hi, this is the test case, and then I got ubsan error
(signed integer overflow) report, so the root cause is from
user or kernel? Shall we change something in timeval_valid()?
struct itimerval new_value;
int ret;
new_value.it_interval.tv_sec = 140673496649799L;
new_value.it_interval.tv_usec =
On 2017/5/24 21:16, Vlastimil Babka wrote:
> On 05/24/2017 02:10 PM, Xishi Qiu wrote:
>> On 2017/5/24 19:52, Vlastimil Babka wrote:
>>
>>> On 05/24/2017 01:38 PM, Xishi Qiu wrote:
>>>>>
>>>>> Race condition with what? Who else would isolat
On 2017/5/24 21:16, Vlastimil Babka wrote:
> On 05/24/2017 02:10 PM, Xishi Qiu wrote:
>> On 2017/5/24 19:52, Vlastimil Babka wrote:
>>
>>> On 05/24/2017 01:38 PM, Xishi Qiu wrote:
>>>>>
>>>>> Race condition with what? Who else would isolat
On 2017/5/24 19:52, Vlastimil Babka wrote:
> On 05/24/2017 01:38 PM, Xishi Qiu wrote:
>>>
>>> Race condition with what? Who else would isolate our pages?
>>>
>>
>> Hi Vlastimil,
>>
>> I find the root cause, if the page was not cached on the c
On 2017/5/24 19:52, Vlastimil Babka wrote:
> On 05/24/2017 01:38 PM, Xishi Qiu wrote:
>>>
>>> Race condition with what? Who else would isolate our pages?
>>>
>>
>> Hi Vlastimil,
>>
>> I find the root cause, if the page was not cached on the c
44
--- a/mm/mlock.c
+++ b/mm/mlock.c
@@ -88,6 +88,11 @@ void mlock_vma_page(struct page *page)
count_vm_event(UNEVICTABLE_PGMLOCKED);
if (!isolate_lru_page(page))
putback_lru_page(page);
+ else {
+ ClearPageMlocked(page);
+ mod_zone_page_state(page_zone(page), NR_MLOCK,
+ -hpage_nr_pages(page));
+ }
}
}
Thanks,
Xishi Qiu
ma_page(struct page *page)
count_vm_event(UNEVICTABLE_PGMLOCKED);
if (!isolate_lru_page(page))
putback_lru_page(page);
+ else {
+ ClearPageMlocked(page);
+ mod_zone_page_state(page_zone(page), NR_MLOCK,
+ -hpage_nr_pages(page));
+ }
}
}
Thanks,
Xishi Qiu
ntentionally changed with my patch. There should be a Fixes:
> tag for that.
>
Hi Vlastimil,
Why the page has marked Mlocked, but not in lru list?
if (TestClearPageMlocked(page)) {
/*
* We already have pin from follow_page_mask()
lastimil,
Why the page has marked Mlocked, but not in lru list?
if (TestClearPageMlocked(page)) {
/*
* We already have pin from follow_page_mask()
* so we can spare the get_page() here.
*/
On 2017/5/24 15:49, Vlastimil Babka wrote:
> On 05/24/2017 06:40 AM, Xishi Qiu wrote:
>> On 2017/5/24 9:40, Xishi Qiu wrote:
>>
>>> Hi, I find we use rcu access task_struct in mm_match_cgroup(), but not use
>>> rcu free in free_task_struct(), is it right?
>&g
On 2017/5/24 15:49, Vlastimil Babka wrote:
> On 05/24/2017 06:40 AM, Xishi Qiu wrote:
>> On 2017/5/24 9:40, Xishi Qiu wrote:
>>
>>> Hi, I find we use rcu access task_struct in mm_match_cgroup(), but not use
>>> rcu free in free_task_struct(), is it right?
>&g
On 2017/5/24 9:40, Xishi Qiu wrote:
> Hi, I find we use rcu access task_struct in mm_match_cgroup(), but not use
> rcu free in free_task_struct(), is it right?
>
> Here is the backtrace.
>
> PID: 2133 TASK: 881fe3353300 CPU: 2 COMMAND: "CPU 15/KVM&q
On 2017/5/24 9:40, Xishi Qiu wrote:
> Hi, I find we use rcu access task_struct in mm_match_cgroup(), but not use
> rcu free in free_task_struct(), is it right?
>
> Here is the backtrace.
>
> PID: 2133 TASK: 881fe3353300 CPU: 2 COMMAND: "CPU 15/KVM&q
Hi, I find we use rcu access task_struct in mm_match_cgroup(), but not use
rcu free in free_task_struct(), is it right?
Here is the backtrace.
PID: 2133 TASK: 881fe3353300 CPU: 2 COMMAND: "CPU 15/KVM"
#0 [881fe276b528] machine_kexec at 8105280b
#1 [881fe276b588]
Hi, I find we use rcu access task_struct in mm_match_cgroup(), but not use
rcu free in free_task_struct(), is it right?
Here is the backtrace.
PID: 2133 TASK: 881fe3353300 CPU: 2 COMMAND: "CPU 15/KVM"
#0 [881fe276b528] machine_kexec at 8105280b
#1 [881fe276b588]
On 2017/5/23 3:26, Hugh Dickins wrote:
> On Mon, 22 May 2017, Xishi Qiu wrote:
>> On 2017/5/20 10:40, Hugh Dickins wrote:
>>> On Sat, 20 May 2017, Xishi Qiu wrote:
>>>>
>>>> Here is a bug report form redhat:
>>>> https://bugzilla.redhat.c
On 2017/5/23 3:26, Hugh Dickins wrote:
> On Mon, 22 May 2017, Xishi Qiu wrote:
>> On 2017/5/20 10:40, Hugh Dickins wrote:
>>> On Sat, 20 May 2017, Xishi Qiu wrote:
>>>>
>>>> Here is a bug report form redhat:
>>>> https://bugzilla.redhat.c
On 2017/5/20 10:40, Hugh Dickins wrote:
> On Sat, 20 May 2017, Xishi Qiu wrote:
>>
>> Here is a bug report form redhat:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1305620
>> And I meet the bug too. However it is hard to reproduce, and
>> 624483f3ea82
On 2017/5/20 10:40, Hugh Dickins wrote:
> On Sat, 20 May 2017, Xishi Qiu wrote:
>>
>> Here is a bug report form redhat:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1305620
>> And I meet the bug too. However it is hard to reproduce, and
>> 624483f3ea82
On 2017/5/20 10:02, Hugh Dickins wrote:
> On Sat, 20 May 2017, Xishi Qiu wrote:
>> On 2017/5/20 6:00, Hugh Dickins wrote:
>>>
>>> You're ignoring the rcu_read_lock() on entry to page_lock_anon_vma_read(),
>>> and the SLAB_DESTROY_BY_RCU (recently
On 2017/5/20 10:02, Hugh Dickins wrote:
> On Sat, 20 May 2017, Xishi Qiu wrote:
>> On 2017/5/20 6:00, Hugh Dickins wrote:
>>>
>>> You're ignoring the rcu_read_lock() on entry to page_lock_anon_vma_read(),
>>> and the SLAB_DESTROY_BY_RCU (recently
On 2017/5/20 6:00, Hugh Dickins wrote:
> On Fri, 19 May 2017, Xishi Qiu wrote:
>> On 2017/5/19 16:52, Xishi Qiu wrote:
>>> On 2017/5/18 17:46, Xishi Qiu wrote:
>>>
>>>> Hi, my system triggers this bug, and the vmcore shows the anon_vma seems
>
On 2017/5/20 6:00, Hugh Dickins wrote:
> On Fri, 19 May 2017, Xishi Qiu wrote:
>> On 2017/5/19 16:52, Xishi Qiu wrote:
>>> On 2017/5/18 17:46, Xishi Qiu wrote:
>>>
>>>> Hi, my system triggers this bug, and the vmcore shows the anon_vma seems
>
On 2017/5/19 16:52, Xishi Qiu wrote:
> On 2017/5/18 17:46, Xishi Qiu wrote:
>
>> Hi, my system triggers this bug, and the vmcore shows the anon_vma seems be
>> freed.
>> The kernel is RHEL 7.2, and the bug is hard to reproduce, so I don't know if
>> it
&g
On 2017/5/19 16:52, Xishi Qiu wrote:
> On 2017/5/18 17:46, Xishi Qiu wrote:
>
>> Hi, my system triggers this bug, and the vmcore shows the anon_vma seems be
>> freed.
>> The kernel is RHEL 7.2, and the bug is hard to reproduce, so I don't know if
>> it
&g
On 2017/5/18 17:46, Xishi Qiu wrote:
> Hi, my system triggers this bug, and the vmcore shows the anon_vma seems be
> freed.
> The kernel is RHEL 7.2, and the bug is hard to reproduce, so I don't know if
> it
> exists in mainline, any reply is welcome!
>
When we alloc anon
On 2017/5/18 17:46, Xishi Qiu wrote:
> Hi, my system triggers this bug, and the vmcore shows the anon_vma seems be
> freed.
> The kernel is RHEL 7.2, and the bug is hard to reproduce, so I don't know if
> it
> exists in mainline, any reply is welcome!
>
When we alloc anon
Hi, my system triggers this bug, and the vmcore shows the anon_vma seems be
freed.
The kernel is RHEL 7.2, and the bug is hard to reproduce, so I don't know if it
exists in mainline, any reply is welcome!
[35030.332666] general protection fault: [#1] SMP
[35030.333016] Modules linked in:
Hi, my system triggers this bug, and the vmcore shows the anon_vma seems be
freed.
The kernel is RHEL 7.2, and the bug is hard to reproduce, so I don't know if it
exists in mainline, any reply is welcome!
[35030.332666] general protection fault: [#1] SMP
[35030.333016] Modules linked in:
2017-05-12T04:46:36.373001+08:00[[32m OK [0m] Reached target System
Initialization.
2017-05-12T04:46:36.385253+08:00[[32m OK [0m] Reached target Basic System.
2017-05-12T04:46:43.049936+08:00[ 25.839157] BUG: unable to handle kernel [
25.841509] floppy0: no floppy controllers found
2017-05-12T04:46:36.373001+08:00[[32m OK [0m] Reached target System
Initialization.
2017-05-12T04:46:36.385253+08:00[[32m OK [0m] Reached target Basic System.
2017-05-12T04:46:43.049936+08:00[ 25.839157] BUG: unable to handle kernel [
25.841509] floppy0: no floppy controllers found
ems simply have large
> gaps in physical memory access. Their memory map
> may look like this:
>
> |MM|IO||..||
>
> Where M is memory, IO is IO space, and the
> dots are simply a gap in physical address
> space with no valid accesse
ems simply have large
> gaps in physical memory access. Their memory map
> may look like this:
>
> |MM|IO||..||
>
> Where M is memory, IO is IO space, and the
> dots are simply a gap in physical address
> space with no valid accesse
On 2017/5/2 17:16, Michal Hocko wrote:
> On Tue 02-05-17 16:52:00, Xishi Qiu wrote:
>> On 2017/5/2 16:43, Michal Hocko wrote:
>>
>>> On Tue 02-05-17 15:59:23, Xishi Qiu wrote:
>>>> Hi, I use "memtester -p 0x6c800 10G" to test physi
On 2017/5/2 17:16, Michal Hocko wrote:
> On Tue 02-05-17 16:52:00, Xishi Qiu wrote:
>> On 2017/5/2 16:43, Michal Hocko wrote:
>>
>>> On Tue 02-05-17 15:59:23, Xishi Qiu wrote:
>>>> Hi, I use "memtester -p 0x6c800 10G" to test physi
On 2017/5/2 16:43, Michal Hocko wrote:
> On Tue 02-05-17 15:59:23, Xishi Qiu wrote:
>> Hi, I use "memtester -p 0x6c800 10G" to test physical address
>> 0x6c800
>> Because this physical address is invalid, and valid_mmap_phys_addr_range()
>>
On 2017/5/2 16:43, Michal Hocko wrote:
> On Tue 02-05-17 15:59:23, Xishi Qiu wrote:
>> Hi, I use "memtester -p 0x6c800 10G" to test physical address
>> 0x6c800
>> Because this physical address is invalid, and valid_mmap_phys_addr_range()
>>
169.147578] ? panic+0x1f1/0x239
[ 169.150789] oops_end+0xb8/0xd0
[ 169.153910] pgtable_bad+0x8a/0x95
[ 169.157294] __do_page_fault+0x3aa/0x4a0
[ 169.161194] do_page_fault+0x30/0x80
[ 169.164750] ? do_syscall_64+0x175/0x180
[ 169.168649] page_fault+0x28/0x30
Thanks,
Xishi Qiu
169.147578] ? panic+0x1f1/0x239
[ 169.150789] oops_end+0xb8/0xd0
[ 169.153910] pgtable_bad+0x8a/0x95
[ 169.157294] __do_page_fault+0x3aa/0x4a0
[ 169.161194] do_page_fault+0x30/0x80
[ 169.164750] ? do_syscall_64+0x175/0x180
[ 169.168649] page_fault+0x28/0x30
Thanks,
Xishi Qiu
On 2017/4/10 17:37, Hillf Danton wrote:
> On April 10, 2017 4:57 PM Xishi Qiu wrote:
>> On 2017/4/10 14:42, Hillf Danton wrote:
>>
>>> On April 08, 2017 9:40 PM zhong Jiang wrote:
>>>>
>>>> when runing the stabile docker cases in the vm. The f
1 - 100 of 1005 matches
Mail list logo
