OpenLDAP
Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest

Viewing Software Enhancements/8719
Full headers

From: yos-nishino@ys.jp.nec.com
Subject: slapd_crypt() become slow when many ldap cliant connections occur.
Compose comment
Download message
State:
0 replies:
12 followups: 1 2 3 4 5 6 7 8 9 10 11 12

Major security issue: yes  no

Notes:

Notification:


Date: Wed, 30 Aug 2017 10:13:25 +0000
From: yos-nishino@ys.jp.nec.com
To: openldap-its@OpenLDAP.org
Subject: slapd_crypt() become slow when many ldap cliant connections occur.
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,

Followup 1

Download message
Subject: Re: (ITS#8719) slapd_crypt() become slow when many ldap cliant
 connections occur.
To: yos-nishino@ys.jp.nec.com, openldap-its@OpenLDAP.org
From: Howard Chu <hyc@symas.com>
Date: Wed, 30 Aug 2017 11:26:31 +0100
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/



Followup 2

Download message
From: Yoshinori Nishino <yos-nishino@ys.jp.nec.com>
To: Howard Chu <hyc@symas.com>,
        "openldap-its@OpenLDAP.org" <openldap-its@OpenLDAP.org>
CC: Kanji Niwa <kan-niwa@wh.jp.nec.com>
Subject: Re: (ITS#8719) slapd_crypt() become slow when many ldap cliant
 connections occur.
Date: Wed, 30 Aug 2017 11:46:34 +0000
RGVhciBIb3dhcmQtc2FuLA0KDQoNClRoYW5rIHlvdSBzbyBtdWNoIGZvciB5b3VyIHByb21wdCBh
ZHZpY2UuDQoNCkFzIHlvdSB0b2xkLCBJIG5lZWQgdG8gY2hlY2sgd2hldGhlciBvciBub3QgY3J5
cHRfcigpIGV4aXN0cy4NCkkgYW0gZ29pbmcgdG8gY29uc2lkZXIgaW5jbHVkaW5nIHRoZSBjaGVj
ay4NCg0KV291bGQgaXQgYmUgcG9zc2libGUgdG8gbGV0IG1lIGtub3cgd2hldGhlciB0aGVyZSBh
cmUgYW55IG90aGVyIGNvbmNlcm5zIA0KYWJvdXQgdGhlIGZpeCBpZiB3ZSBjYW4gdXNlIGNyeXB0
X3IoKT8NCg0KVGhlIGltcGxlbWVudGF0aW9uIHRoYXQgImJvdGggY2FsbG9jKCkgYW5kIGZyZWUo
KSBvY2N1ciBldmVyeSB0aW1lIA0Kc2xhcGRfY3J5cHQoKSBpcyBjYWxsZWQiIGRvZXMgbm90IHNl
ZW0gdG8gbG9vayBnb29kLg0KVGhlIGNhbGxlcnMgb2Ygc2xhcGRfY3J5cHQoKSBtaWdodCBiZSBh
YmxlIHRvIGdldCB0aGUgbWVtb3J5IGZvciAic3RydWN0IA0KY3J5cHRfZGF0YSIgYmVmb3JlIHRo
ZXkgY2FsbCBpdC4NCkhvd2V2ZXIsIEkgdGhpbmsgaXQgY2F1c2VzIHRoZSBjaGFuZ2VzIG9mIG90
aGVyIHNvdXJjZSBjb2Rlcy4NClNvLCBJIHRoaW5rIHRoZSBhZm9yZW1lbnRpb25lZCBpbXBsZW1l
bnRhdGlvbiBpcyBhIHdvcmthcm91bmQgZm9yIHRoZSANCnNsb3dkb3duIGlmIHRoZSByaXNrIG9m
IG1lbW9yeSBmcmFnbWVudGF0aW9uIGNhbiBiZSBhY2NlcHRhYmxlLg0KDQpPbiB0aGUgb3RoZXIg
aGFuZHMsIEkgdGhpbmsgd2UgZG8gbm90IG5lZWQgdG8gY2FyZSBhYm91dCBzdHJjbXAoKSANCmJl
Y2F1c2UgaXQgaXMgdGhyZWFkLXNhZmUuDQoNCg0KQmVzdCBSZWdhcmRzLA0KLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KT24gMjAxNy8wOC8zMCAxOToyNiwgSG93YXJk
IENodSB3cm90ZToNCj4geW9zLW5pc2hpbm9AeXMuanAubmVjLmNvbSB3cm90ZToNCj4+IEZ1bGxf
TmFtZTogWW9zaGlub3JpIE5pc2hpbm8NCj4+IFZlcnNpb246IDIuNC40NQ0KPj4gT1M6IENlbnRP
UyA3DQo+PiBVUkw6IGZ0cDovL2Z0cC5vcGVubGRhcC5vcmcvaW5jb21pbmcvDQo+PiBTdWJtaXNz
aW9uIGZyb206IChOVUxMKSAoMjEwLjE0My4zNS4yMCkNCj4+DQo+Pg0KPj4gRGVhciBzaXIsDQo+
Pg0KPj4gVGhlIGZ1bmN0aW9uIHNsYXBkX2NyeXB0KCkgaW4gc2VydmVycy9zbGFwZC9wYXNzd2Qu
YyBzZWVtcyB0byBiZWNvbWUgDQo+PiBzbG93IHdoZW4NCj4+IG1hbnkgbGRhcCBjbGllbnQgY29u
bmVjdGlvbnMgb2NjdXIuDQo+PiBJdCBzZWVtcyBpdCBpcyBiZWNhdXNlIHRoZSBmdW5jdGlvbiB1
c2VzIGNyeXB0KCkobm9uIHRocmVhZC1zYWZlIA0KPj4gZnVuY3Rpb24pIGFuZA0KPj4gcHRocmVh
ZF9tdXRleF9sb2NrKCksIHdoaWNoIHJlc3VsdHMgaW4gdGhlIHNsb3dkb3duLg0KPj4gI0Jlc2lk
ZXMsIHdlIG5lZWQgdG8gdXNlIHtDUllQVH0gaGFzaCBhcyB1c2VycycgcGFzc3dvcmQgaGFzaC4N
Cj4+DQo+PiBTbywgSSBtb2RpZmllZCBzZXJ2ZXJzL3NsYXBkL3Bhc3N3ZC5jIGxpa2UgdGhlIGZv
bGxvd2luZy4NCj4+IEFzIGEgcmVzdWx0LCBzbGFwZF9jcnlwdCgpIGJlY29tZXMgbXVjaCBmYXN0
ZXIgdW5kZXIgdGhlIHNhbWUgY29uZGl0aW9uLg0KPj4gV291bGQgeW91IGxldCBtZSBrbm93IHdo
ZXRoZXIgb3Igbm90IHRoZSBmaXggaXMgYXBwcm9wcmlhdGUgZm9yIHNsYXBkPw0KPiANCj4gTm8g
aXQgaXMgbm90IGFuIGFwcHJvcHJpYXRlIGZpeC4NCj4gDQo+IFlvdSBzaG91bGQgYWRkIGFuIGF1
dG9jb25mIHRlc3QgdG8gY2hlY2sgZm9yIHRoZSBleGlzdGVuY2Ugb2YgdGhlIA0KPiBjcnlwdF9y
IGZ1bmN0aW9uLCBhbmQgdXNlIGFuICNpZmRlZiBoZXJlIGJhc2VkIG9uIHRoZSByZXN1bHQgb2Yg
dGhhdCANCj4gdGVzdCwgc2luY2UgY3J5cHRfciBpcyBhIG5vbi1zdGFuZGFyZCBmdW5jdGlvbi4N
Cj4+DQo+PiA9PT09PQ0KPj4gc3RhdGljIGludCBzbGFwZF9jcnlwdCggY29uc3QgY2hhciAqa2V5
LCBjb25zdCBjaGFyICpzYWx0LCBjaGFyICoqaGFzaCApDQo+PiB7DQo+PiDCoMKgwqDCoGNoYXIg
KmNyOw0KPj4gwqDCoMKgwqBpbnQgcmM7DQo+PiDCoMKgwqDCoMKgwqDCoMKgIHN0cnVjdCBjcnlw
dF9kYXRhICpkYXRhOw0KPj4NCj4+IMKgwqDCoMKgwqDCoMKgwqAgZGF0YSA9IChzdHJ1Y3QgY3J5
cHRfZGF0YSAqKWNhbGxvYygxLCBzaXplb2Yoc3RydWN0IA0KPj4gY3J5cHRfZGF0YSkpOw0KPj4g
wqDCoMKgwqAvKiBsZGFwX3B2dF90aHJlYWRfbXV0ZXhfbG9jayggJnBhc3N3ZF9tdXRleCApOyAq
Lw0KPj4NCj4+IMKgwqDCoMKgLyogY3IgPSBjcnlwdCgga2V5LCBzYWx0ICk7ICovDQo+PiDCoMKg
wqDCoGNyID0gY3J5cHRfcigga2V5LCBzYWx0LCBkYXRhICk7DQo+PiDCoMKgwqDCoGlmICggY3Ig
PT0gTlVMTCB8fCBjclswXSA9PSAnXDAnICkgew0KPj4gwqDCoMKgwqDCoMKgwqAgLyogc2FsdCBt
dXN0IGhhdmUgYmVlbiBpbnZhbGlkICovDQo+PiDCoMKgwqDCoMKgwqDCoCByYyA9IExVVElMX1BB
U1NXRF9FUlI7DQo+PiDCoMKgwqDCoH0gZWxzZSB7DQo+PiDCoMKgwqDCoMKgwqDCoCBpZiAoIGhh
c2ggKSB7DQo+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGxkYXBfcHZ0X3RocmVhZF9tdXRleF9s
b2NrKCAmcGFzc3dkX211dGV4ICk7DQo+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICpoYXNoID0g
YmVyX3N0cmR1cCggY3IgKTsNCj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgbGRhcF9wdnRfdGhy
ZWFkX211dGV4X3VubG9jayggJnBhc3N3ZF9tdXRleCApOw0KPj4gwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoCByYyA9IExVVElMX1BBU1NXRF9PSzsNCj4+DQo+PiDCoMKgwqDCoMKgwqDCoCB9IGVsc2Ug
ew0KPj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCByYyA9IHN0cmNtcCggc2FsdCwgY3IgKSA/IExV
VElMX1BBU1NXRF9FUlIgOiBMVVRJTF9QQVNTV0RfT0s7DQo+PiDCoMKgwqDCoMKgwqDCoCB9DQo+
PiDCoMKgwqDCoH0NCj4+DQo+PiDCoMKgwqDCoMKgwqDCoMKgIGZyZWUoZGF0YSk7DQo+PiDCoMKg
wqDCoC8qIGxkYXBfcHZ0X3RocmVhZF9tdXRleF91bmxvY2soICZwYXNzd2RfbXV0ZXggKTsgKi8N
Cj4+IMKgwqDCoMKgcmV0dXJuIHJjOw0KPj4gfQ0KPj4NCj4+ID09PT0NCj4+DQo+PiAjICIjZGVm
aW5lIF9fVVNFX0dOVSIgaXMgYWxzbyByZXF1aXJlZCB0byBidWlsZCBzbGFwZC4NCj4+DQo+Pg0K
Pj4gQmVzdCBSZWdhcmRzLA0KPj4NCj4+DQo+Pg0KPiANCj4gDQoNCi0tIA0KKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQpZb3NoaW5vcmkgTmlzaGlubw0K
DQpORUMgU29sdXRpb24gSW5ub3ZhdG9ycywgTHRkLg0KMS0xOC03IFNoaW5raWJhLCBLb3RvLWt1
LCBUb2t5bywgMTM2LTg2MjcgSmFwYW4NCkUtTUFJTDogeW9zLW5pc2hpbm9AeXMuanAubmVjLmNv
bQ0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq




Followup 3

Download message
From: Yoshinori Nishino <yos-nishino@ys.jp.nec.com>
To: Howard Chu <hyc@symas.com>,
        "openldap-its@OpenLDAP.org" <openldap-its@OpenLDAP.org>
CC: Kanji Niwa <kan-niwa@wh.jp.nec.com>
Subject: Re: (ITS#8719) slapd_crypt() become slow when many ldap cliant
 connections occur.
Date: Fri, 1 Sep 2017 11:42:36 +0000
--_003_ae98b5ab2c831747beb16297218b350eysjpneccom_
Content-Type: text/plain; charset="utf-8"
Content-ID: <514C194789057D4F9AD83D779D27265A@gisp.nec.co.jp>
Content-Transfer-Encoding: base64

RGVhciBIb3dhcmQtc2FuLA0KDQoNClRoYW5rcyB0byB5b3VyIGFkdmljZSwgSSBjb3VsZCBjcmVh
dGUgdGhlIGF0dGFjaGVkIHRlbnRhdGl2ZSBwYXRjaGVzLg0KDQpUaGV5IG1vZGlmaWVzIHNlcnZl
cnMvc2xhcGQvcGFzc3dkLmMgYW5kIGNvbmZpZ3VyZS5pbg0Kc28gdGhhdCBydW5uaW5nICIuL2Nv
bmZpZ3VyZSIgY2FuIGNoZWNrIHdoZXRoZXIgb3Igbm90IGNyeXB0X3IoKSBleGlzdHMNCmFuZCB1
c2UgdGhlIGZ1bmN0aW9uIGluIHNsYXBkX2NyeXB0KCkgaWYgcG9zc2libGUuDQoNCkkgYW0gZ29p
bmcgdG8gY2hlY2sgd2hldGhlciBvciBub3QgImNhbGxvYygpL2ZyZWUoKSIgY2F1c2VzIA0KdW5h
Y2NlcHRhYmxl44CAbWVtb3J5IGZyYWdtZW50YXRpb24uDQoNCg0KQmVzdCBSZWdhcmRzLA0KLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpPbiAyMDE3LzA5
LzAxIDIwOjIzLCBZb3NoaW5vcmkgTmlzaGlubyB3cm90ZToNCj4gDQo+IA0KPiBPbiAyMDE3LzA4
LzMwIDIwOjQ2LCBZb3NoaW5vcmkgTmlzaGlubyB3cm90ZToNCj4+IERlYXIgSG93YXJkLXNhbiwN
Cj4+DQo+Pg0KPj4gVGhhbmsgeW91IHNvIG11Y2ggZm9yIHlvdXIgcHJvbXB0IGFkdmljZS4NCj4+
DQo+PiBBcyB5b3UgdG9sZCwgSSBuZWVkIHRvIGNoZWNrIHdoZXRoZXIgb3Igbm90IGNyeXB0X3Io
KSBleGlzdHMuDQo+PiBJIGFtIGdvaW5nIHRvIGNvbnNpZGVyIGluY2x1ZGluZyB0aGUgY2hlY2su
DQo+Pg0KPj4gV291bGQgaXQgYmUgcG9zc2libGUgdG8gbGV0IG1lIGtub3cgd2hldGhlciB0aGVy
ZSBhcmUgYW55IG90aGVyIA0KPj4gY29uY2VybnMgYWJvdXQgdGhlIGZpeCBpZiB3ZSBjYW4gdXNl
IGNyeXB0X3IoKT8NCj4+DQo+PiBUaGUgaW1wbGVtZW50YXRpb24gdGhhdCAiYm90aCBjYWxsb2Mo
KSBhbmQgZnJlZSgpIG9jY3VyIGV2ZXJ5IHRpbWUgDQo+PiBzbGFwZF9jcnlwdCgpIGlzIGNhbGxl
ZCIgZG9lcyBub3Qgc2VlbSB0byBsb29rIGdvb2QuDQo+PiBUaGUgY2FsbGVycyBvZiBzbGFwZF9j
cnlwdCgpIG1pZ2h0IGJlIGFibGUgdG8gZ2V0IHRoZSBtZW1vcnkgZm9yIA0KPj4gInN0cnVjdCBj
cnlwdF9kYXRhIiBiZWZvcmUgdGhleSBjYWxsIGl0Lg0KPj4gSG93ZXZlciwgSSB0aGluayBpdCBj
YXVzZXMgdGhlIGNoYW5nZXMgb2Ygb3RoZXIgc291cmNlIGNvZGVzLg0KPj4gU28sIEkgdGhpbmsg
dGhlIGFmb3JlbWVudGlvbmVkIGltcGxlbWVudGF0aW9uIGlzIGEgd29ya2Fyb3VuZCBmb3IgdGhl
IA0KPj4gc2xvd2Rvd24gaWYgdGhlIHJpc2sgb2YgbWVtb3J5IGZyYWdtZW50YXRpb24gY2FuIGJl
IGFjY2VwdGFibGUuDQo+Pg0KPj4gT24gdGhlIG90aGVyIGhhbmRzLCBJIHRoaW5rIHdlIGRvIG5v
dCBuZWVkIHRvIGNhcmUgYWJvdXQgc3RyY21wKCkgDQo+PiBiZWNhdXNlIGl0IGlzIHRocmVhZC1z
YWZlLg0KPj4NCj4+DQo+PiBCZXN0IFJlZ2FyZHMsDQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tDQo+PiBPbiAyMDE3LzA4LzMwIDE5OjI2LCBIb3dhcmQgQ2h1IHdy
b3RlOg0KPj4+IHlvcy1uaXNoaW5vQHlzLmpwLm5lYy5jb20gd3JvdGU6DQo+Pj4+IEZ1bGxfTmFt
ZTogWW9zaGlub3JpIE5pc2hpbm8NCj4+Pj4gVmVyc2lvbjogMi40LjQ1DQo+Pj4+IE9TOiBDZW50
T1MgNw0KPj4+PiBVUkw6IGZ0cDovL2Z0cC5vcGVubGRhcC5vcmcvaW5jb21pbmcvDQo+Pj4+IFN1
Ym1pc3Npb24gZnJvbTogKE5VTEwpICgyMTAuMTQzLjM1LjIwKQ0KPj4+Pg0KPj4+Pg0KPj4+PiBE
ZWFyIHNpciwNCj4+Pj4NCj4+Pj4gVGhlIGZ1bmN0aW9uIHNsYXBkX2NyeXB0KCkgaW4gc2VydmVy
cy9zbGFwZC9wYXNzd2QuYyBzZWVtcyB0byBiZWNvbWUgDQo+Pj4+IHNsb3cgd2hlbg0KPj4+PiBt
YW55IGxkYXAgY2xpZW50IGNvbm5lY3Rpb25zIG9jY3VyLg0KPj4+PiBJdCBzZWVtcyBpdCBpcyBi
ZWNhdXNlIHRoZSBmdW5jdGlvbiB1c2VzIGNyeXB0KCkobm9uIHRocmVhZC1zYWZlIA0KPj4+PiBm
dW5jdGlvbikgYW5kDQo+Pj4+IHB0aHJlYWRfbXV0ZXhfbG9jaygpLCB3aGljaCByZXN1bHRzIGlu
IHRoZSBzbG93ZG93bi4NCj4+Pj4gI0Jlc2lkZXMsIHdlIG5lZWQgdG8gdXNlIHtDUllQVH0gaGFz
aCBhcyB1c2VycycgcGFzc3dvcmQgaGFzaC4NCj4+Pj4NCj4+Pj4gU28sIEkgbW9kaWZpZWQgc2Vy
dmVycy9zbGFwZC9wYXNzd2QuYyBsaWtlIHRoZSBmb2xsb3dpbmcuDQo+Pj4+IEFzIGEgcmVzdWx0
LCBzbGFwZF9jcnlwdCgpIGJlY29tZXMgbXVjaCBmYXN0ZXIgdW5kZXIgdGhlIHNhbWUgDQo+Pj4+
IGNvbmRpdGlvbi4NCj4+Pj4gV291bGQgeW91IGxldCBtZSBrbm93IHdoZXRoZXIgb3Igbm90IHRo
ZSBmaXggaXMgYXBwcm9wcmlhdGUgZm9yIHNsYXBkPw0KPj4+DQo+Pj4gTm8gaXQgaXMgbm90IGFu
IGFwcHJvcHJpYXRlIGZpeC4NCj4+Pg0KPj4+IFlvdSBzaG91bGQgYWRkIGFuIGF1dG9jb25mIHRl
c3QgdG8gY2hlY2sgZm9yIHRoZSBleGlzdGVuY2Ugb2YgdGhlIA0KPj4+IGNyeXB0X3IgZnVuY3Rp
b24sIGFuZCB1c2UgYW4gI2lmZGVmIGhlcmUgYmFzZWQgb24gdGhlIHJlc3VsdCBvZiB0aGF0IA0K
Pj4+IHRlc3QsIHNpbmNlIGNyeXB0X3IgaXMgYSBub24tc3RhbmRhcmQgZnVuY3Rpb24uDQo+Pj4+
DQoNCg0KLS0gDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioNCllvc2hpbm9yaSBOaXNoaW5vDQoNCk5FQyBTb2x1dGlvbiBJbm5vdmF0b3JzLCBMdGQuDQox
LTE4LTcgU2hpbmtpYmEsIEtvdG8ta3UsIFRva3lvLCAxMzYtODYyNyBKYXBhbg0KRS1NQUlMOiB5
b3MtbmlzaGlub0B5cy5qcC5uZWMuY29tDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioNCg==

--_003_ae98b5ab2c831747beb16297218b350eysjpneccom_
Content-Type: text/plain; name="openldap-slapd_crypt.patch"
Content-Description: openldap-slapd_crypt.patch
Content-Disposition: attachment; filename="openldap-slapd_crypt.patch";
	size=1542; creation-date="Fri, 01 Sep 2017 11:42:36 GMT";
	modification-date="Fri, 01 Sep 2017 11:42:36 GMT"
Content-ID: <529021D243717746A9BA512F0ED0DA1A@gisp.nec.co.jp>
Content-Transfer-Encoding: base64

bW9kaWZ5IHBhc3N3ZC5jIHNvIHRoYXQgc2xhcGRfY3J5cHQoKSB1c2VzIGNyeXB0X3IoKS4KCmRp
ZmYgLS1naXQgYS9zZXJ2ZXJzL3NsYXBkL3Bhc3N3ZC5jIGIvc2VydmVycy9zbGFwZC9wYXNzd2Qu
YwppbmRleCBkZmEzNzBjLi45YTUyM2VlIDEwMDY0NAotLS0gYS9zZXJ2ZXJzL3NsYXBkL3Bhc3N3
ZC5jCisrKyBiL3NlcnZlcnMvc2xhcGQvcGFzc3dkLmMKQEAgLTIzLDggKzIzLDExIEBACiAjaW5j
bHVkZSA8YWMvdW5pc3RkLmg+CiAKICNpZmRlZiBTTEFQRF9DUllQVAorI2lmZGVmIEhBVkVfQ1JZ
UFRfUgorI2RlZmluZSBfX1VTRV9HTlUKKyNlbmRpZiAvKiBIQVZFX0NSWVBUX1IgKi8KICNpbmNs
dWRlIDxhYy9jcnlwdC

Message of length 8157 truncated


Followup 4

Download message
Subject: Re: (ITS#8719) slapd_crypt() become slow when many ldap cliant
 connections occur.
To: Yoshinori Nishino <yos-nishino@ys.jp.nec.com>,
 "openldap-its@OpenLDAP.org" <openldap-its@OpenLDAP.org>
Cc: Kanji Niwa <kan-niwa@wh.jp.nec.com>
From: Howard Chu <hyc@symas.com>
Date: Fri, 1 Sep 2017 13:33:02 +0100
Yoshinori Nishino wrote:
> Dear Howard-san,
>=20
>=20
> Thanks to your advice, I could create the attached tentative patches.

Thanks, this looks much better.
>=20
> 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.
>=20
> I am going to check whether or not "calloc()/free()" causes
> unacceptable=E3=80=80memory fragmentation.

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

In this particular case, there's no reason to allocate at all. Just defin=
e=20
"struct crypt_data data" as a local variable.
>=20
>=20
> 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 becom=
e
>>>>> 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 sla=
pd?
>>>>
>>>> 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.
>>>>>
>=20
>=20


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



Followup 5

Download message
Subject: Re: (ITS#8719) slapd_crypt() become slow when many ldap cliant
 connections occur.
From: Howard Chu <hyc@symas.com>
To: Yoshinori Nishino <yos-nishino@ys.jp.nec.com>,
 "openldap-its@OpenLDAP.org" <openldap-its@OpenLDAP.org>
Cc: Kanji Niwa <kan-niwa@wh.jp.nec.com>
Date: Fri, 1 Sep 2017 13:35:07 +0100
Howard Chu wrote:
> Yoshinori Nishino wrote:
>> Dear Howard-san,
>>
>>
>> Thanks to your advice, I could create the attached tentative patches.
>=20
> 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() exist=
s
>> and use the function in slapd_crypt() if possible.
>>
>> I am going to check whether or not "calloc()/free()" causes
>> unacceptable=E3=80=80memory fragmentation.
>=20
> Never use calloc/malloc/free directly in slapd code. Always use=20
> ch_calloc/ch_malloc/ch_free.
>=20
> In this particular case, there's no reason to allocate at all. Just def=
ine=20
> "struct crypt_data data" as a local variable.

Also there's no reason to lock the passwd_mutex at all. That would comple=
tely=20
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 th=
e
>>>> 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 beco=
me
>>>>>> 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 sl=
apd?
>>>>>
>>>>> 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 tha=
t
>>>>> test, since crypt_r is a non-standard function.
>>>>>>
>>
>>
>=20
>=20


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



Followup 6

Download message
From: Yoshinori Nishino <yos-nishino@ys.jp.nec.com>
To: "hyc@symas.com" <hyc@symas.com>,
        "openldap-its@OpenLDAP.org" <openldap-its@OpenLDAP.org>
CC: Kanji Niwa <kan-niwa@wh.jp.nec.com>
Subject: Re: (ITS#8719) slapd_crypt() become slow when many ldap cliant
 connections occur.
Date: Sun, 3 Sep 2017 01:38:58 +0000
--_003_282E583D7ED52C4FA3C4CC199465868B02801BECBPXM04GPgispnec_
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable

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 complet=
ely 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. =20
"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 th=
read-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
************************************************

--_003_282E583D7ED52C4FA3C4CC199465868B02801BECBPXM04GPgispnec_
Content-Type: application/octet-stream;
	name="openldap-slapd_crypt_case1.patch"
Content-Description: openldap-slapd_crypt_case1.patch
Content-Disposition: attachment;
	filename="openldap-slapd_crypt_case1.patch"; size=1345;
	creation-date="Sun, 03 Sep 2017 01:05:32 GMT";
	modification-date="Sun, 03 Sep 2017 01:08:20 GMT"
Content-Transfer-Encoding: base64

bW9kaWZ5IHBhc3N3ZC5jIHNvIHRoYXQgc2xhcGRfY3J5cHQoKSB1c2VzIGNyeXB0X3IoKS4KCmRp
ZmYgLS1naXQgYS9wYXNzd2QuYy4gYi9wYXNzd2QuYwppbmRleCBkZmEzNzBjLi5hYzA3ZGQyIDEw
MDY0NAotLS0gYS9wYXNzd2QuYworKysgYi9wYXNzd2QuYwpAQCAtMjMsOCArMjMsMTEgQEAKICNp
bmNsdWRlIDxhYy91bmlzdGQuaD4KIAogI2lmZGVmIFNMQVBEX0NSWVBUCisjaWZkZWYgSEFWRV9D
UllQVF9SCisjZGVmaW5lIF9fVVNFX0dOVQorI2VuZGlmIC8qIEhBVkVfQ1JZUFRfUiAqLwogI2lu
Y2x1ZGUgPGFjL2NyeXB0Lmg+Ci0jZW5kaWYKKyNlbmRpZiAvKiBTTEFQRF9DUllQVCAqLwogCiAj
aW5jbHVkZSAic2xhcC5oIgogCkBAIC01OTAsNiArNTkzLDMxIEBAIHNsYXBfcGFzc3dkX2hhc2go
CiBzdGF0aWMgbGRhcF9wdnRfdGhyZWFkX211dGV4X3QgcGFzc3dkX211dGV4Owogc3RhdGljIGx1
dGlsX2NyeXB0ZnVuYyBzbGFwZF9jcnlwdDsKIAorI2lmZGVmIEhBVkVfQ1JZUFRfUgorc3RhdGlj
IGludCBzbGFwZF9jcnlwdCggY29uc3QgY2hhciAqa2V5LCBjb25zdCBjaGFyICpzYWx0LCBjaGFy
ICoqaGFzaCApCit7CisJY2hhciAqY3I7CisJaW50IHJjOworCXN0cnVjdCBjcnlwdF9kYXRhIGRh
dGE7CisgICAgCisJZGF0YS5pbml0aWFsaXplZCA9IDA7CisJY3IgPSBjcnlwdF9yKCBrZXksIHNh
bHQsICZkYXRhICk7CisJaWYgKCBjciA9PSBOVUxMIHx8IGNyWzBdID09ICdcMCcgKSB7CisJCS8q
IHNhbHQgbXVzdCBoYXZlIGJlZW4gaW52YWxpZCAqLworCQlyYyA9IExVVElMX1BBU1NXRF9FUlI7
CisJfSBlbHNlIHsKKwkJaWYgKCBoYXNoICkgeworCQkJKmhhc2ggPSBiZXJfc3RyZHVwKCBjciAp
OworCQkJcmMgPSBMVVRJTF9QQVNTV0RfT0s7CisJCX0gZWxzZSB7CisJCQlyYyA9IHN0cmNtcCgg
c2FsdCwgY3IgKSA/IExVVElMX1BBU1NXRF9FUlIgOiBMVVRJTF9QQVNTV0RfT0s7CisJCX0KKwl9
CisgCisgICAgZnJlZShkYXRhKTsKKyAgICByZXR1cm4gcmM7Cit9CisjZWxzZQogc3RhdGljIGlu
dCBzbGFwZF9jcnlwdCggY29uc3QgY2hhciAqa2V5LCBjb25zdCBjaGFyICpzYWx0LCBjaGFyICoq
aGFzaCApCiB7CiAJY2hhciAqY3I7CkBAIC02MTQsNiArNjQyLDggQEAgc3RhdGljIGludCBzbGFw
ZF9jcnlwdCggY29uc3QgY2hhciAqa2V5LCBjb25zdCBjaGFyICpzYWx0LCBjaGFyICoqaGFzaCAp
CiAJbGRhcF9wdnRfdGhyZWFkX211dGV4X3VubG9jayggJnBhc3N3ZF9tdXRleCApOwogCXJldHVy
biByYzsKIH0KKyNlbmRpZiAvKiBIQVZFX0NSWVBUX1IgKi8KKwogI2VuZGlmIC8qIFNMQVBEX0NS
WVBUICovCiAKIHZvaWQgc2xhcF9wYXNzd2RfaW5pdCgpCg==

--_003_282E583D7ED52C4FA3C4CC199465868B02801BECBPXM04GPgispnec_
Content-Type: application/octet-stream;
	name="openldap-slapd_crypt_case2.patch"
Content-Description: openldap-slapd_crypt_case2.patch
Content-Disposition: attachment;
	filename="openldap-slapd_crypt_case2.patch"; size=1444;
	creation-date="Sun, 03 Sep 2017 01:05:35 GMT";
	modification-date="Sun, 03 Sep 2017 01:08:20 GMT"
Content-Transfer-Encoding: base64

bW9kaWZ5IHBhc3N3ZC5jIHNvIHRoYXQgc2xhcGRfY3J5cHQoKSB1c2VzIGNyeXB0X3IoKS4KCmRp
ZmYgLS1naXQgYS9wYXNzd2QuYyBiL3Bhc3N3ZC5jCmluZGV4IGRmYTM3MGMuLjM1ZDg3ZTUgMTAw
NjQ0Ci0tLSBhL3Bhc3N3ZC5jCisrKyBiL3Bhc3N3ZC5jCkBAIC0yMyw4ICsyMywxMSBAQAogI2lu
Y2x1ZGUgPGFjL3VuaXN0ZC5oPgogCiAjaWZkZWYgU0xBUERfQ1JZUFQKKyNpZmRlZiBIQVZFX0NS
WVBUX1IKKyNkZWZpbmUgX19VU0VfR05VCisjZW5kaWYgLyogSEFWRV9DUllQVF9SICovCiAjaW5j
bHVkZSA8YWMvY3J5cHQuaD4KLSNlbmRpZgorI2VuZGlmIC8qIFNMQVBEX0NSWVBUICovCiAKICNp
bmNsdWRlICJzbGFwLmgiCiAKQEAgLTU5MCw2ICs1OTMsMzMgQEAgc2xhcF9wYXNzd2RfaGFzaCgK
IHN0YXRpYyBsZGFwX3B2dF90aHJlYWRfbXV0ZXhfdCBwYXNzd2RfbXV0ZXg7CiBzdGF0aWMgbHV0
aWxfY3J5cHRmdW5jIHNsYXBkX2NyeXB0OwogCisjaWZkZWYgSEFWRV9DUllQVF9SCitzdGF0aWMg
aW50IHNsYXBkX2NyeXB0KCBjb25zdCBjaGFyICprZXksIGNvbnN0IGNoYXIgKnNhbHQsIGNoYXIg
KipoYXNoICkKK3sKKwljaGFyICpjcjsKKwlpbnQgcmM7CisJc3RydWN0IGNyeXB0X2RhdGEgZGF0
YTsKKyAgICAKKwlkYXRhLmluaXRpYWxpemVkID0gMDsKKwljciA9IGNyeXB0X3IoIGtleSwgc2Fs
dCwgJmRhdGEgKTsKKwlpZiAoIGNyID09IE5VTEwgf

Message of length 6058 truncated


Followup 7

Download message
From: Yoshinori Nishino <yos-nishino@ys.jp.nec.com>
To: "hyc@symas.com" <hyc@symas.com>,
        "openldap-its@OpenLDAP.org" <openldap-its@OpenLDAP.org>
CC: Kanji Niwa <kan-niwa@wh.jp.nec.com>
Subject: Re: (ITS#8719) slapd_crypt() become slow when many ldap cliant
 connections occur.
Date: Sun, 3 Sep 2017 02:28:20 +0000
--_003_282E583D7ED52C4FA3C4CC199465868B02804CD4BPXM04GPgispnec_
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable

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
************************************************

--_003_282E583D7ED52C4FA3C4CC199465868B02804CD4BPXM04GPgispnec_
Content-Type: application/octet-stream;
	name="openldap-slapd_crypt_case2.patch"
Content-Description: openldap-slapd_crypt_case2.patch
Content-Disposition: attachment;
	filename="openldap-slapd_crypt_case2.patch"; size=1382;
	creation-date="Sun, 03 Sep 2017 01:05:35 GMT";
	modification-date="Sun, 03 Sep 2017 02:11:42 GMT"
Content-Transfer-Encoding: base64

bW9kaWZ5IHBhc3N3ZC5jIHNvIHRoYXQgc2xhcGRfY3J5cHQoKSB1c2VzIGNyeXB0X3IoKS4KCmRp
ZmYgLS1naXQgYS9zZXJ2ZXJzL3NsYXBkL3Bhc3N3ZC5jIGIvc2VydmVycy9zbGFwZC9wYXNzd2Qu
YwppbmRleCBkZmEzNzBjLi5lY2UwNWZiIDEwMDY0NAotLS0gYS9zZXJ2ZXJzL3NsYXBkL3Bhc3N3
ZC5jCisrKyBiL3NlcnZlcnMvc2xhcGQvcGFzc3dkLmMKQEAgLTIzLDggKzIzLDExIEBACiAjaW5j
bHVkZSA8YWMvdW5pc3RkLmg+CiAKICNpZmRlZiBTTEFQRF9DUllQVAorI2lmZGVmIEhBVkVfQ1JZ
UFRfUgorI2RlZmluZSBfX1VTRV9HTlUKKyNlbmRpZiAvKiBIQVZFX0NSWVBUX1IgKi8KICNpbmNs
dWRlIDxhYy9jcnlwdC5oPgotI2VuZGlmCisjZW5kaWYgLyogU0xBUERfQ1JZUFQgKi8KIAogI2lu
Y2x1ZGUgInNsYXAuaCIKIApAQCAtNTkwLDYgKzU5MywzMCBAQCBzbGFwX3Bhc3N3ZF9oYXNoKAog
c3RhdGljIGxkYXBfcHZ0X3RocmVhZF9tdXRleF90IHBhc3N3ZF9tdXRleDsKIHN0YXRpYyBsdXRp
bF9jcnlwdGZ1bmMgc2xhcGRfY3J5cHQ7CiAKKyNpZmRlZiBIQVZFX0NSWVBUX1IKK3N0YXRpYyBp
bnQgc2xhcGRfY3J5cHQoIGNvbnN0IGNoYXIgKmtleSwgY29uc3QgY2hhciAqc2FsdCwgY2hhciAq
Kmhhc2ggKQoreworCWNoYXIgKmNyOworCWludCByYzsKKwlzdHJ1Y3QgY3J5cHRfZGF0YSBkYXRh
OworICAgIAorCWRhdGEuaW5pdGlhbGl6ZWQgPSAwOworCWNyID0gY3J5cHRfcigga2V5LCBzYWx0
LCAmZGF0YSApOworCWlmICggY3IgPT0gTlVMTCB8fCBjclswXSA9PSAnXDAnICkgeworCQkvKiBz
YWx0IG11c3QgaGF2ZSBiZWVuIGludmFsaWQgKi8KKwkJcmMgPSBMVVRJTF9QQVNTV0RfRVJSOwor
CX0gZWxzZSB7CisJCWlmICggaGFzaCApIHsKKwkJCSpoYXNoID0gYmVyX3N0cmR1cCggY3IgKTsK
KwkJCXJjID0gTFVUSUxfUEFTU1dEX09LOworCQl9IGVsc2UgeworCQkJcmMgPSBzdHJjbXAoIHNh
bHQsIGNyICkgPyBMVVRJTF9QQVNTV0RfRVJSIDogTFVUSUxfUEFTU1dEX09LOworCQl9CisJfQor
CisgICAgcmV0dXJuIHJjOworfQorI2Vsc2UKIHN0YXRpYyBpbnQgc2xhcGRfY3J5cHQoIGNvbnN0
IGNoYXIgKmtleSwgY29uc3QgY2hhciAqc2FsdCwgY2hhciAqKmhhc2ggKQogewogCWNoYXIgKmNy
OwpAQCAtNjE0LDYgKzY0MSw4IEBAIHN0YXRpYyBpbnQgc2xhcGRfY3J5cHQoIGNvbnN0IGNoYXIg
KmtleSwgY29uc3QgY2hhciAqc2FsdCwgY2hhciAqKmhhc2ggKQogCWxkYXBfcHZ0X3RocmVhZF9t
dXRleF91bmxvY2soICZwYXNzd2RfbXV0ZXggKTsKIAlyZXR1cm4gcmM7CiB9CisjZW5kaWYgLyog
SEFWRV9DUllQVF9SICovCisKICNlbmRpZiAvKiBTTEFQRF9DUllQVCAqLwogCiB2b2lkIHNsYXBf
cGFzc3dkX2luaXQoKQo=

--_003_282E583D7ED52C4FA3C4CC199465868B02804CD4BPXM04GPgispnec_
Content-Type: application/octet-stream;
	name="openldap-slapd_crypt_case1.patch"
Content-Description: openldap-slapd_crypt_case1.patch
Content-Disposition: attachment;
	filename="openldap-slapd_crypt_case1.patch"; size=1482;
	creation-date="Sun, 03 Sep 2017 01:05:32 GMT";
	modification-date="Sun, 03 Sep 2017 02:10:39 GMT"
Content-Transfer-Encoding: base64

bW9kaWZ5IHBhc3N3ZC5jIHNvIHRoYXQgc2xhcGRfY3J5cHQoKSB1c2VzIGNyeXB0X3IoKS4KCmRp
ZmYgLS1naXQgYS9zZXJ2ZXJzL3NsYXBkL3Bhc3N3ZC5jIGIvc2VydmVycy9zbGFwZC9wYXNzd2Qu
YwppbmRleCBkZmEzNzBjLi40OTcwNWY4IDEwMDY0NAotLS0gYS9zZXJ2ZXJzL3NsYXBkL3Bhc3N3
ZC5jCisrKyBiL3NlcnZlcnMvc2xhcGQvcGFzc3dkLmMKQEAgLTIzLDggKzIzLDExIEBACiAjaW5j
bHVkZSA8YWMvdW5pc3RkLmg+CiAKICNpZmRlZiBTTEFQRF9DUllQVAorI2lmZGVmIEhBVkVfQ1JZ
UFRfUgorI2RlZmluZSBfX1VTRV9HTlUKKyNlbmRpZiAvKiBIQVZFX0NSWVBUX1IgKi8KICNpbmNs
dWRlIDxhYy9jcnlwdC5oPgotI2VuZGlmCisjZW5kaWYgLyogU0xBUERfQ1JZUFQgKi8KIAogI2lu
Y2x1ZGUgInNsYXAuaCIKIApAQCAtNTkwLDYgKzU5MywzMiBAQCBzbGFwX3Bhc3N3ZF9oYXNoKAog
c3RhdGljIGxkYXBfcHZ0X3RocmVhZF9tdXRleF90IHBhc3N3ZF9tdXRleDsKIHN0YXRpYyBsdXRp
bF9jcnlwdGZ1bmMgc2xhcGRfY3J5cHQ7CiAKKyNpZmRlZiBIQVZFX0NSWVBUX1IKK3N0YXRpYyBp
bnQgc2xhcGRfY3J5cHQoIGNvbnN0IGNoYXIgKmtleSwgY29uc3QgY2hhciAqc2FsdCwgY2hhciAq
Kmhhc2ggKQoreworCWNoYXIgKmNyOworCWludCByYzsKKwlzdHJ1Y3QgY3J5cHRfZGF0YSBkYXRh
OworICAgIAorCWRhdGEuaW5pdGlhbGl6ZWQgPSAwOworCWNyID0gY3J5cHRfcigga2V5LCBzYWx0
LCAmZGF0YSApOworCWlmICggY3IgPT0gTlVMTCB8fCBjclswXSA9PSAnXDAnICkgeworCQkvKiBz
YWx0IG11c3QgaGF2ZSBiZWVuIGludmFsaWQgKi8KKwkJcmMgPSBMVVRJTF9QQVNTV0RfRVJSOwor
CX0gZWxzZSB7CisJCWlmICggaGFzaCApIHsKKwkJCWxkYXBfcHZ0X3RocmVhZF9tdXRleF9sb2Nr
KCAmcGFzc3dkX211dGV4ICk7CisJCQkqaGFzaCA9IGJlcl9zdHJkdXAoIGNyICk7CisJCQlsZGFw
X3B2dF90aHJlYWRfbXV0ZXhfdW5sb2NrKCAmcGFzc3dkX211dGV4ICk7CisJCQlyYyA9IExVVElM
X1BBU1NXRF9PSzsKKwkJfSBlbHNlIHsKKwkJCXJjID0gc3RyY21wKCBzYWx0LCBjciApID8gTFVU
SUxfUEFTU1dEX0VSUiA6IExVVElMX1BBU1NXRF9PSzsKKwkJfQorCX0KKworICAgIHJldHVybiBy
YzsKK30KKyNlbHNlCiBzdGF0aWMgaW50IHNsYXBkX2NyeXB0KCBjb25zdCBjaGFyICprZXksIGNv
bnN0IGNoYXIgKnNhbHQsIGNoYXIgKipoYXNoICkKIHsKIAljaGFyICpjcjsKQEAgLTYxNCw2ICs2
NDMsOCBAQCBzdGF0

Message of length 5361 truncated


Followup 8

Download message
Subject: Re: (ITS#8719) slapd_crypt() become slow when many ldap cliant
 connections occur.
To: Yoshinori Nishino <yos-nishino@ys.jp.nec.com>,
 "openldap-its@OpenLDAP.org" <openldap-its@OpenLDAP.org>
Cc: Kanji Niwa <kan-niwa@wh.jp.nec.com>
From: Howard Chu <hyc@symas.com>
Date: Sun, 3 Sep 2017 11:34:20 +0100
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/



Followup 9

Download message
From: Yoshinori Nishino <yos-nishino@ys.jp.nec.com>
To: "hyc@symas.com" <hyc@symas.com>,
        "openldap-its@OpenLDAP.org" <openldap-its@OpenLDAP.org>
CC: Kanji Niwa <kan-niwa@wh.jp.nec.com>
Subject: Re: (ITS#8719) slapd_crypt() become slow when many ldap cliant
 connections occur.
Date: Sun, 3 Sep 2017 10:51:47 +0000
Dear Howard-san,

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

I think ber_strdup(), which uses ber_memalloc_x(), is non thread-safe becau=
se 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 applicat=
ions,
 * you must put mutexes around them, otherwise they will have incorrect val=
ues.
 * When debugging, if you sort the debug output, the sequence number will=20
 * put allocations/frees together.  It is then a simple matter to write a s=
cript
 * 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
************************************************





Followup 10

Download message
Subject: Re: (ITS#8719) slapd_crypt() become slow when many ldap cliant
 connections occur.
To: Yoshinori Nishino <yos-nishino@ys.jp.nec.com>,
 "openldap-its@OpenLDAP.org" <openldap-its@OpenLDAP.org>
Cc: Kanji Niwa <kan-niwa@wh.jp.nec.com>
From: Howard Chu <hyc@symas.com>
Date: Sun, 3 Sep 2017 12:01:51 +0100
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/



Followup 11

Download message
From: Yoshinori Nishino <yos-nishino@ys.jp.nec.com>
To: "hyc@symas.com" <hyc@symas.com>,
        "openldap-its@OpenLDAP.org" <openldap-its@OpenLDAP.org>
CC: Kanji Niwa <kan-niwa@wh.jp.nec.com>
Subject: Re: (ITS#8719) slapd_crypt() become slow when many ldap cliant
 connections occur.
Date: Sun, 3 Sep 2017 11:18:04 +0000
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.


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
************************************************




Followup 12

Download message
Subject: Re: (ITS#8719) slapd_crypt() become slow when many ldap cliant
 connections occur.
To: yos-nishino@ys.jp.nec.com, openldap-its@OpenLDAP.org
From: Howard Chu <hyc@symas.com>
Date: Wed, 6 Sep 2017 21:35:22 +0100
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/


Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest


The OpenLDAP Issue Tracking System uses a hacked version of JitterBug

______________
© Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org