| Message ID | 20191118054727.31045-1-miles.chen@mediatek.com (mailing list archive) |
|---|---|
| State | Mainlined |
| Commit | 7f439bc2d7e8c8cc4e1bab08ab7fe1bb73c9b268 |
| Headers | show |
| Series | Input: evdev - convert kzalloc()/vzalloc() to kvzalloc() | expand |
Hi, Gentle ping. note: We can also observe this issue in kernel-4.4, kernel-4.9, and kernel-4.14. Miles On Mon, 2019-11-18 at 13:47 +0800, Miles Chen wrote: > We observed a large(order-3) allocation in evdev_open() and it may > cause an OOM kenrel panic in kzalloc(), before we getting to the > vzalloc() fallback. > > Fix it by converting kzalloc()/vzalloc() to kvzalloc() to avoid the > OOM killer logic as we have a vmalloc fallback. > > InputReader invoked oom-killer: gfp_mask=0x240c2c0 > (GFP_KERNEL|__GFP_NOWARN|__GFP_COMP|__GFP_ZERO), nodemask=0, order=3, > oom_score_adj=-900 > ... > (dump_backtrace) from (show_stack+0x18/0x1c) > (show_stack) from (dump_stack+0x94/0xa8) > (dump_stack) from (dump_header+0x7c/0xe4) > (dump_header) from (out_of_memory+0x334/0x348) > (out_of_memory) from (__alloc_pages_nodemask+0xe9c/0xeb8) > (__alloc_pages_nodemask) from (kmalloc_order_trace+0x34/0x128) > (kmalloc_order_trace) from (__kmalloc+0x258/0x36c) > (__kmalloc) from (evdev_open+0x5c/0x17c) > (evdev_open) from (chrdev_open+0x100/0x204) > (chrdev_open) from (do_dentry_open+0x21c/0x354) > (do_dentry_open) from (vfs_open+0x58/0x84) > (vfs_open) from (path_openat+0x640/0xc98) > (path_openat) from (do_filp_open+0x78/0x11c) > (do_filp_open) from (do_sys_open+0x130/0x244) > (do_sys_open) from (SyS_openat+0x14/0x18) > (SyS_openat) from (__sys_trace_return+0x0/0x10) > ... > Normal: 12488*4kB (UMEH) 6984*8kB (UMEH) 2101*16kB (UMEH) 0*32kB > 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 139440kB > HighMem: 206*4kB (H) 131*8kB (H) 42*16kB (H) 2*32kB (H) 0*64kB > 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 2608kB > ... > Kernel panic - not syncing: Out of memory and no killable processes... > > Signed-off-by: Miles Chen <miles.chen@mediatek.com> > --- > drivers/input/evdev.c | 5 +---- > 1 file changed, 1 insertion(+), 4 deletions(-) > > diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c > index d7dd6fcf2db0..cf5d7d63fd48 100644 > --- a/drivers/input/evdev.c > +++ b/drivers/input/evdev.c > @@ -484,10 +484,7 @@ static int evdev_open(struct inode *inode, struct file *file) > struct evdev_client *client; > int error; > > - client = kzalloc(struct_size(client, buffer, bufsize), > - GFP_KERNEL | __GFP_NOWARN); > - if (!client) > - client = vzalloc(struct_size(client, buffer, bufsize)); > + client = kvzalloc(struct_size(client, buffer, bufsize), GFP_KERNEL); > if (!client) > return -ENOMEM; >
On Mon, Nov 18, 2019 at 01:47:27PM +0800, Miles Chen wrote: > We observed a large(order-3) allocation in evdev_open() and it may > cause an OOM kenrel panic in kzalloc(), before we getting to the > vzalloc() fallback. > > Fix it by converting kzalloc()/vzalloc() to kvzalloc() to avoid the > OOM killer logic as we have a vmalloc fallback. > > InputReader invoked oom-killer: gfp_mask=0x240c2c0 > (GFP_KERNEL|__GFP_NOWARN|__GFP_COMP|__GFP_ZERO), nodemask=0, order=3, > oom_score_adj=-900 > ... > (dump_backtrace) from (show_stack+0x18/0x1c) > (show_stack) from (dump_stack+0x94/0xa8) > (dump_stack) from (dump_header+0x7c/0xe4) > (dump_header) from (out_of_memory+0x334/0x348) > (out_of_memory) from (__alloc_pages_nodemask+0xe9c/0xeb8) > (__alloc_pages_nodemask) from (kmalloc_order_trace+0x34/0x128) > (kmalloc_order_trace) from (__kmalloc+0x258/0x36c) > (__kmalloc) from (evdev_open+0x5c/0x17c) > (evdev_open) from (chrdev_open+0x100/0x204) > (chrdev_open) from (do_dentry_open+0x21c/0x354) > (do_dentry_open) from (vfs_open+0x58/0x84) > (vfs_open) from (path_openat+0x640/0xc98) > (path_openat) from (do_filp_open+0x78/0x11c) > (do_filp_open) from (do_sys_open+0x130/0x244) > (do_sys_open) from (SyS_openat+0x14/0x18) > (SyS_openat) from (__sys_trace_return+0x0/0x10) > ... > Normal: 12488*4kB (UMEH) 6984*8kB (UMEH) 2101*16kB (UMEH) 0*32kB > 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 139440kB > HighMem: 206*4kB (H) 131*8kB (H) 42*16kB (H) 2*32kB (H) 0*64kB > 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 2608kB > ... > Kernel panic - not syncing: Out of memory and no killable processes... > > Signed-off-by: Miles Chen <miles.chen@mediatek.com> Applied, thank you. > --- > drivers/input/evdev.c | 5 +---- > 1 file changed, 1 insertion(+), 4 deletions(-) > > diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c > index d7dd6fcf2db0..cf5d7d63fd48 100644 > --- a/drivers/input/evdev.c > +++ b/drivers/input/evdev.c > @@ -484,10 +484,7 @@ static int evdev_open(struct inode *inode, struct file *file) > struct evdev_client *client; > int error; > > - client = kzalloc(struct_size(client, buffer, bufsize), > - GFP_KERNEL | __GFP_NOWARN); > - if (!client) > - client = vzalloc(struct_size(client, buffer, bufsize)); > + client = kvzalloc(struct_size(client, buffer, bufsize), GFP_KERNEL); > if (!client) > return -ENOMEM; > > -- > 2.18.0
diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c index d7dd6fcf2db0..cf5d7d63fd48 100644 --- a/drivers/input/evdev.c +++ b/drivers/input/evdev.c @@ -484,10 +484,7 @@ static int evdev_open(struct inode *inode, struct file *file) struct evdev_client *client; int error; - client = kzalloc(struct_size(client, buffer, bufsize), - GFP_KERNEL | __GFP_NOWARN); - if (!client) - client = vzalloc(struct_size(client, buffer, bufsize)); + client = kvzalloc(struct_size(client, buffer, bufsize), GFP_KERNEL); if (!client) return -ENOMEM;
We observed a large(order-3) allocation in evdev_open() and it may cause an OOM kenrel panic in kzalloc(), before we getting to the vzalloc() fallback. Fix it by converting kzalloc()/vzalloc() to kvzalloc() to avoid the OOM killer logic as we have a vmalloc fallback. InputReader invoked oom-killer: gfp_mask=0x240c2c0 (GFP_KERNEL|__GFP_NOWARN|__GFP_COMP|__GFP_ZERO), nodemask=0, order=3, oom_score_adj=-900 ... (dump_backtrace) from (show_stack+0x18/0x1c) (show_stack) from (dump_stack+0x94/0xa8) (dump_stack) from (dump_header+0x7c/0xe4) (dump_header) from (out_of_memory+0x334/0x348) (out_of_memory) from (__alloc_pages_nodemask+0xe9c/0xeb8) (__alloc_pages_nodemask) from (kmalloc_order_trace+0x34/0x128) (kmalloc_order_trace) from (__kmalloc+0x258/0x36c) (__kmalloc) from (evdev_open+0x5c/0x17c) (evdev_open) from (chrdev_open+0x100/0x204) (chrdev_open) from (do_dentry_open+0x21c/0x354) (do_dentry_open) from (vfs_open+0x58/0x84) (vfs_open) from (path_openat+0x640/0xc98) (path_openat) from (do_filp_open+0x78/0x11c) (do_filp_open) from (do_sys_open+0x130/0x244) (do_sys_open) from (SyS_openat+0x14/0x18) (SyS_openat) from (__sys_trace_return+0x0/0x10) ... Normal: 12488*4kB (UMEH) 6984*8kB (UMEH) 2101*16kB (UMEH) 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 139440kB HighMem: 206*4kB (H) 131*8kB (H) 42*16kB (H) 2*32kB (H) 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 2608kB ... Kernel panic - not syncing: Out of memory and no killable processes... Signed-off-by: Miles Chen <miles.chen@mediatek.com> --- drivers/input/evdev.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-)