+CC stable
On 01/20/22 16:25, Valentin Schneider wrote:
TASK_RTLOCK_WAIT currently isn't part of TASK_REPORT, thus a task blocking on an rtlock will appear as having a task state == 0, IOW TASK_RUNNING.
The actual state is saved in p->saved_state, but reading it after reading p->__state has a few issues: o that could still be TASK_RUNNING in the case of e.g. rt_spin_lock o ttwu_state_match() might have changed that to TASK_RUNNING
As pointed out by Eric, adding TASK_RTLOCK_WAIT to TASK_REPORT implies exposing a new state to userspace tools which way not know what to do with them. The only information that needs to be conveyed here is that a task is waiting on an rt_mutex, which matches TASK_UNINTERRUPTIBLE - there's no need for a new state.
Reported-by: Uwe Kleine-König u.kleine-koenig@pengutronix.de Signed-off-by: Valentin Schneider valentin.schneider@arm.com
Any objection for this to be picked up by stable? We care about Patch 1 only in this series for stable, but it seems sensible to pick this one too, no strong feeling if it is omitted though.
AFAICT it seems the problem dates back since commit:
1593baab910d ("sched/debug: Implement consistent task-state printing")
or even before. I think v4.14+ is good enough.
Thoughts?
Thanks!
-- Qais Yousef
On Sun, Apr 10, 2022 at 12:42:24AM +0100, Qais Yousef wrote:
+CC stable
On 01/20/22 16:25, Valentin Schneider wrote:
TASK_RTLOCK_WAIT currently isn't part of TASK_REPORT, thus a task blocking on an rtlock will appear as having a task state == 0, IOW TASK_RUNNING.
The actual state is saved in p->saved_state, but reading it after reading p->__state has a few issues: o that could still be TASK_RUNNING in the case of e.g. rt_spin_lock o ttwu_state_match() might have changed that to TASK_RUNNING
As pointed out by Eric, adding TASK_RTLOCK_WAIT to TASK_REPORT implies exposing a new state to userspace tools which way not know what to do with them. The only information that needs to be conveyed here is that a task is waiting on an rt_mutex, which matches TASK_UNINTERRUPTIBLE - there's no need for a new state.
Reported-by: Uwe Kleine-König u.kleine-koenig@pengutronix.de Signed-off-by: Valentin Schneider valentin.schneider@arm.com
Any objection for this to be picked up by stable? We care about Patch 1 only in this series for stable, but it seems sensible to pick this one too, no strong feeling if it is omitted though.
AFAICT it seems the problem dates back since commit:
1593baab910d ("sched/debug: Implement consistent task-state printing")
or even before. I think v4.14+ is good enough.
<formletter>
This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html for how to do this properly.
</formletter>
On 04/10/22 08:14, Greg KH wrote:
On Sun, Apr 10, 2022 at 12:42:24AM +0100, Qais Yousef wrote:
+CC stable
On 01/20/22 16:25, Valentin Schneider wrote:
TASK_RTLOCK_WAIT currently isn't part of TASK_REPORT, thus a task blocking on an rtlock will appear as having a task state == 0, IOW TASK_RUNNING.
The actual state is saved in p->saved_state, but reading it after reading p->__state has a few issues: o that could still be TASK_RUNNING in the case of e.g. rt_spin_lock o ttwu_state_match() might have changed that to TASK_RUNNING
As pointed out by Eric, adding TASK_RTLOCK_WAIT to TASK_REPORT implies exposing a new state to userspace tools which way not know what to do with them. The only information that needs to be conveyed here is that a task is waiting on an rt_mutex, which matches TASK_UNINTERRUPTIBLE - there's no need for a new state.
Reported-by: Uwe Kleine-K�nig u.kleine-koenig@pengutronix.de Signed-off-by: Valentin Schneider valentin.schneider@arm.com
Any objection for this to be picked up by stable? We care about Patch 1 only in this series for stable, but it seems sensible to pick this one too, no strong feeling if it is omitted though.
AFAICT it seems the problem dates back since commit:
1593baab910d ("sched/debug: Implement consistent task-state printing")
or even before. I think v4.14+ is good enough.
<formletter>
This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html for how to do this properly.
</formletter>
Apologies.
commit: 25795ef6299f07ce3838f3253a9cb34f64efcfae Subject: sched/tracing: Report TASK_RTLOCK_WAIT tasks as TASK_UNINTERRUPTIBLE
I am interested in Patch 1 in this series as I know it impacts some Android 5.10 users. But this patch seems a good candidate for stable too since it was observed by a user (Uwe) and AFAICT the problem dates back to v4.14+ kernels.
Suggested kernels: v4.14+. This has already been picked up by AUTOSEL for v5.15+ stable trees.
Hope I got the process right this time.
Thanks!
-- Qais Yousef
On Sun, Apr 10, 2022 at 11:13:25PM +0100, Qais Yousef wrote:
On 04/10/22 08:14, Greg KH wrote:
On Sun, Apr 10, 2022 at 12:42:24AM +0100, Qais Yousef wrote:
+CC stable
On 01/20/22 16:25, Valentin Schneider wrote:
TASK_RTLOCK_WAIT currently isn't part of TASK_REPORT, thus a task blocking on an rtlock will appear as having a task state == 0, IOW TASK_RUNNING.
The actual state is saved in p->saved_state, but reading it after reading p->__state has a few issues: o that could still be TASK_RUNNING in the case of e.g. rt_spin_lock o ttwu_state_match() might have changed that to TASK_RUNNING
As pointed out by Eric, adding TASK_RTLOCK_WAIT to TASK_REPORT implies exposing a new state to userspace tools which way not know what to do with them. The only information that needs to be conveyed here is that a task is waiting on an rt_mutex, which matches TASK_UNINTERRUPTIBLE - there's no need for a new state.
Reported-by: Uwe Kleine-K�nig u.kleine-koenig@pengutronix.de Signed-off-by: Valentin Schneider valentin.schneider@arm.com
Any objection for this to be picked up by stable? We care about Patch 1 only in this series for stable, but it seems sensible to pick this one too, no strong feeling if it is omitted though.
AFAICT it seems the problem dates back since commit:
1593baab910d ("sched/debug: Implement consistent task-state printing")
or even before. I think v4.14+ is good enough.
<formletter>
This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html for how to do this properly.
</formletter>
Apologies.
commit: 25795ef6299f07ce3838f3253a9cb34f64efcfae Subject: sched/tracing: Report TASK_RTLOCK_WAIT tasks as TASK_UNINTERRUPTIBLE
I am interested in Patch 1 in this series as I know it impacts some Android 5.10 users. But this patch seems a good candidate for stable too since it was observed by a user (Uwe) and AFAICT the problem dates back to v4.14+ kernels.
Suggested kernels: v4.14+. This has already been picked up by AUTOSEL for v5.15+ stable trees.
I do not think you have tested this in any of those kernels, as it breaks the build :(
Please send a set of patches, properly backported and tested, that you wish to see applied to stable kernels and we will be glad to review them and apply them. But to suggest patches to be merged that you have not even tested is not good.
thanks,
greg k-h
On 04/11/22 15:20, Greg KH wrote:
On Sun, Apr 10, 2022 at 11:13:25PM +0100, Qais Yousef wrote:
On 04/10/22 08:14, Greg KH wrote:
On Sun, Apr 10, 2022 at 12:42:24AM +0100, Qais Yousef wrote:
+CC stable
On 01/20/22 16:25, Valentin Schneider wrote:
TASK_RTLOCK_WAIT currently isn't part of TASK_REPORT, thus a task blocking on an rtlock will appear as having a task state == 0, IOW TASK_RUNNING.
The actual state is saved in p->saved_state, but reading it after reading p->__state has a few issues: o that could still be TASK_RUNNING in the case of e.g. rt_spin_lock o ttwu_state_match() might have changed that to TASK_RUNNING
As pointed out by Eric, adding TASK_RTLOCK_WAIT to TASK_REPORT implies exposing a new state to userspace tools which way not know what to do with them. The only information that needs to be conveyed here is that a task is waiting on an rt_mutex, which matches TASK_UNINTERRUPTIBLE - there's no need for a new state.
Reported-by: Uwe Kleine-K�nig u.kleine-koenig@pengutronix.de Signed-off-by: Valentin Schneider valentin.schneider@arm.com
Any objection for this to be picked up by stable? We care about Patch 1 only in this series for stable, but it seems sensible to pick this one too, no strong feeling if it is omitted though.
AFAICT it seems the problem dates back since commit:
1593baab910d ("sched/debug: Implement consistent task-state printing")
or even before. I think v4.14+ is good enough.
<formletter>
This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html for how to do this properly.
</formletter>
Apologies.
commit: 25795ef6299f07ce3838f3253a9cb34f64efcfae Subject: sched/tracing: Report TASK_RTLOCK_WAIT tasks as TASK_UNINTERRUPTIBLE
I am interested in Patch 1 in this series as I know it impacts some Android 5.10 users. But this patch seems a good candidate for stable too since it was observed by a user (Uwe) and AFAICT the problem dates back to v4.14+ kernels.
Suggested kernels: v4.14+. This has already been picked up by AUTOSEL for v5.15+ stable trees.
I do not think you have tested this in any of those kernels, as it breaks the build :(
Please send a set of patches, properly backported and tested, that you wish to see applied to stable kernels and we will be glad to review them and apply them. But to suggest patches to be merged that you have not even tested is not good.
Okay. Maybe I was trying to chew too much. I care about patch 1 only. I'll make sure it builds and works against 5.10 and post it separately. Please ignore this one.
Sorry for the noise.
Thanks
-- Qais Yousef
linux-stable-mirror@lists.linaro.org
-
Greg KH -
Qais Yousef