Dear RT Folks,
I'm pleased to announce the 3.14.23-rt20 stable release.
This is the first 3.14-rt release in the stable-rt series. Normally I
wait till the next development release is out before I pull in a new
one. That is, I would pull in 3.14-rt when 3.16-rt or later was
released. But because development is now moving at a "hobbyist rate"
(read http://lwn.net/Articles/617140/ for details)
and 3.14-rt is no longer being developed against, I figured it was time
to put it under the "stable-rt" umbrella.
This release is just an update to the new stable 3.14.23 version
and no RT specific changes have been made.
You can get this release via the git tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git
branch: v3.14-rt
Head SHA1: 98a86c73c8828ba724eafaef832d71e3c909fb73
Or to build 3.14.23-rt20 directly, the following patches should be
applied:
http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.14.tar.xz
http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.14.23.xz
http://www.kernel.org/pub/linux/kernel/projects/rt/3.14/patch-3.14.23-rt20.patch.xz
Enjoy,
-- Steve
On Fri, 2014-10-31 at 17:03 -0400, Steven Rostedt wrote:
> Dear RT Folks,
>
> I'm pleased to announce the 3.14.23-rt20 stable release.
>
> This is the first 3.14-rt release in the stable-rt series. Normally I
> wait till the next development release is out before I pull in a new
> one. That is, I would pull in 3.14-rt when 3.16-rt or later was
> released. But because development is now moving at a "hobbyist rate"
> (read http://lwn.net/Articles/617140/ for details)
> and 3.14-rt is no longer being developed against, I figured it was
time
> to put it under the "stable-rt" umbrella.
I piddled about with it yesterday, found that you can't change cpufreq
governor IFF the tree is configured as rt, but works fine as voluntary
preempt. I'll poke about for the entertainment value. Having no
personal need/use for rt detracts from its hobby value somewhat, but rt
problems do have a tendency to be 'entertaining'.
I'll follow up with a few patches that folks can apply to their trees if
they so desire. There being no devel tree to submit against, I can't do
a proper submission (rules), and some of them you surely don't want :)
-Mike
Resending to the list due to mailer/html issues.
On Sun, Nov 2, 2014 at 8:30 AM, Mike Galbraith <[email protected]> wrote:
>
> On Fri, 2014-10-31 at 17:03 -0400, Steven Rostedt wrote:
> > Dear RT Folks,
> >
> > I'm pleased to announce the 3.14.23-rt20 stable release.
> >
> > This is the first 3.14-rt release in the stable-rt series. Normally I
> > wait till the next development release is out before I pull in a new
> > one. That is, I would pull in 3.14-rt when 3.16-rt or later was
> > released. But because development is now moving at a "hobbyist rate"
> > (read http://lwn.net/Articles/617140/ for details)
> > and 3.14-rt is no longer being developed against, I figured it was
> > time
> > to put it under the "stable-rt" umbrella.
>
> I piddled about with it yesterday, found that you can't change cpufreq
> governor IFF the tree is configured as rt, but works fine as voluntary
> preempt.
The problem seems to be this patch: https://lkml.org/lkml/2014/4/8/584
The cpufreq code does nested down_read_trylocks and only the first one succeeds:
drivers/cpufreq/cpufreq.c:
store
down_read_trylock(cpufreq_rwsem) <- succeeds
store_scaling_governor
cpufreq_get_policy
cpufreq_cpu_get
down_read_trylock(cpufreq_rwsem) <-- fails
Reverting the above patch 'fixes' the problem. I don't understand
Steven's commit comment that readers of rwsem are not allowed to nest
in mainline since this works just fine in mainline.
...Juerg
> I'll poke about for the entertainment value. Having no
> personal need/use for rt detracts from its hobby value somewhat, but rt
> problems do have a tendency to be 'entertaining'.
>
> I'll follow up with a few patches that folks can apply to their trees if
> they so desire. There being no devel tree to submit against, I can't do
> a proper submission (rules), and some of them you surely don't want :)
>
> -Mike
On Wed, 5 Nov 2014 14:50:41 +0100
Juerg Haefliger <[email protected]> wrote:
> On Sun, Nov 2, 2014 at 8:30 AM, Mike Galbraith <[email protected]>
> wrote:
> >
> > On Fri, 2014-10-31 at 17:03 -0400, Steven Rostedt wrote:
> > > Dear RT Folks,
> > >
> > > I'm pleased to announce the 3.14.23-rt20 stable release.
> > >
> > > This is the first 3.14-rt release in the stable-rt series. Normally I
> > > wait till the next development release is out before I pull in a new
> > > one. That is, I would pull in 3.14-rt when 3.16-rt or later was
> > > released. But because development is now moving at a "hobbyist rate"
> > > (read http://lwn.net/Articles/617140/ for details)
> > > and 3.14-rt is no longer being developed against, I figured it was
> > time
> > > to put it under the "stable-rt" umbrella.
> >
> > I piddled about with it yesterday, found that you can't change cpufreq
> > governor IFF the tree is configured as rt, but works fine as voluntary
> > preempt.
>
> The problem seems to be this patch: https://lkml.org/lkml/2014/4/8/584
>
> The cpufreq code does nested down_read_trylocks and only the first one
> succeeds:
>
> drivers/cpufreq/cpufreq.c:
> store
> down_read_trylock(cpufreq_rwsem) <- succeeds
> store_scaling_governor
> cpufreq_get_policy
> cpufreq_cpu_get
> down_read_trylock(cpufreq_rwsem) <-- fails
>
> Reverting the above patch 'fixes' the problem. I don't understand Steven's
> commit comment that readers of rwsem are not allowed to nest in mainline
> since this works just fine in mainline.
When we allow multiple readers, this will be allowed. But even in
mainline, if a writer were to come in and block between those two
down_read_trylocks(), the second trylock would fail.
PREEMPT_RT just has that fail all the time as we only allow an rwsem to
be held by a single reader.
-- Steve
>
> ...Juerg
>
>
>
> > I'll poke about for the entertainment value. Having no
> > personal need/use for rt detracts from its hobby value somewhat, but rt
> > problems do have a tendency to be 'entertaining'.
> >
> > I'll follow up with a few patches that folks can apply to their trees if
> > they so desire. There being no devel tree to submit against, I can't do
> > a proper submission (rules), and some of them you surely don't want :)
> >
> > -Mike
> >
> >
> >
> >
On Wed, Nov 5, 2014 at 3:27 PM, Steven Rostedt <[email protected]> wrote:
> On Wed, 5 Nov 2014 14:50:41 +0100
> Juerg Haefliger <[email protected]> wrote:
>
>> On Sun, Nov 2, 2014 at 8:30 AM, Mike Galbraith <[email protected]>
>> wrote:
>> >
>> > On Fri, 2014-10-31 at 17:03 -0400, Steven Rostedt wrote:
>> > > Dear RT Folks,
>> > >
>> > > I'm pleased to announce the 3.14.23-rt20 stable release.
>> > >
>> > > This is the first 3.14-rt release in the stable-rt series. Normally I
>> > > wait till the next development release is out before I pull in a new
>> > > one. That is, I would pull in 3.14-rt when 3.16-rt or later was
>> > > released. But because development is now moving at a "hobbyist rate"
>> > > (read http://lwn.net/Articles/617140/ for details)
>> > > and 3.14-rt is no longer being developed against, I figured it was
>> > time
>> > > to put it under the "stable-rt" umbrella.
>> >
>> > I piddled about with it yesterday, found that you can't change cpufreq
>> > governor IFF the tree is configured as rt, but works fine as voluntary
>> > preempt.
>>
>> The problem seems to be this patch: https://lkml.org/lkml/2014/4/8/584
>>
>> The cpufreq code does nested down_read_trylocks and only the first one
>> succeeds:
>>
>> drivers/cpufreq/cpufreq.c:
>> store
>> down_read_trylock(cpufreq_rwsem) <- succeeds
>> store_scaling_governor
>> cpufreq_get_policy
>> cpufreq_cpu_get
>> down_read_trylock(cpufreq_rwsem) <-- fails
>>
>> Reverting the above patch 'fixes' the problem. I don't understand Steven's
>> commit comment that readers of rwsem are not allowed to nest in mainline
>> since this works just fine in mainline.
>
> When we allow multiple readers, this will be allowed. But even in
> mainline, if a writer were to come in and block between those two
> down_read_trylocks(), the second trylock would fail.
Thanks for the explanation. So is this considered a temporary failure
until multiple readers are allowed or does cpufreq need fixing or
something else? Just trying to figure out what to do next.
...Juerg
> PREEMPT_RT just has that fail all the time as we only allow an rwsem to
> be held by a single reader.
>
>
> -- Steve
>
>
>
>>
>> ...Juerg
>>
>>
>>
>> > I'll poke about for the entertainment value. Having no
>> > personal need/use for rt detracts from its hobby value somewhat, but rt
>> > problems do have a tendency to be 'entertaining'.
>> >
>> > I'll follow up with a few patches that folks can apply to their trees if
>> > they so desire. There being no devel tree to submit against, I can't do
>> > a proper submission (rules), and some of them you surely don't want :)
>> >
>> > -Mike
>> >
>> >
>> >
>> >
>
On Wed, 5 Nov 2014 15:43:24 +0100
Juerg Haefliger <[email protected]> wrote:
> Thanks for the explanation. So is this considered a temporary failure
> until multiple readers are allowed or does cpufreq need fixing or
> something else? Just trying to figure out what to do next.
Good question. Unfortunately I don't know the answer to that.
-- Steve
On Wed, 5 Nov 2014 14:50:41 +0100 Juerg Haefliger <[email protected]> wrote:
> The cpufreq code does nested down_read_trylocks and only the first one succeeds:
>drivers/cpufreq/cpufreq.c:
>store
> down_read_trylock(cpufreq_rwsem) <- succeeds
> store_scaling_governor
> cpufreq_get_policy
> cpufreq_cpu_get
> down_read_trylock(cpufreq_rwsem) <-- fails
On a related note: I think this patch/issue may be the cause of the
-rt CPU frequency scaling bug I reported a couple of months ago.
http://comments.gmane.org/gmane.linux.rt.user/12472
I'm currently using the performance governor by default as a
workaround; thanks to JackWinter for packaging in the ArchAudio repos.
Cheers, -Harry
--
http://www.openavproductions.com
On Wed, 2014-11-05 at 10:00 -0500, Steven Rostedt wrote:
> On Wed, 5 Nov 2014 15:43:24 +0100
> Juerg Haefliger <[email protected]> wrote:
>
> > Thanks for the explanation. So is this considered a temporary failure
> > until multiple readers are allowed or does cpufreq need fixing or
> > something else? Just trying to figure out what to do next.
>
> Good question. Unfortunately I don't know the answer to that.
[RFC PATCH RT] rwsem: The return of multi-reader PI rwsems
The above springs to mind.
-Mike
On Wed, 5 Nov 2014, Steven Rostedt wrote:
> On Wed, 5 Nov 2014 14:50:41 +0100
> Juerg Haefliger <[email protected]> wrote:
>
> > On Sun, Nov 2, 2014 at 8:30 AM, Mike Galbraith <[email protected]>
> > wrote:
> > >
> > > On Fri, 2014-10-31 at 17:03 -0400, Steven Rostedt wrote:
> > > > Dear RT Folks,
> > > >
> > > > I'm pleased to announce the 3.14.23-rt20 stable release.
> > > >
> > > > This is the first 3.14-rt release in the stable-rt series. Normally I
> > > > wait till the next development release is out before I pull in a new
> > > > one. That is, I would pull in 3.14-rt when 3.16-rt or later was
> > > > released. But because development is now moving at a "hobbyist rate"
> > > > (read http://lwn.net/Articles/617140/ for details)
> > > > and 3.14-rt is no longer being developed against, I figured it was
> > > time
> > > > to put it under the "stable-rt" umbrella.
> > >
> > > I piddled about with it yesterday, found that you can't change cpufreq
> > > governor IFF the tree is configured as rt, but works fine as voluntary
> > > preempt.
> >
> > The problem seems to be this patch: https://lkml.org/lkml/2014/4/8/584
> >
> > The cpufreq code does nested down_read_trylocks and only the first one
> > succeeds:
> >
> > drivers/cpufreq/cpufreq.c:
> > store
> > down_read_trylock(cpufreq_rwsem) <- succeeds
> > store_scaling_governor
> > cpufreq_get_policy
> > cpufreq_cpu_get
> > down_read_trylock(cpufreq_rwsem) <-- fails
> >
> > Reverting the above patch 'fixes' the problem. I don't understand Steven's
> > commit comment that readers of rwsem are not allowed to nest in mainline
> > since this works just fine in mainline.
>
> When we allow multiple readers, this will be allowed. But even in
> mainline, if a writer were to come in and block between those two
> down_read_trylocks(), the second trylock would fail.
>
> PREEMPT_RT just has that fail all the time as we only allow an rwsem to
> be held by a single reader.
Errm. The reader holds the sem already. So that's a recursive read
lock which should always succeed. And rt_read_trylock() has that
implemented.
Thanks,
tglx
On Wed, 5 Nov 2014, Mike Galbraith wrote:
> On Wed, 2014-11-05 at 10:00 -0500, Steven Rostedt wrote:
> > On Wed, 5 Nov 2014 15:43:24 +0100
> > Juerg Haefliger <[email protected]> wrote:
> >
> > > Thanks for the explanation. So is this considered a temporary failure
> > > until multiple readers are allowed or does cpufreq need fixing or
> > > something else? Just trying to figure out what to do next.
> >
> > Good question. Unfortunately I don't know the answer to that.
>
> [RFC PATCH RT] rwsem: The return of multi-reader PI rwsems
>
> The above springs to mind.
Shudder!
On Wed, 5 Nov 2014, Thomas Gleixner wrote:
> On Wed, 5 Nov 2014, Steven Rostedt wrote:
> > On Wed, 5 Nov 2014 14:50:41 +0100
> > Juerg Haefliger <[email protected]> wrote:
> >
> > > On Sun, Nov 2, 2014 at 8:30 AM, Mike Galbraith <[email protected]>
> > > wrote:
> > > >
> > > > On Fri, 2014-10-31 at 17:03 -0400, Steven Rostedt wrote:
> > > > > Dear RT Folks,
> > > > >
> > > > > I'm pleased to announce the 3.14.23-rt20 stable release.
> > > > >
> > > > > This is the first 3.14-rt release in the stable-rt series. Normally I
> > > > > wait till the next development release is out before I pull in a new
> > > > > one. That is, I would pull in 3.14-rt when 3.16-rt or later was
> > > > > released. But because development is now moving at a "hobbyist rate"
> > > > > (read http://lwn.net/Articles/617140/ for details)
> > > > > and 3.14-rt is no longer being developed against, I figured it was
> > > > time
> > > > > to put it under the "stable-rt" umbrella.
> > > >
> > > > I piddled about with it yesterday, found that you can't change cpufreq
> > > > governor IFF the tree is configured as rt, but works fine as voluntary
> > > > preempt.
> > >
> > > The problem seems to be this patch: https://lkml.org/lkml/2014/4/8/584
> > >
> > > The cpufreq code does nested down_read_trylocks and only the first one
> > > succeeds:
> > >
> > > drivers/cpufreq/cpufreq.c:
> > > store
> > > down_read_trylock(cpufreq_rwsem) <- succeeds
> > > store_scaling_governor
> > > cpufreq_get_policy
> > > cpufreq_cpu_get
> > > down_read_trylock(cpufreq_rwsem) <-- fails
> > >
> > > Reverting the above patch 'fixes' the problem. I don't understand Steven's
> > > commit comment that readers of rwsem are not allowed to nest in mainline
> > > since this works just fine in mainline.
> >
> > When we allow multiple readers, this will be allowed. But even in
> > mainline, if a writer were to come in and block between those two
> > down_read_trylocks(), the second trylock would fail.
> >
> > PREEMPT_RT just has that fail all the time as we only allow an rwsem to
> > be held by a single reader.
>
> Errm. The reader holds the sem already. So that's a recursive read
> lock which should always succeed. And rt_read_trylock() has that
> implemented.
Bah. That's the rwlock path. Untested patch below should fix the issue.
Thanks,
tglx
------------------------>
diff --git a/include/linux/rwsem_rt.h b/include/linux/rwsem_rt.h
index 0065b08fbb7a..924c2d274ab5 100644
--- a/include/linux/rwsem_rt.h
+++ b/include/linux/rwsem_rt.h
@@ -20,6 +20,7 @@
struct rw_semaphore {
struct rt_mutex lock;
+ int read_depth;
#ifdef CONFIG_DEBUG_LOCK_ALLOC
struct lockdep_map dep_map;
#endif
diff --git a/kernel/locking/rt.c b/kernel/locking/rt.c
index 90b8ba03e2a4..a48bff77e2a8 100644
--- a/kernel/locking/rt.c
+++ b/kernel/locking/rt.c
@@ -321,8 +321,11 @@ EXPORT_SYMBOL(rt_up_write);
void rt_up_read(struct rw_semaphore *rwsem)
{
- rwsem_release(&rwsem->dep_map, 1, _RET_IP_);
- rt_mutex_unlock(&rwsem->lock);
+ /* Release the lock only when read_depth is down to 0 */
+ if (--rwsem->read_depth == 0) {
+ rwsem_release(&rwsem->dep_map, 1, _RET_IP_);
+ rt_mutex_unlock(&rwsem->lock);
+ }
}
EXPORT_SYMBOL(rt_up_read);
@@ -332,7 +335,9 @@ EXPORT_SYMBOL(rt_up_read);
*/
void rt_downgrade_write(struct rw_semaphore *rwsem)
{
- BUG_ON(rt_mutex_owner(&rwsem->lock) != current);
+ BUG_ON(rt_mutex_owner(&rwsem->lock) != current ||
+ rwsem->read_depth != 0);
+ rwsem->read_depth++;
}
EXPORT_SYMBOL(rt_downgrade_write);
@@ -370,11 +375,21 @@ EXPORT_SYMBOL(rt_down_write_nested_lock);
int rt_down_read_trylock(struct rw_semaphore *rwsem)
{
- int ret;
+ int ret = 1;
+
+ /*
+ * recursive read locks succeed when current owns the lock
+ */
+ if (rt_mutex_owner(&rwsem->lock) != current) {
+ ret = rt_mutex_trylock(&rwsem->lock);
+ if (ret)
+ rwsem_acquire(&rwsem->dep_map, 0, 1, _RET_IP_);
+ } else if (!rwsem->read_depth) {
+ ret = 0;
+ }
- ret = rt_mutex_trylock(&rwsem->lock);
if (ret)
- rwsem_acquire(&rwsem->dep_map, 0, 1, _RET_IP_);
+ rwsem->read_depth++;
return ret;
}
@@ -382,8 +397,14 @@ EXPORT_SYMBOL(rt_down_read_trylock);
static void __rt_down_read(struct rw_semaphore *rwsem, int subclass)
{
- rwsem_acquire(&rwsem->dep_map, subclass, 0, _RET_IP_);
- rt_mutex_lock(&rwsem->lock);
+ /*
+ * recursive read locks succeed when current owns the lock
+ */
+ if (rt_mutex_owner(&rwsem->lock) != current) {
+ rwsem_acquire(&rwsem->dep_map, subclass, 0, _RET_IP_);
+ rt_mutex_lock(&rwsem->lock);
+ }
+ rwsem->read_depth++;
}
void rt_down_read(struct rw_semaphore *rwsem)
@@ -408,6 +429,7 @@ void __rt_rwsem_init(struct rw_semaphore *rwsem, const char *name,
debug_check_no_locks_freed((void *)rwsem, sizeof(*rwsem));
lockdep_init_map(&rwsem->dep_map, name, key, 0);
#endif
+ rwsem->read_depth = 0;
rwsem->lock.save_state = 0;
}
EXPORT_SYMBOL(__rt_rwsem_init);
On Wed, 5 Nov 2014 23:29:32 +0100 (CET)
Thomas Gleixner <[email protected]> wrote:
> > > When we allow multiple readers, this will be allowed. But even in
> > > mainline, if a writer were to come in and block between those two
> > > down_read_trylocks(), the second trylock would fail.
> > >
> > > PREEMPT_RT just has that fail all the time as we only allow an rwsem to
> > > be held by a single reader.
> >
> > Errm. The reader holds the sem already. So that's a recursive read
> > lock which should always succeed. And rt_read_trylock() has that
> > implemented.
>
> Bah. That's the rwlock path. Untested patch below should fix the issue.
This is basically a revert of my patch that removed rwsems as being
recursive, because they are not recursive in mainline.
If you have the following:
down_read(&A);
down_write(&A);
down_read(&A);
in mainline, you will have a deadlock. With this change, it will not
deadlock on -rt.
This is probably why that cpu governor code uses down_read_trylock()
otherwise, it would have suffered from possible deadlock scenarios.
But, for a quick solution, just use this patch. I'll start working on
the multi rwsem readers again, and then I'll have to revert this to do
that. But when we have multi readers again, we wont need to have this
hack.
-- Steve
On Wed, 5 Nov 2014, Steven Rostedt wrote:
> On Wed, 5 Nov 2014 23:29:32 +0100 (CET)
> Thomas Gleixner <[email protected]> wrote:
>
> > > > When we allow multiple readers, this will be allowed. But even in
> > > > mainline, if a writer were to come in and block between those two
> > > > down_read_trylocks(), the second trylock would fail.
> > > >
> > > > PREEMPT_RT just has that fail all the time as we only allow an rwsem to
> > > > be held by a single reader.
> > >
> > > Errm. The reader holds the sem already. So that's a recursive read
> > > lock which should always succeed. And rt_read_trylock() has that
> > > implemented.
> >
> > Bah. That's the rwlock path. Untested patch below should fix the issue.
>
> This is basically a revert of my patch that removed rwsems as being
> recursive, because they are not recursive in mainline.
Well, they are. Just not in the presence of a writer.
Which is silly, but due to the fact that we do not track the readers
unavoidable. If the reader holds the sem already there is no real
reason why it should not succeed with the recursive lock.
If anything relies on that behaviour then we have a way bigger
problem at some other place.
> If you have the following:
>
> down_read(&A);
>
> down_write(&A);
>
> down_read(&A);
>
> in mainline, you will have a deadlock. With this change, it will not
> deadlock on -rt.
And that's fine on RT in the face of a single reader.
> This is probably why that cpu governor code uses down_read_trylock()
> otherwise, it would have suffered from possible deadlock scenarios.
Right.
> But, for a quick solution, just use this patch. I'll start working on
> the multi rwsem readers again, and then I'll have to revert this to do
> that. But when we have multi readers again, we wont need to have this
> hack.
And how exactly are multi reader rwsem solving that problem?
Not at all. You still need to track recursion of an already 'owning'
reader unless you want to add it twice on the 'owner' list.
Thanks,
tglx