Issue 8719 - slapd_crypt() become slow when many ldap cliant connections occur.
Summary: slapd_crypt() become slow when many ldap cliant connections occur.
Status: VERIFIED FIXED
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: slapd (show other issues)
Version: 2.4.45
Hardware: All All
: --- normal
Target Milestone: 2.5.0
Assignee: OpenLDAP project
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-08-30 10:13 UTC by yos-nishino@ys.jp.nec.com
Modified: 2020-10-14 21:11 UTC (History)
0 users

See Also:


Attachments
openldap-slapd_crypt_case2.patch (1.35 KB, patch)
2017-09-03 02:28 UTC, yos-nishino@ys.jp.nec.com
Details
openldap-slapd_crypt_case1.patch (1.45 KB, patch)
2017-09-03 02:28 UTC, yos-nishino@ys.jp.nec.com
Details
openldap-slapd_crypt_case1.patch (1.31 KB, patch)
2017-09-03 01:38 UTC, yos-nishino@ys.jp.nec.com
Details
openldap-slapd_crypt_case2.patch (1.41 KB, patch)
2017-09-03 01:38 UTC, yos-nishino@ys.jp.nec.com
Details
openldap-slapd_crypt.patch (1.51 KB, text/plain)
2017-09-01 11:42 UTC, yos-nishino@ys.jp.nec.com
Details
openldap-slapd_crypt-configure.patch (756 bytes, text/plain)
2017-09-01 11:42 UTC, yos-nishino@ys.jp.nec.com
Details

Note You need to log in before you can comment on or make changes to this issue.
Description yos-nishino@ys.jp.nec.com 2017-08-30 10:13:25 UTC
Full_Name: Yoshinori Nishino
Version: 2.4.45
OS: CentOS 7
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (210.143.35.20)


Dear sir,

The function slapd_crypt() in servers/slapd/passwd.c seems to become slow when
many ldap client connections occur.
It seems it is because the function uses crypt()(non thread-safe function) and
pthread_mutex_lock(), which results in the slowdown.
#Besides, we need to use {CRYPT} hash as users' password hash.  

So, I modified servers/slapd/passwd.c like the following.
As a result, slapd_crypt() becomes much faster under the same condition.
Would you let me know whether or not the fix is appropriate for slapd?

=====
static int slapd_crypt( const char *key, const char *salt, char **hash )
{
	char *cr;
	int rc;
        struct crypt_data *data;

        data = (struct crypt_data *)calloc(1, sizeof(struct crypt_data));
	/* ldap_pvt_thread_mutex_lock( &passwd_mutex ); */

	/* cr = crypt( key, salt ); */
	cr = crypt_r( key, salt, data );
	if ( cr == NULL || cr[0] == '\0' ) {
		/* salt must have been invalid */
		rc = LUTIL_PASSWD_ERR;
	} else {
		if ( hash ) {
			ldap_pvt_thread_mutex_lock( &passwd_mutex );
			*hash = ber_strdup( cr );
			ldap_pvt_thread_mutex_unlock( &passwd_mutex );
			rc = LUTIL_PASSWD_OK;

		} else {
			rc = strcmp( salt, cr ) ? LUTIL_PASSWD_ERR : LUTIL_PASSWD_OK;
		}
	}

        free(data);
	/* ldap_pvt_thread_mutex_unlock( &passwd_mutex ); */
	return rc;
}

====

# "#define __USE_GNU" is also required to build slapd.


Best Regards,
Comment 1 Howard Chu 2017-08-30 10:26:31 UTC
yos-nishino@ys.jp.nec.com wrote:
> Full_Name: Yoshinori Nishino
> Version: 2.4.45
> OS: CentOS 7
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (210.143.35.20)
> 
> 
> Dear sir,
> 
> The function slapd_crypt() in servers/slapd/passwd.c seems to become slow when
> many ldap client connections occur.
> It seems it is because the function uses crypt()(non thread-safe function) and
> pthread_mutex_lock(), which results in the slowdown.
> #Besides, we need to use {CRYPT} hash as users' password hash.
> 
> So, I modified servers/slapd/passwd.c like the following.
> As a result, slapd_crypt() becomes much faster under the same condition.
> Would you let me know whether or not the fix is appropriate for slapd?

No it is not an appropriate fix.

You should add an autoconf test to check for the existence of the crypt_r 
function, and use an #ifdef here based on the result of that test, since 
crypt_r is a non-standard function.
> 
> =====
> static int slapd_crypt( const char *key, const char *salt, char **hash )
> {
> 	char *cr;
> 	int rc;
>          struct crypt_data *data;
> 
>          data = (struct crypt_data *)calloc(1, sizeof(struct crypt_data));
> 	/* ldap_pvt_thread_mutex_lock( &passwd_mutex ); */
> 
> 	/* cr = crypt( key, salt ); */
> 	cr = crypt_r( key, salt, data );
> 	if ( cr == NULL || cr[0] == '\0' ) {
> 		/* salt must have been invalid */
> 		rc = LUTIL_PASSWD_ERR;
> 	} else {
> 		if ( hash ) {
> 			ldap_pvt_thread_mutex_lock( &passwd_mutex );
> 			*hash = ber_strdup( cr );
> 			ldap_pvt_thread_mutex_unlock( &passwd_mutex );
> 			rc = LUTIL_PASSWD_OK;
> 
> 		} else {
> 			rc = strcmp( salt, cr ) ? LUTIL_PASSWD_ERR : LUTIL_PASSWD_OK;
> 		}
> 	}
> 
>          free(data);
> 	/* ldap_pvt_thread_mutex_unlock( &passwd_mutex ); */
> 	return rc;
> }
> 
> ====
> 
> # "#define __USE_GNU" is also required to build slapd.
> 
> 
> Best Regards,
> 
> 
> 


-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

Comment 2 yos-nishino@ys.jp.nec.com 2017-08-30 11:46:34 UTC
Dear Howard-san,


Thank you so much for your prompt advice.

As you told, I need to check whether or not crypt_r() exists.
I am going to consider including the check.

Would it be possible to let me know whether there are any other concerns 
about the fix if we can use crypt_r()?

The implementation that "both calloc() and free() occur every time 
slapd_crypt() is called" does not seem to look good.
The callers of slapd_crypt() might be able to get the memory for "struct 
crypt_data" before they call it.
However, I think it causes the changes of other source codes.
So, I think the aforementioned implementation is a workaround for the 
slowdown if the risk of memory fragmentation can be acceptable.

On the other hands, I think we do not need to care about strcmp() 
because it is thread-safe.


Best Regards,
----------------------------------------
On 2017/08/30 19:26, Howard Chu wrote:
> yos-nishino@ys.jp.nec.com wrote:
>> Full_Name: Yoshinori Nishino
>> Version: 2.4.45
>> OS: CentOS 7
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (210.143.35.20)
>>
>>
>> Dear sir,
>>
>> The function slapd_crypt() in servers/slapd/passwd.c seems to become 
>> slow when
>> many ldap client connections occur.
>> It seems it is because the function uses crypt()(non thread-safe 
>> function) and
>> pthread_mutex_lock(), which results in the slowdown.
>> #Besides, we need to use {CRYPT} hash as users' password hash.
>>
>> So, I modified servers/slapd/passwd.c like the following.
>> As a result, slapd_crypt() becomes much faster under the same condition.
>> Would you let me know whether or not the fix is appropriate for slapd?
> 
> No it is not an appropriate fix.
> 
> You should add an autoconf test to check for the existence of the 
> crypt_r function, and use an #ifdef here based on the result of that 
> test, since crypt_r is a non-standard function.
>>
>> =====
>> static int slapd_crypt( const char *key, const char *salt, char **hash )
>> {
>>     char *cr;
>>     int rc;
>>          struct crypt_data *data;
>>
>>          data = (struct crypt_data *)calloc(1, sizeof(struct 
>> crypt_data));
>>     /* ldap_pvt_thread_mutex_lock( &passwd_mutex ); */
>>
>>     /* cr = crypt( key, salt ); */
>>     cr = crypt_r( key, salt, data );
>>     if ( cr == NULL || cr[0] == '\0' ) {
>>         /* salt must have been invalid */
>>         rc = LUTIL_PASSWD_ERR;
>>     } else {
>>         if ( hash ) {
>>             ldap_pvt_thread_mutex_lock( &passwd_mutex );
>>             *hash = ber_strdup( cr );
>>             ldap_pvt_thread_mutex_unlock( &passwd_mutex );
>>             rc = LUTIL_PASSWD_OK;
>>
>>         } else {
>>             rc = strcmp( salt, cr ) ? LUTIL_PASSWD_ERR : LUTIL_PASSWD_OK;
>>         }
>>     }
>>
>>          free(data);
>>     /* ldap_pvt_thread_mutex_unlock( &passwd_mutex ); */
>>     return rc;
>> }
>>
>> ====
>>
>> # "#define __USE_GNU" is also required to build slapd.
>>
>>
>> Best Regards,
>>
>>
>>
> 
> 


-- 
************************************************
Yoshinori Nishino

NEC Solution Innovators, Ltd.
1-18-7 Shinkiba, Koto-ku, Tokyo, 136-8627 Japan
E-MAIL: yos-nishino@ys.jp.nec.com
************************************************
Comment 3 yos-nishino@ys.jp.nec.com 2017-09-01 11:42:36 UTC
Dear Howard-san,


Thanks to your advice, I could create the attached tentative patches.

They modifies servers/slapd/passwd.c and configure.in
so that running "./configure" can check whether or not crypt_r() exists
and use the function in slapd_crypt() if possible.

I am going to check whether or not "calloc()/free()" causes 
unacceptable memory fragmentation.


Best Regards,
------------------------------------------------
On 2017/09/01 20:23, Yoshinori Nishino wrote:
> 
> 
> On 2017/08/30 20:46, Yoshinori Nishino wrote:
>> Dear Howard-san,
>>
>>
>> Thank you so much for your prompt advice.
>>
>> As you told, I need to check whether or not crypt_r() exists.
>> I am going to consider including the check.
>>
>> Would it be possible to let me know whether there are any other 
>> concerns about the fix if we can use crypt_r()?
>>
>> The implementation that "both calloc() and free() occur every time 
>> slapd_crypt() is called" does not seem to look good.
>> The callers of slapd_crypt() might be able to get the memory for 
>> "struct crypt_data" before they call it.
>> However, I think it causes the changes of other source codes.
>> So, I think the aforementioned implementation is a workaround for the 
>> slowdown if the risk of memory fragmentation can be acceptable.
>>
>> On the other hands, I think we do not need to care about strcmp() 
>> because it is thread-safe.
>>
>>
>> Best Regards,
>> ----------------------------------------
>> On 2017/08/30 19:26, Howard Chu wrote:
>>> yos-nishino@ys.jp.nec.com wrote:
>>>> Full_Name: Yoshinori Nishino
>>>> Version: 2.4.45
>>>> OS: CentOS 7
>>>> URL: ftp://ftp.openldap.org/incoming/
>>>> Submission from: (NULL) (210.143.35.20)
>>>>
>>>>
>>>> Dear sir,
>>>>
>>>> The function slapd_crypt() in servers/slapd/passwd.c seems to become 
>>>> slow when
>>>> many ldap client connections occur.
>>>> It seems it is because the function uses crypt()(non thread-safe 
>>>> function) and
>>>> pthread_mutex_lock(), which results in the slowdown.
>>>> #Besides, we need to use {CRYPT} hash as users' password hash.
>>>>
>>>> So, I modified servers/slapd/passwd.c like the following.
>>>> As a result, slapd_crypt() becomes much faster under the same 
>>>> condition.
>>>> Would you let me know whether or not the fix is appropriate for slapd?
>>>
>>> No it is not an appropriate fix.
>>>
>>> You should add an autoconf test to check for the existence of the 
>>> crypt_r function, and use an #ifdef here based on the result of that 
>>> test, since crypt_r is a non-standard function.
>>>>



-- 
************************************************
Yoshinori Nishino

NEC Solution Innovators, Ltd.
1-18-7 Shinkiba, Koto-ku, Tokyo, 136-8627 Japan
E-MAIL: yos-nishino@ys.jp.nec.com
************************************************
Comment 4 Howard Chu 2017-09-01 12:33:02 UTC
Yoshinori Nishino wrote:
> Dear Howard-san,
> 
> 
> Thanks to your advice, I could create the attached tentative patches.

Thanks, this looks much better.
> 
> They modifies servers/slapd/passwd.c and configure.in
> so that running "./configure" can check whether or not crypt_r() exists
> and use the function in slapd_crypt() if possible.
> 
> I am going to check whether or not "calloc()/free()" causes
> unacceptable memory fragmentation.

Never use calloc/malloc/free directly in slapd code. Always use 
ch_calloc/ch_malloc/ch_free.

In this particular case, there's no reason to allocate at all. Just define 
"struct crypt_data data" as a local variable.
> 
> 
> Best Regards,
> ------------------------------------------------
> On 2017/09/01 20:23, Yoshinori Nishino wrote:
>>
>>
>> On 2017/08/30 20:46, Yoshinori Nishino wrote:
>>> Dear Howard-san,
>>>
>>>
>>> Thank you so much for your prompt advice.
>>>
>>> As you told, I need to check whether or not crypt_r() exists.
>>> I am going to consider including the check.
>>>
>>> Would it be possible to let me know whether there are any other
>>> concerns about the fix if we can use crypt_r()?
>>>
>>> The implementation that "both calloc() and free() occur every time
>>> slapd_crypt() is called" does not seem to look good.
>>> The callers of slapd_crypt() might be able to get the memory for
>>> "struct crypt_data" before they call it.
>>> However, I think it causes the changes of other source codes.
>>> So, I think the aforementioned implementation is a workaround for the
>>> slowdown if the risk of memory fragmentation can be acceptable.
>>>
>>> On the other hands, I think we do not need to care about strcmp()
>>> because it is thread-safe.
>>>
>>>
>>> Best Regards,
>>> ----------------------------------------
>>> On 2017/08/30 19:26, Howard Chu wrote:
>>>> yos-nishino@ys.jp.nec.com wrote:
>>>>> Full_Name: Yoshinori Nishino
>>>>> Version: 2.4.45
>>>>> OS: CentOS 7
>>>>> URL: ftp://ftp.openldap.org/incoming/
>>>>> Submission from: (NULL) (210.143.35.20)
>>>>>
>>>>>
>>>>> Dear sir,
>>>>>
>>>>> The function slapd_crypt() in servers/slapd/passwd.c seems to become
>>>>> slow when
>>>>> many ldap client connections occur.
>>>>> It seems it is because the function uses crypt()(non thread-safe
>>>>> function) and
>>>>> pthread_mutex_lock(), which results in the slowdown.
>>>>> #Besides, we need to use {CRYPT} hash as users' password hash.
>>>>>
>>>>> So, I modified servers/slapd/passwd.c like the following.
>>>>> As a result, slapd_crypt() becomes much faster under the same
>>>>> condition.
>>>>> Would you let me know whether or not the fix is appropriate for slapd?
>>>>
>>>> No it is not an appropriate fix.
>>>>
>>>> You should add an autoconf test to check for the existence of the
>>>> crypt_r function, and use an #ifdef here based on the result of that
>>>> test, since crypt_r is a non-standard function.
>>>>>
> 
> 


-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

Comment 5 Howard Chu 2017-09-01 12:35:07 UTC
Howard Chu wrote:
> Yoshinori Nishino wrote:
>> Dear Howard-san,
>>
>>
>> Thanks to your advice, I could create the attached tentative patches.
> 
> Thanks, this looks much better.
>>
>> They modifies servers/slapd/passwd.c and configure.in
>> so that running "./configure" can check whether or not crypt_r() exists
>> and use the function in slapd_crypt() if possible.
>>
>> I am going to check whether or not "calloc()/free()" causes
>> unacceptable memory fragmentation.
> 
> Never use calloc/malloc/free directly in slapd code. Always use 
> ch_calloc/ch_malloc/ch_free.
> 
> In this particular case, there's no reason to allocate at all. Just define 
> "struct crypt_data data" as a local variable.

Also there's no reason to lock the passwd_mutex at all. That would completely 
defeat the purpose of using crypt_r() in the first place.
>>
>>
>> Best Regards,
>> ------------------------------------------------
>> On 2017/09/01 20:23, Yoshinori Nishino wrote:
>>>
>>>
>>> On 2017/08/30 20:46, Yoshinori Nishino wrote:
>>>> Dear Howard-san,
>>>>
>>>>
>>>> Thank you so much for your prompt advice.
>>>>
>>>> As you told, I need to check whether or not crypt_r() exists.
>>>> I am going to consider including the check.
>>>>
>>>> Would it be possible to let me know whether there are any other
>>>> concerns about the fix if we can use crypt_r()?
>>>>
>>>> The implementation that "both calloc() and free() occur every time
>>>> slapd_crypt() is called" does not seem to look good.
>>>> The callers of slapd_crypt() might be able to get the memory for
>>>> "struct crypt_data" before they call it.
>>>> However, I think it causes the changes of other source codes.
>>>> So, I think the aforementioned implementation is a workaround for the
>>>> slowdown if the risk of memory fragmentation can be acceptable.
>>>>
>>>> On the other hands, I think we do not need to care about strcmp()
>>>> because it is thread-safe.
>>>>
>>>>
>>>> Best Regards,
>>>> ----------------------------------------
>>>> On 2017/08/30 19:26, Howard Chu wrote:
>>>>> yos-nishino@ys.jp.nec.com wrote:
>>>>>> Full_Name: Yoshinori Nishino
>>>>>> Version: 2.4.45
>>>>>> OS: CentOS 7
>>>>>> URL: ftp://ftp.openldap.org/incoming/
>>>>>> Submission from: (NULL) (210.143.35.20)
>>>>>>
>>>>>>
>>>>>> Dear sir,
>>>>>>
>>>>>> The function slapd_crypt() in servers/slapd/passwd.c seems to become
>>>>>> slow when
>>>>>> many ldap client connections occur.
>>>>>> It seems it is because the function uses crypt()(non thread-safe
>>>>>> function) and
>>>>>> pthread_mutex_lock(), which results in the slowdown.
>>>>>> #Besides, we need to use {CRYPT} hash as users' password hash.
>>>>>>
>>>>>> So, I modified servers/slapd/passwd.c like the following.
>>>>>> As a result, slapd_crypt() becomes much faster under the same
>>>>>> condition.
>>>>>> Would you let me know whether or not the fix is appropriate for slapd?
>>>>>
>>>>> No it is not an appropriate fix.
>>>>>
>>>>> You should add an autoconf test to check for the existence of the
>>>>> crypt_r function, and use an #ifdef here based on the result of that
>>>>> test, since crypt_r is a non-standard function.
>>>>>>
>>
>>
> 
> 


-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

Comment 6 yos-nishino@ys.jp.nec.com 2017-09-03 01:38:58 UTC
Dear Howard-san,

I appreciate your many valuable advices.

>Never use calloc/malloc/free directly in slapd code. Always use ch_calloc/ch_malloc/ch_free.
>
>In this particular case, there's no reason to allocate at all. Just define "struct crypt_data data" as a local variable.

You are right. There is no need to allocate memory for "data" because using a local variable is also thread-safe in this case.

>Also there's no reason to lock the passwd_mutex at all. That would completely defeat the purpose of using crypt_r() in the first place.

I decide to use passwd_mutex only for ber_strdup(),  which seems to be non thread-safe according to ./libraries/liblber/memory.c.

I created two patches for passwd.c.
Both patches uses "data" as a local variable.  
"case1" uses passwd_mutex for ber_strdup(), "case2" dose not so.

For the time being , I am going to use "case1" due to the aforementioned thread-safe concern about ber_strdup().


Best Regards,
************************************************
Yoshinori Nishino

NEC Solution Innovators, Ltd.
1-18-7 Shinkiba, Koto-ku, Tokyo, 136-8627 Japan
E-MAIL: yos-nishino@ys.jp.nec.com
************************************************
Comment 7 yos-nishino@ys.jp.nec.com 2017-09-03 02:28:20 UTC
Dear Howard-san,

>I created two patches for passwd.c.

I am sorry. The patches I sent before were wrong because free(data) is left.
I send the fixed patches again.



Best Regards,
************************************************
Yoshinori Nishino

NEC Solution Innovators, Ltd.
1-18-7 Shinkiba, Koto-ku, Tokyo, 136-8627 Japan
E-MAIL: yos-nishino@ys.jp.nec.com
************************************************
Comment 8 Howard Chu 2017-09-03 10:34:20 UTC
Yoshinori Nishino wrote:

> I decide to use passwd_mutex only for ber_strdup(),  which seems to be non thread-safe according to ./libraries/liblber/memory.c.

There is no issue with thread-safety for ber_strdup. What exact line of  
memory.c are you talking about?

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

Comment 9 yos-nishino@ys.jp.nec.com 2017-09-03 10:51:47 UTC
Dear Howard-san,

>There is no issue with thread-safety for ber_strdup. What exact line of memory.c are you talking about?

I think ber_strdup(), which uses ber_memalloc_x(), is non thread-safe because of the following comment at around line 69 of memory.c:

/* Note sequence and ber_int_meminuse are counters, but are not
 * thread safe.  If you want to use these values for multithreaded applications,
 * you must put mutexes around them, otherwise they will have incorrect values.
 * When debugging, if you sort the debug output, the sequence number will 
 * put allocations/frees together.  It is then a simple matter to write a script
 * to find any allocations that don't have a buffer free function.
 */


Best Regards,
************************************************
Yoshinori Nishino

NEC Solution Innovators, Ltd.
1-18-7 Shinkiba, Koto-ku, Tokyo, 136-8627 Japan
E-MAIL: yos-nishino@ys.jp.nec.com
************************************************



Comment 10 Howard Chu 2017-09-03 11:01:51 UTC
Yoshinori Nishino wrote:
> Dear Howard-san,
> 
>> There is no issue with thread-safety for ber_strdup. What exact line of memory.c are you talking about?
> 
> I think ber_strdup(), which uses ber_memalloc_x(), is non thread-safe because of the following comment at around line 69 of memory.c:
> 
> /* Note sequence and ber_int_meminuse are counters, but are not
>   * thread safe.  If you want to use these values for multithreaded applications,
>   * you must put mutexes around them, otherwise they will have incorrect values.
>   * When debugging, if you sort the debug output, the sequence number will
>   * put allocations/frees together.  It is then a simple matter to write a script
>   * to find any allocations that don't have a buffer free function.
>   */

That comment only applies when using LDAP_MEMORY_DEBUG and is irrelevant.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

Comment 11 yos-nishino@ys.jp.nec.com 2017-09-03 11:18:04 UTC
Dear Howard-san,

>That comment only applies when using LDAP_MEMORY_DEBUG and is irrelevant.

I saw memory.c again. 
As you told, I confirmed the comment was available only when LDAP_MEMORY_DEBUG was used(from line 27 to line 119).

I am sorry to bother you, and I am grateful for your help.
I am going to use "case2" patch, which I expect slapd_crypt() becomes much faster.


Best Reagrds,
************************************************
Yoshinori Nishino

NEC Solution Innovators, Ltd.
1-18-7 Shinkiba, Koto-ku, Tokyo, 136-8627 Japan
E-MAIL: yos-nishino@ys.jp.nec.com
************************************************


Comment 12 OpenLDAP project 2017-09-06 20:26:08 UTC
added in master
Comment 13 Howard Chu 2017-09-06 20:26:08 UTC
changed notes
changed state Open to Test
moved from Incoming to Software Enhancements
Comment 14 Howard Chu 2017-09-06 20:35:22 UTC
yos-nishino@ys.jp.nec.com wrote:
> Dear Howard-san,
> 
>> That comment only applies when using LDAP_MEMORY_DEBUG and is irrelevant.
> 
> I saw memory.c again.=20
> As you told, I confirmed the comment was available only when LDAP_MEMORY_DE=
> BUG was used(from line 27 to line 119).
> 
> I am sorry to bother you, and I am grateful for your help.
> I am going to use "case2" patch, which I expect slapd_crypt() becomes much =
> faster.

Thanks for the patch, now in git master.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/