Re: [EDT][PATCH] kernel/exit.c : Fix missing read_unlock
EP-F6AA0618C49C4AEDA73BFF1B39950BAB
Hi Oleg,
Hi,
From: Maninder Singh maninder...@samsung.com
Subject: [PATCH 1/1] kernel/exit.c : Fix missing task_unlock
This patch adds missing read_unlock if do_wait_thread or ptrace_do_wait
returns non zero.
Confused...
wait_consider_task() should drop tasklist_lock if it returns non-zero?
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -1486,12 +1486,16 @@ repeat:
tsk = current;
do {
retval = do_wait_thread(wo, tsk);
-if (retval)
+if (retval) {
+read_unlock(tasklist_lock);
goto end;
+}
retval = ptrace_do_wait(wo, tsk);
-if (retval)
+if (retval) {
+read_unlock(tasklist_lock);
goto end;
+}
Well, the patch is obviously wrong. Because, again, tasklist_lock was
already unlocked if (say) wait_task_zombie() reaps a child.
Yes, agree, My wrong
If you think there is a case which forgets to unlock, please tell us
more.
I have checked It is getting unlocked in wait_task_zombie Sorry for unnecessary
disturbance.
Oleg.
Thanks
[EDT][PATCH] kernel/exit.c : Fix missing read_unlock
EP-F6AA0618C49C4AEDA73BFF1B39950BAB
Hi,
From: Maninder Singh
Subject: [PATCH 1/1] kernel/exit.c : Fix missing task_unlock
This patch adds missing read_unlock if do_wait_thread or ptrace_do_wait
returns non zero.
Signed-off-by: Maninder Singh
Signed-off-by: Vaneet Narang
Reviewd-by: Akhilesh Kumar
---
kernel/exit.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/kernel/exit.c b/kernel/exit.c
index 22fcc05..31a061f 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -1486,12 +1486,16 @@ repeat:
tsk = current;
do {
retval = do_wait_thread(wo, tsk);
- if (retval)
+ if (retval) {
+ read_unlock(_lock);
goto end;
+ }
retval = ptrace_do_wait(wo, tsk);
- if (retval)
+ if (retval) {
+ read_unlock(_lock);
goto end;
+ }
if (wo->wo_flags & __WNOTHREAD)
break;
--
1.7.1
Thanks
Maninder SinghN‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·¥Š{±‘êçzX§¶›¡Ü¨}©ž²Æ
zÚ:+v‰¨¾«‘êçzZ+€Ê+zf£¢·hšˆ§~††Ûiÿûàz¹ ®w¥¢¸?™¨èÚ&¢)ߢf”ù^jÇ«y§m…á@A«a¶Úÿ
0¶ìh®å’i
[EDT][PATCH] kernel/exit.c : Fix missing read_unlock
EP-F6AA0618C49C4AEDA73BFF1B39950BAB
Hi,
From: Maninder Singh maninder...@samsung.com
Subject: [PATCH 1/1] kernel/exit.c : Fix missing task_unlock
This patch adds missing read_unlock if do_wait_thread or ptrace_do_wait
returns non zero.
Signed-off-by: Maninder Singh maninder...@samsung.com
Signed-off-by: Vaneet Narang v.nar...@samsung.com
Reviewd-by: Akhilesh Kumar akhiles...@samsung.com
---
kernel/exit.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/kernel/exit.c b/kernel/exit.c
index 22fcc05..31a061f 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -1486,12 +1486,16 @@ repeat:
tsk = current;
do {
retval = do_wait_thread(wo, tsk);
- if (retval)
+ if (retval) {
+ read_unlock(tasklist_lock);
goto end;
+ }
retval = ptrace_do_wait(wo, tsk);
- if (retval)
+ if (retval) {
+ read_unlock(tasklist_lock);
goto end;
+ }
if (wo-wo_flags __WNOTHREAD)
break;
--
1.7.1
Thanks
Maninder SinghN‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·¥Š{±‘êçzX§¶›¡Ü¨}©ž²Æ
zÚj:+v‰¨¾«‘êçzZ+€Ê+zf£¢·hšˆ§~††Ûiÿûàz¹ ®w¥¢¸?™¨èÚ¢)ߢf”ù^jÇ«y§m…á@A«a¶Úÿ
0¶ìh®å’i
[EDT][PATCh 1/1]mdfld_dsi_pkg_sender.c : Fix Possible NULL Pointer dereference
EP-AA9D1F29B02341529D96C06444D8471D
Hi,
There is NULL pointer check for sender after dereferencing sender in
__read_panel_data as below:-
struct drm_device *dev = sender->dev;
...
if (!sender || !data || !len)
And from codeflow
mdfld_dsi_get_panel_status --> mdfld_dsi_read_mcs --> __read_panel_data
In mdfld_dsi_get_panel_status & mdfld_dsi_read_mcs there is already a same
check.
---Cut
if (!sender || !data || !len) {
DRM_ERROR("Invalid parameters\n");
return -EINVAL;
}
return __read_panel_data(sender, MIPI_DSI_DCS_READ, , 1,
data, len, hs);
Cut---
So either we can remove this check from __read_panel_data ,
or if we want to have defensive code then below change should be included.
Subject: [PATCH 1/1] mdfld_dsi_pkg_sender.c : Initialize dev struct after NULL
check of sender
Signed-off-by: Maninder Singh
Reviewed-By: Vaneet Narang
---
drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c
b/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c
index 6b43ae3..6f2b2c9 100644
--- a/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c
+++ b/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c
@@ -520,7 +520,7 @@ static int __read_panel_data(struct mdfld_dsi_pkg_sender
*sender, u8 data_type,
u8 *data, u16 len, u32 *data_out, u16 len_out, bool hs)
{
unsigned long flags;
- struct drm_device *dev = sender->dev;
+ struct drm_device *dev;
int i;
u32 gen_data_reg;
int retry = MDFLD_DSI_READ_MAX_COUNT;
@@ -530,6 +530,8 @@ static int __read_panel_data(struct mdfld_dsi_pkg_sender
*sender, u8 data_type,
return -EINVAL;
}
+ dev = sender->dev;
+
/**
* do reading.
* 0) send out generic read request
--
1.7.1
Thanks
Maninder
[EDT][PATCh 1/1]mdfld_dsi_pkg_sender.c : Fix Possible NULL Pointer dereference
EP-AA9D1F29B02341529D96C06444D8471D
Hi,
There is NULL pointer check for sender after dereferencing sender in
__read_panel_data as below:-
struct drm_device *dev = sender-dev;
...
if (!sender || !data || !len)
And from codeflow
mdfld_dsi_get_panel_status -- mdfld_dsi_read_mcs -- __read_panel_data
In mdfld_dsi_get_panel_status mdfld_dsi_read_mcs there is already a same
check.
---Cut
if (!sender || !data || !len) {
DRM_ERROR(Invalid parameters\n);
return -EINVAL;
}
return __read_panel_data(sender, MIPI_DSI_DCS_READ, cmd, 1,
data, len, hs);
Cut---
So either we can remove this check from __read_panel_data ,
or if we want to have defensive code then below change should be included.
Subject: [PATCH 1/1] mdfld_dsi_pkg_sender.c : Initialize dev struct after NULL
check of sender
Signed-off-by: Maninder Singh maninder...@samsung.com
Reviewed-By: Vaneet Narang v.nar...@samsung.com
---
drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c
b/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c
index 6b43ae3..6f2b2c9 100644
--- a/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c
+++ b/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c
@@ -520,7 +520,7 @@ static int __read_panel_data(struct mdfld_dsi_pkg_sender
*sender, u8 data_type,
u8 *data, u16 len, u32 *data_out, u16 len_out, bool hs)
{
unsigned long flags;
- struct drm_device *dev = sender-dev;
+ struct drm_device *dev;
int i;
u32 gen_data_reg;
int retry = MDFLD_DSI_READ_MAX_COUNT;
@@ -530,6 +530,8 @@ static int __read_panel_data(struct mdfld_dsi_pkg_sender
*sender, u8 data_type,
return -EINVAL;
}
+ dev = sender-dev;
+
/**
* do reading.
* 0) send out generic read request
--
1.7.1
Thanks
Maninder
[EDT][PATCH 1/1] dma/pl330.c : Initialize pl330 pointer after NULL check of pch pointer
EP-AA9D1F29B02341529D96C06444D8471D
Hi,
Subject: [PATCH 1/1] dma/pl330.c : Initialize pl330 pointer after NULL check of
pch pointer
Signed-off-by: Maninder Singh
Reviewed-By: Vaneet Narang
---
drivers/dma/pl330.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index a7d9d30..7e27144 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -2581,12 +2581,14 @@ pl330_prep_dma_memcpy(struct dma_chan *chan, dma_addr_t
dst,
{
struct dma_pl330_desc *desc;
struct dma_pl330_chan *pch = to_pchan(chan);
- struct pl330_dmac *pl330 = pch->dmac;
+ struct pl330_dmac *pl330;
int burst;
if (unlikely(!pch || !len))
return NULL;
+ pl330 = pch->dmac;
+
desc = __pl330_prep_dma_memcpy(pch, dst, src, len);
if (!desc)
return NULL;
--
1.7.1
Thanks
Maninder Singh
[EDT][PATCH 1/1] dma/pl330.c : Initialize pl330 pointer after NULL check of pch pointer
EP-AA9D1F29B02341529D96C06444D8471D
Hi,
Subject: [PATCH 1/1] dma/pl330.c : Initialize pl330 pointer after NULL check of
pch pointer
Signed-off-by: Maninder Singh maninder...@samsung.com
Reviewed-By: Vaneet Narang v.nar...@samsung.com
---
drivers/dma/pl330.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index a7d9d30..7e27144 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -2581,12 +2581,14 @@ pl330_prep_dma_memcpy(struct dma_chan *chan, dma_addr_t
dst,
{
struct dma_pl330_desc *desc;
struct dma_pl330_chan *pch = to_pchan(chan);
- struct pl330_dmac *pl330 = pch-dmac;
+ struct pl330_dmac *pl330;
int burst;
if (unlikely(!pch || !len))
return NULL;
+ pl330 = pch-dmac;
+
desc = __pl330_prep_dma_memcpy(pch, dst, src, len);
if (!desc)
return NULL;
--
1.7.1
Thanks
Maninder Singh
[EDT][PATCH 1/1] hw_breakpoint.c :cpu hotplug handling
EP-2DAD0AFA905A4ACB804C4F82A001242F
Subject: [PATCH 1/1] hw_breakpoint.c :cpu hotplug handling
This patch adds support for CPU hotplug, It re-installl all installed
watchpoints and breakpoints
back on H/W in case of cpu-hot plug.
Signed-off-by: Vaneet Narang
Signed-off-by: Maninder Singh
Reviewed-by: Amit Arora
Reviewed-by: Ajeet Yadav
---
arch/arm/kernel/hw_breakpoint.c | 56 +++
1 files changed, 56 insertions(+), 0 deletions(-)
diff --git a/arch/arm/kernel/hw_breakpoint.c b/arch/arm/kernel/hw_breakpoint.c
index dc7d0a9..172bfa8 100644
--- a/arch/arm/kernel/hw_breakpoint.c
+++ b/arch/arm/kernel/hw_breakpoint.c
@@ -388,6 +388,56 @@ int arch_install_hw_breakpoint(struct perf_event *bp)
return 0;
}
+/*
+ * reInstall a perf counter breakpoint.
+ */
+void arch_reinstall_hw_breakpoint(int index, int type)
+{
+ struct arch_hw_breakpoint *info;
+ struct perf_event **slots;
+ int ctrl_base, val_base;
+ u32 addr, ctrl;
+ struct perf_event *bp;
+
+ if (type == ARM_ENTRY_BREAKPOINT) {
+ /* Breakpoint */
+ ctrl_base = ARM_BASE_BCR;
+ val_base = ARM_BASE_BVR;
+ slots = (struct perf_event **)__get_cpu_var(bp_on_reg);
+ } else {
+ /* Watchpoint */
+ ctrl_base = ARM_BASE_WCR;
+ val_base = ARM_BASE_WVR;
+ slots = (struct perf_event **)__get_cpu_var(wp_on_reg);
+ }
+
+ bp = slots[index];
+ if (!bp)
+ return;
+
+ info = counter_arch_bp(bp);
+ addr = info->address;
+ ctrl = encode_ctrl_reg(info->ctrl) | 0x1;
+
+
+ /* Override the breakpoint data with the step data. */
+ if (info->step_ctrl.enabled) {
+ addr = info->trigger & ~0x3;
+ ctrl = encode_ctrl_reg(info->step_ctrl);
+ if (info->ctrl.type != ARM_BREAKPOINT_EXECUTE) {
+ index = 0;
+ ctrl_base = ARM_BASE_BCR + core_num_brps;
+ val_base = ARM_BASE_BVR + core_num_brps;
+ }
+ }
+
+ /* Setup the address register. */
+ write_wb_reg(val_base + index, addr);
+
+ /* Setup the control register. */
+ write_wb_reg(ctrl_base + index, ctrl);
+}
+
void arch_uninstall_hw_breakpoint(struct perf_event *bp)
{
struct arch_hw_breakpoint *info = counter_arch_bp(bp);
@@ -1019,6 +1069,12 @@ clear_vcr:
out_mdbgen:
if (enable_monitor_mode())
cpumask_or(_err_mask, _err_mask, cpumask_of(cpu));
+
+ for (i = 0; i < core_num_brps; ++i)
+ arch_reinstall_hw_breakpoint(i, ARM_ENTRY_BREAKPOINT);
+ for (i = 0; i < core_num_wrps; ++i)
+ arch_reinstall_hw_breakpoint(i, ARM_ENTRY_SYNC_WATCHPOINT);
+
}
static int dbg_reset_notify(struct notifier_block *self,
--
1.7.1
Thanks
Maninder SinghN‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·¥Š{±‘êçzX§¶›¡Ü¨}©ž²Æ
zÚ:+v‰¨¾«‘êçzZ+€Ê+zf£¢·hšˆ§~††Ûiÿûàz¹ ®w¥¢¸?™¨èÚ&¢)ߢf”ù^jÇ«y§m…á@A«a¶Úÿ
0¶ìh®å’i
[EDT] [PATCH 1/1] Fix: hw watchpoint continually triggers callback
EP-2DAD0AFA905A4ACB804C4F82A001242F
On ARM, when a watchpoint is registered using register_wide_hw_breakpoint,
the callback handler endlessly runs until the watchpoint is unregistered.
The reason for this issue is debug interrupts gets raised before executing the
instruction,
and after interrupt handling ARM tries to execute the same instruction again ,
which results
in interrupt getting raised again.
This patch fixes this issue by using KPROBES (getting the instruction executed
and incrementing PC
to next instruction).
Signed-off-by: Vaneet Narang
Signed-off-by: Maninder Singh
Reviewed-by: Amit Arora
Reviewed-by: Ajeet Yadav
---
arch/arm/kernel/hw_breakpoint.c | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/arch/arm/kernel/hw_breakpoint.c b/arch/arm/kernel/hw_breakpoint.c
index dc7d0a9..ec72f86 100644
--- a/arch/arm/kernel/hw_breakpoint.c
+++ b/arch/arm/kernel/hw_breakpoint.c
@@ -37,6 +37,9 @@
#include
#include
#include
+#ifdef CONFIG_KPROBES
+#include
+#endif
/* Breakpoint currently in use for each BRP. */
static DEFINE_PER_CPU(struct perf_event *, bp_on_reg[ARM_MAX_BRP]);
@@ -757,6 +760,21 @@ static void watchpoint_handler(unsigned long addr,
unsigned int fsr,
*/
if (!wp->overflow_handler)
enable_single_step(wp, instruction_pointer(regs));
+#ifdef CONFIG_KPROBES
+ else {
+ struct kprobe kp;
+ unsigned long flags;
+
+ arch_uninstall_hw_breakpoint(wp);
+ kp.addr = (kprobe_opcode_t *)instruction_pointer(regs);
+ if (!arch_prepare_kprobe()) {
+ local_irq_save(flags);
+ kp.ainsn.insn_singlestep(, regs);
+ local_irq_restore(flags);
+ }
+ arch_install_hw_breakpoint(wp);
+ }
+#endif
unlock:
rcu_read_unlock();
--
1.7.1
Thanks ,
Maninder SinghN‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·¥Š{±‘êçzX§¶›¡Ü¨}©ž²Æ
zÚ:+v‰¨¾«‘êçzZ+€Ê+zf£¢·hšˆ§~††Ûiÿûàz¹ ®w¥¢¸?™¨èÚ&¢)ߢf”ù^jÇ«y§m…á@A«a¶Úÿ
0¶ìh®å’i
[EDT] [PATCH 1/1] Fix: hw watchpoint continually triggers callback
EP-2DAD0AFA905A4ACB804C4F82A001242F
On ARM, when a watchpoint is registered using register_wide_hw_breakpoint,
the callback handler endlessly runs until the watchpoint is unregistered.
The reason for this issue is debug interrupts gets raised before executing the
instruction,
and after interrupt handling ARM tries to execute the same instruction again ,
which results
in interrupt getting raised again.
This patch fixes this issue by using KPROBES (getting the instruction executed
and incrementing PC
to next instruction).
Signed-off-by: Vaneet Narang v.nar...@samsung.com
Signed-off-by: Maninder Singh maninder...@samsung.com
Reviewed-by: Amit Arora amit.ar...@samsung.com
Reviewed-by: Ajeet Yadav ajee...@samsung.com
---
arch/arm/kernel/hw_breakpoint.c | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/arch/arm/kernel/hw_breakpoint.c b/arch/arm/kernel/hw_breakpoint.c
index dc7d0a9..ec72f86 100644
--- a/arch/arm/kernel/hw_breakpoint.c
+++ b/arch/arm/kernel/hw_breakpoint.c
@@ -37,6 +37,9 @@
#include asm/hw_breakpoint.h
#include asm/kdebug.h
#include asm/traps.h
+#ifdef CONFIG_KPROBES
+#include linux/kprobes.h
+#endif
/* Breakpoint currently in use for each BRP. */
static DEFINE_PER_CPU(struct perf_event *, bp_on_reg[ARM_MAX_BRP]);
@@ -757,6 +760,21 @@ static void watchpoint_handler(unsigned long addr,
unsigned int fsr,
*/
if (!wp-overflow_handler)
enable_single_step(wp, instruction_pointer(regs));
+#ifdef CONFIG_KPROBES
+ else {
+ struct kprobe kp;
+ unsigned long flags;
+
+ arch_uninstall_hw_breakpoint(wp);
+ kp.addr = (kprobe_opcode_t *)instruction_pointer(regs);
+ if (!arch_prepare_kprobe(kp)) {
+ local_irq_save(flags);
+ kp.ainsn.insn_singlestep(kp, regs);
+ local_irq_restore(flags);
+ }
+ arch_install_hw_breakpoint(wp);
+ }
+#endif
unlock:
rcu_read_unlock();
--
1.7.1
Thanks ,
Maninder SinghN‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·¥Š{±‘êçzX§¶›¡Ü¨}©ž²Æ
zÚj:+v‰¨¾«‘êçzZ+€Ê+zf£¢·hšˆ§~††Ûiÿûàz¹ ®w¥¢¸?™¨èÚ¢)ߢf”ù^jÇ«y§m…á@A«a¶Úÿ
0¶ìh®å’i
[EDT][PATCH 1/1] hw_breakpoint.c :cpu hotplug handling
EP-2DAD0AFA905A4ACB804C4F82A001242F
Subject: [PATCH 1/1] hw_breakpoint.c :cpu hotplug handling
This patch adds support for CPU hotplug, It re-installl all installed
watchpoints and breakpoints
back on H/W in case of cpu-hot plug.
Signed-off-by: Vaneet Narang v.nar...@samsung.com
Signed-off-by: Maninder Singh maninder...@samsung.com
Reviewed-by: Amit Arora amit.ar...@samsung.com
Reviewed-by: Ajeet Yadav ajee...@samsung.com
---
arch/arm/kernel/hw_breakpoint.c | 56 +++
1 files changed, 56 insertions(+), 0 deletions(-)
diff --git a/arch/arm/kernel/hw_breakpoint.c b/arch/arm/kernel/hw_breakpoint.c
index dc7d0a9..172bfa8 100644
--- a/arch/arm/kernel/hw_breakpoint.c
+++ b/arch/arm/kernel/hw_breakpoint.c
@@ -388,6 +388,56 @@ int arch_install_hw_breakpoint(struct perf_event *bp)
return 0;
}
+/*
+ * reInstall a perf counter breakpoint.
+ */
+void arch_reinstall_hw_breakpoint(int index, int type)
+{
+ struct arch_hw_breakpoint *info;
+ struct perf_event **slots;
+ int ctrl_base, val_base;
+ u32 addr, ctrl;
+ struct perf_event *bp;
+
+ if (type == ARM_ENTRY_BREAKPOINT) {
+ /* Breakpoint */
+ ctrl_base = ARM_BASE_BCR;
+ val_base = ARM_BASE_BVR;
+ slots = (struct perf_event **)__get_cpu_var(bp_on_reg);
+ } else {
+ /* Watchpoint */
+ ctrl_base = ARM_BASE_WCR;
+ val_base = ARM_BASE_WVR;
+ slots = (struct perf_event **)__get_cpu_var(wp_on_reg);
+ }
+
+ bp = slots[index];
+ if (!bp)
+ return;
+
+ info = counter_arch_bp(bp);
+ addr = info-address;
+ ctrl = encode_ctrl_reg(info-ctrl) | 0x1;
+
+
+ /* Override the breakpoint data with the step data. */
+ if (info-step_ctrl.enabled) {
+ addr = info-trigger ~0x3;
+ ctrl = encode_ctrl_reg(info-step_ctrl);
+ if (info-ctrl.type != ARM_BREAKPOINT_EXECUTE) {
+ index = 0;
+ ctrl_base = ARM_BASE_BCR + core_num_brps;
+ val_base = ARM_BASE_BVR + core_num_brps;
+ }
+ }
+
+ /* Setup the address register. */
+ write_wb_reg(val_base + index, addr);
+
+ /* Setup the control register. */
+ write_wb_reg(ctrl_base + index, ctrl);
+}
+
void arch_uninstall_hw_breakpoint(struct perf_event *bp)
{
struct arch_hw_breakpoint *info = counter_arch_bp(bp);
@@ -1019,6 +1069,12 @@ clear_vcr:
out_mdbgen:
if (enable_monitor_mode())
cpumask_or(debug_err_mask, debug_err_mask, cpumask_of(cpu));
+
+ for (i = 0; i core_num_brps; ++i)
+ arch_reinstall_hw_breakpoint(i, ARM_ENTRY_BREAKPOINT);
+ for (i = 0; i core_num_wrps; ++i)
+ arch_reinstall_hw_breakpoint(i, ARM_ENTRY_SYNC_WATCHPOINT);
+
}
static int dbg_reset_notify(struct notifier_block *self,
--
1.7.1
Thanks
Maninder SinghN‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·¥Š{±‘êçzX§¶›¡Ü¨}©ž²Æ
zÚj:+v‰¨¾«‘êçzZ+€Ê+zf£¢·hšˆ§~††Ûiÿûàz¹ ®w¥¢¸?™¨èÚ¢)ߢf”ù^jÇ«y§m…á@A«a¶Úÿ
0¶ìh®å’i
Re: [EDT][PATCH 1/1] msgsnd use freezable blocking call
EP-F6AA0618C49C4AEDA73BFF1B39950BAB >On Wed, 06 May 2015 11:29:57 + (GMT) Maninder Singh wrote: >> EP-F6AA0618C49C4AEDA73BFF1B39950BAB >> >> Hi , >> >> Recently shared a patch for using freezable_schedule instead of schedule in >> msgrcv, >> and after analysing message queuie implemntation we have realized even >> msgsnd can also block, if queue is full, >> So in this scenerio msgsnd sets task state as TASK_INTERRUPTIBLE and can >> schedule function, similar behaviour as msgrcv. >> This change is applicable for msgsnd as well. >> >> we have created patch for remotes/linux-next/akpm, because msgrcv patch is >> already applied at this branch. .> so we didnt include >> >This changelog is quite poor. It doesn't explain why the change is >being made, it doesn't explain the user-visible effects which are being >fixed, etc. >So I threw it away and copied text from "ipc/msg.c: use freezable >blocking call": >One thing which isn't clear to me: *why* do we want to "Avoid waking up >every thread sleeping in XXX during suspend and resume"? Suspend and >resume are rare operations. Why do we care if a few threads wake up >then go to sleep again? When any task is stuck in Interruptible or Uninterruptible state then waking up of that task fails. If wakeup fails, then suspend operation fails and all process send to frezeer state at this moment also gets wakeup. Correct implementation is that if suspend fails, then kernel would retry suspend operation again after some specific timeinterval for some fixed retry count. But as changes suggested by Mr Colin Cross on LKML https://lkml.org/lkml/2013/5/1/424, for the system calls for which issue has been faced process flag being appended with PF_FREEZER_SKIP. we are testing some scenerio in which we have to do multi suspend-resume scenario, and we faced the problem thats why suggested the change for msgsnd and msgrcv Signed-off-by: Vaneet narang Signed-off-by: Maninder Singh Cc: Yogesh Gaur Cc: Manjeet Pawar Cc: Ajeet Yadav Cc: Peter Zijlstra Cc: Tejun Heo Signed-off-by: Andrew Morton --- ipc/msg.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -puN ipc/msg.c~ipc-msgc-msgsnd-use-freezable-blocking-call ipc/msg.c --- a/ipc/msg.c~ipc-msgc-msgsnd-use-freezable-blocking-call +++ a/ipc/msg.c @@ -673,7 +673,7 @@ long do_msgsnd(int msqid, long mtype, vo ipc_unlock_object(>q_perm); rcu_read_unlock(); - schedule(); + freezable_schedule(); rcu_read_lock(); ipc_lock_object(>q_perm); _
Re: [EDT][PATCH 1/1] msgsnd use freezable blocking call
EP-F6AA0618C49C4AEDA73BFF1B39950BAB On Wed, 06 May 2015 11:29:57 + (GMT) Maninder Singh wrote: EP-F6AA0618C49C4AEDA73BFF1B39950BAB Hi , Recently shared a patch for using freezable_schedule instead of schedule in msgrcv, and after analysing message queuie implemntation we have realized even msgsnd can also block, if queue is full, So in this scenerio msgsnd sets task state as TASK_INTERRUPTIBLE and can schedule function, similar behaviour as msgrcv. This change is applicable for msgsnd as well. we have created patch for remotes/linux-next/akpm, because msgrcv patch is already applied at this branch. . so we didnt include This changelog is quite poor. It doesn't explain why the change is being made, it doesn't explain the user-visible effects which are being fixed, etc. So I threw it away and copied text from ipc/msg.c: use freezable blocking call: One thing which isn't clear to me: *why* do we want to Avoid waking up every thread sleeping in XXX during suspend and resume? Suspend and resume are rare operations. Why do we care if a few threads wake up then go to sleep again? When any task is stuck in Interruptible or Uninterruptible state then waking up of that task fails. If wakeup fails, then suspend operation fails and all process send to frezeer state at this moment also gets wakeup. Correct implementation is that if suspend fails, then kernel would retry suspend operation again after some specific timeinterval for some fixed retry count. But as changes suggested by Mr Colin Cross on LKML https://lkml.org/lkml/2013/5/1/424, for the system calls for which issue has been faced process flag being appended with PF_FREEZER_SKIP. we are testing some scenerio in which we have to do multi suspend-resume scenario, and we faced the problem thats why suggested the change for msgsnd and msgrcv Signed-off-by: Vaneet narang v.nar...@samsung.com Signed-off-by: Maninder Singh maninder...@samsung.com Cc: Yogesh Gaur yn.g...@samsung.com Cc: Manjeet Pawar manjee...@samsung.com Cc: Ajeet Yadav ajee...@samsung.com Cc: Peter Zijlstra a.p.zijls...@chello.nl Cc: Tejun Heo t...@kernel.org Signed-off-by: Andrew Morton a...@linux-foundation.org --- ipc/msg.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -puN ipc/msg.c~ipc-msgc-msgsnd-use-freezable-blocking-call ipc/msg.c --- a/ipc/msg.c~ipc-msgc-msgsnd-use-freezable-blocking-call +++ a/ipc/msg.c @@ -673,7 +673,7 @@ long do_msgsnd(int msqid, long mtype, vo ipc_unlock_object(msq-q_perm); rcu_read_unlock(); - schedule(); + freezable_schedule(); rcu_read_lock(); ipc_lock_object(msq-q_perm); _
[EDT][Patch 1/1] socket family check in netlabel APIs
EP-E68D5E24548545C9BBB607A98ADD61E6
Hi Paul,
>On Monday, March 30, 2015 11:09:00 AM Maninder Singh wrote:
>> Dear All,
>> we found One Kernel Crash issue in cipso_v4_sock_delattr :-
>> As Cipso supports only inet sockets so cipso_v4_sock_delattr will crash when
>> try to access any other socket type. cipso_v4_sock_delattr access
>> sk_inet->inet_opt which may contain not NULL but invalid address. we found
>> this issue with netlink socket.(reproducible by trinity using sendto system
>> call .)
>Hello,
>First, please go read the Documentation/SubmittingPatches from the kernel
>sources; your patch needs to be resubmitted and the instructions in that file
>will show you how to do it correctly next time.
>Second, this appears to only affect Smack based systems, yes? SELinux based
>systems should have the proper checking in place to prevent this (the checks
>are handled in the LSM). That said, it probably wouldn't hurt to add the
>extra checking to netlbl_sock_delattr(). If you properly resubmit your patch
>I'll ACK it.
>-Paul
>--
>paul moore
>www.paul-moore.com
As suggested resubmitting the patch .
Subject : socket family check in netlabel APIs
Adding check for socket family in netlbl_sock_delattr and netlbl_req_delattr as
check present
in netlbl_sock_setattr and netlbl_req_setattr respectively.
as we faced crash in cipso_v4_sock_delattr due to other socket type.
Crash Logs :
[0-182.2400] [] (cipso_v4_sock_delattr+0x0/0x74) from []
(netlbl_sock_delattr+0x18/0x1c)
[0-182.2497] r4: r3:c07872f8
[0-182.2531] [] (netlbl_sock_delattr+0x0/0x1c) from []
(smack_netlabel+0x88/0x9c)
[0-182.2622] [] (smack_netlabel+0x0/0x9c) from []
(smack_netlabel_send+0x12c/0x144)
[0-182.2714] r7 9ce9500 r6 7b67ef4 r5:c076f408 r4 8903dc0
[0-182.2770] [] (smack_netlabel_send+0x0/0x144) from []
(smack_socket_sendmsg+0x54/0x60)
[0-182.2866] [] (smack_socket_sendmsg+0x0/0x60) from []
(security_socket_sendmsg+0x28/0x2c)
[0-182.2966] [] (security_socket_sendmsg+0x0/0x2c) from []
(sock_sendmsg+0x68/0xc0)
[0-182.3058] [] (sock_sendmsg+0x0/0xc0) from []
(SyS_sendto+0xd8/0x110)
Signed-off-by: Vaneet Narang
Signed-off-by: Maninder Singh
Reviewed-by : Ajeet Yadav
---
net/netlabel/netlabel_kapi.c | 16 ++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/net/netlabel/netlabel_kapi.c b/net/netlabel/netlabel_kapi.c
index 28cddc8..606a5ce 100644
--- a/net/netlabel/netlabel_kapi.c
+++ b/net/netlabel/netlabel_kapi.c
@@ -824,7 +824,13 @@ socket_setattr_return:
*/
void netlbl_sock_delattr(struct sock *sk)
{
- cipso_v4_sock_delattr(sk);
+ switch (sk->sk_family) {
+ case AF_INET:
+ cipso_v4_sock_delattr(sk);
+ break;
+ default:
+ }
+ return;
}
/**
@@ -987,7 +993,13 @@ req_setattr_return:
*/
void netlbl_req_delattr(struct request_sock *req)
{
- cipso_v4_req_delattr(req);
+ switch (req->rsk_ops->family) {
+ case AF_INET:
+ cipso_v4_req_delattr(req);
+ break;
+ default:
+ }
+ return;
}
/**
--
1.7.1
[EDT][PATCH 1/1] msgsnd use freezable blocking call
EP-F6AA0618C49C4AEDA73BFF1B39950BAB Hi , Recently shared a patch for using freezable_schedule instead of schedule in msgrcv, and after analysing message queuie implemntation we have realized even msgsnd can also block, if queue is full, So in this scenerio msgsnd sets task state as TASK_INTERRUPTIBLE and can schedule function, similar behaviour as msgrcv. This change is applicable for msgsnd as well. we have created patch for remotes/linux-next/akpm, because msgrcv patch is already applied at this branch. so we didnt include Signed-off-by: Vaneet narang Signed-off-by: Maninder Singh --- ipc/msg.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/ipc/msg.c b/ipc/msg.c index a7261d5..da5658e 100644 --- a/ipc/msg.c +++ b/ipc/msg.c @@ -674,7 +674,7 @@ long do_msgsnd(int msqid, long mtype, void __user *mtext, ipc_unlock_object(>q_perm); rcu_read_unlock(); - schedule(); + freezable_schedule(); rcu_read_lock(); ipc_lock_object(>q_perm); -- 1.7.1 Thanks and Regards, Maninder Singh
[EDT][PATCH 1/1] msgsnd use freezable blocking call
EP-F6AA0618C49C4AEDA73BFF1B39950BAB Hi , Recently shared a patch for using freezable_schedule instead of schedule in msgrcv, and after analysing message queuie implemntation we have realized even msgsnd can also block, if queue is full, So in this scenerio msgsnd sets task state as TASK_INTERRUPTIBLE and can schedule function, similar behaviour as msgrcv. This change is applicable for msgsnd as well. we have created patch for remotes/linux-next/akpm, because msgrcv patch is already applied at this branch. so we didnt include linux/freezer.h Signed-off-by: Vaneet narang v.nar...@samsung.com Signed-off-by: Maninder Singh maninder...@samsung.com --- ipc/msg.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/ipc/msg.c b/ipc/msg.c index a7261d5..da5658e 100644 --- a/ipc/msg.c +++ b/ipc/msg.c @@ -674,7 +674,7 @@ long do_msgsnd(int msqid, long mtype, void __user *mtext, ipc_unlock_object(msq-q_perm); rcu_read_unlock(); - schedule(); + freezable_schedule(); rcu_read_lock(); ipc_lock_object(msq-q_perm); -- 1.7.1 Thanks and Regards, Maninder Singh
[EDT][Patch 1/1] socket family check in netlabel APIs
EP-E68D5E24548545C9BBB607A98ADD61E6
Hi Paul,
On Monday, March 30, 2015 11:09:00 AM Maninder Singh wrote:
Dear All,
we found One Kernel Crash issue in cipso_v4_sock_delattr :-
As Cipso supports only inet sockets so cipso_v4_sock_delattr will crash when
try to access any other socket type. cipso_v4_sock_delattr access
sk_inet-inet_opt which may contain not NULL but invalid address. we found
this issue with netlink socket.(reproducible by trinity using sendto system
call .)
Hello,
First, please go read the Documentation/SubmittingPatches from the kernel
sources; your patch needs to be resubmitted and the instructions in that file
will show you how to do it correctly next time.
Second, this appears to only affect Smack based systems, yes? SELinux based
systems should have the proper checking in place to prevent this (the checks
are handled in the LSM). That said, it probably wouldn't hurt to add the
extra checking to netlbl_sock_delattr(). If you properly resubmit your patch
I'll ACK it.
-Paul
--
paul moore
www.paul-moore.com
As suggested resubmitting the patch .
Subject : socket family check in netlabel APIs
Adding check for socket family in netlbl_sock_delattr and netlbl_req_delattr as
check present
in netlbl_sock_setattr and netlbl_req_setattr respectively.
as we faced crash in cipso_v4_sock_delattr due to other socket type.
Crash Logs :
[0-182.2400] [c04c7fa4] (cipso_v4_sock_delattr+0x0/0x74) from [c0517b64]
(netlbl_sock_delattr+0x18/0x1c)
[0-182.2497] r4: r3:c07872f8
[0-182.2531] [c0517b4c] (netlbl_sock_delattr+0x0/0x1c) from [c027b2fc]
(smack_netlabel+0x88/0x9c)
[0-182.2622] [c027b274] (smack_netlabel+0x0/0x9c) from [c027b43c]
(smack_netlabel_send+0x12c/0x144)
[0-182.2714] r7 9ce9500 r6 7b67ef4 r5:c076f408 r4 8903dc0
[0-182.2770] [c027b310] (smack_netlabel_send+0x0/0x144) from [c027b4a8]
(smack_socket_sendmsg+0x54/0x60)
[0-182.2866] [c027b454] (smack_socket_sendmsg+0x0/0x60) from [c02789ec]
(security_socket_sendmsg+0x28/0x2c)
[0-182.2966] [c02789c4] (security_socket_sendmsg+0x0/0x2c) from [c04343b0]
(sock_sendmsg+0x68/0xc0)
[0-182.3058] [c0434348] (sock_sendmsg+0x0/0xc0) from [c04369e8]
(SyS_sendto+0xd8/0x110)
Signed-off-by: Vaneet Narang v.nar...@samsung.com
Signed-off-by: Maninder Singh maninder...@samsung.com
Reviewed-by : Ajeet Yadav ajee...@samsung.com
---
net/netlabel/netlabel_kapi.c | 16 ++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/net/netlabel/netlabel_kapi.c b/net/netlabel/netlabel_kapi.c
index 28cddc8..606a5ce 100644
--- a/net/netlabel/netlabel_kapi.c
+++ b/net/netlabel/netlabel_kapi.c
@@ -824,7 +824,13 @@ socket_setattr_return:
*/
void netlbl_sock_delattr(struct sock *sk)
{
- cipso_v4_sock_delattr(sk);
+ switch (sk-sk_family) {
+ case AF_INET:
+ cipso_v4_sock_delattr(sk);
+ break;
+ default:
+ }
+ return;
}
/**
@@ -987,7 +993,13 @@ req_setattr_return:
*/
void netlbl_req_delattr(struct request_sock *req)
{
- cipso_v4_req_delattr(req);
+ switch (req-rsk_ops-family) {
+ case AF_INET:
+ cipso_v4_req_delattr(req);
+ break;
+ default:
+ }
+ return;
}
/**
--
1.7.1
Re: msgrcv: use freezable blocking call
Hi Andrew, Both patches looks fine to us. Thank You > On Wed, Apr 01, 2015 at 05:18:46AM +0000, Maninder Singh wrote: > > Hi Andrew, > > Thanks for making new patch, Actually there is some problem with our mail > > editor. > > It changes tabs with spaces and corrupts the patch, we are solving the same > > at our end. > > Thats why i am sending you signed -off by only for both patches. > > Sort it and resend, no real great hurry with these patches, right? I tend not to bother too much about occasional messy patches. These ones appear to be be the first patches from these contributors and fixing them up only takes a couple of minutes. If Maninder's team expects to send more patches in the future then yes, please fix this stuff. But for now, the important thing is to get these kernel problems sorted out. > > 1. For msgrcv: use freezable blocking call > > Signed-off-by: Yogesh Gaur > > Signed-off-by: Maninder Singh > > Signed-off-by: Manjeet Pawar > > Did you really pass around that patch through 3 people or did it take > all three of you to modify those two lines? > > Should some of those SoBs be a reviewed-by perhaps? > > > > > For Peter's Review comment:- This is what, no why mentioned > > > > This call was selected to be converted to a freezable call because > > it doesn't hold any locks or release any resources when interrupted > > that might be needed by another freezing task or a kernel driver > > during suspend, and is a common site where idle userspace tasks are > > blocked. > > Please put such things in the Changelog so that we can see you've > thought about things. I have made that change. Maninder, we currently have yourself as the primary author of "restart_syscall: use freezable blocking call". Is that correct, or should that be Yogesh Gaur? --> It is correct Below are my latest copies of these two patches. How do they look? -- > Looks fine, Thnaks for making patches. From: Yogesh Gaur Subject: ipc/msg.c: use freezable blocking call Avoid waking up every thread sleeping in a msgrcv call during suspend and resume by calling a freezable blocking call. Previous patches modified the freezer to avoid sending wakeups to threads that are blocked in freezable blocking calls. Ref: https://lkml.org/lkml/2013/5/1/424 Backtrace: [] (__schedule+0x0/0x5d8) from [] (schedule+0x8c/0x90) [] (schedule+0x0/0x90) from [] (do_msgrcv+0x2e0/0x368) [] (do_msgrcv+0x0/0x368) from [] (SyS_msgrcv+0x2c/0x38) [] (SyS_msgrcv+0x0/0x38) from [] (ret_fast_syscall+0x0/0x48) tPlay0Cb2 R running 0 297204 0x0001 This call was selected to be converted to a freezable call because it doesn't hold any locks or release any resources when interrupted that might be needed by another freezing task or a kernel driver during suspend, and is a common site where idle userspace tasks are blocked. Signed-off-by: Yogesh Gaur Signed-off-by: Manjeet Pawar Signed-off-by: Maninder Singh Reviewed-by : Ajeet Yadav Cc: Peter Zijlstra Cc: Tejun Heo Signed-off-by: Andrew Morton --- ipc/msg.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff -puN ipc/msg.c~msgrcv-use-freezable-blocking-call ipc/msg.c --- a/ipc/msg.c~msgrcv-use-freezable-blocking-call +++ a/ipc/msg.c @@ -37,6 +37,7 @@ #include #include #include +#include #include #include @@ -915,7 +916,7 @@ long do_msgrcv(int msqid, void __user *b ipc_unlock_object(>q_perm); rcu_read_unlock(); - schedule(); + freezable_schedule(); /* Lockless receive, part 1: * Disable preemption. We don't hold a reference to the queue _ From: Maninder Singh Subject: kernel/time/hrtimer.c: restart_syscall: use freezable blocking call Avoid waking up every thread sleeping in a restart_syscall call during suspend and resume by calling a freezable blocking call. Previous patches modified the freezer to avoid sending wakeups to threads that are blocked in freezable blocking calls. Ref: https://lkml.org/lkml/2013/5/1/424 Backtrace: [] (__schedule+0x0/0x5d8) from [] (schedule+0x8c/0x90) [] (schedule+0x0/0x90) from [] (schedule_hrtimeout_range_clock+0xdc/0x110) [] (schedule_hrtimeout_range_clock+0x0/0x110) from [] (schedule_hrtimeout_range+0x1c/0x20) r9:d16c9be0 r8:8b7d9c2c r7: r6: r5:d16c8028 [] (schedule_hrtimeout_range+0x0/0x20) from [] (poll_schedule_timeout+0x48/0x6c) [] (poll_schedule_timeout+0x0/0x6c) from [] (do_sys_poll+0x2c8/0x378) r5:d16c9f78 r4: [] (do_sys_poll+0x0/0x378) from [] (do_restart_poll+0x40/0x5c) [] (do_restart_poll+0x0/0x5c) from [] (sys_restart_syscall+0x2c/0x30) r4:fe7a [] (sys_restart_syscall+0x0/0x30) from [] (ret_fast_syscall+0x0/0x48) This call was selected to be converted to a freezable call because i
Re: Re: [Fix kernel crash in cipso_v4_sock_delattr ]
We have run trinity tool on smack enable system. like below:- #./trinity -c sendto --dangerous After some time we are able to crash the kernel:- [] (cipso_v4_sock_delattr+0x0/0x74) from [] (netlbl_sock_delattr+0x18/0x1c) r4: r3:c07872f8 [] (netlbl_sock_delattr+0x0/0x1c) from [] (smack_netlabel+0x88/0x9c) [] (smack_netlabel+0x0/0x9c) from [] (smack_netlabel_send+0x12c/0x144) r7:d9cee3c0 r6:d7b01ef4 r5:c076f408 r4:d88c84c0 [] (smack_netlabel_send+0x0/0x144) from [] (smack_socket_sendmsg+0x54/0x60) [] (smack_socket_sendmsg+0x0/0x60) from [] (security_socket_sendmsg+0x28/0x2c) [] (security_socket_sendmsg+0x0/0x2c) from [] (sock_sendmsg+0x68/0xc0) [] (sock_sendmsg+0x0/0xc0) from [] (SyS_sendto+0xd8/0x110) r7:01400118 r6:007f r5:da308a00 r4:c076f408 [] (SyS_sendto+0x0/0x110) from [] (ret_fast_syscall+0x0/0x48) Code: e5903200 e1a04000 e353 089da818 (e5d33016) [SELP] while loop ... please attach T32... And after further debugging we find this crash always come with Netlink socket. And except thi API "netlbl_sock_delattr" all other related Netlabel APIs have check to validate socket family. Thats why we added socket family check for this API "netlbl_sock_delattr" and resolves our issue. Thanks Maninder Singh On 3/30/2015 10:09 PM, Maninder Singh wrote: > We are currently using 3.10.58 kernel and we are facing this issue for samck > enabled system. > and as we can check in other APIs like netlbl_sock_getattr and > netlbl_conn_setattr have this preventive check so we added this check for > netlbl_sock_delattr also. > > And regarding patch re-submission, actually we have run checkpatch.pl before > submission(successfull) But when we submit the patch our editor changes tabs > into space, we will resubmitt the patch ASAP. Further review shows that the Smack code in 3.10.72 (I don't believe it changed after 3.10.58) already checks for the address family being AF_INET. This would indicate that the netlink code is sending garbage to security_socket_sendmsg(). Can you provide a more specific test case? I would like to see if this problem is present in newer kernels. > > Maninder Singh > --- Original Message --- > Sender : Casey Schaufler > Date : Mar 31, 2015 02:25 (GMT+09:00) > Title : Re: [Fix kernel crash in cipso_v4_sock_delattr ] > > On 3/30/2015 4:32 AM, Paul Moore wrote: >> On Monday, March 30, 2015 11:09:00 AM Maninder Singh wrote: >>> Dear All, >>> we found One Kernel Crash issue in cipso_v4_sock_delattr :- >>> As Cipso supports only inet sockets so cipso_v4_sock_delattr will crash when >>> try to access any other socket type. cipso_v4_sock_delattr access >>> sk_inet->inet_opt which may contain not NULL but invalid address. we found >>> this issue with netlink socket.(reproducible by trinity using sendto system >>> call .) >> Hello, >> >> First, please go read the Documentation/SubmittingPatches from the kernel >> sources; your patch needs to be resubmitted and the instructions in that >> file >> will show you how to do it correctly next time. >> >> Second, this appears to only affect Smack based systems, yes? SELinux based >> systems should have the proper checking in place to prevent this (the checks >> are handled in the LSM). > This looks like a problem that was fixed some time ago. > The current Smack code clearly checks for this. What kernel > version are you testing against? > >> That said, it probably wouldn't hurt to add the >> extra checking to netlbl_sock_delattr(). If you properly resubmit your >> patch >> I'll ACK it. >> >> -Paul
Re: Re: [Fix kernel crash in cipso_v4_sock_delattr ]
We have run trinity tool on smack enable system. like below:- #./trinity -c sendto --dangerous After some time we are able to crash the kernel:- [c04c8084] (cipso_v4_sock_delattr+0x0/0x74) from [c0517c44] (netlbl_sock_delattr+0x18/0x1c) r4: r3:c07872f8 [c0517c2c] (netlbl_sock_delattr+0x0/0x1c) from [c027b3e0] (smack_netlabel+0x88/0x9c) [c027b358] (smack_netlabel+0x0/0x9c) from [c027b520] (smack_netlabel_send+0x12c/0x144) r7:d9cee3c0 r6:d7b01ef4 r5:c076f408 r4:d88c84c0 [c027b3f4] (smack_netlabel_send+0x0/0x144) from [c027b58c] (smack_socket_sendmsg+0x54/0x60) [c027b538] (smack_socket_sendmsg+0x0/0x60) from [c0278ad0] (security_socket_sendmsg+0x28/0x2c) [c0278aa8] (security_socket_sendmsg+0x0/0x2c) from [c0434490] (sock_sendmsg+0x68/0xc0) [c0434428] (sock_sendmsg+0x0/0xc0) from [c0436ac8] (SyS_sendto+0xd8/0x110) r7:01400118 r6:007f r5:da308a00 r4:c076f408 [c04369f0] (SyS_sendto+0x0/0x110) from [c0012280] (ret_fast_syscall+0x0/0x48) Code: e5903200 e1a04000 e353 089da818 (e5d33016) [SELP] while loop ... please attach T32... And after further debugging we find this crash always come with Netlink socket. And except thi API netlbl_sock_delattr all other related Netlabel APIs have check to validate socket family. Thats why we added socket family check for this API netlbl_sock_delattr and resolves our issue. Thanks Maninder Singh On 3/30/2015 10:09 PM, Maninder Singh wrote: We are currently using 3.10.58 kernel and we are facing this issue for samck enabled system. and as we can check in other APIs like netlbl_sock_getattr and netlbl_conn_setattr have this preventive check so we added this check for netlbl_sock_delattr also. And regarding patch re-submission, actually we have run checkpatch.pl before submission(successfull) But when we submit the patch our editor changes tabs into space, we will resubmitt the patch ASAP. Further review shows that the Smack code in 3.10.72 (I don't believe it changed after 3.10.58) already checks for the address family being AF_INET. This would indicate that the netlink code is sending garbage to security_socket_sendmsg(). Can you provide a more specific test case? I would like to see if this problem is present in newer kernels. Maninder Singh --- Original Message --- Sender : Casey Schaufler Date : Mar 31, 2015 02:25 (GMT+09:00) Title : Re: [Fix kernel crash in cipso_v4_sock_delattr ] On 3/30/2015 4:32 AM, Paul Moore wrote: On Monday, March 30, 2015 11:09:00 AM Maninder Singh wrote: Dear All, we found One Kernel Crash issue in cipso_v4_sock_delattr :- As Cipso supports only inet sockets so cipso_v4_sock_delattr will crash when try to access any other socket type. cipso_v4_sock_delattr access sk_inet-inet_opt which may contain not NULL but invalid address. we found this issue with netlink socket.(reproducible by trinity using sendto system call .) Hello, First, please go read the Documentation/SubmittingPatches from the kernel sources; your patch needs to be resubmitted and the instructions in that file will show you how to do it correctly next time. Second, this appears to only affect Smack based systems, yes? SELinux based systems should have the proper checking in place to prevent this (the checks are handled in the LSM). This looks like a problem that was fixed some time ago. The current Smack code clearly checks for this. What kernel version are you testing against? That said, it probably wouldn't hurt to add the extra checking to netlbl_sock_delattr(). If you properly resubmit your patch I'll ACK it. -Paul
Re: msgrcv: use freezable blocking call
Hi Andrew, Both patches looks fine to us. Thank You On Wed, Apr 01, 2015 at 05:18:46AM +, Maninder Singh wrote: Hi Andrew, Thanks for making new patch, Actually there is some problem with our mail editor. It changes tabs with spaces and corrupts the patch, we are solving the same at our end. Thats why i am sending you signed -off by only for both patches. Sort it and resend, no real great hurry with these patches, right? I tend not to bother too much about occasional messy patches. These ones appear to be be the first patches from these contributors and fixing them up only takes a couple of minutes. If Maninder's team expects to send more patches in the future then yes, please fix this stuff. But for now, the important thing is to get these kernel problems sorted out. 1. For msgrcv: use freezable blocking call Signed-off-by: Yogesh Gaur yn.g...@samsung.com Signed-off-by: Maninder Singh maninder...@samsung.com Signed-off-by: Manjeet Pawar manjee...@samsung.com Did you really pass around that patch through 3 people or did it take all three of you to modify those two lines? Should some of those SoBs be a reviewed-by perhaps? For Peter's Review comment:- This is what, no why mentioned This call was selected to be converted to a freezable call because it doesn't hold any locks or release any resources when interrupted that might be needed by another freezing task or a kernel driver during suspend, and is a common site where idle userspace tasks are blocked. Please put such things in the Changelog so that we can see you've thought about things. I have made that change. Maninder, we currently have yourself as the primary author of restart_syscall: use freezable blocking call. Is that correct, or should that be Yogesh Gaur? -- It is correct Below are my latest copies of these two patches. How do they look? -- Looks fine, Thnaks for making patches. From: Yogesh Gaur yn.g...@samsung.com Subject: ipc/msg.c: use freezable blocking call Avoid waking up every thread sleeping in a msgrcv call during suspend and resume by calling a freezable blocking call. Previous patches modified the freezer to avoid sending wakeups to threads that are blocked in freezable blocking calls. Ref: https://lkml.org/lkml/2013/5/1/424 Backtrace: [c03e3924] (__schedule+0x0/0x5d8) from [c03e3f88] (schedule+0x8c/0x90) [c03e3efc] (schedule+0x0/0x90) from [c01ef9f8] (do_msgrcv+0x2e0/0x368) [c01ef718] (do_msgrcv+0x0/0x368) from [c01efaac] (SyS_msgrcv+0x2c/0x38) [c01efa80] (SyS_msgrcv+0x0/0x38) from [c001a180] (ret_fast_syscall+0x0/0x48) tPlay0Cb2 R running 0 297204 0x0001 This call was selected to be converted to a freezable call because it doesn't hold any locks or release any resources when interrupted that might be needed by another freezing task or a kernel driver during suspend, and is a common site where idle userspace tasks are blocked. Signed-off-by: Yogesh Gaur yn.g...@samsung.com Signed-off-by: Manjeet Pawar manjee...@samsung.com Signed-off-by: Maninder Singh maninder...@samsung.com Reviewed-by : Ajeet Yadav ajee...@samsung.com Cc: Peter Zijlstra a.p.zijls...@chello.nl Cc: Tejun Heo t...@kernel.org Signed-off-by: Andrew Morton a...@linux-foundation.org --- ipc/msg.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff -puN ipc/msg.c~msgrcv-use-freezable-blocking-call ipc/msg.c --- a/ipc/msg.c~msgrcv-use-freezable-blocking-call +++ a/ipc/msg.c @@ -37,6 +37,7 @@ #include linux/rwsem.h #include linux/nsproxy.h #include linux/ipc_namespace.h +#include linux/freezer.h #include asm/current.h #include linux/uaccess.h @@ -915,7 +916,7 @@ long do_msgrcv(int msqid, void __user *b ipc_unlock_object(msq-q_perm); rcu_read_unlock(); - schedule(); + freezable_schedule(); /* Lockless receive, part 1: * Disable preemption. We don't hold a reference to the queue _ From: Maninder Singh maninder...@samsung.com Subject: kernel/time/hrtimer.c: restart_syscall: use freezable blocking call Avoid waking up every thread sleeping in a restart_syscall call during suspend and resume by calling a freezable blocking call. Previous patches modified the freezer to avoid sending wakeups to threads that are blocked in freezable blocking calls. Ref: https://lkml.org/lkml/2013/5/1/424 Backtrace: [c03e3924] (__schedule+0x0/0x5d8) from [c03e3f88] (schedule+0x8c/0x90) [c03e3efc] (schedule+0x0/0x90) from [c03e3150] (schedule_hrtimeout_range_clock+0xdc/0x110) [c03e3074] (schedule_hrtimeout_range_clock+0x0/0x110) from [c03e31a0] (schedule_hrtimeout_range+0x1c/0x20) r9:d16c9be0 r8:8b7d9c2c r7: r6: r5:d16c8028 [c03e3184] (schedule_hrtimeout_range+0x0/0x20) from [c015778c] (poll_schedule_timeout+0x48/0x6c) [c0157744] (poll_schedule_timeout+0x0/0x6c) from [c0158994] (do_sys_poll+0x2c8/0x378) r5:d16c9f78 r4: [c01586cc
Re: Re: msgrcv: use freezable blocking call
Hi Andrew, Thanks for making new patch, Actually there is some problem with our mail editor. It changes tabs with spaces and corrupts the patch, we are solving the same at our end. Thats why i am sending you signed -off by only for both patches. 1. For msgrcv: use freezable blocking call Signed-off-by: Yogesh Gaur Signed-off-by: Maninder Singh Signed-off-by: Manjeet Pawar Reviewed-by : Ajeet Yadav Cc: Peter Zijlstra Cc: Tejun Heo Signed-off-by: Andrew Morton 2. For restart_syscall: use freezable blocking call Signed-off-by: Yogesh Gaur Signed-off-by: Maninder Singh Signed-off-by: Amit Arora Reviewed-by : Ajeet Yadav Cc: Peter Zijlstra Cc: Tejun Heo Signed-off-by: Andrew Morton > For Peter's Review comment:- This is what, no why mentioned This call was selected to be converted to a freezable call because it doesn't hold any locks or release any resources when interrupted that might be needed by another freezing task or a kernel driver during suspend, and is a common site where idle userspace tasks are blocked. Thanks Maninder Singh Presumably Peter's review comments for "restart_syscall: use freezable blocking call" also apply here. Please send your signed-off-by: for both patches, as detailed in Documentation/SubmittingPatches section 11, thanks. From: Yogesh Gaur Subject: ipc/msg.c: use freezable blocking call Avoid waking up every thread sleeping in a msgrcv call during suspend and resume by calling a freezable blocking call. Previous patches modified the freezer to avoid sending wakeups to threads that are blocked in freezable blocking calls. Ref: https://lkml.org/lkml/2013/5/1/424 Backtrace: [] (__schedule+0x0/0x5d8) from [] (schedule+0x8c/0x90) [] (schedule+0x0/0x90) from [] (do_msgrcv+0x2e0/0x368) [] (do_msgrcv+0x0/0x368) from [] (SyS_msgrcv+0x2c/0x38) [] (SyS_msgrcv+0x0/0x38) from [] (ret_fast_syscall+0x0/0x48) tPlay0Cb2 R running 0 297204 0x0001 Signed-off-by: Yogesh Gaur Signed-off-by: Manjeet Pawar Reviewed-by : Ajeet Yadav Cc: Peter Zijlstra Cc: Tejun Heo Signed-off-by: Andrew Morton --- ipc/msg.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff -puN ipc/msg.c~msgrcv-use-freezable-blocking-call ipc/msg.c --- a/ipc/msg.c~msgrcv-use-freezable-blocking-call +++ a/ipc/msg.c @@ -37,6 +37,7 @@ #include #include #include +#include #include #include @@ -915,7 +916,7 @@ long do_msgrcv(int msqid, void __user *b ipc_unlock_object(>q_perm); rcu_read_unlock(); - schedule(); + freezable_schedule(); /* Lockless receive, part 1: * Disable preemption. We don't hold a reference to the queue _
Re: Re: msgrcv: use freezable blocking call
Hi Andrew, Thanks for making new patch, Actually there is some problem with our mail editor. It changes tabs with spaces and corrupts the patch, we are solving the same at our end. Thats why i am sending you signed -off by only for both patches. 1. For msgrcv: use freezable blocking call Signed-off-by: Yogesh Gaur yn.g...@samsung.com Signed-off-by: Maninder Singh maninder...@samsung.com Signed-off-by: Manjeet Pawar manjee...@samsung.com Reviewed-by : Ajeet Yadav ajee...@samsung.com Cc: Peter Zijlstra a.p.zijls...@chello.nl Cc: Tejun Heo t...@kernel.org Signed-off-by: Andrew Morton a...@linux-foundation.org 2. For restart_syscall: use freezable blocking call Signed-off-by: Yogesh Gaur yn.g...@samsung.com Signed-off-by: Maninder Singh maninder...@samsung.com Signed-off-by: Amit Arora amit.ar...@samsung.com Reviewed-by : Ajeet Yadav ajee...@samsung.com Cc: Peter Zijlstra a.p.zijls...@chello.nl Cc: Tejun Heo t...@kernel.org Signed-off-by: Andrew Morton a...@linux-foundation.org For Peter's Review comment:- This is what, no why mentioned This call was selected to be converted to a freezable call because it doesn't hold any locks or release any resources when interrupted that might be needed by another freezing task or a kernel driver during suspend, and is a common site where idle userspace tasks are blocked. Thanks Maninder Singh Presumably Peter's review comments for restart_syscall: use freezable blocking call also apply here. Please send your signed-off-by: for both patches, as detailed in Documentation/SubmittingPatches section 11, thanks. From: Yogesh Gaur yn.g...@samsung.com Subject: ipc/msg.c: use freezable blocking call Avoid waking up every thread sleeping in a msgrcv call during suspend and resume by calling a freezable blocking call. Previous patches modified the freezer to avoid sending wakeups to threads that are blocked in freezable blocking calls. Ref: https://lkml.org/lkml/2013/5/1/424 Backtrace: [c03e3924] (__schedule+0x0/0x5d8) from [c03e3f88] (schedule+0x8c/0x90) [c03e3efc] (schedule+0x0/0x90) from [c01ef9f8] (do_msgrcv+0x2e0/0x368) [c01ef718] (do_msgrcv+0x0/0x368) from [c01efaac] (SyS_msgrcv+0x2c/0x38) [c01efa80] (SyS_msgrcv+0x0/0x38) from [c001a180] (ret_fast_syscall+0x0/0x48) tPlay0Cb2 R running 0 297204 0x0001 Signed-off-by: Yogesh Gaur yn.g...@samsung.com Signed-off-by: Manjeet Pawar manjee...@samsung.com Reviewed-by : Ajeet Yadav ajee...@samsung.com Cc: Peter Zijlstra a.p.zijls...@chello.nl Cc: Tejun Heo t...@kernel.org Signed-off-by: Andrew Morton a...@linux-foundation.org --- ipc/msg.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff -puN ipc/msg.c~msgrcv-use-freezable-blocking-call ipc/msg.c --- a/ipc/msg.c~msgrcv-use-freezable-blocking-call +++ a/ipc/msg.c @@ -37,6 +37,7 @@ #include linux/rwsem.h #include linux/nsproxy.h #include linux/ipc_namespace.h +#include linux/freezer.h #include asm/current.h #include linux/uaccess.h @@ -915,7 +916,7 @@ long do_msgrcv(int msqid, void __user *b ipc_unlock_object(msq-q_perm); rcu_read_unlock(); - schedule(); + freezable_schedule(); /* Lockless receive, part 1: * Disable preemption. We don't hold a reference to the queue _
Re: Re: [Fix kernel crash in cipso_v4_sock_delattr ]
We are currently using 3.10.58 kernel and we are facing this issue for samck enabled system. and as we can check in other APIs like netlbl_sock_getattr and netlbl_conn_setattr have this preventive check so we added this check for netlbl_sock_delattr also. And regarding patch re-submission, actually we have run checkpatch.pl before submission(successfull) But when we submit the patch our editor changes tabs into space, we will resubmitt the patch ASAP. Maninder Singh --- Original Message --- Sender : Casey Schaufler Date : Mar 31, 2015 02:25 (GMT+09:00) Title : Re: [Fix kernel crash in cipso_v4_sock_delattr ] On 3/30/2015 4:32 AM, Paul Moore wrote: > On Monday, March 30, 2015 11:09:00 AM Maninder Singh wrote: >> Dear All, >> we found One Kernel Crash issue in cipso_v4_sock_delattr :- >> As Cipso supports only inet sockets so cipso_v4_sock_delattr will crash when >> try to access any other socket type. cipso_v4_sock_delattr access >> sk_inet->inet_opt which may contain not NULL but invalid address. we found >> this issue with netlink socket.(reproducible by trinity using sendto system >> call .) > Hello, > > First, please go read the Documentation/SubmittingPatches from the kernel > sources; your patch needs to be resubmitted and the instructions in that file > will show you how to do it correctly next time. > > Second, this appears to only affect Smack based systems, yes? SELinux based > systems should have the proper checking in place to prevent this (the checks > are handled in the LSM). This looks like a problem that was fixed some time ago. The current Smack code clearly checks for this. What kernel version are you testing against? > That said, it probably wouldn't hurt to add the > extra checking to netlbl_sock_delattr(). If you properly resubmit your patch > I'll ACK it. > > -Paul >
[ARM: code clean up local_irq_disable]
Hi Subject: [PATCH] ARM: code clean up local_irq_disable Signed-off-by: Akhilesh Kumar --- arch/arm/kernel/process.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c index 81ef686..18cfce4 100644 --- a/arch/arm/kernel/process.c +++ b/arch/arm/kernel/process.c @@ -195,7 +195,6 @@ void machine_halt(void) local_irq_disable(); smp_send_stop(); - local_irq_disable(); while (1); } -- 1.7.1 Thanks and Regards, Maninder Singh
[Fix kernel crash in cipso_v4_sock_delattr ]
Dear All,
we found One Kernel Crash issue in cipso_v4_sock_delattr :-
As Cipso supports only inet sockets so cipso_v4_sock_delattr will crash when
try to access
any other socket type. cipso_v4_sock_delattr access sk_inet->inet_opt which may
contain not NULL but invalid address. we found this issue with netlink
socket.(reproducible by trinity using sendto system call .)
Crash Logs :
[0-182.2400] [] (cipso_v4_sock_delattr+0x0/0x74) from []
(netlbl_sock_delattr+0x18/0x1c)
[0-182.2497] r4: r3:c07872f8
[0-182.2531] [] (netlbl_sock_delattr+0x0/0x1c) from []
(smack_netlabel+0x88/0x9c)
[0-182.2622] [] (smack_netlabel+0x0/0x9c) from []
(smack_netlabel_send+0x12c/0x144)
[0-182.2714] r7 9ce9500 r6 7b67ef4 r5:c076f408 r4 8903dc0
[0-182.2770] [] (smack_netlabel_send+0x0/0x144) from []
(smack_socket_sendmsg+0x54/0x60)
[0-182.2866] [] (smack_socket_sendmsg+0x0/0x60) from []
(security_socket_sendmsg+0x28/0x2c)
[0-182.2966] [] (security_socket_sendmsg+0x0/0x2c) from []
(sock_sendmsg+0x68/0xc0)
[0-182.3058] [] (sock_sendmsg+0x0/0xc0) from []
(SyS_sendto+0xd8/0x110)
Signed-off-by: Vaneet Narang
Signed-off-by: Maninder Singh
Reviewed-by : Ajeet Yadav
---
net/netlabel/netlabel_kapi.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/net/netlabel/netlabel_kapi.c b/net/netlabel/netlabel_kapi.c
index 7c94aed..7a2c6f5 100755
--- a/net/netlabel/netlabel_kapi.c
+++ b/net/netlabel/netlabel_kapi.c
@@ -700,7 +700,13 @@ socket_setattr_return:
*/
void netlbl_sock_delattr(struct sock *sk)
{
- cipso_v4_sock_delattr(sk);
+ switch (sk->sk_family) {
+ case AF_INET:
+ cipso_v4_sock_delattr(sk);
+ break;
+ default:
+ break;
+ }
}
/**
--
1.7.9.5
Thanks and Regards,
Maninder Singh
restart_syscall: use freezable blocking call
Hello All,
Avoid waking up every thread sleeping in a restart_syscall call during suspend
and resume by calling a freezable blocking call.
Previous patches modified the freezer to avoid sending wakeups to threads that
are blocked in freezable blocking calls.
Ref: https://lkml.org/lkml/2013/5/1/424
We have faced similiar issue of sleep fail when calling restart() system call
in stress testing.
Patch :-
Subject: restart_syscall: use freezable blocking call
Avoid waking up every thread sleeping in a restart_syscall call during
suspend and resume by calling a freezable blocking call. Previous
patches modified the freezer to avoid sending wakeups to threads
that are blocked in freezable blocking calls.
Ref: https://lkml.org/lkml/2013/5/1/424
Backtrace:
[] (__schedule+0x0/0x5d8) from [] (schedule+0x8c/0x90)
[] (schedule+0x0/0x90) from []
(schedule_hrtimeout_range_clock+0xdc/0x110)
[] (schedule_hrtimeout_range_clock+0x0/0x110) from []
(schedule_hrtimeout_range+0x1c/0x20)
r9:d16c9be0 r8:8b7d9c2c r7: r6: r5:d16c8028
[] (schedule_hrtimeout_range+0x0/0x20) from []
(poll_schedule_timeout+0x48/0x6c)
[] (poll_schedule_timeout+0x0/0x6c) from []
(do_sys_poll+0x2c8/0x378)
r5:d16c9f78 r4:
[] (do_sys_poll+0x0/0x378) from []
(do_restart_poll+0x40/0x5c)
[] (do_restart_poll+0x0/0x5c) from []
(sys_restart_syscall+0x2c/0x30)
r4:fe7a
[] (sys_restart_syscall+0x0/0x30) from []
(ret_fast_syscall+0x0/0x48)
esTask03R running 0 270204 0x0001
Signed-off-by: Yogesh Gaur samsung.com>
Signed-off-by: Amit Arora samsung.com>
Reviewed-by : Ajeet Yadav samsung.com>
---
kernel/time/hrtimer.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
index 37e50aa..75ebc3f 100644
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -1775,7 +1775,7 @@ schedule_hrtimeout_range_clock(ktime_t *expires, unsigned
long delta,
* A NULL parameter means "infinite"
*/
if (!expires) {
- schedule();
+ freezable_schedule();
return -EINTR;
}
@@ -1789,7 +1789,7 @@ schedule_hrtimeout_range_clock(ktime_t *expires, unsigned
long delta,
t.task = NULL;
if (likely(t.task))
- schedule();
+ freezable_schedule();
hrtimer_cancel();
destroy_hrtimer_on_stack();
--
1.7.1
Thanks and Regards,
Maninder Singh
restart_syscall: use freezable blocking call
Hello All,
Avoid waking up every thread sleeping in a restart_syscall call during suspend
and resume by calling a freezable blocking call.
Previous patches modified the freezer to avoid sending wakeups to threads that
are blocked in freezable blocking calls.
Ref: https://lkml.org/lkml/2013/5/1/424
We have faced similiar issue of sleep fail when calling restart() system call
in stress testing.
Patch :-
Subject: restart_syscall: use freezable blocking call
Avoid waking up every thread sleeping in a restart_syscall call during
suspend and resume by calling a freezable blocking call. Previous
patches modified the freezer to avoid sending wakeups to threads
that are blocked in freezable blocking calls.
Ref: https://lkml.org/lkml/2013/5/1/424
Backtrace:
[c03e3924] (__schedule+0x0/0x5d8) from [c03e3f88] (schedule+0x8c/0x90)
[c03e3efc] (schedule+0x0/0x90) from [c03e3150]
(schedule_hrtimeout_range_clock+0xdc/0x110)
[c03e3074] (schedule_hrtimeout_range_clock+0x0/0x110) from [c03e31a0]
(schedule_hrtimeout_range+0x1c/0x20)
r9:d16c9be0 r8:8b7d9c2c r7: r6: r5:d16c8028
[c03e3184] (schedule_hrtimeout_range+0x0/0x20) from [c015778c]
(poll_schedule_timeout+0x48/0x6c)
[c0157744] (poll_schedule_timeout+0x0/0x6c) from [c0158994]
(do_sys_poll+0x2c8/0x378)
r5:d16c9f78 r4:
[c01586cc] (do_sys_poll+0x0/0x378) from [c0158a84]
(do_restart_poll+0x40/0x5c)
[c0158a44] (do_restart_poll+0x0/0x5c) from [c005710c]
(sys_restart_syscall+0x2c/0x30)
r4:fe7a
[c00570e0] (sys_restart_syscall+0x0/0x30) from [c001a180]
(ret_fast_syscall+0x0/0x48)
esTask03R running 0 270204 0x0001
Signed-off-by: Yogesh Gaur yn.gaur at samsung.com
Signed-off-by: Amit Arora amit.arora at samsung.com
Reviewed-by : Ajeet Yadav ajeet.y at samsung.com
---
kernel/time/hrtimer.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
index 37e50aa..75ebc3f 100644
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -1775,7 +1775,7 @@ schedule_hrtimeout_range_clock(ktime_t *expires, unsigned
long delta,
* A NULL parameter means infinite
*/
if (!expires) {
- schedule();
+ freezable_schedule();
return -EINTR;
}
@@ -1789,7 +1789,7 @@ schedule_hrtimeout_range_clock(ktime_t *expires, unsigned
long delta,
t.task = NULL;
if (likely(t.task))
- schedule();
+ freezable_schedule();
hrtimer_cancel(t.timer);
destroy_hrtimer_on_stack(t.timer);
--
1.7.1
Thanks and Regards,
Maninder Singh
[Fix kernel crash in cipso_v4_sock_delattr ]
Dear All,
we found One Kernel Crash issue in cipso_v4_sock_delattr :-
As Cipso supports only inet sockets so cipso_v4_sock_delattr will crash when
try to access
any other socket type. cipso_v4_sock_delattr access sk_inet-inet_opt which may
contain not NULL but invalid address. we found this issue with netlink
socket.(reproducible by trinity using sendto system call .)
Crash Logs :
[0-182.2400] [c04c7fa4] (cipso_v4_sock_delattr+0x0/0x74) from [c0517b64]
(netlbl_sock_delattr+0x18/0x1c)
[0-182.2497] r4: r3:c07872f8
[0-182.2531] [c0517b4c] (netlbl_sock_delattr+0x0/0x1c) from [c027b2fc]
(smack_netlabel+0x88/0x9c)
[0-182.2622] [c027b274] (smack_netlabel+0x0/0x9c) from [c027b43c]
(smack_netlabel_send+0x12c/0x144)
[0-182.2714] r7 9ce9500 r6 7b67ef4 r5:c076f408 r4 8903dc0
[0-182.2770] [c027b310] (smack_netlabel_send+0x0/0x144) from [c027b4a8]
(smack_socket_sendmsg+0x54/0x60)
[0-182.2866] [c027b454] (smack_socket_sendmsg+0x0/0x60) from [c02789ec]
(security_socket_sendmsg+0x28/0x2c)
[0-182.2966] [c02789c4] (security_socket_sendmsg+0x0/0x2c) from [c04343b0]
(sock_sendmsg+0x68/0xc0)
[0-182.3058] [c0434348] (sock_sendmsg+0x0/0xc0) from [c04369e8]
(SyS_sendto+0xd8/0x110)
Signed-off-by: Vaneet Narang v.nar...@samsung.com
Signed-off-by: Maninder Singh maninder...@samsung.com
Reviewed-by : Ajeet Yadav ajee...@samsung.com
---
net/netlabel/netlabel_kapi.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/net/netlabel/netlabel_kapi.c b/net/netlabel/netlabel_kapi.c
index 7c94aed..7a2c6f5 100755
--- a/net/netlabel/netlabel_kapi.c
+++ b/net/netlabel/netlabel_kapi.c
@@ -700,7 +700,13 @@ socket_setattr_return:
*/
void netlbl_sock_delattr(struct sock *sk)
{
- cipso_v4_sock_delattr(sk);
+ switch (sk-sk_family) {
+ case AF_INET:
+ cipso_v4_sock_delattr(sk);
+ break;
+ default:
+ break;
+ }
}
/**
--
1.7.9.5
Thanks and Regards,
Maninder Singh
[ARM: code clean up local_irq_disable]
Hi Subject: [PATCH] ARM: code clean up local_irq_disable Signed-off-by: Akhilesh Kumar akhiles...@samsung.com --- arch/arm/kernel/process.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c index 81ef686..18cfce4 100644 --- a/arch/arm/kernel/process.c +++ b/arch/arm/kernel/process.c @@ -195,7 +195,6 @@ void machine_halt(void) local_irq_disable(); smp_send_stop(); - local_irq_disable(); while (1); } -- 1.7.1 Thanks and Regards, Maninder Singh
Re: Re: [Fix kernel crash in cipso_v4_sock_delattr ]
We are currently using 3.10.58 kernel and we are facing this issue for samck enabled system. and as we can check in other APIs like netlbl_sock_getattr and netlbl_conn_setattr have this preventive check so we added this check for netlbl_sock_delattr also. And regarding patch re-submission, actually we have run checkpatch.pl before submission(successfull) But when we submit the patch our editor changes tabs into space, we will resubmitt the patch ASAP. Maninder Singh --- Original Message --- Sender : Casey Schauflerca...@schaufler-ca.com Date : Mar 31, 2015 02:25 (GMT+09:00) Title : Re: [Fix kernel crash in cipso_v4_sock_delattr ] On 3/30/2015 4:32 AM, Paul Moore wrote: On Monday, March 30, 2015 11:09:00 AM Maninder Singh wrote: Dear All, we found One Kernel Crash issue in cipso_v4_sock_delattr :- As Cipso supports only inet sockets so cipso_v4_sock_delattr will crash when try to access any other socket type. cipso_v4_sock_delattr access sk_inet-inet_opt which may contain not NULL but invalid address. we found this issue with netlink socket.(reproducible by trinity using sendto system call .) Hello, First, please go read the Documentation/SubmittingPatches from the kernel sources; your patch needs to be resubmitted and the instructions in that file will show you how to do it correctly next time. Second, this appears to only affect Smack based systems, yes? SELinux based systems should have the proper checking in place to prevent this (the checks are handled in the LSM). This looks like a problem that was fixed some time ago. The current Smack code clearly checks for this. What kernel version are you testing against? That said, it probably wouldn't hurt to add the extra checking to netlbl_sock_delattr(). If you properly resubmit your patch I'll ACK it. -Paul
