Locking and unlocking a non-recursive mutex is a simple memory operation and should not fail on any reasonable platform with correct usage. A pthread mutex can return EDEADLK on lock or EPERM on unlock, or EINVAL if the mutex is uninitialized, but all of these conditions would reflect serious bugs in the calling code. Change the k5_mutex_lock and k5_mutex_unlock wrappers to return void and adjust all call sites. Propagate this change through k5_cc_mutex_lock and k5_cc_mutex_unlock as well.
ticket: 6929 git-svn-id: svn://anonsvn.mit.edu/krb5/trunk@25025 dc483132-0cff-0310-8789-dd5450dbe970
ticket: 6929 git-svn-id: svn://anonsvn.mit.edu/krb5/trunk@25024 dc483132-0cff-0310-8789-dd5450dbe970
git-svn-id: svn://anonsvn.mit.edu/krb5/trunk@23455 dc483132-0cff-0310-8789-dd5450dbe970
make reindent git-svn-id: svn://anonsvn.mit.edu/krb5/trunk@23100 dc483132-0cff-0310-8789-dd5450dbe970
In profile_node_iterator we unlock a mutex in order to call profile_update_file_data, which wants to lock that mutex itself, and then when it returns we re-lock the mutex. (We don't use recursive mutexes, and I would continue to argue that we shouldn't.) On the Mac, when running multiple threads, it appears that this results in very poor peformance, and much system and user CPU time is spent working with the locks. (Linux doesn't seem to suffer as much.) So: Split profile_update_file_data into a locking wrapper, and an inner routine that does the real work but requires that the lock be held on entry. Call the latter from profile_node_iterator *without* unlocking first, and only unlock if there's an error. This doesn't move any significant amount of work into the locking region; it pretty much just joins locking regions that were disjoint for no good reason. On my tests on an 8-core Mac, in a test program running gss_init_sec_context in a loop in 6 threads, this brought CPU usage per call down by 40%, and improved wall-clock time even more. Single-threaded performance improved very slightly, probably in the noise. Linux showed modest improvement (5% or less) in CPU usage in a 3-thread test on a 4-core system. Similar tests with gss_accept_sec_context showed similar contention around the profile-library mutexes, but I haven't analyzed the performance changes there from this patch. More work is needed, but this will help. ticket: 6515 tags: pullup target_version: 1.7.1 version_reported: 1.7 git-svn-id: svn://anonsvn.mit.edu/krb5/trunk@22418 dc483132-0cff-0310-8789-dd5450dbe970
ticket: 6200 status: open git-svn-id: svn://anonsvn.mit.edu/krb5/trunk@20898 dc483132-0cff-0310-8789-dd5450dbe970
git-svn-id: svn://anonsvn.mit.edu/krb5/trunk@20609 dc483132-0cff-0310-8789-dd5450dbe970
I have a modified version of valgrind that will allow me to have malloc fail in a controlled way. A number of memory leaks in error return passes exist in the profile library. They are essentially inconsequental - but my goal is to eventually create a test harness that tries to cover all code - including error returns... prof_parse.c: (profile_parse_file): Free node being created if parse_line() fails. prof_file.c (profile_open_file): free prf_data_t on malloc failure prof_tree.c (profile_create_node): The magic element must be set before calling profile_free_node for it to release memory. ticket: new git-svn-id: svn://anonsvn.mit.edu/krb5/trunk@19981 dc483132-0cff-0310-8789-dd5450dbe970
The "deleted" flag was being checked when writing out the file, but not when iterating through using the profile handle being used to do the deletions. * prof_tree.c (profile_node_iterator): After checking skip_num counter, also skip over deleted nodes. * prof_test1 (test3): New proc. (top level): Run it. ticket: new target_version: 1.4.1 git-svn-id: svn://anonsvn.mit.edu/krb5/trunk@17111 dc483132-0cff-0310-8789-dd5450dbe970