[PATCH] Validate pointer when copying mount namespace.
We encountered following panic. Validate the pointer to avoid this. [35046.276380] BUG: unable to handle kernel NULL pointer dereference at 0010 [35046.283316] IP: [<8095dc91>] copy_mnt_ns+0x111/0x260 [35046.288225] *pdpt = 1b883001 *pde = [35046.293901] Oops: [#1] PREEMPT SMP [35046.307342] CPU: 2 PID: 6761 Comm: main Tainted: GW O [35046.315345] task: a7f06f80 ti: 82e16000 task.ti: 82e16000 [35046.320673] EIP: 0060:[<8095dc91>] EFLAGS: 00210246 CPU: 2 [35046.326106] EIP is at copy_mnt_ns+0x111/0x260 [35046.330397] EAX: 3436362e EBX: b1026880 ECX: 96822f80 EDX: 828314a8 [35046.336590] ESI: EDI: b0dde300 EBP: 82e17f50 ESP: 82e17f24 [35046.342789] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 [35046.348124] CR0: 8005003b CR2: 0010 CR3: 033c6000 CR4: 00102720 [35046.354397] DR0: DR1: 0001 DR2: 0002 DR3: 0003 [35046.360525] DR6: 0006 DR7: 0007 [35046.364299] Stack: [35046.366278] 828314a8 96822f80 82831490 82831490 82831490 a3161780 82831480 0018 [35046.373932] a7f06f80 a4c130d8 00020200 82e17f6c 8085f98d b1026880 8134b920 00020200 [35046.381593] 8134b920 82e17f9c 82e17f84 8085fbcf b1026880 00020200 ffea [35046.389259] Call Trace: [35046.391693] [<8085f98d>] create_new_namespaces+0x4d/0x160 [35046.397106] [<8085fbcf>] unshare_nsproxy_namespaces+0x5f/0xa0 [35046.402870] [<8083c7c4>] SyS_unshare+0x104/0x240 [35046.407518] [<80fe1700>] syscall_call+0x7/0xb Signed-off-by: Leon Ma --- fs/namespace.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/namespace.c b/fs/namespace.c index 1f4f9da..1c61c92 100644 --- a/fs/namespace.c +++ b/fs/namespace.c @@ -2788,7 +2788,7 @@ struct mnt_namespace *copy_mnt_ns(unsigned long flags, struct mnt_namespace *ns, q = next_mnt(q, new); if (!q) break; - while (p->mnt.mnt_root != q->mnt.mnt_root) + while (p && p->mnt.mnt_root != q->mnt.mnt_root) p = next_mnt(p, old); } namespace_unlock(); -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] move exit_task_work() before exit_fs().
We encountered following panic. The scenario is the process is exiting and executing its task work. When closing dev node, the driver triggers a firmware reload according to device status. Because task->fs is set to NULL in exit_fs(), panic happens. Task work is a common interface, we should not limite the resource the user will utilize. [ 118.521972] task: 880038de5cd0 ti: 880038e86000 task.ti: 880038e86000 [ 118.521977] RIP: 0010:[] [] path_init+0x336/0x440 [ 118.521986] RSP: :880038e876a0 EFLAGS: 00010246 [ 118.521991] RAX: RBX: 880038e87790 RCX: 0071 [ 118.521996] RDX: 88003f30f5d4 RSI: 82179f75 RDI: 8209b167 [ 118.522000] RBP: 880038e876e0 R08: 880038e87730 R09: 8800218b44c0 [ 118.522005] R10: R11: 000f R12: 880038ebf000 [ 118.522010] R13: 880038e87870 R14: 880038e87850 R15: ff9c [ 118.522015] FS: () GS:88003f30() knlGS: [ 118.522020] CS: 0010 DS: 002b ES: 002b CR0: 80050033 [ 118.522025] CR2: 0020 CR3: 39d4f000 CR4: 001007e0 [ 118.522030] DR0: DR1: DR2: [ 118.522035] DR3: DR6: 0ff0 DR7: 0400 [ 118.522039] Stack: [ 118.522043] 880038dbc300 880038e876b8 822cf046 88002e434f00 [ 118.522056] 880038e87790 880038e87870 880038e87850 ff9c [ 118.522069] 880038e87780 8217d419 88003b1de480 88003bbf7700 [ 118.522082] Call Trace: [ 118.522092] [] ? security_file_alloc+0x16/0x20 [ 118.522100] [] path_openat+0x69/0x4b0 [ 118.522109] [] ? is_connected_output_ep+0x15f/0x260 [ 118.522117] [] do_filp_open+0x39/0x90 [ 118.522125] [] ? string.isra.3+0x3a/0xe0 [ 118.522133] [] ? vsnprintf+0x209/0x620 [ 118.522141] [] file_open_name+0xb2/0xf0 [ 118.522148] [] filp_open+0x36/0x40 [ 118.522157] [] _request_firmware+0x351/0x9c0 [ 118.522164] [] request_firmware+0x16/0x20 [ 118.522172] [] sst_request_fw+0x63/0x510 [ 118.522180] [] ? __mutex_lock_slowpath+0x280/0x3b0 [ 118.522188] [] sst_load_fw+0x1f7/0x4a0 [ 118.522195] [] sst_download_fw+0xf/0x60 [ 118.522202] [] intel_sst_check_device+0x92/0x1f0 [ 118.522209] [] sst_set_generic_params+0x18d/0x500 [ 118.522218] [] sst_fill_and_send_cmd.constprop.7+0x95/0x130 [ 118.56] [] sst_send_gain_cmd+0x9d/0xe0 [ 118.522233] [] sst_set_pipe_gain+0x63/0xa0 [ 118.522241] [] sst_send_pipe_gains+0xd5/0x2b0 [ 118.522248] [] sst_media_digital_mute+0x46/0x80 [ 118.522257] [] snd_soc_dai_digital_mute+0x21/0x60 [ 118.522265] [] soc_pcm_close+0xbd/0x250 [ 118.522272] [] dpcm_fe_dai_close+0x7a/0x150 [ 118.522281] [] snd_pcm_release_substream+0x58/0xb0 [ 118.522289] [] snd_pcm_release+0x3f/0xa0// [ 118.522296] [] __fput+0xf0/0x240 [ 118.522304] [] fput+0xe/0x10 [ 118.522312] [] task_work_run+0xa5/0xd0 [ 118.522320] [] do_exit+0x2b8/0xad0 [ 118.522327] [] ? __schedule+0x3df/0x820 [ 118.522335] [] do_group_exit+0x3f/0xa0 [ 118.522343] [] get_signal_to_deliver+0x24e/0x650 [ 118.522352] [] do_signal+0x4d/0x960 [ 118.522360] [] ? hrtimer_start_range_ns+0x14/0x20 [ 118.522368] [] ? binder_ioctl+0x15d/0x990 [ 118.522377] [] do_notify_resume+0x65/0x80 [ 118.522384] [] int_signal+0x12/0x17 Signed-off-by: Leon Ma Signed-off-by: Zhang Di Signed-off-by: Sun Zhonghua --- kernel/exit.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/exit.c b/kernel/exit.c index 1ea4369..64ba13b 100644 --- a/kernel/exit.c +++ b/kernel/exit.c @@ -729,6 +729,8 @@ void do_exit(long code) tsk->exit_code = code; taskstats_exit(tsk, group_dead); + exit_files(tsk); + exit_task_work(tsk); exit_mm(tsk); if (group_dead) @@ -737,12 +739,10 @@ void do_exit(long code) exit_sem(tsk); exit_shm(tsk); - exit_files(tsk); exit_fs(tsk); if (group_dead) disassociate_ctty(1); exit_task_namespaces(tsk); - exit_task_work(tsk); exit_thread(); /* -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] rmap: validate pointer in anon_vma_clone
If memory allocation failed in first loop, root will be NULL and will lead to kernel panic. Signed-off-by: Leon Ma --- mm/rmap.c |6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/mm/rmap.c b/mm/rmap.c index 9c3e773..6e53aed 100644 --- a/mm/rmap.c +++ b/mm/rmap.c @@ -246,8 +246,10 @@ int anon_vma_clone(struct vm_area_struct *dst, struct vm_area_struct *src) avc = anon_vma_chain_alloc(GFP_NOWAIT | __GFP_NOWARN); if (unlikely(!avc)) { - unlock_anon_vma_root(root); - root = NULL; + if (!root) { + unlock_anon_vma_root(root); + root = NULL; + } avc = anon_vma_chain_alloc(GFP_KERNEL); if (!avc) goto enomem_failure; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:timers/urgent] hrtimer: Prevent remote enqueue of leftmost timers
Commit-ID: 012a45e3f4af68e86d85cce060c6c2fed56498b2 Gitweb: http://git.kernel.org/tip/012a45e3f4af68e86d85cce060c6c2fed56498b2 Author: Leon Ma AuthorDate: Wed, 30 Apr 2014 16:43:10 +0800 Committer: Thomas Gleixner CommitDate: Wed, 30 Apr 2014 12:34:51 +0200 hrtimer: Prevent remote enqueue of leftmost timers If a cpu is idle and starts an hrtimer which is not pinned on that same cpu, the nohz code might target the timer to a different cpu. In the case that we switch the cpu base of the timer we already have a sanity check in place, which determines whether the timer is earlier than the current leftmost timer on the target cpu. In that case we enqueue the timer on the current cpu because we cannot reprogram the clock event device on the target. If the timers base is already the target CPU we do not have this sanity check in place so we enqueue the timer as the leftmost timer in the target cpus rb tree, but we cannot reprogram the clock event device on the target cpu. So the timer expires late and subsequently prevents the reprogramming of the target cpu clock event device until the previously programmed event fires or a timer with an earlier expiry time gets enqueued on the target cpu itself. Add the same target check as we have for the switch base case and start the timer on the current cpu if it would become the leftmost timer on the target. [ tglx: Rewrote subject and changelog ] Signed-off-by: Leon Ma Link: http://lkml.kernel.org/r/1398847391-5994-1-git-send-email-xindong...@intel.com Cc: sta...@vger.kernel.org Signed-off-by: Thomas Gleixner --- kernel/hrtimer.c | 5 + 1 file changed, 5 insertions(+) diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c index e3724fd..6b715c0 100644 --- a/kernel/hrtimer.c +++ b/kernel/hrtimer.c @@ -234,6 +234,11 @@ again: goto again; } timer->base = new_base; + } else { + if (cpu != this_cpu && hrtimer_check_target(timer, new_base)) { + cpu = this_cpu; + goto again; + } } return new_base; } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] hrtimer:do not start hrtimer on other cpu if it is the leftmost timer.
On SMP system, if cpuX is idle and it starts an hrtimer, the timer will be started on cpuY. But it can not reprogram the event source on cpuY. The timer is inserted into rb tree of cpuY, if it is the leftmost timer on cpuY and it is a very short timer, following hrtimers started on cpuY will also not set the event source. As a result, the timers on cpuY will expire later than expected. When this case is detected, we should start the timer on cpuX and program event source properly. Signed-off-by: Leon Ma --- kernel/hrtimer.c |5 + 1 file changed, 5 insertions(+) diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c index d55092c..68becbc 100644 --- a/kernel/hrtimer.c +++ b/kernel/hrtimer.c @@ -234,6 +234,11 @@ again: goto again; } timer->base = new_base; + } else { + if (cpu != this_cpu && hrtimer_check_target(timer, new_base)) { + cpu = this_cpu; + goto again; + } } return new_base; } -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] LMK: Optimize lowmem_shrink
From: Leon Ma Date: Mon, 19 Aug 2013 14:22:38 +0800 Subject: [PATCH] LMK: Optimize lowmem_shrink. By comparing with selected_oom_score_adj instead of min_score_adj, we may do less calculation. Signed-off-by: Leon Ma --- drivers/staging/android/lowmemorykiller.c | 12 1 files changed, 4 insertions(+), 8 deletions(-) diff --git a/drivers/staging/android/lowmemorykiller.c b/drivers/staging/android/lowmemorykiller.c index f6c05c9..cb944c5 100644 --- a/drivers/staging/android/lowmemorykiller.c +++ b/drivers/staging/android/lowmemorykiller.c @@ -126,7 +126,7 @@ static int lowmem_shrink(struct shrinker *s, struct shrink_control *sc) return 0; } oom_score_adj = p->signal->oom_score_adj; - if (oom_score_adj < min_score_adj) { + if (oom_score_adj < selected_oom_score_adj) { task_unlock(p); continue; } @@ -134,13 +134,9 @@ static int lowmem_shrink(struct shrinker *s, struct shrink_control *sc) task_unlock(p); if (tasksize <= 0) continue; - if (selected) { - if (oom_score_adj < selected_oom_score_adj) - continue; - if (oom_score_adj == selected_oom_score_adj && - tasksize <= selected_tasksize) - continue; - } + if (selected && oom_score_adj == selected_oom_score_adj && + tasksize <= selected_tasksize) + continue; selected = p; selected_tasksize = tasksize; selected_oom_score_adj = oom_score_adj; -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Enable dumping running process stack.
From: Leon Ma Date: Fri, 16 Aug 2013 13:11:15 +0800 Subject: [PATCH] Enable dumping running process stack. Currently, if the process is running, we can not dump the stack via /proc//stack, because in __save_stack_address() it will return immediately if the address is not reliable. Sometimes one process would run into dead loop in kernel, it will facilitate debugging to have it's stack retrieved via procfs. Signed-off-by: Leon Ma --- arch/x86/kernel/dumpstack.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c index 1b81839..c892ceb 100644 --- a/arch/x86/kernel/dumpstack.c +++ b/arch/x86/kernel/dumpstack.c @@ -103,7 +103,10 @@ print_context_stack(struct thread_info *tinfo, frame = frame->next_frame; bp = (unsigned long) frame; } else { - ops->address(data, addr, 0); + if (tinfo->task->state == TASK_RUNNING) + ops->address(data, addr, 1); + else + ops->address(data, addr, 0); } print_ftrace_graph_addr(addr, data, ops, tinfo, graph); } -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] LMK: Optimize lowmem_shrink
From: Leon Ma Date: Mon, 19 Aug 2013 14:22:38 +0800 Subject: [PATCH] LMK: Optimize lowmem_shrink. By comparing with selected_oom_score_adj instead of min_score_adj, we may do less calculation. Signed-off-by: Leon Ma --- drivers/staging/android/lowmemorykiller.c | 12 1 files changed, 4 insertions(+), 8 deletions(-) diff --git a/drivers/staging/android/lowmemorykiller.c b/drivers/staging/android/lowmemorykiller.c index f6c05c9..cb944c5 100644 --- a/drivers/staging/android/lowmemorykiller.c +++ b/drivers/staging/android/lowmemorykiller.c @@ -126,7 +126,7 @@ static int lowmem_shrink(struct shrinker *s, struct shrink_control *sc) return 0; } oom_score_adj = p->signal->oom_score_adj; - if (oom_score_adj < min_score_adj) { + if (oom_score_adj < selected_oom_score_adj) { task_unlock(p); continue; } @@ -134,13 +134,9 @@ static int lowmem_shrink(struct shrinker *s, struct shrink_control *sc) task_unlock(p); if (tasksize <= 0) continue; - if (selected) { - if (oom_score_adj < selected_oom_score_adj) - continue; - if (oom_score_adj == selected_oom_score_adj && - tasksize <= selected_tasksize) - continue; - } + if (selected && oom_score_adj == selected_oom_score_adj && + tasksize <= selected_tasksize) + continue; selected = p; selected_tasksize = tasksize; selected_oom_score_adj = oom_score_adj; -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/