[PATCH] Validate pointer when copying mount namespace.

2015-04-28 Thread Leon Ma
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().

2014-12-25 Thread Leon Ma
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

2014-05-06 Thread Leon Ma
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

2014-04-30 Thread tip-bot for Leon Ma
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.

2014-04-30 Thread Leon Ma
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

2013-08-20 Thread Leon Ma
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.

2013-08-19 Thread Leon Ma
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

2013-08-19 Thread Leon Ma
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/