[PATCH] skip increamenting nr for TASK_UNINTERRUPTIBLE
Dear All,
We found below issue in coredump for uninterruptible task -
>From 1c46f0327d98ad593d8913f9f1dad352f8f44304 Mon Sep 17 00:00:00 2001
From: Ajeet Yadav
Date: Sat, 21 Dec 2013 17:06:05 +0530
Subject: [PATCH] skip increamenting nr for TASK_UNINTERRUPTIBLE
In coredump case, where thread_1 faults while thread_2 is in
TASK_UNINTERRUPTIBLE state, it cannot handle the SIGKILL.
Thus the process hangs on event.
The coredump routine freezes until the thread state is
uninterruptible.
Solution: Continue for coredump, without waiting for uninterruptible
thread, as it will get killed as soon as it returns from
uninterruptible state.
Therefore do not increament thread count for threads with
TASK_UNINTERRUPTIBLE.
Signed-off-by: Ajeet Yadav
Signed-off-by: Vaibhav Shinde
---
fs/coredump.c |3 ++-
1 file changed, 2 insertions(+), 1 deletions(-)
diff --git a/fs/coredump.c b/fs/coredump.c
index 447b02c..54b0664 100644
--- a/fs/coredump.c
+++ b/fs/coredump.c
@@ -281,7 +281,8 @@ static int zap_process(struct task_struct *start,
int exit_code)
if (t != current && t->mm) {
sigaddset(>pending.signal, SIGKILL);
signal_wake_up(t, 1);
- nr++;
+ if(!(t->state & TASK_UNINTERRUPTIBLE))
+ nr++;
}
} while_each_thread(start, t);
--
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] skip increamenting nr for TASK_UNINTERRUPTIBLE
Dear All,
We found below issue in coredump for uninterruptible task -
From 1c46f0327d98ad593d8913f9f1dad352f8f44304 Mon Sep 17 00:00:00 2001
From: Ajeet Yadav ajeet.yadav...@gmail.com
Date: Sat, 21 Dec 2013 17:06:05 +0530
Subject: [PATCH] skip increamenting nr for TASK_UNINTERRUPTIBLE
In coredump case, where thread_1 faults while thread_2 is in
TASK_UNINTERRUPTIBLE state, it cannot handle the SIGKILL.
Thus the process hangs on event.
The coredump routine freezes until the thread state is
uninterruptible.
Solution: Continue for coredump, without waiting for uninterruptible
thread, as it will get killed as soon as it returns from
uninterruptible state.
Therefore do not increament thread count for threads with
TASK_UNINTERRUPTIBLE.
Signed-off-by: Ajeet Yadav ajeet.yadav...@gmail.com
Signed-off-by: Vaibhav Shinde v.bhav.shi...@gmail.com
---
fs/coredump.c |3 ++-
1 file changed, 2 insertions(+), 1 deletions(-)
diff --git a/fs/coredump.c b/fs/coredump.c
index 447b02c..54b0664 100644
--- a/fs/coredump.c
+++ b/fs/coredump.c
@@ -281,7 +281,8 @@ static int zap_process(struct task_struct *start,
int exit_code)
if (t != current t-mm) {
sigaddset(t-pending.signal, SIGKILL);
signal_wake_up(t, 1);
- nr++;
+ if(!(t-state TASK_UNINTERRUPTIBLE))
+ nr++;
}
} while_each_thread(start, t);
--
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/
Re: DEBUG_STACKOVERFLOW issue on ARM
Hi Russel, On Fri, Oct 5, 2012 at 2:01 PM, Russell King - ARM Linux wrote: > > On Wed, Oct 03, 2012 at 05:18:56PM +0530, trisha yad wrote: > > I wish to know how can I support this function in 3.0 ? > > If your description is correct, then all you need to do is to ensure > that you route interrupts to other CPUs. > > You can do that by running the userspace irqbalance daemon. > I also tried with the irqbalance daemon, on ARM quad core architecture, and as per my understanding, the daemon sets the /proc/irq//smp_affinity file according to the irq frequency on a particular processor. However, the daemon doesn't work as expected, I also tried accessing the proc file mentioned above to set the cpu mask for particular irq, but this just block the processing of the irq, as I see the count of that irq doesnt increase in /proc/interrupts. My conclusion is that the irqbalancing is not supported on ARM arch or there is something more required for this to work. Kindly provide some pointers over this. Regards, Vaibhav -- 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/
Re: DEBUG_STACKOVERFLOW issue on ARM
Hi Russel, On Fri, Oct 5, 2012 at 2:01 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Wed, Oct 03, 2012 at 05:18:56PM +0530, trisha yad wrote: I wish to know how can I support this function in 3.0 ? If your description is correct, then all you need to do is to ensure that you route interrupts to other CPUs. You can do that by running the userspace irqbalance daemon. I also tried with the irqbalance daemon, on ARM quad core architecture, and as per my understanding, the daemon sets the /proc/irq/irq.no./smp_affinity file according to the irq frequency on a particular processor. However, the daemon doesn't work as expected, I also tried accessing the proc file mentioned above to set the cpu mask for particular irq, but this just block the processing of the irq, as I see the count of that irq doesnt increase in /proc/interrupts. My conclusion is that the irqbalancing is not supported on ARM arch or there is something more required for this to work. Kindly provide some pointers over this. Regards, Vaibhav -- 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/
