Bug 572520 - suspicious rcu_dereference_check() usage: cgroup.h:533 invoked rcu_dereference_check() without protection
Summary: suspicious rcu_dereference_check() usage: cgroup.h:533 invoked rcu_dereferen...
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 14
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
: 593026 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-03-11 12:54 UTC by Aioanei Rares
Modified: 2011-10-11 18:20 UTC (History)
18 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2011-10-11 18:20:17 UTC


Attachments (Terms of Use)
full dmesg output after boot (67.60 KB, text/plain)
2010-09-30 18:57 UTC, Joel
no flags Details

Description Aioanei Rares 2010-03-11 12:54:52 UTC
Description of problem:
I found the following in /var/log/messages in a Rawhide guest running on KVM

Version-Release number of selected component (if applicable):

2.6.34-0.10.rc1.git0.fc14.x86_64

How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

The whole messages as found in /var/log/messages : 

Mar 11 14:34:50 localhost kernel:
Mar 11 14:34:50 localhost kernel: ===================================================
Mar 11 14:34:50 localhost kernel: [ INFO: suspicious rcu_dereference_check() usage. ]
Mar 11 14:34:50 localhost kernel: ---------------------------------------------------
Mar 11 14:34:50 localhost kernel: include/linux/cgroup.h:492 invoked rcu_dereference_check() without protection!
Mar 11 14:34:50 localhost kernel:
Mar 11 14:34:50 localhost kernel: other info that might help us debug this:
Mar 11 14:34:50 localhost kernel:
Mar 11 14:34:50 localhost kernel: 1 lock held by swapper/0:
Mar 11 14:34:50 localhost kernel: #0:  (&rq->lock){......}, at: [<ffffffff8147c40d>] init_idle+0x30/0xcf
Mar 11 14:34:50 localhost kernel:
Mar 11 14:34:50 localhost kernel: stack backtrace:
Mar 11 14:34:50 localhost kernel: Pid: 0, comm: swapper Not tainted 2.6.34-0.10.rc1.git0.fc14.x86_64 #1
Mar 11 14:34:50 localhost kernel: Call Trace:
Mar 11 14:34:50 localhost kernel: [<ffffffff8107cf10>] lockdep_rcu_dereference+0x8c/0x95
Mar 11 14:34:50 localhost kernel: [<ffffffff8103ec6b>] task_subsys_state+0x3d/0x55
Mar 11 14:34:50 localhost kernel: [<ffffffff8103ec9f>] set_task_rq+0x1c/0x87
Mar 11 14:34:50 localhost kernel: [<ffffffff8147c465>] init_idle+0x88/0xcf
Mar 11 14:34:50 localhost kernel: [<ffffffff81d9a31e>] sched_init+0x41b/0x46b
Mar 11 14:34:50 localhost kernel: [<ffffffff81d81ca2>] start_kernel+0x24d/0x44b
Mar 11 14:34:50 localhost kernel: [<ffffffff81d812bc>] x86_64_start_reservations+0xa7/0xab
Mar 11 14:34:50 localhost kernel: [<ffffffff81d813b8>] x86_64_start_kernel+0xf8/0x107
Mar 11 14:34:50 localhost kernel: Hierarchical RCU implementation.
Mar 11 14:34:50 localhost kernel: NR_IRQS:33024 nr_irqs:536

Comment 1 Tom London 2010-03-30 20:13:03 UTC
I'm seeing something similar:

ACPI: Core revision 20100121
ftrace: converting mcount calls to 0f 1f 44 00 00
ftrace: allocating 20730 entries in 82 pages

===================================================
[ INFO: suspicious rcu_dereference_check() usage. ]
---------------------------------------------------
include/linux/cgroup.h:533 invoked rcu_dereference_check() without protection!

other info that might help us debug this:


rcu_scheduler_active = 1, debug_locks = 0
no locks held by swapper/0.

stack backtrace:
Pid: 0, comm: swapper Not tainted 2.6.34-0.19.rc2.git4.fc14.x86_64 #1
Call Trace:
 [<ffffffff8107c5a6>] lockdep_rcu_dereference+0xaa/0xb3
 [<ffffffff8103e876>] task_subsys_state+0x46/0x5e
 [<ffffffff8103e8aa>] set_task_rq+0x1c/0x87
 [<ffffffff81048048>] set_task_cpu+0xbf/0xd0
 [<ffffffff8104862a>] sched_fork+0xa7/0x116
 [<ffffffff8104e7ca>] copy_process+0x6bb/0x1250
 [<ffffffff8104f4d9>] do_fork+0x17a/0x395
 [<ffffffff81010491>] ? native_sched_clock+0x2d/0x5f
 [<ffffffff8147cca4>] ? mutex_unlock+0xe/0x10
 [<ffffffff81070bfe>] ? sched_clock_cpu+0xc3/0xce
 [<ffffffff8107b0ef>] ? trace_hardirqs_off+0xd/0xf
 [<ffffffff81070c4c>] ? cpu_clock+0x43/0x5e
 [<ffffffff81011160>] kernel_thread+0x75/0x77
 [<ffffffff81d81584>] ? kernel_init+0x0/0x2a3
 [<ffffffff8100aaa0>] ? kernel_thread_helper+0x0/0x10
 [<ffffffff81068f00>] ? rcu_scheduler_starting+0x34/0x58
 [<ffffffff814655e2>] rest_init+0x26/0xca
 [<ffffffff81d81e95>] start_kernel+0x440/0x44b
 [<ffffffff81d812bc>] x86_64_start_reservations+0xa7/0xab
 [<ffffffff81d813b8>] x86_64_start_kernel+0xf8/0x107
DMAR: Host address width 36
DMAR: DRHD base: 0x000000feb03000 flags: 0x0

Comment 2 William Lovaton 2010-04-03 04:54:08 UTC
I'm seeing this too with the latest Rawhide fc14:

kernel: ===================================================
kernel: [ INFO: suspicious rcu_dereference_check() usage. ]
kernel: ---------------------------------------------------
kernel: include/linux/cgroup.h:533 invoked rcu_dereference_check() without protection!
kernel:
kernel: other info that might help us debug this:
kernel:
kernel:
kernel: rcu_scheduler_active = 1, debug_locks = 0
kernel: no locks held by swapper/0.
kernel:
kernel: stack backtrace:
kernel: Pid: 0, comm: swapper Not tainted 2.6.34-0.19.rc2.git4.fc14.i686.PAE #1
kernel: Call Trace:
kernel: [<c07c9617>] ? printk+0x14/0x1d
kernel: [<c0468a54>] lockdep_rcu_dereference+0x7d/0x86
kernel: [<c0432edd>] task_subsys_state+0x41/0x51
kernel: [<c0432f05>] set_task_rq+0x18/0x70
kernel: [<c043c23c>] set_task_cpu+0xa8/0xb6
kernel: [<c043c71e>] sched_fork+0x90/0xf1
kernel: [<c04406b9>] copy_process+0x5a1/0xec2
kernel: [<c040d1b5>] ? sched_clock+0x9/0xd
kernel: [<c0441111>] do_fork+0x137/0x2ec
kernel: [<c0468e00>] ? mark_lock+0x1e/0x1e1
kernel: [<c0469006>] ? mark_held_locks+0x43/0x5b
kernel: [<c0467e19>] ? trace_hardirqs_off+0xb/0xd
kernel: [<c045dbde>] ? cpu_clock+0x3b/0x53
kernel: [<c07ca502>] ? mutex_unlock+0xd/0xf
kernel: [<c0a57254>] ? kernel_init+0x0/0x21d
kernel: [<c040e295>] kernel_thread+0x7e/0x86
kernel: [<c0a57254>] ? kernel_init+0x0/0x21d
kernel: [<c0408f3c>] ? kernel_thread_helper+0x0/0x10
kernel: [<c07b639f>] rest_init+0x1f/0xa1
kernel: [<c0a579b2>] start_kernel+0x37d/0x382
kernel: [<c0a570c2>] i386_start_kernel+0xb1/0xb8

Bug #571609 got closed as UPSTREAM because of this:
http://lkml.org/lkml/2010/3/10/453

Comment 3 Chuck Ebbert 2010-04-06 11:15:59 UTC
(In reply to comment #1)
> I'm seeing something similar:

Is it still happening in 2.6.34-rc3-git3?

Comment 4 Tom London 2010-04-06 13:21:26 UTC
Well, still happening with 2.6.34-0.28.rc3.git3.fc14.x86_64:

ftrace: converting mcount calls to 0f 1f 44 00 00
ftrace: allocating 20748 entries in 82 pages

===================================================
[ INFO: suspicious rcu_dereference_check() usage. ]
---------------------------------------------------
include/linux/cgroup.h:533 invoked rcu_dereference_check() without protection!

other info that might help us debug this:


rcu_scheduler_active = 1, debug_locks = 0
no locks held by swapper/0.

stack backtrace:
Pid: 0, comm: swapper Not tainted 2.6.34-0.28.rc3.git3.fc14.x86_64 #1
Call Trace:
 [<ffffffff8107bb06>] lockdep_rcu_dereference+0xaa/0xb3
 [<ffffffff8103e9d7>] task_subsys_state+0x46/0x5e
 [<ffffffff8103ea0b>] set_task_rq+0x1c/0x87
 [<ffffffff81049975>] set_task_cpu+0xa1/0xb2
 [<ffffffff81049f55>] sched_fork+0xa7/0x116
 [<ffffffff8104e966>] copy_process+0x6bb/0x1250
 [<ffffffff81078bf5>] ? tick_nohz_stop_sched_tick+0x360/0x3a9
 [<ffffffff8104f675>] do_fork+0x17a/0x395
 [<ffffffff81010491>] ? native_sched_clock+0x2d/0x5f
 [<ffffffff8147d58c>] ? mutex_unlock+0xe/0x10
 [<ffffffff81070146>] ? sched_clock_cpu+0xc3/0xce
 [<ffffffff8107a64f>] ? trace_hardirqs_off+0xd/0xf
 [<ffffffff81070194>] ? cpu_clock+0x43/0x5e
 [<ffffffff81011160>] kernel_thread+0x75/0x77
 [<ffffffff81d81590>] ? kernel_init+0x0/0x2a3
 [<ffffffff8100aaa0>] ? kernel_thread_helper+0x0/0x10
 [<ffffffff81068448>] ? rcu_scheduler_starting+0x34/0x58
 [<ffffffff81465ec2>] rest_init+0x26/0xca
 [<ffffffff81d81ea1>] start_kernel+0x440/0x44b
 [<ffffffff81d812c8>] x86_64_start_reservations+0xb3/0xb7
 [<ffffffff81d813c4>] x86_64_start_kernel+0xf8/0x107
DMAR: Host address width 36
DMAR: DRHD base: 0x000000feb03000 flags: 0x0
IOMMU feb03000: ver 1:0 cap c9008020e30260 ecap 1000
DMAR: DRHD base: 0x000000feb01000 flags: 0x0
IOMMU feb01000: ver 1:0 cap c0000020630260 ecap 1000
DMAR: DRHD base: 0x000000feb00000 flags: 0x0
IOMMU feb00000: ver 1:0 cap c0000020630270 ecap 1000
DMAR: DRHD base: 0x000000feb02000 flags: 0x1
IOMMU feb02000: ver 1:0 cap c9008020630260 ecap 1000

Comment 5 Alexandr Kara 2010-04-10 12:38:37 UTC
I have version 2.6.34-0.28.rc3.git3.fc14.x86_64 (not tainted) and I am seeing the same stack trace as in comment #c1 from Tom London early in the boot process.

Comment 6 Frank Murphy 2010-06-01 18:36:54 UTC
kernel-2.6.34-18.fc14.x86_64
Almost near the end of dmesg, not quite tail.
full dmesg: http://www.frankly3d.com/dmesg



===================================================
[ INFO: suspicious rcu_dereference_check() usage. ]
---------------------------------------------------
include/net/inet_timewait_sock.h:227 invoked rcu_dereference_check() without protection!

other info that might help us debug this:


rcu_scheduler_active = 1, debug_locks = 0
1 lock held by swapper/0:
 #0:  (net/ipv4/tcp_minisocks.c:41){+.-...}, at: [<ffffffff8105cfa3>] run_timer_softirq+0x193/0x2ef

stack backtrace:
Pid: 0, comm: swapper Not tainted 2.6.34-18.fc14.x86_64 #1
Call Trace:
 <IRQ>  [<ffffffff8107bfa2>] lockdep_rcu_dereference+0xaa/0xb3
 [<ffffffff8140fac1>] twsk_net+0x44/0x4c
 [<ffffffff8141005f>] __inet_twsk_kill+0x7e/0xd5
 [<ffffffff81410479>] inet_twdr_do_twkill_work+0x5e/0xbf
 [<ffffffff814105c7>] inet_twdr_hangman+0x35/0x9a
 [<ffffffff8105d035>] run_timer_softirq+0x225/0x2ef
 [<ffffffff8105cfa3>] ? run_timer_softirq+0x193/0x2ef
 [<ffffffff81010385>] ? sched_clock+0x9/0xd
 [<ffffffff810706f9>] ? sched_clock_local+0x1c/0x82
 [<ffffffff81410592>] ? inet_twdr_hangman+0x0/0x9a
 [<ffffffff81056a76>] ? __do_softirq+0x76/0x1d7
 [<ffffffff81056afd>] __do_softirq+0xfd/0x1d7
 [<ffffffff81078845>] ? tick_program_event+0x2a/0x2c
 [<ffffffff8100abdc>] call_softirq+0x1c/0x30
 [<ffffffff8100c3df>] do_softirq+0x4b/0xa3
 [<ffffffff810566e4>] irq_exit+0x4a/0x8c
 [<ffffffff81489430>] smp_apic_timer_interrupt+0x8d/0x9b
 [<ffffffff8100a693>] apic_timer_interrupt+0x13/0x20
 <EOI>  [<ffffffff8101196d>] ? mwait_idle+0x82/0x94
 [<ffffffff81011964>] ? mwait_idle+0x79/0x94
 [<ffffffff81008c04>] cpu_idle+0xaf/0xe9
 [<ffffffff8146a58f>] rest_init+0xc3/0xca
 [<ffffffff8146a4cc>] ? rest_init+0x0/0xca
 [<ffffffff81d82ea1>] start_kernel+0x440/0x44b
 [<ffffffff81d822c8>] x86_64_start_reservations+0xb3/0xb7
 [<ffffffff81d823c4>] x86_64_start_kernel+0xf8/0x107

Comment 7 Orion Poplawski 2010-07-19 15:07:42 UTC
*** Bug 593026 has been marked as a duplicate of this bug. ***

Comment 8 Bug Zapper 2010-07-30 11:02:03 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 9 Bill Davidsen 2010-09-01 17:25:13 UTC
This problem persists in the recent 2.6.35.4-12.fc14.i686 kernel release.

Comment 10 Jeff Raber 2010-09-21 19:08:14 UTC
I am seeing this in 2.6.35.4-28.fc14.x86_64.

===================================================
[ INFO: suspicious rcu_dereference_check() usage. ]
---------------------------------------------------
include/linux/cgroup.h:542 invoked rcu_dereference_check() without protection!

other info that might help us debug this:


rcu_scheduler_active = 1, debug_locks = 0
1 lock held by swapper/1:
 #0:  (net_mutex){+.+.+.}, at: [<ffffffff813e9010>] register_pernet_subsys+0x1f/0x47

stack backtrace:
Pid: 1, comm: swapper Not tainted 2.6.35.4-28.fc14.x86_64 #1
Call Trace:
 [<ffffffff8107bd3a>] lockdep_rcu_dereference+0xaa/0xb3
 [<ffffffff813e04b9>] sock_update_classid+0x7c/0xa2
 [<ffffffff813e054a>] sk_alloc+0x6b/0x77
 [<ffffffff8140b281>] __netlink_create+0x37/0xab
 [<ffffffff813f941c>] ? rtnetlink_rcv+0x0/0x2d
 [<ffffffff8140cee1>] netlink_kernel_create+0x74/0x19d
 [<ffffffff8149c3ca>] ? __mutex_lock_common+0x339/0x35b
 [<ffffffff813f7e9c>] rtnetlink_net_init+0x2e/0x48
 [<ffffffff813e8d7a>] ops_init+0xe9/0xff
 [<ffffffff813e8f0d>] register_pernet_operations+0xab/0x130
 [<ffffffff813e901f>] register_pernet_subsys+0x2e/0x47
 [<ffffffff81db7bca>] rtnetlink_init+0x53/0x102
 [<ffffffff81db835c>] netlink_proto_init+0x126/0x143
 [<ffffffff81db8236>] ? netlink_proto_init+0x0/0x143
 [<ffffffff810021b8>] do_one_initcall+0x72/0x186
 [<ffffffff81d78ebc>] kernel_init+0x23b/0x2c9
 [<ffffffff8100aae4>] kernel_thread_helper+0x4/0x10
 [<ffffffff8149e2d0>] ? restore_args+0x0/0x30
 [<ffffffff81d78c81>] ? kernel_init+0x0/0x2c9
 [<ffffffff8100aae0>] ? kernel_thread_helper+0x0/0x10

Comment 11 Jeff Raber 2010-09-21 19:34:48 UTC
(In reply to comment #6)
> kernel-2.6.34-18.fc14.x86_64
> Almost near the end of dmesg, not quite tail.
> full dmesg: http://www.frankly3d.com/dmesg

That link is dead now.  Please attach files to the bug instead of posting links. to avoid this issue.

> 
> 
> 
> ===================================================
> [ INFO: suspicious rcu_dereference_check() usage. ]
> ---------------------------------------------------
> include/net/inet_timewait_sock.h:227 invoked rcu_dereference_check() without
> protection!
> 
This looks like a different bug as it was occurring in inet_timewait_sock.h.  A  patch was applied to address that issue[1].   If you are still seeing this bug with the latest kernel, please open a new bug.

1: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=7ec75c582e639d956ce3afd499f67febe6f902a4;hp=d4c4f07df16c767b8efbc44e7cdf795fac326b33

Comment 12 Frank Murphy 2010-09-21 21:02:49 UTC
(In reply to comment #11)
> (In reply to comment #6)
> > kernel-2.6.34-18.fc14.x86_64
> > Almost near the end of dmesg, not quite tail.
> > full dmesg: http://www.frankly3d.com/dmesg
> 
> That link is dead now.  Please attach files to the bug instead of posting
> links. to avoid this issue.
> 

That was "three months" ago, and no I wasn't going to attach a then4mb dmesg.
Live with it.

Comment 13 Kjartan Maraas 2010-09-26 20:15:22 UTC
I'm seeing the same trace as in comment #10 with the same kernel. Intel Core Duo here. Smolt profile is here: http://www.smolts.org/client/show/pub_686b5402-08df-481f-9a15-e5644461cd5a

Comment 14 Joel 2010-09-30 18:57:05 UTC
Created attachment 450838 [details]
full dmesg output after boot

Seeing the message with 2.5.35.4-28 x86_64

===================================================
[ INFO: suspicious rcu_dereference_check() usage. ]
---------------------------------------------------
include/linux/cgroup.h:542 invoked rcu_dereference_check() without protection!

other info that might help us debug this:


rcu_scheduler_active = 1, debug_locks = 0
1 lock held by swapper/1:
 #0:  (net_mutex){+.+.+.}, at: [<ffffffff813e9010>] register_pernet_subsys+0x1f/0x47

stack backtrace:
Pid: 1, comm: swapper Not tainted 2.6.35.4-28.fc14.x86_64 #1
Call Trace:
 [<ffffffff8107bd3a>] lockdep_rcu_dereference+0xaa/0xb3
 [<ffffffff813e04b9>] sock_update_classid+0x7c/0xa2
 [<ffffffff813e054a>] sk_alloc+0x6b/0x77
 [<ffffffff8140b281>] __netlink_create+0x37/0xab
 [<ffffffff813f941c>] ? rtnetlink_rcv+0x0/0x2d
 [<ffffffff8140cee1>] netlink_kernel_create+0x74/0x19d
 [<ffffffff8149c3ca>] ? __mutex_lock_common+0x339/0x35b
 [<ffffffff813f7e9c>] rtnetlink_net_init+0x2e/0x48
 [<ffffffff813e8d7a>] ops_init+0xe9/0xff
 [<ffffffff813e8f0d>] register_pernet_operations+0xab/0x130
 [<ffffffff813e901f>] register_pernet_subsys+0x2e/0x47
 [<ffffffff81db7bca>] rtnetlink_init+0x53/0x102
 [<ffffffff81db835c>] netlink_proto_init+0x126/0x143
 [<ffffffff81db8236>] ? netlink_proto_init+0x0/0x143
 [<ffffffff810021b8>] do_one_initcall+0x72/0x186
 [<ffffffff81d78ebc>] kernel_init+0x23b/0x2c9
 [<ffffffff8100aae4>] kernel_thread_helper+0x4/0x10
 [<ffffffff8149e2d0>] ? restore_args+0x0/0x30
 [<ffffffff81d78c81>] ? kernel_init+0x0/0x2c9
 [<ffffffff8100aae0>] ? kernel_thread_helper+0x0/0x10

Smolt profile: http://www.smolts.org/client/show/pub_05b82a07-536c-4a95-a715-edd8b0e2acc3

Comment 15 collura 2010-10-07 06:41:09 UTC
[ INFO: suspicious rcu_dereference_check() usage. ]
---------------------------------------------------
include/linux/cgroup.h:542 invoked rcu_dereference_check() without protection!

other info that might help us debug this:


rcu_scheduler_active = 1, debug_locks = 0
1 lock held by swapper/1:
 #0:  (net_mutex){+.+.+.}, at: [<ffffffff813e9010>] register_pernet_subsys+0x1f/0x47

stack backtrace:
Pid: 1, comm: swapper Not tainted 2.6.35.4-28.fc14.x86_64 #1
Call Trace:
 [<ffffffff8107bd3a>] lockdep_rcu_dereference+0xaa/0xb3
 [<ffffffff813e04b9>] sock_update_classid+0x7c/0xa2
 [<ffffffff813e054a>] sk_alloc+0x6b/0x77
 [<ffffffff8140b281>] __netlink_create+0x37/0xab
 [<ffffffff813f941c>] ? rtnetlink_rcv+0x0/0x2d
 [<ffffffff8140cee1>] netlink_kernel_create+0x74/0x19d
 [<ffffffff8149c3ca>] ? __mutex_lock_common+0x339/0x35b
 [<ffffffff813f7e9c>] rtnetlink_net_init+0x2e/0x48
 [<ffffffff813e8d7a>] ops_init+0xe9/0xff
 [<ffffffff813e8f0d>] register_pernet_operations+0xab/0x130
 [<ffffffff813e901f>] register_pernet_subsys+0x2e/0x47
 [<ffffffff81db7bca>] rtnetlink_init+0x53/0x102
 [<ffffffff81db835c>] netlink_proto_init+0x126/0x143
 [<ffffffff81db8236>] ? netlink_proto_init+0x0/0x143
 [<ffffffff810021b8>] do_one_initcall+0x72/0x186
 [<ffffffff81d78ebc>] kernel_init+0x23b/0x2c9
 [<ffffffff8100aae4>] kernel_thread_helper+0x4/0x10
 [<ffffffff8149e2d0>] ? restore_args+0x0/0x30
 [<ffffffff81d78c81>] ? kernel_init+0x0/0x2c9
 [<ffffffff8100aae0>] ? kernel_thread_helper+0x0/0x10
TOM: 00000000c0000000 aka 3072M
Fam 10h mmconf [f7000000, f7ffffff]
ACPI: bus type pci registered

Comment 16 Joel 2010-10-14 13:09:25 UTC
Not seeing these messages anymore on my machine with 2.6.35.6-39.fc14.x86_64.

Comment 17 Josh Boyer 2011-08-26 15:05:22 UTC
If anyone is seeing these messages on the latest f14 kernel, please attach the output.

Comment 18 Dave Jones 2011-10-11 18:20:17 UTC
Should be fixed in the current updates.  If not, f14 is unlikely to see changes beyond security fixes unless they are identified easily backported fixes at this point in its lifecycle.


Note You need to log in before you can comment on or make changes to this bug.