Hello,
syzbot found the following crash on:
HEAD commit: 81a72c79 Add linux-next specific files for 20190612
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1451d31ea00000
kernel config: https://syzkaller.appspot.com/x/.config?x=8aa46bbce201b8b6
dashboard link: https://syzkaller.appspot.com/bug?extid=8ab2d0f39fb79fe6ca40
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1250ae3ea00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1568557aa00000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: [email protected]
INFO: task syz-executor050:8619 can't die for more than 143 seconds.
syz-executor050 R running task 27536 8619 8618 0x00004006
Call Trace:
Showing all locks held in the system:
1 lock held by khungtaskd/1046:
#0: 00000000f58b83ec (rcu_read_lock){....}, at:
debug_show_all_locks+0x5f/0x27e kernel/locking/lockdep.c:5262
1 lock held by rsyslogd/8504:
#0: 00000000b8867a10 (&f->f_pos_lock){+.+.}, at: __fdget_pos+0xee/0x110
fs/file.c:801
2 locks held by getty/8594:
#0: 000000008c94b07f (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x33/0x40 drivers/tty/tty_ldsem.c:341
#1: 000000006c5169d5 (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x232/0x1b70 drivers/tty/n_tty.c:2156
2 locks held by getty/8595:
#0: 0000000042bd87ed (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x33/0x40 drivers/tty/tty_ldsem.c:341
#1: 000000009ebc0e1a (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x232/0x1b70 drivers/tty/n_tty.c:2156
2 locks held by getty/8596:
#0: 00000000ad647db4 (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x33/0x40 drivers/tty/tty_ldsem.c:341
#1: 00000000f68a3152 (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x232/0x1b70 drivers/tty/n_tty.c:2156
2 locks held by getty/8597:
#0: 0000000072ec45a9 (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x33/0x40 drivers/tty/tty_ldsem.c:341
#1: 00000000daa58f5f (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x232/0x1b70 drivers/tty/n_tty.c:2156
2 locks held by getty/8598:
#0: 000000007698feb5 (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x33/0x40 drivers/tty/tty_ldsem.c:341
#1: 0000000017a6b41f (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x232/0x1b70 drivers/tty/n_tty.c:2156
2 locks held by getty/8599:
#0: 00000000f5a5df8a (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x33/0x40 drivers/tty/tty_ldsem.c:341
#1: 000000003ed47aa1 (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x232/0x1b70 drivers/tty/n_tty.c:2156
2 locks held by getty/8600:
#0: 00000000ab9f490c (&tty->ldisc_sem){++++}, at:
ldsem_down_read+0x33/0x40 drivers/tty/tty_ldsem.c:341
#1: 00000000332ddba5 (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x232/0x1b70 drivers/tty/n_tty.c:2156
1 lock held by syz-executor050/8619:
=============================================
NMI backtrace for cpu 0
CPU: 0 PID: 1046 Comm: khungtaskd Not tainted 5.2.0-rc4-next-20190612 #13
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x172/0x1f0 lib/dump_stack.c:113
nmi_cpu_backtrace.cold+0x63/0xa4 lib/nmi_backtrace.c:101
nmi_trigger_cpumask_backtrace+0x1be/0x236 lib/nmi_backtrace.c:62
arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38
trigger_all_cpu_backtrace include/linux/nmi.h:146 [inline]
check_hung_uninterruptible_tasks kernel/hung_task.c:249 [inline]
watchdog+0xb88/0x12b0 kernel/hung_task.c:333
kthread+0x354/0x420 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
Sending NMI from CPU 0 to CPUs 1:
NMI backtrace for cpu 1
CPU: 1 PID: 8619 Comm: syz-executor050 Not tainted 5.2.0-rc4-next-20190612
#13
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:get_current arch/x86/include/asm/current.h:15 [inline]
RIP: 0010:__sanitizer_cov_trace_pc+0x8/0x50 kernel/kcov.c:101
Code: f4 ff ff ff e8 9d fa e9 ff 48 c7 05 ce b0 15 09 00 00 00 00 e9 a4 e9
ff ff 90 90 90 90 90 90 90 90 90 55 48 89 e5 48 8b 75 08 <65> 48 8b 04 25
c0 fd 01 00 65 8b 15 f0 fa 90 7e 81 e2 00 01 1f 00
RSP: 0018:ffff8880a9acfd80 EFLAGS: 00000206
RAX: 1ffffd40000720d9 RBX: 0000160000000000 RCX: ffffffff81682654
RDX: 0000000000000000 RSI: ffffffff8168263c RDI: ffffea00003906c8
RBP: ffff8880a9acfd80 R08: ffff88808fe146c0 R09: 0000000000000002
R10: ffff88808fe14f78 R11: ffff88808fe146c0 R12: ffffea0000390688
R13: dffffc0000000000 R14: ffffea0000390680 R15: 00000000049a5000
FS: 0000555555a3e880(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffff600400 CR3: 00000000a3d59000 CR4: 00000000001406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
page_to_boot_pfn include/linux/kexec.h:325 [inline]
kimage_alloc_page+0xac/0x9f0 kernel/kexec_core.c:708
kimage_load_normal_segment kernel/kexec_core.c:802 [inline]
kimage_load_segment+0x25d/0x740 kernel/kexec_core.c:919
do_kexec_load+0x41a/0x600 kernel/kexec.c:157
__do_sys_kexec_load kernel/kexec.c:251 [inline]
__se_sys_kexec_load kernel/kexec.c:226 [inline]
__x64_sys_kexec_load+0x1d5/0x260 kernel/kexec.c:226
do_syscall_64+0xfd/0x680 arch/x86/entry/common.c:301
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x441149
Code: e8 fc ab 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 9b 09 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007ffd407ca1e8 EFLAGS: 00000246 ORIG_RAX: 00000000000000f6
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 0000000000441149
RDX: 0000000020000100 RSI: 0000000000000001 RDI: fffffffffffffffe
RBP: 00000000006cb018 R08: 0000000000000004 R09: 00000000004002c8
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000401f70
R13: 0000000000402000 R14: 0000000000000000 R15: 0000000000000000
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at [email protected].
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
syzbot has bisected this bug to:
commit 4ddc1b28aac57a90c6426d55e0dea3c1b5eb4782
Author: Chao Yu <[email protected]>
Date: Wed Jul 25 23:19:48 2018 +0000
f2fs: fix to restrict mount condition when without CONFIG_QUOTA
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=142f4e49a00000
start commit: 81a72c79 Add linux-next specific files for 20190612
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=122f4e49a00000
kernel config: https://syzkaller.appspot.com/x/.config?x=8aa46bbce201b8b6
dashboard link: https://syzkaller.appspot.com/bug?extid=8ab2d0f39fb79fe6ca40
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1250ae3ea00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1568557aa00000
Reported-by: [email protected]
Fixes: 4ddc1b28aac5 ("f2fs: fix to restrict mount condition when without
CONFIG_QUOTA")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot found that a thread can stall for minutes inside kexec_load() after
that thread was killed by SIGKILL [1]. It turned out that the reproducer
was trying to allocate 2408MB of memory using kimage_alloc_page() from
kimage_load_normal_segment(). Let's check for SIGKILL before doing memory
allocation.
[1] https://syzkaller.appspot.com/bug?id=a0e3436829698d5824231251fad9d8e998f94f5e
Signed-off-by: Tetsuo Handa <[email protected]>
Reported-by: syzbot <[email protected]>
---
kernel/kexec_core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index fd5c95f..2b25d95 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -302,6 +302,8 @@ static struct page *kimage_alloc_pages(gfp_t gfp_mask, unsigned int order)
{
struct page *pages;
+ if (fatal_signal_pending(current))
+ return NULL;
pages = alloc_pages(gfp_mask & ~__GFP_ZERO, order);
if (pages) {
unsigned int count, i;
--
1.8.3.1
Hello.
I noticed (using below debug patch and reproducer) that memory allocation from
ion_system_heap_allocate() is calling ion_system_heap_shrink(). Is such behavior
what we want?
----------------------------------------
diff --git a/drivers/staging/android/ion/ion.h b/drivers/staging/android/ion/ion.h
index e291299fd35f..ce096d520915 100644
--- a/drivers/staging/android/ion/ion.h
+++ b/drivers/staging/android/ion/ion.h
@@ -168,6 +168,8 @@ struct ion_heap {
/* protect heap statistics */
spinlock_t stat_lock;
+
+ bool no_shrink;
};
/**
diff --git a/drivers/staging/android/ion/ion_system_heap.c b/drivers/staging/android/ion/ion_system_heap.c
index aa8d8425be25..ecc22eb870d0 100644
--- a/drivers/staging/android/ion/ion_system_heap.c
+++ b/drivers/staging/android/ion/ion_system_heap.c
@@ -114,6 +114,7 @@ static int ion_system_heap_allocate(struct ion_heap *heap,
return -ENOMEM;
INIT_LIST_HEAD(&pages);
+ heap->no_shrink = true;
while (size_remaining > 0) {
page = alloc_largest_available(sys_heap, buffer, size_remaining,
max_order);
@@ -139,6 +140,7 @@ static int ion_system_heap_allocate(struct ion_heap *heap,
}
buffer->sg_table = table;
+ heap->no_shrink = false;
return 0;
free_table:
@@ -146,6 +148,7 @@ static int ion_system_heap_allocate(struct ion_heap *heap,
free_pages:
list_for_each_entry_safe(page, tmp_page, &pages, lru)
free_buffer_page(sys_heap, buffer, page);
+ heap->no_shrink = false;
return -ENOMEM;
}
@@ -200,6 +203,7 @@ static int ion_system_heap_shrink(struct ion_heap *heap, gfp_t gfp_mask,
break;
}
}
+ BUG_ON(heap->no_shrink && nr_total);
return nr_total;
}
----------------------------------------
----------------------------------------
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <unistd.h>
int main(int argc, char *argv[])
{
struct ion_allocation_data {
unsigned long long len;
unsigned int heap_id_mask;
unsigned int flags;
unsigned int fd;
unsigned int unused;
} data = {
3ULL * 1048576 * 1024, -1, 1, -1, 0
};
int i;
for (i = 0; i < 10; i++) {
if (fork() == 0) {
ioctl(open("/dev/ion", 0, 0), 0xc0184900, &data);
pause();
}
}
return 0;
}
----------------------------------------
----------------------------------------
[ 182.907464][ T7500] ------------[ cut here ]------------
[ 182.907468][ T7500] kernel BUG at drivers/staging/android/ion/ion_system_heap.c:206!
[ 182.907477][ T7500] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
[ 182.907481][ T7500] CPU: 4 PID: 7500 Comm: a.out Not tainted 5.2.0-rc5+ #207
[ 182.907483][ T7500] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 04/13/2018
[ 182.907491][ T7500] RIP: 0010:ion_system_heap_shrink+0xbf/0xd0
[ 182.907495][ T7500] Code: 41 5f 5d c3 e8 02 91 8f fe 8b 75 d4 44 89 ea 48 8b 7d c0 e8 23 0d 00 00 41 29 c5 41 01 c4 45 85 ed 7f a7 eb b4 e8 e1 90 8f fe <0f> 0b 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 41
[ 182.907497][ T7500] RSP: 0000:ffffc90001de77d0 EFLAGS: 00010293
[ 182.907501][ T7500] RAX: ffff888212698700 RBX: ffff88822985fba8 RCX: ffffffff82a398af
[ 182.907503][ T7500] RDX: 0000000000000000 RSI: 0000000000140dc2 RDI: ffff888229927b00
[ 182.907506][ T7500] RBP: ffffc90001de7810 R08: 0000000000000000 R09: 0000000000000004
[ 182.907508][ T7500] R10: ffffc90001de7790 R11: 0000000000000001 R12: 0000000000002021
[ 182.907511][ T7500] R13: 0000000000000000 R14: 0000000000000000 R15: ffff88822985fa00
[ 182.907515][ T7500] FS: 00007fe4034934c0(0000) GS:ffff888235d00000(0000) knlGS:0000000000000000
[ 182.907520][ T7500] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 182.907522][ T7500] CR2: 00007fe402f9e5ad CR3: 0000000215075003 CR4: 00000000003606e0
[ 182.907556][ T7500] Call Trace:
[ 182.907562][ T7500] ? order_to_index+0x50/0x50
[ 182.907566][ T7500] ion_heap_shrink_count+0x5b/0x80
[ 182.907572][ T7500] do_shrink_slab+0x66/0x570
[ 182.907578][ T7500] shrink_slab+0x288/0x360
[ 182.907583][ T7500] shrink_node+0x1f6/0x5e0
[ 182.907589][ T7500] do_try_to_free_pages+0x118/0x520
[ 182.907594][ T7500] try_to_free_pages+0x138/0x420
[ 182.907601][ T7500] __alloc_pages_slowpath+0x452/0x1150
[ 182.907610][ T7500] __alloc_pages_nodemask+0x3ac/0x440
[ 182.907615][ T7500] alloc_pages_current+0x7a/0x110
[ 182.907620][ T7500] ion_page_pool_alloc+0x62/0xd0
[ 182.907624][ T7500] ion_system_heap_allocate+0xb4/0x420
[ 182.907628][ T7500] ? ion_ioctl+0x364/0x800
[ 182.907633][ T7500] ion_ioctl+0x332/0x800
[ 182.907641][ T7500] ? _ion_buffer_destroy+0x80/0x80
[ 182.907645][ T7500] do_vfs_ioctl+0xc1/0x8a0
[ 182.907650][ T7500] ? tomoyo_file_ioctl+0x23/0x30
[ 182.907655][ T7500] ksys_ioctl+0x94/0xb0
[ 182.907660][ T7500] __x64_sys_ioctl+0x1e/0x30
[ 182.907665][ T7500] do_syscall_64+0x81/0x2b0
[ 182.907670][ T7500] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 182.907674][ T7500] RIP: 0033:0x7fe402f9e5d7
[ 182.907679][ T7500] Code: Bad RIP value.
[ 182.907681][ T7500] RSP: 002b:00007fff65b39098 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[ 182.907685][ T7500] RAX: ffffffffffffffda RBX: 0000000000000009 RCX: 00007fe402f9e5d7
[ 182.907688][ T7500] RDX: 00007fff65b390a0 RSI: 00000000c0184900 RDI: 0000000000000003
[ 182.907690][ T7500] RBP: 00007fff65b390a0 R08: 00007fe4034934c0 R09: 00007fe403274d80
[ 182.907693][ T7500] R10: 0000000000000000 R11: 0000000000000246 R12: 000055c9049dd720
[ 182.907695][ T7500] R13: 00007fff65b391b0 R14: 0000000000000000 R15: 0000000000000000
[ 182.907699][ T7500] Modules linked in:
[ 182.907738][ T7500] ---[ end trace b9487e8931865499 ]---
[ 182.907745][ T7500] RIP: 0010:ion_system_heap_shrink+0xbf/0xd0
[ 182.907752][ T7500] Code: 41 5f 5d c3 e8 02 91 8f fe 8b 75 d4 44 89 ea 48 8b 7d c0 e8 23 0d 00 00 41 29 c5 41 01 c4 45 85 ed 7f a7 eb b4 e8 e1 90 8f fe <0f> 0b 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 41
[ 182.907756][ T7500] RSP: 0000:ffffc90001de77d0 EFLAGS: 00010293
[ 182.907765][ T7500] RAX: ffff888212698700 RBX: ffff88822985fba8 RCX: ffffffff82a398af
[ 182.907771][ T7500] RDX: 0000000000000000 RSI: 0000000000140dc2 RDI: ffff888229927b00
[ 182.907775][ T7500] RBP: ffffc90001de7810 R08: 0000000000000000 R09: 0000000000000004
[ 182.907780][ T7500] R10: ffffc90001de7790 R11: 0000000000000001 R12: 0000000000002021
[ 182.907784][ T7500] R13: 0000000000000000 R14: 0000000000000000 R15: ffff88822985fa00
[ 182.907789][ T7500] FS: 00007fe4034934c0(0000) GS:ffff888235d00000(0000) knlGS:0000000000000000
[ 182.907793][ T7500] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 182.907798][ T7500] CR2: 00007fe402f9e5ad CR3: 0000000215075003 CR4: 00000000003606e0
----------------------------------------
Below is a patch for the original problem reported by syzbot
( https://syzkaller.appspot.com/text?tag=CrashLog&x=11bb246ea00000 ).
----------------------------------------
From e0758655727044753399fb4f7c5f3eb25ac5cccd Mon Sep 17 00:00:00 2001
From: Tetsuo Handa <[email protected]>
Date: Fri, 21 Jun 2019 11:22:51 +0900
Subject: [PATCH] staging: android: ion: Bail out upon SIGKILL when allocating memory.
syzbot found that a thread can stall for minutes inside
ion_system_heap_allocate() after that thread was killed by SIGKILL [1].
Let's check for SIGKILL before doing memory allocation.
[1] https://syzkaller.appspot.com/bug?id=a0e3436829698d5824231251fad9d8e998f94f5e
Signed-off-by: Tetsuo Handa <[email protected]>
Reported-by: syzbot <[email protected]>
---
drivers/staging/android/ion/ion_page_pool.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/staging/android/ion/ion_page_pool.c b/drivers/staging/android/ion/ion_page_pool.c
index fd4995fb676e..f85ec5b16b65 100644
--- a/drivers/staging/android/ion/ion_page_pool.c
+++ b/drivers/staging/android/ion/ion_page_pool.c
@@ -8,11 +8,14 @@
#include <linux/list.h>
#include <linux/slab.h>
#include <linux/swap.h>
+#include <linux/sched/signal.h>
#include "ion.h"
static inline struct page *ion_page_pool_alloc_pages(struct ion_page_pool *pool)
{
+ if (fatal_signal_pending(current))
+ return NULL;
return alloc_pages(pool->gfp_mask, pool->order);
}
--
2.17.1
Andrew, can you pick up this patch? We might miss next merge window, for
Eric Biederman seems to be offline for two weeks.
On 2019/06/14 19:16, Tetsuo Handa wrote:
> syzbot found that a thread can stall for minutes inside kexec_load() after
> that thread was killed by SIGKILL [1]. It turned out that the reproducer
> was trying to allocate 2408MB of memory using kimage_alloc_page() from
> kimage_load_normal_segment(). Let's check for SIGKILL before doing memory
> allocation.
>
> [1] https://syzkaller.appspot.com/bug?id=a0e3436829698d5824231251fad9d8e998f94f5e
>
> Signed-off-by: Tetsuo Handa <[email protected]>
> Reported-by: syzbot <[email protected]>
> ---
> kernel/kexec_core.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index fd5c95f..2b25d95 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -302,6 +302,8 @@ static struct page *kimage_alloc_pages(gfp_t gfp_mask, unsigned int order)
> {
> struct page *pages;
>
> + if (fatal_signal_pending(current))
> + return NULL;
> pages = alloc_pages(gfp_mask & ~__GFP_ZERO, order);
> if (pages) {
> unsigned int count, i;
>
Andrew, can you pick up this patch? No response from Laura Abbott nor Sumit Semwal.
On 2019/06/21 18:58, Tetsuo Handa wrote:
> From e0758655727044753399fb4f7c5f3eb25ac5cccd Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa <[email protected]>
> Date: Fri, 21 Jun 2019 11:22:51 +0900
> Subject: [PATCH] staging: android: ion: Bail out upon SIGKILL when allocating memory.
>
> syzbot found that a thread can stall for minutes inside
> ion_system_heap_allocate() after that thread was killed by SIGKILL [1].
> Let's check for SIGKILL before doing memory allocation.
>
> [1] https://syzkaller.appspot.com/bug?id=a0e3436829698d5824231251fad9d8e998f94f5e
>
> Signed-off-by: Tetsuo Handa <[email protected]>
> Reported-by: syzbot <[email protected]>
> ---
> drivers/staging/android/ion/ion_page_pool.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/staging/android/ion/ion_page_pool.c b/drivers/staging/android/ion/ion_page_pool.c
> index fd4995fb676e..f85ec5b16b65 100644
> --- a/drivers/staging/android/ion/ion_page_pool.c
> +++ b/drivers/staging/android/ion/ion_page_pool.c
> @@ -8,11 +8,14 @@
> #include <linux/list.h>
> #include <linux/slab.h>
> #include <linux/swap.h>
> +#include <linux/sched/signal.h>
>
> #include "ion.h"
>
> static inline struct page *ion_page_pool_alloc_pages(struct ion_page_pool *pool)
> {
> + if (fatal_signal_pending(current))
> + return NULL;
> return alloc_pages(pool->gfp_mask, pool->order);
> }
>
>
On 7/1/19 6:55 AM, Tetsuo Handa wrote:
> Andrew, can you pick up this patch? No response from Laura Abbott nor Sumit Semwal.
>
> On 2019/06/21 18:58, Tetsuo Handa wrote:
>> From e0758655727044753399fb4f7c5f3eb25ac5cccd Mon Sep 17 00:00:00 2001
>> From: Tetsuo Handa <[email protected]>
>> Date: Fri, 21 Jun 2019 11:22:51 +0900
>> Subject: [PATCH] staging: android: ion: Bail out upon SIGKILL when allocating memory.
>>
>> syzbot found that a thread can stall for minutes inside
>> ion_system_heap_allocate() after that thread was killed by SIGKILL [1].
>> Let's check for SIGKILL before doing memory allocation.
>>
>> [1] https://syzkaller.appspot.com/bug?id=a0e3436829698d5824231251fad9d8e998f94f5e
>>
>> Signed-off-by: Tetsuo Handa <[email protected]>
>> Reported-by: syzbot <[email protected]>
>> ---
>> drivers/staging/android/ion/ion_page_pool.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/staging/android/ion/ion_page_pool.c b/drivers/staging/android/ion/ion_page_pool.c
>> index fd4995fb676e..f85ec5b16b65 100644
>> --- a/drivers/staging/android/ion/ion_page_pool.c
>> +++ b/drivers/staging/android/ion/ion_page_pool.c
>> @@ -8,11 +8,14 @@
>> #include <linux/list.h>
>> #include <linux/slab.h>
>> #include <linux/swap.h>
>> +#include <linux/sched/signal.h>
>>
>> #include "ion.h"
>>
>> static inline struct page *ion_page_pool_alloc_pages(struct ion_page_pool *pool)
>> {
>> + if (fatal_signal_pending(current))
>> + return NULL;
>> return alloc_pages(pool->gfp_mask, pool->order);
>> }
>>
>>
>
Acked-by: Laura Abbott <[email protected]>
Hello Tetsuo,
On Mon, 1 Jul 2019 at 17:07, Laura Abbott <[email protected]> wrote:
>
> On 7/1/19 6:55 AM, Tetsuo Handa wrote:
> > Andrew, can you pick up this patch? No response from Laura Abbott nor Sumit Semwal.
Apologies; it didn't seem to get flitered out for me. I'll re-check my
email filters.
> >
> > On 2019/06/21 18:58, Tetsuo Handa wrote:
> >> From e0758655727044753399fb4f7c5f3eb25ac5cccd Mon Sep 17 00:00:00 2001
> >> From: Tetsuo Handa <[email protected]>
> >> Date: Fri, 21 Jun 2019 11:22:51 +0900
> >> Subject: [PATCH] staging: android: ion: Bail out upon SIGKILL when allocating memory.
> >>
> >> syzbot found that a thread can stall for minutes inside
> >> ion_system_heap_allocate() after that thread was killed by SIGKILL [1].
> >> Let's check for SIGKILL before doing memory allocation.
> >>
> >> [1] https://syzkaller.appspot.com/bug?id=a0e3436829698d5824231251fad9d8e998f94f5e
> >>
> >> Signed-off-by: Tetsuo Handa <[email protected]>
> >> Reported-by: syzbot <[email protected]>
> >> ---
> >> drivers/staging/android/ion/ion_page_pool.c | 3 +++
> >> 1 file changed, 3 insertions(+)
> >>
> >> diff --git a/drivers/staging/android/ion/ion_page_pool.c b/drivers/staging/android/ion/ion_page_pool.c
> >> index fd4995fb676e..f85ec5b16b65 100644
> >> --- a/drivers/staging/android/ion/ion_page_pool.c
> >> +++ b/drivers/staging/android/ion/ion_page_pool.c
> >> @@ -8,11 +8,14 @@
> >> #include <linux/list.h>
> >> #include <linux/slab.h>
> >> #include <linux/swap.h>
> >> +#include <linux/sched/signal.h>
> >>
> >> #include "ion.h"
> >>
> >> static inline struct page *ion_page_pool_alloc_pages(struct ion_page_pool *pool)
> >> {
> >> + if (fatal_signal_pending(current))
> >> + return NULL;
> >> return alloc_pages(pool->gfp_mask, pool->order);
> >> }
> >>
> >>
> >
>
> Acked-by: Laura Abbott <[email protected]>
fwiw, Acked-by: Sumit Semwal <[email protected]>
--
Thanks and regards,
Sumit Semwal
Linaro Consumer Group - Kernel Team Lead
Linaro.org │ Open source software for ARM SoCs
On 2019/07/01 23:02, Sumit Semwal wrote:
>> Acked-by: Laura Abbott <[email protected]>
> fwiw, Acked-by: Sumit Semwal <[email protected]>
Thank you for responding. You can carry this patch via whichever tree you like.
By the way, is "memory allocation from ion_system_heap_allocate() is calling
ion_system_heap_shrink()"
( https://lkml.kernel.org/r/[email protected] )
what we want? Such memory allocations might not want to call shrinkers...
On 7/1/19 5:02 PM, Tetsuo Handa wrote:
> On 2019/07/01 23:02, Sumit Semwal wrote:
>>> Acked-by: Laura Abbott <[email protected]>
>> fwiw, Acked-by: Sumit Semwal <[email protected]>
>
> Thank you for responding. You can carry this patch via whichever tree you like.
>
> By the way, is "memory allocation from ion_system_heap_allocate() is calling
> ion_system_heap_shrink()"
> ( https://lkml.kernel.org/r/[email protected] )
> what we want? Such memory allocations might not want to call shrinkers...
>
For what Ion gets typically used for we do want to be calling shrinkers.
I've had discussions with people in the past about the risk of Ion as
DoS vector due to its ability to allocate large amounts of memory.
At the very least, we probably shouldn't be trying to call the Ion shrinker
when we're in the middle of an ion allocation since shrinking won't do us
any good. We're in the process of re-working Ion at the moment so this
might be a good topic to bring up again.
Thanks,
Laura
On Fri, Jun 14, 2019 at 07:16:18PM +0900, Tetsuo Handa wrote:
> syzbot found that a thread can stall for minutes inside kexec_load() after
> that thread was killed by SIGKILL [1]. It turned out that the reproducer
> was trying to allocate 2408MB of memory using kimage_alloc_page() from
> kimage_load_normal_segment(). Let's check for SIGKILL before doing memory
> allocation.
>
> [1] https://syzkaller.appspot.com/bug?id=a0e3436829698d5824231251fad9d8e998f94f5e
>
> Signed-off-by: Tetsuo Handa <[email protected]>
> Reported-by: syzbot <[email protected]>
> ---
> kernel/kexec_core.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index fd5c95f..2b25d95 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -302,6 +302,8 @@ static struct page *kimage_alloc_pages(gfp_t gfp_mask, unsigned int order)
> {
> struct page *pages;
>
> + if (fatal_signal_pending(current))
> + return NULL;
> pages = alloc_pages(gfp_mask & ~__GFP_ZERO, order);
> if (pages) {
> unsigned int count, i;
> --
> 1.8.3.1
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/993c9185-d324-2640-d061-bed2dd18b1f7%40I-love.SAKURA.ne.jp.
> For more options, visit https://groups.google.com/d/optout.
What happened to this patch? This bug is still occurring.
- Eric
On 2019/07/24 11:54, Eric Biggers wrote:
>
> What happened to this patch? This bug is still occurring.
Andrew Morton added this patch to the -mm tree.
Should appear in the linux-next tree in a few days.
https://marc.info/?l=linux-mm-commits&m=156391134729795&w=2