restorecond matchpathcon patch

[Steve G <linux_4ever@yahoo.com>]

[-- Attachment #1: Type: text/plain, Size: 910 bytes --]

Hi,

I was investigating why restorecond consumes so much memory and noticed that
valgrind is reporting about 18mb of reachable memory at exit. It seems that
matchpathcon sits on a lot of memory that may or may not help restorcond. This
patch causes matchpathcon to free its memory after we get its results. 

This helps cleanup valgrind output so that leaks are confined to utmpter and
another list. But I have to wonder if the strategy of allocating memory for each
file in a directory is a good thing or if we can just depend on partial path
matching to decide if we should care about the file. 

IOW, this patch cleans up one problem, but I wonder if the underlying algorithm
should be changed to be les of a memory hog.

-Steve


 
____________________________________________________________________________________
TV dinner still cooling? 
Check out "Tonight's Picks" on Yahoo! TV.
http://tv.yahoo.com/

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 1515479032-policycoreutils-2.0.1-restorecond-leak.patch --]
[-- Type: text/x-patch; name="policycoreutils-2.0.1-restorecond-leak.patch", Size: 635 bytes --]

diff -urp policycoreutils-2.0.1.orig/restorecond/restorecond.c policycoreutils-2.0.1/restorecond/restorecond.c
--- policycoreutils-2.0.1.orig/restorecond/restorecond.c	2007-02-19 21:25:54.000000000 -0500
+++ policycoreutils-2.0.1/restorecond/restorecond.c	2007-02-19 21:28:09.000000000 -0500
@@ -188,7 +188,9 @@ static void restore(const char *filename
 		return;
 	}
 
-	if (matchpathcon(filename, st.st_mode, &scontext) < 0) {
+	retcontext = matchpathcon(filename, st.st_mode, &scontext);
+	matchpathcon_fini();
+	if (retcontext < 0) {
 		if (errno == ENOENT)
 			return;
 		syslog(LOG_ERR, "matchpathcon(%s) failed %s\n", filename,