Skip to contentSkip to conversation

conditionally reschedule in mls_convert_context while loading selinux policy.

PATCH Applied Dave Jones 3 participants 3 messages May 15, 2014 SELinux security module

lore
Share & tools
lore

Dave Jones

author
#0 lore raw

PATCH 1/2 conditionally reschedule in mls_convert_context while loading selinux policy.

On a slow machine (with debugging enabled), upgrading selinux policy may take a considerable amount of time. Long enough that the softlockup detector gets triggered.

The backtrace looks like this..

Quoted 21 lines
BUG: soft lockup - CPU#2 stuck for 23s! [load_policy:19045]
Call Trace:
 [<ffffffff81221ddf>] symcmp+0xf/0x20
 [<ffffffff81221c27>] hashtab_search+0x47/0x80
 [<ffffffff8122e96c>] mls_convert_context+0xdc/0x1c0
 [<ffffffff812294e8>] convert_context+0x378/0x460
 [<ffffffff81229170>] ? security_context_to_sid_core+0x240/0x240
 [<ffffffff812221b5>] sidtab_map+0x45/0x80
 [<ffffffff8122bb9f>] security_load_policy+0x3ff/0x580
 [<ffffffff810788a8>] ? sched_clock_cpu+0xa8/0x100
 [<ffffffff810786dd>] ? sched_clock_local+0x1d/0x80
 [<ffffffff810788a8>] ? sched_clock_cpu+0xa8/0x100
 [<ffffffff8103096a>] ? __change_page_attr_set_clr+0x82a/0xa50
 [<ffffffff810786dd>] ? sched_clock_local+0x1d/0x80
 [<ffffffff810788a8>] ? sched_clock_cpu+0xa8/0x100
 [<ffffffff8103096a>] ? __change_page_attr_set_clr+0x82a/0xa50
 [<ffffffff810788a8>] ? sched_clock_cpu+0xa8/0x100
 [<ffffffff81534ddc>] ? retint_restore_args+0xe/0xe
 [<ffffffff8109c82d>] ? trace_hardirqs_on_caller+0xfd/0x1c0
 [<ffffffff81279a2e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
 [<ffffffff810d28a8>] ? rcu_irq_exit+0x68/0xb0
Quoted 8 lines
 [<ffffffff81534ddc>] ? retint_restore_args+0xe/0xe
 [<ffffffff8121e947>] sel_write_load+0xa7/0x770
 [<ffffffff81139633>] ? vfs_write+0x1c3/0x200
 [<ffffffff81210e8e>] ? security_file_permission+0x1e/0xa0
 [<ffffffff8113952b>] vfs_write+0xbb/0x200
 [<ffffffff811581c7>] ? fget_light+0x397/0x4b0
 [<ffffffff81139c27>] SyS_write+0x47/0xa0
 [<ffffffff8153bde4>] tracesys+0xdd/0xe2

Stephen Smalley suggested:

Quoted 2 lines

Maybe put a cond_resched() within the ebitmap_for_each_positive_bit() loop in mls_convert_context()?

That seems to do the trick. Tested by downgrading and re-upgrading selinux-policy-targeted.

---
 security/selinux/ss/mls.c | 2 ++
 1 file changed, 2 insertions(+)
security/selinux/ss/mls.c +2 -0
index c85bc1ec040c..d307b37ddc2b 100644
@@ -492,6 +492,8 @@ int mls_convert_context(struct policydb *oldp,
 			rc = ebitmap_set_bit(&bitmap, catdatum->value - 1, 1);
 			if (rc)
 				return rc;
+
+			cond_resched();
 		}
 		ebitmap_destroy(&c->range.level[l].cat);
 		c->range.level[l].cat = bitmap;
Signature · 1 line
1.9.0
Acked-by on v1 1/2
#1 lore raw
Quoted 36 lines · Dave Jones

On a slow machine (with debugging enabled), upgrading selinux policy may take a considerable amount of time. Long enough that the softlockup detector gets triggered.

The backtrace looks like this..

Quoted 21 lines
BUG: soft lockup - CPU#2 stuck for 23s! [load_policy:19045]
Call Trace:
 [<ffffffff81221ddf>] symcmp+0xf/0x20
 [<ffffffff81221c27>] hashtab_search+0x47/0x80
 [<ffffffff8122e96c>] mls_convert_context+0xdc/0x1c0
 [<ffffffff812294e8>] convert_context+0x378/0x460
 [<ffffffff81229170>] ? security_context_to_sid_core+0x240/0x240
 [<ffffffff812221b5>] sidtab_map+0x45/0x80
 [<ffffffff8122bb9f>] security_load_policy+0x3ff/0x580
 [<ffffffff810788a8>] ? sched_clock_cpu+0xa8/0x100
 [<ffffffff810786dd>] ? sched_clock_local+0x1d/0x80
 [<ffffffff810788a8>] ? sched_clock_cpu+0xa8/0x100
 [<ffffffff8103096a>] ? __change_page_attr_set_clr+0x82a/0xa50
 [<ffffffff810786dd>] ? sched_clock_local+0x1d/0x80
 [<ffffffff810788a8>] ? sched_clock_cpu+0xa8/0x100
 [<ffffffff8103096a>] ? __change_page_attr_set_clr+0x82a/0xa50
 [<ffffffff810788a8>] ? sched_clock_cpu+0xa8/0x100
 [<ffffffff81534ddc>] ? retint_restore_args+0xe/0xe
 [<ffffffff8109c82d>] ? trace_hardirqs_on_caller+0xfd/0x1c0
 [<ffffffff81279a2e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
 [<ffffffff810d28a8>] ? rcu_irq_exit+0x68/0xb0
Quoted 8 lines
 [<ffffffff81534ddc>] ? retint_restore_args+0xe/0xe
 [<ffffffff8121e947>] sel_write_load+0xa7/0x770
 [<ffffffff81139633>] ? vfs_write+0x1c3/0x200
 [<ffffffff81210e8e>] ? security_file_permission+0x1e/0xa0
 [<ffffffff8113952b>] vfs_write+0xbb/0x200
 [<ffffffff811581c7>] ? fget_light+0x397/0x4b0
 [<ffffffff81139c27>] SyS_write+0x47/0xa0
 [<ffffffff8153bde4>] tracesys+0xdd/0xe2
Quoted 8 lines

Stephen Smalley suggested:

Quoted 2 lines

Maybe put a cond_resched() within the ebitmap_for_each_positive_bit() loop in mls_convert_context()?

That seems to do the trick. Tested by downgrading and re-upgrading selinux-policy-targeted.

Quoted 19 lines
---
 security/selinux/ss/mls.c | 2 ++
 1 file changed, 2 insertions(+)
security/selinux/ss/mls.c +2 -0
index c85bc1ec040c..d307b37ddc2b 100644
@@ -492,6 +492,8 @@ int mls_convert_context(struct policydb *oldp,
 			rc = ebitmap_set_bit(&bitmap, catdatum->value - 1, 1);
 			if (rc)
 				return rc;
+
+			cond_resched();
 		}
 		ebitmap_destroy(&c->range.level[l].cat);
 		c->range.level[l].cat = bitmap;
Applied
#2 lore raw
In reply to Dave Jones
Quoted 41 lines · Dave Jones

On a slow machine (with debugging enabled), upgrading selinux policy may take a considerable amount of time. Long enough that the softlockup detector gets triggered.

The backtrace looks like this..

Quoted 22 lines
BUG: soft lockup - CPU#2 stuck for 23s! [load_policy:19045]

Call Trace:
 [<ffffffff81221ddf>] symcmp+0xf/0x20
 [<ffffffff81221c27>] hashtab_search+0x47/0x80
 [<ffffffff8122e96c>] mls_convert_context+0xdc/0x1c0
 [<ffffffff812294e8>] convert_context+0x378/0x460
 [<ffffffff81229170>] ? security_context_to_sid_core+0x240/0x240
 [<ffffffff812221b5>] sidtab_map+0x45/0x80
 [<ffffffff8122bb9f>] security_load_policy+0x3ff/0x580
 [<ffffffff810788a8>] ? sched_clock_cpu+0xa8/0x100
 [<ffffffff810786dd>] ? sched_clock_local+0x1d/0x80
 [<ffffffff810788a8>] ? sched_clock_cpu+0xa8/0x100
 [<ffffffff8103096a>] ? __change_page_attr_set_clr+0x82a/0xa50
 [<ffffffff810786dd>] ? sched_clock_local+0x1d/0x80
 [<ffffffff810788a8>] ? sched_clock_cpu+0xa8/0x100
 [<ffffffff8103096a>] ? __change_page_attr_set_clr+0x82a/0xa50
 [<ffffffff810788a8>] ? sched_clock_cpu+0xa8/0x100
 [<ffffffff81534ddc>] ? retint_restore_args+0xe/0xe
 [<ffffffff8109c82d>] ? trace_hardirqs_on_caller+0xfd/0x1c0
 [<ffffffff81279a2e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
 [<ffffffff810d28a8>] ? rcu_irq_exit+0x68/0xb0
Quoted 8 lines
 [<ffffffff81534ddc>] ? retint_restore_args+0xe/0xe
 [<ffffffff8121e947>] sel_write_load+0xa7/0x770
 [<ffffffff81139633>] ? vfs_write+0x1c3/0x200
 [<ffffffff81210e8e>] ? security_file_permission+0x1e/0xa0
 [<ffffffff8113952b>] vfs_write+0xbb/0x200
 [<ffffffff811581c7>] ? fget_light+0x397/0x4b0
 [<ffffffff81139c27>] SyS_write+0x47/0xa0
 [<ffffffff8153bde4>] tracesys+0xdd/0xe2

Stephen Smalley suggested:

Quoted 2 lines

Maybe put a cond_resched() within the ebitmap_for_each_positive_bit() loop in mls_convert_context()?

Quoted 8 lines

That seems to do the trick. Tested by downgrading and re-upgrading selinux-policy-targeted.

---
 security/selinux/ss/mls.c | 2 ++
 1 file changed, 2 insertions(+)

Merged to the SELinux #next branch, thanks.

Quoted 13 lines
security/selinux/ss/mls.c +2 -0
index c85bc1ec040c..d307b37ddc2b 100644
@@ -492,6 +492,8 @@ int mls_convert_context(struct policydb *oldp,
 			rc = ebitmap_set_bit(&bitmap, catdatum->value - 1, 1);
 			if (rc)
 				return rc;
+
+			cond_resched();
 		}
 		ebitmap_destroy(&c->range.level[l].cat);
 		c->range.level[l].cat = bitmap;
Signature · 2 lines
paul moore
security and virtualization @ redhat