linux-kernel - Re: [PATCH 3/3] rcu: Drive configuration directly from SMP and PREEMPT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 21 Nov 2011 18:46:09 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	John Kacur <jkacur@...hat.com>
Cc:	lkml <linux-kernel@...r.kernel.org>,
	rt-users <linux-rt-users@...r.kernel.org>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Subject: Re: [PATCH 3/3] rcu: Drive configuration directly from SMP and
 PREEMPT

On Tue, 2011-11-22 at 00:18 +0100, John Kacur wrote:

> Imagine you have a uni-processor system and want to do real-time.
> According to the descriptions in init/Kconfig, you would want to
> select TINY_PREEMPT_RCU. The description is
> 
> 	  This option selects the RCU implementation that is designed
> 	  for real-time UP systems.  This option greatly reduces the
> 	  memory footprint of RCU.
> 
> Without this patch, you cannot choose this option because of the &&
> !PREEMPT_RT_FULL
> So, that is a bug, and makes this patch appropriate for stable.


3.0-rt never supported rcutiny, which means adding it now is not a bug
fix but a new feature. Sure, it may have been a mistake that Thomas kept
rcutiny out for 3.0-rt, but because 3.0-rt never supported it, and
3.0-rt can fully support rcutree with !SMP, there is no bug to be fixed
here. You're adding a new feature to stable, not fixing someones
problem.

> 
> I suppose if you want to be really conservative, you can say we only
> need that third hunk.
> However, this upstream patch, makes these options in v3.0-rt match the
> options in v3.2-rc2-rt3.
> 
> Furthermore, it doesn't seem like a good idea to me to support
> configurations in a stable branch that are not supported upstream.

No, upstream changed the game, in which the configuration can't be
supported. But the stable release can fully support this configuration.
there's no reason to this change just because the latest tree can't
support it. It's like we have to deprecate everything in stable that has
been deprecated in upstream.

Stable is not a mirror of upstream, it's a snapshot in time. Only if we
discover something that crashes, or causes huge latencies do we want to
update stable. Not when we realized that a feature wasn't supported by
-rt.

-- Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/