selinux: introduce schedule points in policydb_destroy()
authorEric Paris <eparis@redhat.com>
Mon, 4 Jun 2007 21:41:22 +0000 (17:41 -0400)
committerJames Morris <jmorris@namei.org>
Thu, 12 Jul 2007 02:52:23 +0000 (22:52 -0400)
commit9dc9978084ea2a96b9f42752753d9e38a9f9d7b2
tree24aac2351df72f9f12fa9143a7746a2e83d24899
parente47c8fc582a2c9f3cba059e543c4a056cd6bf8c4
selinux: introduce schedule points in policydb_destroy()

During the LSPP testing we found that it was possible for
policydb_destroy() to take 10+ seconds of kernel time to complete.
Basically all policydb_destroy() does is walk some (possibly long) lists
and free the memory it finds.  Turning off slab debugging config options
made the problem go away since the actual functions which took most of
the time were (as seen by oprofile)

> 121202   23.9879  .check_poison_obj
> 78247    15.4864  .check_slabp

were caused by that.  So I decided to also add some voluntary schedule
points in that code so config voluntary preempt would be enough to solve
the problem.  Something similar was done in places like
shmem_free_pages() when we have to walk a list of memory and free it.
This was tested by the LSPP group on the hardware which could reproduce
the problem just loading a new policy and was found to not trigger the
softlock detector.  It takes just as much processing time, but the
kernel doesn't spend all that time stuck doing one thing and never
scheduling.

Someday a better way to handle memory might make the time needed in this
function a lot less, but this fixes the current issue as it stands
today.

Signed-off-by: Eric Paris <eparis@redhat.com>
Signed-off-by: James Morris <jmorris@namei.org>
security/selinux/ss/policydb.c