* Re: [PATCH] fork: fix kmemleak false positive due to thread stacks caching
From: Luis Henriques @ 2017-05-26 15:06 UTC (permalink / raw)
To: Catalin Marinas
Cc: Andy Lutomirski, Ingo Molnar, Andrew Morton, Michal Hocko,
Thomas Gleixner, Eric W . Biederman, Peter Zijlstra,
Oleg Nesterov, Mateusz Guzik, linux-kernel, stable
In-Reply-To: <20170526142254.GB30853@e104818-lin.cambridge.arm.com>
On Fri, May 26, 2017 at 03:22:54PM +0100, Catalin Marinas wrote:
> On Fri, May 26, 2017 at 02:49:49PM +0100, Luis Henriques wrote:
> > kmemleak has been reporting memory leaks since commit ac496bf48d97 ("fork:
> > Optimize task creation by caching two thread stacks per CPU if
> > CONFIG_VMAP_STACK=y"):
> >
> > unreferenced object 0xffffc900002b0000 (size 16384):
> > comm "init", pid 147, jiffies 4294893306 (age 11.292s)
> > hex dump (first 32 bytes):
> > 9d 6e ac 57 00 00 00 00 00 00 00 00 00 00 00 00 .n.W............
> > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> > backtrace:
> > [<ffffffff815b481e>] kmemleak_alloc+0x4e/0xb0
> > [<ffffffff8112a8b0>] __vmalloc_node_range+0x160/0x240
> > [<ffffffff8104a328>] copy_process.part.8+0x478/0x1630
> > [<ffffffff8104b69a>] _do_fork+0xca/0x330
> > [<ffffffff8104b9a9>] SyS_clone+0x19/0x20
> > [<ffffffff8100199c>] do_syscall_64+0x4c/0xb0
> > [<ffffffff815b8d06>] return_from_SYSCALL_64+0x0/0x6a
> > [<ffffffffffffffff>] 0xffffffffffffffff
> >
> > This is because this commit started caching 2 thread stacks per CPU, and
> > kmemleak assumes its memory is never freed. Report these stacks as not
> > being memory leaks using kmemleak_not_leak().
> >
> > Cc: stable@vger.kernel.org
> > Fixes: ac496bf48d97 ("fork: Optimize task creation by caching two thread stacks per CPU if CONFIG_VMAP_STACK=y")
> > Signed-off-by: Luis Henriques <lhenriques@suse.com>
>
> I guess that's meant as a 4.12 and earlier fix until the
> kmemleak_vmalloc() patches go in
> (http://lkml.kernel.org/r/1495726937-23557-1-git-send-email-catalin.marinas@arm.com)
>
> > diff --git a/kernel/fork.c b/kernel/fork.c
> > index aa1076c5e4a9..c4d79ad0f5bc 100644
> > --- a/kernel/fork.c
> > +++ b/kernel/fork.c
> > @@ -255,6 +255,7 @@ static inline void free_thread_stack(struct task_struct *tsk)
> >
> > this_cpu_write(cached_stacks[i], tsk->stack_vm_area);
> > local_irq_restore(flags);
> > + kmemleak_not_leak(tsk->stack);
>
> I would add a comment here on why the annotation is needed.
>
> The disadvantage is that such objects would no longer be detected as
> leaks since kmemleak doesn't have a way to "unignore" an object (I have
> a patch but not worth merging since we'll fix the above with a dedicated
> kmemleak_vmalloc() API). We could however work around this with the
> current kmemleak API as in this patch:
>
> http://lkml.kernel.org/r/20170516133925.GA9453@e104818-lin.cambridge.arm.com
Ok, looks like I need to improve my lkml search-fu -- I totally missed
this discussion and the patchset with the new API!
So, I guess it only makes sense to work around this issue with the current
API when backporting the fix to stable kernels, in case you think it's
worth fixing this in older kernels, of course. (Or maybe if this new API
doesn't make it into 4.12...)
Anyway, thanks for pointing me at this patchset Catalin. I'll have a look
at it.
Cheers,
--
Lu�s
^ permalink raw reply
* Re: + mm-migrate-fix-ref-count-handling-when-hugepage_migration_supported-v2.patch added to -mm tree
From: Punit Agrawal @ 2017-05-26 14:52 UTC (permalink / raw)
To: Mel Gorman
Cc: akpm, cl, iamjoonsoo.kim, manoj.iyer, n-horiguchi, stable,
wanpeng.li, mm-commits
In-Reply-To: <20170526104239.d2dwmm3vdcjx2g5n@techsingularity.net>
Mel Gorman <mgorman@techsingularity.net> writes:
> On Thu, May 25, 2017 at 03:46:23PM -0700, akpm@linux-foundation.org wrote:
>> ------------------------------------------------------
>> From: Punit Agrawal <punit.agrawal@arm.com>
>> Subject: mm/migrate: fix refcount handling when !hugepage_migration_supported()
>>
>> On failing to migrate a page, soft_offline_huge_page() performs the
>> necessary update to the hugepage ref-count. When
>> !hugepage_migration_supported() , unmap_and_move_hugepage() also
>> decrements the page ref-count for the hugepage. The combined behaviour
>> leaves the ref-count in an inconsistent state.
>>
>> This leads to soft lockups when running the overcommitted hugepage test
>> from mce-tests suite.
>>
>> Soft offlining pfn 0x83ed600 at process virtual address 0x400000000000
>> soft offline: 0x83ed600: migration failed 1, type
>> 1fffc00000008008 (uptodate|head)
>> INFO: rcu_preempt detected stalls on CPUs/tasks:
>> Tasks blocked on level-0 rcu_node (CPUs 0-7): P2715
>> (detected by 7, t=5254 jiffies, g=963, c=962, q=321)
>> thugetlb_overco R running task 0 2715 2685 0x00000008
>> Call trace:
>> [<ffff000008089f90>] dump_backtrace+0x0/0x268
>> [<ffff00000808a2d4>] show_stack+0x24/0x30
>> [<ffff000008100d34>] sched_show_task+0x134/0x180
>> [<ffff0000081c90fc>] rcu_print_detail_task_stall_rnp+0x54/0x7c
>> [<ffff00000813cfd4>] rcu_check_callbacks+0xa74/0xb08
>> [<ffff000008143a3c>] update_process_times+0x34/0x60
>> [<ffff0000081550e8>] tick_sched_handle.isra.7+0x38/0x70
>> [<ffff00000815516c>] tick_sched_timer+0x4c/0x98
>> [<ffff0000081442e0>] __hrtimer_run_queues+0xc0/0x300
>> [<ffff000008144fa4>] hrtimer_interrupt+0xac/0x228
>> [<ffff0000089a56d4>] arch_timer_handler_phys+0x3c/0x50
>> [<ffff00000812f1bc>] handle_percpu_devid_irq+0x8c/0x290
>> [<ffff0000081297fc>] generic_handle_irq+0x34/0x50
>> [<ffff000008129f00>] __handle_domain_irq+0x68/0xc0
>> [<ffff0000080816b4>] gic_handle_irq+0x5c/0xb0
>>
>> Address this by changing the putback_active_hugepage() in
>> soft_offline_huge_page() to putback_movable_pages().
>>
>
> I've never looked too closely at how hardware poisoning and hugetlb pages
> migration is handled so I could easily have missed something but this
> changelog and patch confuses me.
>
> Surely if the inconsistency is between hugepage_migration_supported and
> !hugepage_migration_supported then the check in soft_offline_huge_page()
> should also be related to hugepage_migration_supported either in
> soft_offline_huge_page() or in putback_movable_pages()?
The first version of the patch did indeed make a change that was around
!hugepage_migration_supported() [0] which was effectively a revert of
32665f2bbfed ("mm/migrate: correct failure handling if
!hugepage_migration_support()").
But Horiguchi-san suggested that dropping the putback_active_hugepage()
from unmap_and_move_hugepage() will bring back the issue that
32665f2bbfed addressed it was safer to take the current approach. It
also matches the pattern followed for !hugepage.
I did update the changelog but perhaps not enough - would updating the
changelog to reflect this help make it clearer?
Thanks,
Punit
[0] https://www.spinics.net/lists/kernel/msg2516334.html
^ permalink raw reply
* Re: [PATCH] fork: fix kmemleak false positive due to thread stacks caching
From: Catalin Marinas @ 2017-05-26 14:22 UTC (permalink / raw)
To: Luis Henriques
Cc: Andy Lutomirski, Ingo Molnar, Andrew Morton, Michal Hocko,
Thomas Gleixner, Eric W . Biederman, Peter Zijlstra,
Oleg Nesterov, Mateusz Guzik, linux-kernel, stable
In-Reply-To: <20170526134949.3045-1-lhenriques@suse.com>
On Fri, May 26, 2017 at 02:49:49PM +0100, Luis Henriques wrote:
> kmemleak has been reporting memory leaks since commit ac496bf48d97 ("fork:
> Optimize task creation by caching two thread stacks per CPU if
> CONFIG_VMAP_STACK=y"):
>
> unreferenced object 0xffffc900002b0000 (size 16384):
> comm "init", pid 147, jiffies 4294893306 (age 11.292s)
> hex dump (first 32 bytes):
> 9d 6e ac 57 00 00 00 00 00 00 00 00 00 00 00 00 .n.W............
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> backtrace:
> [<ffffffff815b481e>] kmemleak_alloc+0x4e/0xb0
> [<ffffffff8112a8b0>] __vmalloc_node_range+0x160/0x240
> [<ffffffff8104a328>] copy_process.part.8+0x478/0x1630
> [<ffffffff8104b69a>] _do_fork+0xca/0x330
> [<ffffffff8104b9a9>] SyS_clone+0x19/0x20
> [<ffffffff8100199c>] do_syscall_64+0x4c/0xb0
> [<ffffffff815b8d06>] return_from_SYSCALL_64+0x0/0x6a
> [<ffffffffffffffff>] 0xffffffffffffffff
>
> This is because this commit started caching 2 thread stacks per CPU, and
> kmemleak assumes its memory is never freed. Report these stacks as not
> being memory leaks using kmemleak_not_leak().
>
> Cc: stable@vger.kernel.org
> Fixes: ac496bf48d97 ("fork: Optimize task creation by caching two thread stacks per CPU if CONFIG_VMAP_STACK=y")
> Signed-off-by: Luis Henriques <lhenriques@suse.com>
I guess that's meant as a 4.12 and earlier fix until the
kmemleak_vmalloc() patches go in
(http://lkml.kernel.org/r/1495726937-23557-1-git-send-email-catalin.marinas@arm.com)
> diff --git a/kernel/fork.c b/kernel/fork.c
> index aa1076c5e4a9..c4d79ad0f5bc 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -255,6 +255,7 @@ static inline void free_thread_stack(struct task_struct *tsk)
>
> this_cpu_write(cached_stacks[i], tsk->stack_vm_area);
> local_irq_restore(flags);
> + kmemleak_not_leak(tsk->stack);
I would add a comment here on why the annotation is needed.
The disadvantage is that such objects would no longer be detected as
leaks since kmemleak doesn't have a way to "unignore" an object (I have
a patch but not worth merging since we'll fix the above with a dedicated
kmemleak_vmalloc() API). We could however work around this with the
current kmemleak API as in this patch:
http://lkml.kernel.org/r/20170516133925.GA9453@e104818-lin.cambridge.arm.com
Thanks.
--
Catalin
^ permalink raw reply
* [PATCH] fork: fix kmemleak false positive due to thread stacks caching
From: Luis Henriques @ 2017-05-26 13:49 UTC (permalink / raw)
To: Andy Lutomirski, Catalin Marinas
Cc: Ingo Molnar, Andrew Morton, Michal Hocko, Thomas Gleixner,
Eric W . Biederman, Peter Zijlstra, Oleg Nesterov, Mateusz Guzik,
linux-kernel, Luis Henriques, stable
kmemleak has been reporting memory leaks since commit ac496bf48d97 ("fork:
Optimize task creation by caching two thread stacks per CPU if
CONFIG_VMAP_STACK=y"):
unreferenced object 0xffffc900002b0000 (size 16384):
comm "init", pid 147, jiffies 4294893306 (age 11.292s)
hex dump (first 32 bytes):
9d 6e ac 57 00 00 00 00 00 00 00 00 00 00 00 00 .n.W............
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff815b481e>] kmemleak_alloc+0x4e/0xb0
[<ffffffff8112a8b0>] __vmalloc_node_range+0x160/0x240
[<ffffffff8104a328>] copy_process.part.8+0x478/0x1630
[<ffffffff8104b69a>] _do_fork+0xca/0x330
[<ffffffff8104b9a9>] SyS_clone+0x19/0x20
[<ffffffff8100199c>] do_syscall_64+0x4c/0xb0
[<ffffffff815b8d06>] return_from_SYSCALL_64+0x0/0x6a
[<ffffffffffffffff>] 0xffffffffffffffff
This is because this commit started caching 2 thread stacks per CPU, and
kmemleak assumes its memory is never freed. Report these stacks as not
being memory leaks using kmemleak_not_leak().
Cc: stable@vger.kernel.org
Fixes: ac496bf48d97 ("fork: Optimize task creation by caching two thread stacks per CPU if CONFIG_VMAP_STACK=y")
Signed-off-by: Luis Henriques <lhenriques@suse.com>
---
kernel/fork.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/fork.c b/kernel/fork.c
index aa1076c5e4a9..c4d79ad0f5bc 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -255,6 +255,7 @@ static inline void free_thread_stack(struct task_struct *tsk)
this_cpu_write(cached_stacks[i], tsk->stack_vm_area);
local_irq_restore(flags);
+ kmemleak_not_leak(tsk->stack);
return;
}
local_irq_restore(flags);
^ permalink raw reply related
* [PATCH 5/5] efi/bgrt: Skip efi_bgrt_init in case of non-efi boot
From: Matt Fleming @ 2017-05-26 11:36 UTC (permalink / raw)
To: Ingo Molnar, Thomas Gleixner, H . Peter Anvin
Cc: Dave Young, Ard Biesheuvel, linux-kernel, linux-efi, Matt Fleming,
Sabrina Dubroca, stable
In-Reply-To: <20170526113652.21339-1-matt@codeblueprint.co.uk>
From: Dave Young <dyoung@redhat.com>
Sabrina Dubroca reported an early panic below, it was introduced by
commit 7b0a911478c7 ("efi/x86: Move the EFI BGRT init code to early init
code"). The cause is on this machine even for legacy boot firmware still
provide the ACPI BGRT table which should be EFI only. Thus the garbage
bgrt data caused the efi_bgrt_init panic.
Add a checking to skip efi_bgrt_init in case non EFI booting solves this
problem.
BUG: unable to handle kernel paging request at ffffffffff240001
IP: efi_bgrt_init+0xdc/0x134
PGD 1ac0c067
PUD 1ac0e067
PMD 1aee9067
PTE 9380701800000163
Oops: 0009 [#1] SMP
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 4.10.0-rc5-00116-g7b0a911 #19
Hardware name: Hewlett-Packard HP Z220 CMT Workstation/1790, BIOS K51 v01.02 05/03/2012
task: ffffffff9fc10500 task.stack: ffffffff9fc00000
RIP: 0010:efi_bgrt_init+0xdc/0x134
RSP: 0000:ffffffff9fc03d58 EFLAGS: 00010082
RAX: ffffffffff240001 RBX: 0000000000000000 RCX: 1380701800000006
RDX: 8000000000000163 RSI: 9380701800000163 RDI: 00000000000005be
RBP: ffffffff9fc03d70 R08: 1380701800001000 R09: 0000000000000002
R10: 000000000002d000 R11: ffff98a3dedd2fc6 R12: ffffffff9f9f22b6
R13: ffffffff9ff49480 R14: 0000000000000010 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffffffff9fd20000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffff240001 CR3: 000000001ac09000 CR4: 00000000000406b0
Call Trace:
? acpi_parse_ioapic+0x98/0x98
acpi_parse_bgrt+0x9/0xd
acpi_table_parse+0x7a/0xa9
acpi_boot_init+0x3c7/0x4f9
? acpi_parse_x2apic+0x74/0x74
? acpi_parse_x2apic_nmi+0x46/0x46
setup_arch+0xb4b/0xc6f
? printk+0x52/0x6e
start_kernel+0xb2/0x47b
? early_idt_handler_array+0x120/0x120
x86_64_start_reservations+0x24/0x26
x86_64_start_kernel+0xf7/0x11a
start_cpu+0x14/0x14
Code: 48 c7 c7 10 16 a0 9f e8 4e 94 40 ff eb 62 be 06 00 00 00 e8 f9 ff 00 00 48 85 c0 75 0e 48
c7 c7 40 16 a0 9f e8 31 94 40 ff eb 45 <66> 44 8b 20 be 06 00 00 00 48 89 c7 8b 58 02 e8 87 00
01 00 66
RIP: efi_bgrt_init+0xdc/0x134 RSP: ffffffff9fc03d58
CR2: ffffffffff240001
---[ end trace f68728a0d3053b52 ]---
Kernel panic - not syncing: Attempted to kill the idle task!
---[ end Kernel panic - not syncing: Attempted to kill the idle task!
Fixes: 7b0a911478c7 ("efi/x86: Move the EFI BGRT init code to early init code")
Signed-off-by: Dave Young <dyoung@redhat.com>
Tested-by: Sabrina Dubroca <sd@queasysnail.net>
Cc: <stable@vger.kernel.org> # v4.11+
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
---
drivers/firmware/efi/efi-bgrt.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/firmware/efi/efi-bgrt.c b/drivers/firmware/efi/efi-bgrt.c
index 04ca8764f0c0..8bf27323f7a3 100644
--- a/drivers/firmware/efi/efi-bgrt.c
+++ b/drivers/firmware/efi/efi-bgrt.c
@@ -36,6 +36,9 @@ void __init efi_bgrt_init(struct acpi_table_header *table)
if (acpi_disabled)
return;
+ if (!efi_enabled(EFI_BOOT))
+ return;
+
if (table->length < sizeof(bgrt_tab)) {
pr_notice("Ignoring BGRT: invalid length %u (expected %zu)\n",
table->length, sizeof(bgrt_tab));
--
2.12.2
^ permalink raw reply related
* [PATCH 1/5] efi: Don't issue error message when booted under xen
From: Matt Fleming @ 2017-05-26 11:36 UTC (permalink / raw)
To: Ingo Molnar, Thomas Gleixner, H . Peter Anvin
Cc: Juergen Gross, Ard Biesheuvel, linux-kernel, linux-efi,
Matt Fleming, stable
In-Reply-To: <20170526113652.21339-1-matt@codeblueprint.co.uk>
From: Juergen Gross <jgross@suse.com>
When booted as Xen dom0 there won't be an EFI memmap allocated. Avoid
issuing an error message in this case:
[ 0.144079] efi: Failed to allocate new EFI memmap
Signed-off-by: Juergen Gross <jgross@suse.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: <stable@vger.kernel.org> # v4.9+
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
---
arch/x86/platform/efi/quirks.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
index 26615991d69c..e0cf95a83f3f 100644
--- a/arch/x86/platform/efi/quirks.c
+++ b/arch/x86/platform/efi/quirks.c
@@ -360,6 +360,9 @@ void __init efi_free_boot_services(void)
free_bootmem_late(start, size);
}
+ if (!num_entries)
+ return;
+
new_size = efi.memmap.desc_size * num_entries;
new_phys = efi_memmap_alloc(num_entries);
if (!new_phys) {
--
2.12.2
^ permalink raw reply related
* v4.9+ stable backport request
From: Jani Nikula @ 2017-05-26 11:21 UTC (permalink / raw)
To: stable, intel-gfx, Daniel Drake, ville.syrjala, Jim Bride; +Cc: Daniel Vetter
Stable team, please backport upstream commits
665788572c64 ("drm/i915/vbt: don't propagate errors from intel_bios_init()")
bb1d132935c2 ("drm/i915/vbt: split out defaults that are set when there is no VBT")
to stable kernels v4.9+. The first is a small refactor that makes the
actual fix in second easier and apply cleanly.
References: http://mid.mail-archive.com/CAD8Lp45zcVDAAshmiBbi3VZ-Zk=bCSBwP0Qw0QL8ibnDO-CECQ@mail.gmail.com
Fixes: 0ce140d45a83 ("drm/i915: Clean up DDI DDC/AUX CH sanitation")
Tested-by: Daniel Drake <drake@endlessm.com>
Cc: <stable@vger.kernel.org> # v4.9+
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
^ permalink raw reply
* Re: + mm-migrate-fix-ref-count-handling-when-hugepage_migration_supported-v2.patch added to -mm tree
From: Mel Gorman @ 2017-05-26 10:42 UTC (permalink / raw)
To: akpm
Cc: punit.agrawal, cl, iamjoonsoo.kim, manoj.iyer, n-horiguchi,
stable, wanpeng.li, mm-commits
In-Reply-To: <59275ebf.J2Z9kk9uuHWKdJS8%akpm@linux-foundation.org>
On Thu, May 25, 2017 at 03:46:23PM -0700, akpm@linux-foundation.org wrote:
> ------------------------------------------------------
> From: Punit Agrawal <punit.agrawal@arm.com>
> Subject: mm/migrate: fix refcount handling when !hugepage_migration_supported()
>
> On failing to migrate a page, soft_offline_huge_page() performs the
> necessary update to the hugepage ref-count. When
> !hugepage_migration_supported() , unmap_and_move_hugepage() also
> decrements the page ref-count for the hugepage. The combined behaviour
> leaves the ref-count in an inconsistent state.
>
> This leads to soft lockups when running the overcommitted hugepage test
> from mce-tests suite.
>
> Soft offlining pfn 0x83ed600 at process virtual address 0x400000000000
> soft offline: 0x83ed600: migration failed 1, type
> 1fffc00000008008 (uptodate|head)
> INFO: rcu_preempt detected stalls on CPUs/tasks:
> Tasks blocked on level-0 rcu_node (CPUs 0-7): P2715
> (detected by 7, t=5254 jiffies, g=963, c=962, q=321)
> thugetlb_overco R running task 0 2715 2685 0x00000008
> Call trace:
> [<ffff000008089f90>] dump_backtrace+0x0/0x268
> [<ffff00000808a2d4>] show_stack+0x24/0x30
> [<ffff000008100d34>] sched_show_task+0x134/0x180
> [<ffff0000081c90fc>] rcu_print_detail_task_stall_rnp+0x54/0x7c
> [<ffff00000813cfd4>] rcu_check_callbacks+0xa74/0xb08
> [<ffff000008143a3c>] update_process_times+0x34/0x60
> [<ffff0000081550e8>] tick_sched_handle.isra.7+0x38/0x70
> [<ffff00000815516c>] tick_sched_timer+0x4c/0x98
> [<ffff0000081442e0>] __hrtimer_run_queues+0xc0/0x300
> [<ffff000008144fa4>] hrtimer_interrupt+0xac/0x228
> [<ffff0000089a56d4>] arch_timer_handler_phys+0x3c/0x50
> [<ffff00000812f1bc>] handle_percpu_devid_irq+0x8c/0x290
> [<ffff0000081297fc>] generic_handle_irq+0x34/0x50
> [<ffff000008129f00>] __handle_domain_irq+0x68/0xc0
> [<ffff0000080816b4>] gic_handle_irq+0x5c/0xb0
>
> Address this by changing the putback_active_hugepage() in
> soft_offline_huge_page() to putback_movable_pages().
>
I've never looked too closely at how hardware poisoning and hugetlb pages
migration is handled so I could easily have missed something but this
changelog and patch confuses me.
Surely if the inconsistency is between hugepage_migration_supported and
!hugepage_migration_supported then the check in soft_offline_huge_page()
should also be related to hugepage_migration_supported either in
soft_offline_huge_page() or in putback_movable_pages()?
--
Mel Gorman
SUSE Labs
^ permalink raw reply
* Re: [PATCH] pinctrl/amd: Use regular interrupt instead of chained
From: Borislav Petkov @ 2017-05-26 9:57 UTC (permalink / raw)
To: Shah, Nehal-bakulchandra
Cc: Thomas Gleixner, LKML, Linus Walleij, linux-gpio@vger.kernel.org,
Xue, Ken, S-k, Shyam-sundar, stable@vger.kernel.org
In-Reply-To: <BLUPR12MB0721B0824892B985DC807471A0FC0@BLUPR12MB0721.namprd12.prod.outlook.com>
On Fri, May 26, 2017 at 09:33:10AM +0000, Shah, Nehal-bakulchandra wrote:
> Hi Thomas,
>
> Thanks for the prompt reply. Agree on points.
>
> we will validate at our end and shall provide the update.
First of all, please do not top-post.
What update are you talking about? The patch needs to go in regardless.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply
* RE: [PATCH] pinctrl/amd: Use regular interrupt instead of chained
From: Shah, Nehal-bakulchandra @ 2017-05-26 9:33 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, Linus Walleij, linux-gpio@vger.kernel.org, Borislav Petkov,
Xue, Ken, S-k, Shyam-sundar, stable@vger.kernel.org
In-Reply-To: <alpine.DEB.2.20.1705260841250.1902@nanos>
Hi Thomas,
Thanks for the prompt reply. Agree on points.
we will validate at our end and shall provide the update.
Nehal
-----Original Message-----
From: Thomas Gleixner [mailto:tglx@linutronix.de]
Sent: Friday, May 26, 2017 12:19 PM
To: Shah, Nehal-bakulchandra <Nehal-bakulchandra.Shah@amd.com>
Cc: LKML <linux-kernel@vger.kernel.org>; Linus Walleij <linus.walleij@linaro.org>; linux-gpio@vger.kernel.org; Borislav Petkov <bp@alien8.de>; Xue, Ken <Ken.Xue@amd.com>; S-k, Shyam-sundar <Shyam-sundar.S-k@amd.com>; stable@vger.kernel.org
Subject: RE: [PATCH] pinctrl/amd: Use regular interrupt instead of chained
Nehal,
On Fri, 26 May 2017, Shah, Nehal-bakulchandra wrote:
> Thanks for the patch. However, we have received this issue from
> multiple people and different disro but it occurs only on Gigabyte
> hardware. With reference AM4 ryzen board we are not facing this issue.
> We are in discussion with gigabyte to check the BIOS part. Once we
> have clarity on that, we can consider driver part. Also, this code is
> running on multiple platform of different customers so changing
> directly at this point of time may be risky in my point of view.
> Requesting you to hold this patch till we get clarity on bios end.
It does not matter at all whether this is a problem only on GB hardware. Fact is, that this happened and it will happen again.
The patch does not change any functionality of the driver, it merily makes it more robust and spares users the bloody annoying experience of a non booting machine and the tedious task of figuring out why.
The main objective of the kernel is robustness and not pleasing the ego of silicon vendors. We can't prevent the stupidity of BIOS people, we merily can deal with it.
That patch should go into mainline ASAP and backported to stable in order to help those people who bought wreckaged hardware.
Thanks,
tglx
^ permalink raw reply
* Re: + mm-migrate-fix-ref-count-handling-when-hugepage_migration_supported-v2.patch added to -mm tree
From: Punit Agrawal @ 2017-05-26 9:22 UTC (permalink / raw)
To: akpm
Cc: cl, iamjoonsoo.kim, manoj.iyer, mgorman, n-horiguchi, stable,
wanpeng.li, mm-commits
In-Reply-To: <59275ebf.J2Z9kk9uuHWKdJS8%akpm@linux-foundation.org>
<akpm@linux-foundation.org> writes:
> The patch titled
> Subject: mm/migrate: fix refcount handling when !hugepage_migration_supported()
> has been added to the -mm tree. Its filename is
> mm-migrate-fix-ref-count-handling-when-hugepage_migration_supported-v2.patch
>
> This patch should soon appear at
> http://ozlabs.org/~akpm/mmots/broken-out/mm-migrate-fix-ref-count-handling-when-hugepage_migration_supported-v2.patch
> and later at
> http://ozlabs.org/~akpm/mmotm/broken-out/mm-migrate-fix-ref-count-handling-when-hugepage_migration_supported-v2.patch
>
> Before you just go and hit "reply", please:
> a) Consider who else should be cc'ed
> b) Prefer to cc a suitable mailing list as well
> c) Ideally: find the original patch on the mailing list and do a
> reply-to-all to that, adding suitable additional cc's
>
> *** Remember to use Documentation/SubmitChecklist when testing your code ***
>
> The -mm tree is included into linux-next and is updated
> there every 3-4 working days
>
> ------------------------------------------------------
> From: Punit Agrawal <punit.agrawal@arm.com>
> Subject: mm/migrate: fix refcount handling when !hugepage_migration_supported()
>
> On failing to migrate a page, soft_offline_huge_page() performs the
> necessary update to the hugepage ref-count. When
> !hugepage_migration_supported() , unmap_and_move_hugepage() also
> decrements the page ref-count for the hugepage. The combined behaviour
> leaves the ref-count in an inconsistent state.
>
> This leads to soft lockups when running the overcommitted hugepage test
> from mce-tests suite.
>
> Soft offlining pfn 0x83ed600 at process virtual address 0x400000000000
> soft offline: 0x83ed600: migration failed 1, type
> 1fffc00000008008 (uptodate|head)
> INFO: rcu_preempt detected stalls on CPUs/tasks:
> Tasks blocked on level-0 rcu_node (CPUs 0-7): P2715
> (detected by 7, t=5254 jiffies, g=963, c=962, q=321)
> thugetlb_overco R running task 0 2715 2685 0x00000008
> Call trace:
> [<ffff000008089f90>] dump_backtrace+0x0/0x268
> [<ffff00000808a2d4>] show_stack+0x24/0x30
> [<ffff000008100d34>] sched_show_task+0x134/0x180
> [<ffff0000081c90fc>] rcu_print_detail_task_stall_rnp+0x54/0x7c
> [<ffff00000813cfd4>] rcu_check_callbacks+0xa74/0xb08
> [<ffff000008143a3c>] update_process_times+0x34/0x60
> [<ffff0000081550e8>] tick_sched_handle.isra.7+0x38/0x70
> [<ffff00000815516c>] tick_sched_timer+0x4c/0x98
> [<ffff0000081442e0>] __hrtimer_run_queues+0xc0/0x300
> [<ffff000008144fa4>] hrtimer_interrupt+0xac/0x228
> [<ffff0000089a56d4>] arch_timer_handler_phys+0x3c/0x50
> [<ffff00000812f1bc>] handle_percpu_devid_irq+0x8c/0x290
> [<ffff0000081297fc>] generic_handle_irq+0x34/0x50
> [<ffff000008129f00>] __handle_domain_irq+0x68/0xc0
> [<ffff0000080816b4>] gic_handle_irq+0x5c/0xb0
>
> Address this by changing the putback_active_hugepage() in
> soft_offline_huge_page() to putback_movable_pages().
>
> Link: http://lkml.kernel.org/r/20170525135146.32011-1-punit.agrawal@arm.com
> Reported-by: Manoj Iyer <manoj.iyer@canonical.com>
> Tested-by: Manoj Iyer <manoj.iyer@canonical.com>
> Suggested-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
> Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
> Cc: Wanpeng Li <wanpeng.li@hotmail.com>
> Cc: Christoph Lameter <cl@linux.com>
> Cc: Mel Gorman <mgorman@techsingularity.net>
> Cc: <stable@vger.kernel.org> [3.14+]
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Hi Andrew,
Thanks a lot for fixing up the stable email address. I need to introduce
some form of sanity checking of emails in my flow considering the number
of bounces I am generating with the current set of patches. Manual
inspection just isn't cutting it.
Appreciate you picking up all the patches.
Thanks,
Punit
> ---
>
> mm/memory-failure.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff -puN mm/memory-failure.c~mm-migrate-fix-ref-count-handling-when-hugepage_migration_supported-v2 mm/memory-failure.c
> --- a/mm/memory-failure.c~mm-migrate-fix-ref-count-handling-when-hugepage_migration_supported-v2
> +++ a/mm/memory-failure.c
> @@ -1600,7 +1600,8 @@ static int soft_offline_huge_page(struct
> * only one hugepage pointed to by hpage, so we need not
> * run through the pagelist here.
> */
> - putback_active_hugepage(hpage);
> + if (!list_empty(&pagelist))
> + putback_movable_pages(&pagelist);
> if (ret > 0)
> ret = -EIO;
> } else {
> _
>
> Patches currently in -mm which might be from punit.agrawal@arm.com are
>
> mm-migrate-fix-ref-count-handling-when-hugepage_migration_supported-v2.patch
> mm-gup-ensure-real-head-page-is-ref-counted-when-using-hugepages.patch
> mm-hugetlb-add-size-parameter-to-huge_pte_offset.patch
> mm-hugetlb-allow-architectures-to-override-huge_pte_clear.patch
> mm-hugetlb-introduce-set_huge_swap_pte_at-helper.patch
> mm-hugetlb-introduce-set_huge_swap_pte_at-helper-v4.patch
> mm-hugetlb-introduce-set_huge_swap_pte_at-helper-v41.patch
> mm-rmap-use-correct-helper-when-poisoning-hugepages.patch
^ permalink raw reply
* patch "Drivers: hv: vmbus: Close timing hole that can corrupt per-cpu page" added to char-misc-next
From: gregkh @ 2017-05-26 9:12 UTC (permalink / raw)
To: mikelley, Stable, gregkh, kys
This is a note to let you know that I've just added the patch titled
Drivers: hv: vmbus: Close timing hole that can corrupt per-cpu page
to my char-misc git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
in the char-misc-next branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will also be merged in the next major kernel release
during the merge window.
If you have any questions about this process, please let me know.
>From 13b9abfc92be7c4454bff912021b9f835dea6e15 Mon Sep 17 00:00:00 2001
From: Michael Kelley <mikelley@microsoft.com>
Date: Thu, 18 May 2017 10:46:07 -0700
Subject: Drivers: hv: vmbus: Close timing hole that can corrupt per-cpu page
Extend the disabling of preemption to include the hypercall so that
another thread can't get the CPU and corrupt the per-cpu page used
for hypercall arguments.
Cc: <Stable@vger.kernel.org> #4.11
Signed-off-by: Michael Kelley <mikelley@microsoft.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hv/hv.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/hv/hv.c b/drivers/hv/hv.c
index 61fc8ce169a5..2ea12207caa0 100644
--- a/drivers/hv/hv.c
+++ b/drivers/hv/hv.c
@@ -82,10 +82,15 @@ int hv_post_message(union hv_connection_id connection_id,
aligned_msg->message_type = message_type;
aligned_msg->payload_size = payload_size;
memcpy((void *)aligned_msg->payload, payload, payload_size);
- put_cpu_ptr(hv_cpu);
status = hv_do_hypercall(HVCALL_POST_MESSAGE, aligned_msg, NULL);
+ /* Preemption must remain disabled until after the hypercall
+ * so some other thread can't get scheduled onto this cpu and
+ * corrupt the per-cpu post_msg_page
+ */
+ put_cpu_ptr(hv_cpu);
+
return status & 0xFFFF;
}
--
2.13.0
^ permalink raw reply related
* RE: [PATCH] pinctrl/amd: Use regular interrupt instead of chained
From: Thomas Gleixner @ 2017-05-26 6:48 UTC (permalink / raw)
To: Shah, Nehal-bakulchandra
Cc: LKML, Linus Walleij, linux-gpio@vger.kernel.org, Borislav Petkov,
Xue, Ken, S-k, Shyam-sundar, stable
In-Reply-To: <BLUPR12MB07212D4797B68DB06C3A6D40A0FC0@BLUPR12MB0721.namprd12.prod.outlook.com>
Nehal,
On Fri, 26 May 2017, Shah, Nehal-bakulchandra wrote:
> Thanks for the patch. However, we have received this issue from multiple
> people and different disro but it occurs only on Gigabyte hardware. With
> reference AM4 ryzen board we are not facing this issue. We are in
> discussion with gigabyte to check the BIOS part. Once we have clarity on
> that, we can consider driver part. Also, this code is running on multiple
> platform of different customers so changing directly at this point of
> time may be risky in my point of view. Requesting you to hold this patch
> till we get clarity on bios end.
It does not matter at all whether this is a problem only on GB
hardware. Fact is, that this happened and it will happen again.
The patch does not change any functionality of the driver, it merily makes
it more robust and spares users the bloody annoying experience of a non
booting machine and the tedious task of figuring out why.
The main objective of the kernel is robustness and not pleasing the ego of
silicon vendors. We can't prevent the stupidity of BIOS people, we merily
can deal with it.
That patch should go into mainline ASAP and backported to stable in order
to help those people who bought wreckaged hardware.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH 0/2] nohz: Deal with clock reprogram skipping issues v3
From: Ingo Molnar @ 2017-05-26 6:13 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: LKML, Peter Zijlstra, Rik van Riel, James Hartsock,
Thomas Gleixner, stable, Tim Wright, Pavel Machek
In-Reply-To: <20170526021051.GA27061@lerouge>
* Frederic Weisbecker <fweisbec@gmail.com> wrote:
> On Wed, May 24, 2017 at 09:16:28AM +0200, Ingo Molnar wrote:
> > So the interdiff between your two patches and the 3 commits already queued up is:
> >
> > diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
> > index e3043873fcdc..30253ed0380b 100644
> > --- a/kernel/time/tick-sched.c
> > +++ b/kernel/time/tick-sched.c
> > @@ -150,12 +150,6 @@ static void tick_sched_handle(struct tick_sched *ts, struct pt_regs *regs)
> > touch_softlockup_watchdog_sched();
> > if (is_idle_task(current))
> > ts->idle_jiffies++;
> > - /*
> > - * In case the current tick fired too early past its expected
> > - * expiration, make sure we don't bypass the next clock reprogramming
> > - * to the same deadline.
> > - */
> > - ts->next_tick = 0;
> > }
> > #endif
> > update_process_times(user_mode(regs));
> > @@ -1103,8 +1097,15 @@ static void tick_nohz_handler(struct clock_event_device *dev)
> > tick_sched_handle(ts, regs);
> >
> > /* No need to reprogram if we are running tickless */
> > - if (unlikely(ts->tick_stopped))
> > + if (unlikely(ts->tick_stopped)) {
> > + /*
> > + * In case the current tick fired too early past its expected
> > + * expiration, make sure we don't bypass the next clock reprogramming
> > + * to the same deadline.
> > + */
> > + ts->next_tick = 0;
> > return;
> > + }
> >
> > hrtimer_forward(&ts->sched_timer, now, tick_period);
> > tick_program_event(hrtimer_get_expires(&ts->sched_timer), 1);
> > @@ -1202,12 +1203,17 @@ static enum hrtimer_restart tick_sched_timer(struct hrtimer *timer)
> > */
> > if (regs)
> > tick_sched_handle(ts, regs);
> > - else
> > - ts->next_tick = 0;
> >
> > /* No need to reprogram if we are in idle or full dynticks mode */
> > - if (unlikely(ts->tick_stopped))
> > + if (unlikely(ts->tick_stopped)) {
> > + /*
> > + * In case the current tick fired too early past its expected
> > + * expiration, make sure we don't bypass the next clock reprogramming
> > + * to the same deadline.
> > + */
> > + ts->next_tick = 0;
> > return HRTIMER_NORESTART;
> > + }
> >
> > hrtimer_forward(timer, now, tick_period);
> >
> >
> > ... so the two are not the same - I'd rather not rebase it, I'd like to keep what
> > is working, we had problems with these changes before ...
> >
> > If you'd like the changes in this interdiff to be applied as well, please add a
> > changelog to it and post it as a fourth patch.
> >
> > Thanks,
> >
> > Ingo
>
> So if you like, you can replace the top patch with the following. It's exactly
> the same code, I've only added a comment and a changelog:
>
> ---
> From 72956bf08c3b2e506a5ce5ec4faac9fd6b097307 Mon Sep 17 00:00:00 2001
> From: Frederic Weisbecker <fweisbec@gmail.com>
> Date: Mon, 15 May 2017 14:56:50 +0200
> Subject: [PATCH] nohz: Reset next_tick cache even when the timer has no regs
>
> The tick IRQ regs can be NULL if hrtimer_interrupt() is called from
> non-interrupt contexts (ex: hotplug CPU down). For such very special
> path we forget to clean the cached next tick deadline. If we are in
> dynticks mode and the actual timer deadline is ahead of us, we might
> perform a buggy bypass of the next clock reprogramming.
>
> In fact since CPU down is the only user I'm aware of, this fix is likely
> unnecessary as dying CPUs already clean their tick deadline cache. But
> given how hard it is to debug such timer cache related issue, we should
> never be short on paranoid measures.
>
> Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Signed-off-by: Ingo Molnar <mingo@kernel.org>
> ---
> kernel/time/tick-sched.c | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
> index 764d290..ed18ca5 100644
> --- a/kernel/time/tick-sched.c
> +++ b/kernel/time/tick-sched.c
> @@ -1200,8 +1200,17 @@ static enum hrtimer_restart tick_sched_timer(struct hrtimer *timer)
> * Do not call, when we are not in irq context and have
> * no valid regs pointer
> */
> - if (regs)
> + if (regs) {
> tick_sched_handle(ts, regs);
> + } else {
> + /*
> + * IRQ regs are NULL if hrtimer_interrupt() is called from
> + * non-interrupt contexts (ex: hotplug cpu down). Make sure to
> + * clean the cached next tick deadline to avoid buggy bypass of
> + * clock reprog.
> + */
> + ts->next_tick = 0;
> + }
>
> /* No need to reprogram if we are in idle or full dynticks mode */
> if (unlikely(ts->tick_stopped))
Well, this does not answer my question: between latest tip:timers/nohz and the
patches you posted there's a delta, so it's not just a pure rebase.
I can do a rebase to resolve the bisectability problem (which isn't very serious
by the way, only a single commit wide window, right?), but only if 'git diff
old_branch new_branch' comes up empty.
In every other case let's iterate the existing timers/nohz with additional
patches, ok? I'd rather have a finegrained iteration with well-tested intermediate
stages than break things again.
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH 01/19] block: Avoid that blk_exit_rl() triggers a use-after-free
From: Christoph Hellwig @ 2017-05-26 6:01 UTC (permalink / raw)
To: Bart Van Assche
Cc: Jens Axboe, linux-block, Christoph Hellwig, Jens Axboe, Jan Kara,
stable
In-Reply-To: <20170525184327.23570-2-bart.vanassche@sandisk.com>
Looks fine,
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply
* Re: + mm-migrate-fix-ref-count-handling-when-hugepage_migration_supported-v2.patch added to -mm tree
From: Naoya Horiguchi @ 2017-05-26 5:41 UTC (permalink / raw)
To: akpm@linux-foundation.org
Cc: punit.agrawal@arm.com, cl@linux.com, iamjoonsoo.kim@lge.com,
manoj.iyer@canonical.com, mgorman@techsingularity.net,
stable@vger.kernel.org, wanpeng.li@hotmail.com,
mm-commits@vger.kernel.org
In-Reply-To: <59275ebf.J2Z9kk9uuHWKdJS8%akpm@linux-foundation.org>
On Thu, May 25, 2017 at 03:46:23PM -0700, akpm@linux-foundation.org wrote:
>
> The patch titled
> Subject: mm/migrate: fix refcount handling when !hugepage_migration_supported()
> has been added to the -mm tree. Its filename is
> mm-migrate-fix-ref-count-handling-when-hugepage_migration_supported-v2.patch
>
> This patch should soon appear at
> http://ozlabs.org/~akpm/mmots/broken-out/mm-migrate-fix-ref-count-handling-when-hugepage_migration_supported-v2.patch
> and later at
> http://ozlabs.org/~akpm/mmotm/broken-out/mm-migrate-fix-ref-count-handling-when-hugepage_migration_supported-v2.patch
>
> Before you just go and hit "reply", please:
> a) Consider who else should be cc'ed
> b) Prefer to cc a suitable mailing list as well
> c) Ideally: find the original patch on the mailing list and do a
> reply-to-all to that, adding suitable additional cc's
>
> *** Remember to use Documentation/SubmitChecklist when testing your code ***
>
> The -mm tree is included into linux-next and is updated
> there every 3-4 working days
>
> ------------------------------------------------------
> From: Punit Agrawal <punit.agrawal@arm.com>
> Subject: mm/migrate: fix refcount handling when !hugepage_migration_supported()
>
> On failing to migrate a page, soft_offline_huge_page() performs the
> necessary update to the hugepage ref-count. When
> !hugepage_migration_supported() , unmap_and_move_hugepage() also
> decrements the page ref-count for the hugepage. The combined behaviour
> leaves the ref-count in an inconsistent state.
>
> This leads to soft lockups when running the overcommitted hugepage test
> from mce-tests suite.
>
> Soft offlining pfn 0x83ed600 at process virtual address 0x400000000000
> soft offline: 0x83ed600: migration failed 1, type
> 1fffc00000008008 (uptodate|head)
> INFO: rcu_preempt detected stalls on CPUs/tasks:
> Tasks blocked on level-0 rcu_node (CPUs 0-7): P2715
> (detected by 7, t=5254 jiffies, g=963, c=962, q=321)
> thugetlb_overco R running task 0 2715 2685 0x00000008
> Call trace:
> [<ffff000008089f90>] dump_backtrace+0x0/0x268
> [<ffff00000808a2d4>] show_stack+0x24/0x30
> [<ffff000008100d34>] sched_show_task+0x134/0x180
> [<ffff0000081c90fc>] rcu_print_detail_task_stall_rnp+0x54/0x7c
> [<ffff00000813cfd4>] rcu_check_callbacks+0xa74/0xb08
> [<ffff000008143a3c>] update_process_times+0x34/0x60
> [<ffff0000081550e8>] tick_sched_handle.isra.7+0x38/0x70
> [<ffff00000815516c>] tick_sched_timer+0x4c/0x98
> [<ffff0000081442e0>] __hrtimer_run_queues+0xc0/0x300
> [<ffff000008144fa4>] hrtimer_interrupt+0xac/0x228
> [<ffff0000089a56d4>] arch_timer_handler_phys+0x3c/0x50
> [<ffff00000812f1bc>] handle_percpu_devid_irq+0x8c/0x290
> [<ffff0000081297fc>] generic_handle_irq+0x34/0x50
> [<ffff000008129f00>] __handle_domain_irq+0x68/0xc0
> [<ffff0000080816b4>] gic_handle_irq+0x5c/0xb0
>
> Address this by changing the putback_active_hugepage() in
> soft_offline_huge_page() to putback_movable_pages().
>
> Link: http://lkml.kernel.org/r/20170525135146.32011-1-punit.agrawal@arm.com
> Reported-by: Manoj Iyer <manoj.iyer@canonical.com>
> Tested-by: Manoj Iyer <manoj.iyer@canonical.com>
> Suggested-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
> Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
> Cc: Wanpeng Li <wanpeng.li@hotmail.com>
> Cc: Christoph Lameter <cl@linux.com>
> Cc: Mel Gorman <mgorman@techsingularity.net>
> Cc: <stable@vger.kernel.org> [3.14+]
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
>
> mm/memory-failure.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff -puN mm/memory-failure.c~mm-migrate-fix-ref-count-handling-when-hugepage_migration_supported-v2 mm/memory-failure.c
> --- a/mm/memory-failure.c~mm-migrate-fix-ref-count-handling-when-hugepage_migration_supported-v2
> +++ a/mm/memory-failure.c
> @@ -1600,7 +1600,8 @@ static int soft_offline_huge_page(struct
> * only one hugepage pointed to by hpage, so we need not
> * run through the pagelist here.
> */
Hi Andrew,
I just noticed that the comment above this becomes obsolete with this change,
so could you remove it? (please fold it to this patch.)
@@ -1649,11 +1649,6 @@ static int soft_offline_huge_page(struct page *page, int flags)
if (ret) {
pr_info("soft offline: %#lx: migration failed %d, type %lx (%pGp)\n",
pfn, ret, page->flags, &page->flags);
- /*
- * We know that soft_offline_huge_page() tries to migrate
- * only one hugepage pointed to by hpage, so we need not
- * run through the pagelist here.
- */
if (!list_empty(&pagelist))
putback_movable_pages(&pagelist);
if (ret > 0)
Thanks,
Naoya Horiguchi
> - putback_active_hugepage(hpage);
> + if (!list_empty(&pagelist))
> + putback_movable_pages(&pagelist);
> if (ret > 0)
> ret = -EIO;
> } else {
> _
>
> Patches currently in -mm which might be from punit.agrawal@arm.com are
>
> mm-migrate-fix-ref-count-handling-when-hugepage_migration_supported-v2.patch
> mm-gup-ensure-real-head-page-is-ref-counted-when-using-hugepages.patch
> mm-hugetlb-add-size-parameter-to-huge_pte_offset.patch
> mm-hugetlb-allow-architectures-to-override-huge_pte_clear.patch
> mm-hugetlb-introduce-set_huge_swap_pte_at-helper.patch
> mm-hugetlb-introduce-set_huge_swap_pte_at-helper-v4.patch
> mm-hugetlb-introduce-set_huge_swap_pte_at-helper-v41.patch
> mm-rmap-use-correct-helper-when-poisoning-hugepages.patch
>
>
^ permalink raw reply
* v3.18.55 build: 0 failures 0 warnings (v3.18.55)
From: Build bot for Mark Brown @ 2017-05-26 4:35 UTC (permalink / raw)
To: kernel-build-reports, linaro-kernel, stable
Tree/Branch: v3.18.55
Git describe: v3.18.55
Commit: 6b65a8f64f Linux 3.18.55
Build Time: 97 min 20 sec
Passed: 9 / 9 (100.00 %)
Failed: 0 / 9 ( 0.00 %)
Errors: 0
Warnings: 0
Section Mismatches: 0
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
-------------------------------------------------------------------------------
===============================================================================
Detailed per-defconfig build reports below:
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
arm64-allnoconfig
arm64-allmodconfig
arm-multi_v5_defconfig
arm-multi_v7_defconfig
x86_64-defconfig
arm-allmodconfig
arm-allnoconfig
x86_64-allnoconfig
arm64-defconfig
close failed in file object destructor:
sys.excepthook is missing
lost sys.stderr
^ permalink raw reply
* Re: [PATCH 0/2] nohz: Deal with clock reprogram skipping issues v3
From: Frederic Weisbecker @ 2017-05-26 2:10 UTC (permalink / raw)
To: Ingo Molnar
Cc: LKML, Peter Zijlstra, Rik van Riel, James Hartsock,
Thomas Gleixner, stable, Tim Wright, Pavel Machek
In-Reply-To: <20170524071628.ftwjuh27jpdo6qkm@gmail.com>
On Wed, May 24, 2017 at 09:16:28AM +0200, Ingo Molnar wrote:
> So the interdiff between your two patches and the 3 commits already queued up is:
>
> diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
> index e3043873fcdc..30253ed0380b 100644
> --- a/kernel/time/tick-sched.c
> +++ b/kernel/time/tick-sched.c
> @@ -150,12 +150,6 @@ static void tick_sched_handle(struct tick_sched *ts, struct pt_regs *regs)
> touch_softlockup_watchdog_sched();
> if (is_idle_task(current))
> ts->idle_jiffies++;
> - /*
> - * In case the current tick fired too early past its expected
> - * expiration, make sure we don't bypass the next clock reprogramming
> - * to the same deadline.
> - */
> - ts->next_tick = 0;
> }
> #endif
> update_process_times(user_mode(regs));
> @@ -1103,8 +1097,15 @@ static void tick_nohz_handler(struct clock_event_device *dev)
> tick_sched_handle(ts, regs);
>
> /* No need to reprogram if we are running tickless */
> - if (unlikely(ts->tick_stopped))
> + if (unlikely(ts->tick_stopped)) {
> + /*
> + * In case the current tick fired too early past its expected
> + * expiration, make sure we don't bypass the next clock reprogramming
> + * to the same deadline.
> + */
> + ts->next_tick = 0;
> return;
> + }
>
> hrtimer_forward(&ts->sched_timer, now, tick_period);
> tick_program_event(hrtimer_get_expires(&ts->sched_timer), 1);
> @@ -1202,12 +1203,17 @@ static enum hrtimer_restart tick_sched_timer(struct hrtimer *timer)
> */
> if (regs)
> tick_sched_handle(ts, regs);
> - else
> - ts->next_tick = 0;
>
> /* No need to reprogram if we are in idle or full dynticks mode */
> - if (unlikely(ts->tick_stopped))
> + if (unlikely(ts->tick_stopped)) {
> + /*
> + * In case the current tick fired too early past its expected
> + * expiration, make sure we don't bypass the next clock reprogramming
> + * to the same deadline.
> + */
> + ts->next_tick = 0;
> return HRTIMER_NORESTART;
> + }
>
> hrtimer_forward(timer, now, tick_period);
>
>
> ... so the two are not the same - I'd rather not rebase it, I'd like to keep what
> is working, we had problems with these changes before ...
>
> If you'd like the changes in this interdiff to be applied as well, please add a
> changelog to it and post it as a fourth patch.
>
> Thanks,
>
> Ingo
So if you like, you can replace the top patch with the following. It's exactly
the same code, I've only added a comment and a changelog:
---
>From 72956bf08c3b2e506a5ce5ec4faac9fd6b097307 Mon Sep 17 00:00:00 2001
From: Frederic Weisbecker <fweisbec@gmail.com>
Date: Mon, 15 May 2017 14:56:50 +0200
Subject: [PATCH] nohz: Reset next_tick cache even when the timer has no regs
The tick IRQ regs can be NULL if hrtimer_interrupt() is called from
non-interrupt contexts (ex: hotplug CPU down). For such very special
path we forget to clean the cached next tick deadline. If we are in
dynticks mode and the actual timer deadline is ahead of us, we might
perform a buggy bypass of the next clock reprogramming.
In fact since CPU down is the only user I'm aware of, this fix is likely
unnecessary as dying CPUs already clean their tick deadline cache. But
given how hard it is to debug such timer cache related issue, we should
never be short on paranoid measures.
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
kernel/time/tick-sched.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 764d290..ed18ca5 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -1200,8 +1200,17 @@ static enum hrtimer_restart tick_sched_timer(struct hrtimer *timer)
* Do not call, when we are not in irq context and have
* no valid regs pointer
*/
- if (regs)
+ if (regs) {
tick_sched_handle(ts, regs);
+ } else {
+ /*
+ * IRQ regs are NULL if hrtimer_interrupt() is called from
+ * non-interrupt contexts (ex: hotplug cpu down). Make sure to
+ * clean the cached next tick deadline to avoid buggy bypass of
+ * clock reprog.
+ */
+ ts->next_tick = 0;
+ }
/* No need to reprogram if we are in idle or full dynticks mode */
if (unlikely(ts->tick_stopped))
--
2.7.4
^ permalink raw reply related
* v4.9.30 build: 0 failures 0 warnings (v4.9.30)
From: Build bot for Mark Brown @ 2017-05-26 1:25 UTC (permalink / raw)
To: kernel-build-reports, linaro-kernel, stable
Tree/Branch: v4.9.30
Git describe: v4.9.30
Commit: db3fd4527e Linux 4.9.30
Build Time: 96 min 4 sec
Passed: 10 / 10 (100.00 %)
Failed: 0 / 10 ( 0.00 %)
Errors: 0
Warnings: 0
Section Mismatches: 0
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
-------------------------------------------------------------------------------
===============================================================================
Detailed per-defconfig build reports below:
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
arm64-allnoconfig
arm64-allmodconfig
arm-multi_v5_defconfig
arm-multi_v7_defconfig
x86_64-defconfig
arm-allmodconfig
arm-allnoconfig
x86_64-allnoconfig
arm-multi_v4t_defconfig
arm64-defconfig
close failed in file object destructor:
sys.excepthook is missing
lost sys.stderr
^ permalink raw reply
* Re: [PATCH v4 2/2] Add "shutdown" to "struct class".
From: Josh Zimmerman @ 2017-05-25 23:12 UTC (permalink / raw)
To: Josh Zimmerman; +Cc: stable
In-Reply-To: <20170525230620.21656-3-joshz@google.com>
On Thu, May 25, 2017 at 4:06 PM, Josh Zimmerman <joshz@google.com> wrote:
> The TPM class has some common shutdown code that must be executed for
> all drivers. This adds some needed functionality for that.
>
> Signed-off-by: Josh Zimmerman <joshz@google.com>
> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: stable@vger.kernel.org
>
> -----
> v2: Add Signed-off-by.
> v3: Remove logically separate change.
> v4: Add "acked-by" and "cc".
> ---
> drivers/base/core.c | 5 +++++
> include/linux/device.h | 2 ++
> 2 files changed, 7 insertions(+)
>
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index 6bb60fb6a30b..687668d9afbe 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -2667,6 +2667,11 @@ void device_shutdown(void)
> pm_runtime_get_noresume(dev);
> pm_runtime_barrier(dev);
>
> + if (dev->class && dev->class->shutdown) {
> + if (initcall_debug)
> + dev_info(dev, "shutdown\n");
> + dev->class->shutdown(dev);
> + }
> if (dev->bus && dev->bus->shutdown) {
> if (initcall_debug)
> dev_info(dev, "shutdown\n");
> diff --git a/include/linux/device.h b/include/linux/device.h
> index 9ef518af5515..f240baac2001 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -378,6 +378,7 @@ int subsys_virtual_register(struct bus_type *subsys,
> * @suspend: Used to put the device to sleep mode, usually to a low power
> * state.
> * @resume: Used to bring the device from the sleep mode.
> + * @shutdown: Called at shut-down time to quiesce the device.
> * @ns_type: Callbacks so sysfs can detemine namespaces.
> * @namespace: Namespace of the device belongs to this class.
> * @pm: The default device power management operations of this class.
> @@ -407,6 +408,7 @@ struct class {
>
> int (*suspend)(struct device *dev, pm_message_t state);
> int (*resume)(struct device *dev);
> + int (*shutdown)(struct device *dev);
>
> const struct kobj_ns_type_operations *ns_type;
> const void *(*namespace)(struct device *dev);
> --
> 2.13.0.219.gdb65acc882-goog
>
This was not meant to be sent explicitly to stable@; git send-email
"helpfully" added stable@ to the emails cc's despite my --suppress-cc
argument. Apologies.
Josh
^ permalink raw reply
* Re: [PATCH v4 1/2] tpm: Issue a TPM2_Shutdown for TPM2 devices.
From: Josh Zimmerman @ 2017-05-25 23:11 UTC (permalink / raw)
To: Josh Zimmerman; +Cc: stable
In-Reply-To: <20170525230620.21656-2-joshz@google.com>
On Thu, May 25, 2017 at 4:06 PM, Josh Zimmerman <joshz@google.com> wrote:
>
> If a TPM2 loses power without a TPM2_Shutdown command being issued (a
> "disorderly reboot"), it may lose some state that has yet to be
> persisted to NVRam, and will increment the DA counter. After the DA
> counter gets sufficiently large, the TPM will lock the user out.
>
> NOTE: This only changes behavior on TPM2 devices. Since TPM1 uses sysfs,
> and sysfs relies on implicit locking on chip->ops, it is not safe to
> allow this code to run in TPM1, or to add sysfs support to TPM2, until
> that locking is made explicit.
>
> Signed-off-by: Josh Zimmerman <joshz@google.com>
> Reviewed-by: Jarko Sakkinen <jarkko.sakkinen@linux.intel.com>
> Cc: stable@vger.kernel.org
>
> ----
> v2:
> - Properly split changes between this and another commit
> - Use proper locking primitive.
> - Fix commenting style
> v3:
> - Re-fix commenting style
> v4:
> - Update description and tags (Reviewed-by, Cc).
> ---
> drivers/char/tpm/tpm-chip.c | 20 ++++++++++++++++++++
> drivers/char/tpm/tpm-sysfs.c | 3 +++
> 2 files changed, 23 insertions(+)
>
> diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c
> index 9dec9f551b83..272a42e77574 100644
> --- a/drivers/char/tpm/tpm-chip.c
> +++ b/drivers/char/tpm/tpm-chip.c
> @@ -142,6 +142,25 @@ static void tpm_devs_release(struct device *dev)
> put_device(&chip->dev);
> }
>
> +static void tpm_shutdown(struct device *dev)
> +{
> + struct tpm_chip *chip = container_of(dev, struct tpm_chip, dev);
> + /* TPM 2.0 requires that the TPM2_Shutdown() command be issued prior to
> + * loss of power. If it is not, the DA counter will be incremented and,
> + * eventually, the user will be locked out of their TPM.
> + * XXX: This codepath relies on the fact that sysfs is not enabled for
> + * TPM2: sysfs uses an implicit lock on chip->ops, so this use could
> + * race if TPM2 has sysfs support enabled before TPM sysfs's implicit
> + * locking is fixed.
> + */
> + if (chip->flags & TPM_CHIP_FLAG_TPM2) {
> + down_write(&chip->ops_sem);
> + tpm2_shutdown(chip, TPM_SU_CLEAR);
> + chip->ops = NULL;
> + up_write(&chip->ops_sem);
> + }
> +}
> +
> /**
> * tpm_chip_alloc() - allocate a new struct tpm_chip instance
> * @pdev: device to which the chip is associated
> @@ -181,6 +200,7 @@ struct tpm_chip *tpm_chip_alloc(struct device *pdev,
> device_initialize(&chip->devs);
>
> chip->dev.class = tpm_class;
> + chip->dev.class.shutdown = tpm_shutdown;
> chip->dev.release = tpm_dev_release;
> chip->dev.parent = pdev;
> chip->dev.groups = chip->groups;
> diff --git a/drivers/char/tpm/tpm-sysfs.c b/drivers/char/tpm/tpm-sysfs.c
> index 55405dbe43fa..5e5ff7eb6f7e 100644
> --- a/drivers/char/tpm/tpm-sysfs.c
> +++ b/drivers/char/tpm/tpm-sysfs.c
> @@ -294,6 +294,9 @@ static const struct attribute_group tpm_dev_group = {
>
> void tpm_sysfs_add_device(struct tpm_chip *chip)
> {
> + /* XXX: Before this restriction is removed, tpm_sysfs must be updated
> + * to explicitly lock chip->ops.
> + */
> if (chip->flags & TPM_CHIP_FLAG_TPM2)
> return;
>
> --
> 2.13.0.219.gdb65acc882-goog
>
This was not meant to be sent explicitly to stable@; git send-email
"helpfully" added stable@ to the emails cc's despite my --suppress-cc
argument. Apologies.
Josh
^ permalink raw reply
* [PATCH v4 2/2] Add "shutdown" to "struct class".
From: Josh Zimmerman @ 2017-05-25 23:06 UTC (permalink / raw)
To: joshz; +Cc: stable
In-Reply-To: <20170525230620.21656-1-joshz@google.com>
The TPM class has some common shutdown code that must be executed for
all drivers. This adds some needed functionality for that.
Signed-off-by: Josh Zimmerman <joshz@google.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: stable@vger.kernel.org
-----
v2: Add Signed-off-by.
v3: Remove logically separate change.
v4: Add "acked-by" and "cc".
---
drivers/base/core.c | 5 +++++
include/linux/device.h | 2 ++
2 files changed, 7 insertions(+)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 6bb60fb6a30b..687668d9afbe 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -2667,6 +2667,11 @@ void device_shutdown(void)
pm_runtime_get_noresume(dev);
pm_runtime_barrier(dev);
+ if (dev->class && dev->class->shutdown) {
+ if (initcall_debug)
+ dev_info(dev, "shutdown\n");
+ dev->class->shutdown(dev);
+ }
if (dev->bus && dev->bus->shutdown) {
if (initcall_debug)
dev_info(dev, "shutdown\n");
diff --git a/include/linux/device.h b/include/linux/device.h
index 9ef518af5515..f240baac2001 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -378,6 +378,7 @@ int subsys_virtual_register(struct bus_type *subsys,
* @suspend: Used to put the device to sleep mode, usually to a low power
* state.
* @resume: Used to bring the device from the sleep mode.
+ * @shutdown: Called at shut-down time to quiesce the device.
* @ns_type: Callbacks so sysfs can detemine namespaces.
* @namespace: Namespace of the device belongs to this class.
* @pm: The default device power management operations of this class.
@@ -407,6 +408,7 @@ struct class {
int (*suspend)(struct device *dev, pm_message_t state);
int (*resume)(struct device *dev);
+ int (*shutdown)(struct device *dev);
const struct kobj_ns_type_operations *ns_type;
const void *(*namespace)(struct device *dev);
--
2.13.0.219.gdb65acc882-goog
^ permalink raw reply related
* [PATCH v4 1/2] tpm: Issue a TPM2_Shutdown for TPM2 devices.
From: Josh Zimmerman @ 2017-05-25 23:06 UTC (permalink / raw)
To: joshz; +Cc: stable
In-Reply-To: <20170525230620.21656-1-joshz@google.com>
If a TPM2 loses power without a TPM2_Shutdown command being issued (a
"disorderly reboot"), it may lose some state that has yet to be
persisted to NVRam, and will increment the DA counter. After the DA
counter gets sufficiently large, the TPM will lock the user out.
NOTE: This only changes behavior on TPM2 devices. Since TPM1 uses sysfs,
and sysfs relies on implicit locking on chip->ops, it is not safe to
allow this code to run in TPM1, or to add sysfs support to TPM2, until
that locking is made explicit.
Signed-off-by: Josh Zimmerman <joshz@google.com>
Reviewed-by: Jarko Sakkinen <jarkko.sakkinen@linux.intel.com>
Cc: stable@vger.kernel.org
----
v2:
- Properly split changes between this and another commit
- Use proper locking primitive.
- Fix commenting style
v3:
- Re-fix commenting style
v4:
- Update description and tags (Reviewed-by, Cc).
---
drivers/char/tpm/tpm-chip.c | 20 ++++++++++++++++++++
drivers/char/tpm/tpm-sysfs.c | 3 +++
2 files changed, 23 insertions(+)
diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c
index 9dec9f551b83..272a42e77574 100644
--- a/drivers/char/tpm/tpm-chip.c
+++ b/drivers/char/tpm/tpm-chip.c
@@ -142,6 +142,25 @@ static void tpm_devs_release(struct device *dev)
put_device(&chip->dev);
}
+static void tpm_shutdown(struct device *dev)
+{
+ struct tpm_chip *chip = container_of(dev, struct tpm_chip, dev);
+ /* TPM 2.0 requires that the TPM2_Shutdown() command be issued prior to
+ * loss of power. If it is not, the DA counter will be incremented and,
+ * eventually, the user will be locked out of their TPM.
+ * XXX: This codepath relies on the fact that sysfs is not enabled for
+ * TPM2: sysfs uses an implicit lock on chip->ops, so this use could
+ * race if TPM2 has sysfs support enabled before TPM sysfs's implicit
+ * locking is fixed.
+ */
+ if (chip->flags & TPM_CHIP_FLAG_TPM2) {
+ down_write(&chip->ops_sem);
+ tpm2_shutdown(chip, TPM_SU_CLEAR);
+ chip->ops = NULL;
+ up_write(&chip->ops_sem);
+ }
+}
+
/**
* tpm_chip_alloc() - allocate a new struct tpm_chip instance
* @pdev: device to which the chip is associated
@@ -181,6 +200,7 @@ struct tpm_chip *tpm_chip_alloc(struct device *pdev,
device_initialize(&chip->devs);
chip->dev.class = tpm_class;
+ chip->dev.class.shutdown = tpm_shutdown;
chip->dev.release = tpm_dev_release;
chip->dev.parent = pdev;
chip->dev.groups = chip->groups;
diff --git a/drivers/char/tpm/tpm-sysfs.c b/drivers/char/tpm/tpm-sysfs.c
index 55405dbe43fa..5e5ff7eb6f7e 100644
--- a/drivers/char/tpm/tpm-sysfs.c
+++ b/drivers/char/tpm/tpm-sysfs.c
@@ -294,6 +294,9 @@ static const struct attribute_group tpm_dev_group = {
void tpm_sysfs_add_device(struct tpm_chip *chip)
{
+ /* XXX: Before this restriction is removed, tpm_sysfs must be updated
+ * to explicitly lock chip->ops.
+ */
if (chip->flags & TPM_CHIP_FLAG_TPM2)
return;
--
2.13.0.219.gdb65acc882-goog
^ permalink raw reply related
* + mm-migrate-fix-ref-count-handling-when-hugepage_migration_supported-v2.patch added to -mm tree
From: akpm @ 2017-05-25 22:46 UTC (permalink / raw)
To: punit.agrawal, cl, iamjoonsoo.kim, manoj.iyer, mgorman,
n-horiguchi, stable, wanpeng.li, mm-commits
The patch titled
Subject: mm/migrate: fix refcount handling when !hugepage_migration_supported()
has been added to the -mm tree. Its filename is
mm-migrate-fix-ref-count-handling-when-hugepage_migration_supported-v2.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-migrate-fix-ref-count-handling-when-hugepage_migration_supported-v2.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-migrate-fix-ref-count-handling-when-hugepage_migration_supported-v2.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Punit Agrawal <punit.agrawal@arm.com>
Subject: mm/migrate: fix refcount handling when !hugepage_migration_supported()
On failing to migrate a page, soft_offline_huge_page() performs the
necessary update to the hugepage ref-count. When
!hugepage_migration_supported() , unmap_and_move_hugepage() also
decrements the page ref-count for the hugepage. The combined behaviour
leaves the ref-count in an inconsistent state.
This leads to soft lockups when running the overcommitted hugepage test
from mce-tests suite.
Soft offlining pfn 0x83ed600 at process virtual address 0x400000000000
soft offline: 0x83ed600: migration failed 1, type
1fffc00000008008 (uptodate|head)
INFO: rcu_preempt detected stalls on CPUs/tasks:
Tasks blocked on level-0 rcu_node (CPUs 0-7): P2715
(detected by 7, t=5254 jiffies, g=963, c=962, q=321)
thugetlb_overco R running task 0 2715 2685 0x00000008
Call trace:
[<ffff000008089f90>] dump_backtrace+0x0/0x268
[<ffff00000808a2d4>] show_stack+0x24/0x30
[<ffff000008100d34>] sched_show_task+0x134/0x180
[<ffff0000081c90fc>] rcu_print_detail_task_stall_rnp+0x54/0x7c
[<ffff00000813cfd4>] rcu_check_callbacks+0xa74/0xb08
[<ffff000008143a3c>] update_process_times+0x34/0x60
[<ffff0000081550e8>] tick_sched_handle.isra.7+0x38/0x70
[<ffff00000815516c>] tick_sched_timer+0x4c/0x98
[<ffff0000081442e0>] __hrtimer_run_queues+0xc0/0x300
[<ffff000008144fa4>] hrtimer_interrupt+0xac/0x228
[<ffff0000089a56d4>] arch_timer_handler_phys+0x3c/0x50
[<ffff00000812f1bc>] handle_percpu_devid_irq+0x8c/0x290
[<ffff0000081297fc>] generic_handle_irq+0x34/0x50
[<ffff000008129f00>] __handle_domain_irq+0x68/0xc0
[<ffff0000080816b4>] gic_handle_irq+0x5c/0xb0
Address this by changing the putback_active_hugepage() in
soft_offline_huge_page() to putback_movable_pages().
Link: http://lkml.kernel.org/r/20170525135146.32011-1-punit.agrawal@arm.com
Reported-by: Manoj Iyer <manoj.iyer@canonical.com>
Tested-by: Manoj Iyer <manoj.iyer@canonical.com>
Suggested-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Wanpeng Li <wanpeng.li@hotmail.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: <stable@vger.kernel.org> [3.14+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/memory-failure.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff -puN mm/memory-failure.c~mm-migrate-fix-ref-count-handling-when-hugepage_migration_supported-v2 mm/memory-failure.c
--- a/mm/memory-failure.c~mm-migrate-fix-ref-count-handling-when-hugepage_migration_supported-v2
+++ a/mm/memory-failure.c
@@ -1600,7 +1600,8 @@ static int soft_offline_huge_page(struct
* only one hugepage pointed to by hpage, so we need not
* run through the pagelist here.
*/
- putback_active_hugepage(hpage);
+ if (!list_empty(&pagelist))
+ putback_movable_pages(&pagelist);
if (ret > 0)
ret = -EIO;
} else {
_
Patches currently in -mm which might be from punit.agrawal@arm.com are
mm-migrate-fix-ref-count-handling-when-hugepage_migration_supported-v2.patch
mm-gup-ensure-real-head-page-is-ref-counted-when-using-hugepages.patch
mm-hugetlb-add-size-parameter-to-huge_pte_offset.patch
mm-hugetlb-allow-architectures-to-override-huge_pte_clear.patch
mm-hugetlb-introduce-set_huge_swap_pte_at-helper.patch
mm-hugetlb-introduce-set_huge_swap_pte_at-helper-v4.patch
mm-hugetlb-introduce-set_huge_swap_pte_at-helper-v41.patch
mm-rmap-use-correct-helper-when-poisoning-hugepages.patch
^ permalink raw reply
* v4.4.70 build: 0 failures 0 warnings (v4.4.70)
From: Build bot for Mark Brown @ 2017-05-25 22:15 UTC (permalink / raw)
To: kernel-build-reports, linaro-kernel, stable
Tree/Branch: v4.4.70
Git describe: v4.4.70
Commit: b409ba3b05 Linux 4.4.70
Build Time: 78 min 31 sec
Passed: 9 / 9 (100.00 %)
Failed: 0 / 9 ( 0.00 %)
Errors: 0
Warnings: 0
Section Mismatches: 0
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
-------------------------------------------------------------------------------
===============================================================================
Detailed per-defconfig build reports below:
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
arm64-allnoconfig
arm64-allmodconfig
arm-multi_v5_defconfig
arm-multi_v7_defconfig
x86_64-defconfig
arm-allmodconfig
arm-allnoconfig
x86_64-allnoconfig
arm64-defconfig
close failed in file object destructor:
sys.excepthook is missing
lost sys.stderr
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox