Re: [PATCH 3.14.25-rt22 1/2] rtmutex Real-Time Linux: Fixing kernel BUG at kernel/locking/rtmutex.c:997!
From: Thavatchai Makphaibulchoke
Date: Mon Feb 23 2015 - 19:17:29 EST
On 02/23/2015 11:37 AM, Steven Rostedt wrote:
> OK, I believe I understand the issue. Perhaps it would be much better
> to create a fake task per CPU that we use when grabbing locks in
> interrupt mode. And make these have a priority of 0 (highest), since
> they can not be preempted, they do have such a priority.
> Then in the fast trylock and unlock code, we can add:
> struct task_struct *curr = current;
> if (unlikely(in_irq()))
> curr = this_cpu_read(irq_task);
> This way the priority inheritance will stop when it hits this task (no
> need to boost a task of highest priority), and we can leave that code
Thanks again for the comments and suggestion.
Yes, creating a per cpu fake task was one of the alternative considered.
I believe one of the reasons I did not purse is the amount of extra
storage it requires (sizeof(struct task_struct) * number of cpus.
Though the changes may not be as intrusive as the one I sent, some are
still required, mainly with current (one in particular came to mind is
If I'm not mistaken, another reason could also be due to the rate of the
timer interrupt, in the case that the mutex is highly contested IH could
stall the non-real-time requester for a long time, even to the point of
the cpu is perceived as hung.
Anyway, I'll retry the fake task approach a try and report back if there
is any issue.
> -- Steve
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/