openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#8107) olcMemberOfDangling: error doesn't prevent adding nonexistent member to group
by ryan＠nardis.ca 19 Apr '15

19 Apr '15

Adding a new group containing a nonexistent member, or or a nonexistent member to an existing group, triggers the following AddressSanitizer splat. No error when adding a valid member, or with memberof disabled. (Line numbers from git master) 5532dc8c connection_get(11): got connid=1000 5532dc8c connection_read(11): checking for input on id=1000 ber_get_next ber_get_next: tag 0x30 len 66 contents: 5532dc8c op tag 0x66, time 1429396620 ber_get_next 5532dc8c conn=1000 op=2 do_modify ber_scanf fmt ({m) ber: ber_scanf fmt ({e{m[W]}}) ber: 5532dc8c >>> dnPrettyNormal: <cn=testgroup,dc=example,dc=com> 5532dc8c <<< dnPrettyNormal: <cn=testgroup,dc=example,dc=com>, <cn=testgroup,dc=example,dc=com> 5532dc8c >>> dnPretty: <cn=dummy> 5532dc8c <<< dnPretty: <cn=dummy> 5532dc8c >>> dnNormalize: <cn=dummy> 5532dc8c <<< dnNormalize: <cn=dummy> 5532dc8c => mdb_search 5532dc8c mdb_dn2entry("cn=testgroup,dc=example,dc=com") 5532dc8c => mdb_dn2id("cn=testgroup,dc=example,dc=com") 5532dc8c <= mdb_dn2id: got id=0x3 5532dc8c => mdb_entry_decode: 5532dc8c <= mdb_entry_decode 5532dc8c send_ldap_result: conn=1000 op=2 p=3 5532dc8c mdb_dn2entry("cn=dummy") 5532dc8c => mdb_dn2id("cn=dummy") ================================================================= ==1998==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000024967 at pc 0x000000ebdb1f bp 0x7f91f2773650 sp 0x7f91f2773648 READ of size 1 at 0x602000024967 thread T2 #0 0xebdb1e in lutil_strncopy /home/ryan/pkg/openldap/openldap/libraries/liblutil/utils.c:317:2 #1 0xd10adb in mdb_dn2id /home/ryan/pkg/openldap/openldap/servers/slapd/back-mdb/dn2id.c:360:9 #2 0xd0798e in mdb_dn2entry /home/ryan/pkg/openldap/openldap/servers/slapd/back-mdb/dn2entry.c:51:7 #3 0xd4afb5 in mdb_entry_get /home/ryan/pkg/openldap/openldap/servers/slapd/back-mdb/id2entry.c:336:7 #4 0xa8feb5 in overlay_entry_get_ov /home/ryan/pkg/openldap/openldap/servers/slapd/backover.c:376:9 #5 0xaa6dd2 in over_entry_get_rw /home/ryan/pkg/openldap/openldap/servers/slapd/backover.c:408:9 #6 0x6a4d9c in be_entry_get_rw /home/ryan/pkg/openldap/openldap/servers/slapd/backend.c:1436:10 #7 0xdb6298 in memberof_op_modify /home/ryan/pkg/openldap/openldap/servers/slapd/overlays/memberof.c:892:12 #8 0xa931bb in overlay_op_walk /home/ryan/pkg/openldap/openldap/servers/slapd/backover.c:681:9 #9 0xaadbea in over_op_func /home/ryan/pkg/openldap/openldap/servers/slapd/backover.c:749:7 #10 0xaa5493 in over_op_modify /home/ryan/pkg/openldap/openldap/servers/slapd/backover.c:788:9 #11 0x7144f2 in fe_op_modify /home/ryan/pkg/openldap/openldap/servers/slapd/modify.c:303:4 #12 0x70b08e in do_modify /home/ryan/pkg/openldap/openldap/servers/slapd/modify.c:177:15 #13 0x609ccc in connection_operation /home/ryan/pkg/openldap/openldap/servers/slapd/connection.c:1134:7 #14 0x602ec3 in connection_read_thread /home/ryan/pkg/openldap/openldap/servers/slapd/connection.c:1280:14 #15 0xf094de in ldap_int_thread_pool_wrapper /home/ryan/pkg/openldap/openldap/libraries/libldap_r/tpool.c:958:3 #16 0x7f91fc2f40a3 in start_thread /build/glibc-Ir_s5K/glibc-2.19/nptl/pthread_create.c:309 #17 0x7f91fb70604c in clone /build/glibc-Ir_s5K/glibc-2.19/misc/../sysdeps/unix/sysv/linux/x86_64/clone.S:111 0x602000024967 is located 9 bytes to the left of 10-byte region [0x602000024970,0x60200002497a) allocated by thread T2 here: #0 0x4bb46b in malloc (/usr/local/libexec/slapd+0x4bb46b) #1 0x10e4d7f in ber_memalloc_x /home/ryan/pkg/openldap/openldap/libraries/liblber/memory.c:228:9 #2 0xfc01e1 in ldap_dn2bv_x /home/ryan/pkg/openldap/openldap/libraries/libldap_r/getdn.c:3015:23 #3 0x6e7a37 in dnNormalize /home/ryan/pkg/openldap/openldap/servers/slapd/dn.c:454:8 #4 0x744d1d in ordered_value_normalize /home/ryan/pkg/openldap/openldap/servers/slapd/value.c:587:7 #5 0x7106cd in slap_mods_check /home/ryan/pkg/openldap/openldap/servers/slapd/modify.c:627:11 #6 0x70aca3 in do_modify /home/ryan/pkg/openldap/openldap/servers/slapd/modify.c:168:15 #7 0x609ccc in connection_operation /home/ryan/pkg/openldap/openldap/servers/slapd/connection.c:1134:7 #8 0x602ec3 in connection_read_thread /home/ryan/pkg/openldap/openldap/servers/slapd/connection.c:1280:14 #9 0xf094de in ldap_int_thread_pool_wrapper /home/ryan/pkg/openldap/openldap/libraries/libldap_r/tpool.c:958:3 #10 0x7f91fc2f40a3 in start_thread /build/glibc-Ir_s5K/glibc-2.19/nptl/pthread_create.c:309 Thread T2 created by T1 here: #0 0x4a309f in __interceptor_pthread_create (/usr/local/libexec/slapd+0x4a309f) #1 0xf1d269 in ldap_pvt_thread_create /home/ryan/pkg/openldap/openldap/libraries/libldap_r/thr_posix.c:165:8 #2 0xf05f35 in ldap_pvt_thread_pool_submit /home/ryan/pkg/openldap/openldap/libraries/libldap_r/tpool.c:420:12 #3 0x5e92a5 in slap_listener_activate /home/ryan/pkg/openldap/openldap/servers/slapd/daemon.c:2097:7 #4 0x5e17a4 in slapd_daemon_task /home/ryan/pkg/openldap/openldap/servers/slapd/daemon.c:2728:10 #5 0x7f91fc2f40a3 in start_thread /build/glibc-Ir_s5K/glibc-2.19/nptl/pthread_create.c:309 Thread T1 created by T0 here: #0 0x4a309f in __interceptor_pthread_create (/usr/local/libexec/slapd+0x4a309f) #1 0xf1d269 in ldap_pvt_thread_create /home/ryan/pkg/openldap/openldap/libraries/libldap_r/thr_posix.c:165:8 #2 0x5d2539 in slapd_daemon /home/ryan/pkg/openldap/openldap/servers/slapd/daemon.c:2898:8 #3 0x4e2e3e in main /home/ryan/pkg/openldap/openldap/servers/slapd/main.c:1018:7 #4 0x7f91fb641b44 in __libc_start_main /build/glibc-Ir_s5K/glibc-2.19/csu/libc-start.c:287 SUMMARY: AddressSanitizer: heap-buffer-overflow /home/ryan/pkg/openldap/openldap/libraries/liblutil/utils.c:317 lutil_strncopy Shadow bytes around the buggy address: 0x0c047fffc8d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fffc8e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fffc8f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fffc900: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fffc910: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =>0x0c047fffc920: fa fa fa fa fa fa fa fa fa fa fa fa[fa]fa 00 02 0x0c047fffc930: fa fa fd fd fa fa fd fd fa fa fd fa fa fa 00 02 0x0c047fffc940: fa fa fd fd fa fa fd fa fa fa fd fd fa fa fd fd 0x0c047fffc950: fa fa fd fa fa fa fd fd fa fa fd fa fa fa fd fa 0x0c047fffc960: fa fa fd fd fa fa fd fa fa fa fd fa fa fa fd fa 0x0c047fffc970: fa fa fd fa fa fa fd fa fa fa fd fd fa fa fd fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc ASan internal: fe ==1998==ABORTING

1 0

Re: (ITS#8106) Retry pwrite operations in case of EINTR
by hyc＠symas.com 18 Apr '15

18 Apr '15

Dmytro Milinevskyy wrote: > Hello, > we've encountered this problem mainly on Android device. The kernel > sends a fake signal and the baking storage(flash) is not so fast. > I've noticed a typo in my patch for the macro DO_PWRITE in > mdb_env_init_meta. The test should be done for EINTR, not EINVAL. > Do you want me to resend the patch? Yes I already noticed that, so I wrote the patch myself instead of applying yours. Thank you for the context, that's good information. > > Thanks, > Dmytro > > On Fri, Apr 17, 2015 at 7:34 PM, Howard Chu <hyc(a)symas.com > <mailto:hyc@symas.com>> wrote: > > milinevskyy(a)gmail.com <mailto:milinevskyy@gmail.com> wrote: > > Full_Name: Dmytro Milinevskyy > Version: > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (92.132.131.166) > > > On linux systems it's common to have system calls interrupted > and restarted. > LMDB should retry pwrites to avoid "false" failures. > > > In practice, writes to a file are "fast" and will always write at > least one byte. But we've patched this as suggested, thanks. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8106) Retry pwrite operations in case of EINTR
by milinevskyy＠gmail.com 17 Apr '15

17 Apr '15

--047d7bd910b0d34afe0513f14c84 Content-Type: text/plain; charset=UTF-8 Hello, we've encountered this problem mainly on Android device. The kernel sends a fake signal and the baking storage(flash) is not so fast. I've noticed a typo in my patch for the macro DO_PWRITE in mdb_env_init_meta. The test should be done for EINTR, not EINVAL. Do you want me to resend the patch? Thanks, Dmytro On Fri, Apr 17, 2015 at 7:34 PM, Howard Chu <hyc(a)symas.com> wrote: > milinevskyy(a)gmail.com wrote: > >> Full_Name: Dmytro Milinevskyy >> Version: >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (92.132.131.166) >> >> >> On linux systems it's common to have system calls interrupted and >> restarted. >> LMDB should retry pwrites to avoid "false" failures. >> > > In practice, writes to a file are "fast" and will always write at least > one byte. But we've patched this as suggested, thanks. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > --047d7bd910b0d34afe0513f14c84 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div><div><div>Hello,<br>we've encountered this proble= m mainly on Android device. The kernel sends a fake signal and the baking s= torage(flash) is not so fast.<br>I've noticed a typo in my patch for th= e macro DO_PWRITE in mdb_env_init_meta. The test should be done for EINTR, = not EINVAL.<br></div>Do you want me to resend the patch?<br><br></div>Thank= s,<br></div>Dmytro<br></div><div class=3D"gmail_extra"><br><div class=3D"gm= ail_quote">On Fri, Apr 17, 2015 at 7:34 PM, Howard Chu <span dir=3D"ltr">&l= t;<a href=3D"mailto:hyc@symas.com" target=3D"_blank">hyc(a)symas.com</a>><= /span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8= ex;border-left:1px #ccc solid;padding-left:1ex"><a href=3D"mailto:milinevsk= yy(a)gmail.com" target=3D"_blank">milinevskyy(a)gmail.com</a> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Full_Name: Dmytro Milinevskyy<br> Version:<br> OS: Linux<br> URL: <a href=3D"ftp://ftp.openldap.org/incoming/" target=3D"_blank">ftp://f= tp.openldap.org/incoming/</a><br> Submission from: (NULL) (92.132.131.166)<br> <br> <br> On linux systems it's common to have system calls interrupted and resta= rted.<br> LMDB should retry pwrites to avoid "false" failures.<br> </blockquote> <br> In practice, writes to a file are "fast" and will always write at= least one byte. But we've patched this as suggested, thanks.<span clas= s=3D"HOEnZb"><font color=3D"#888888"><br> <br> -- <br> =C2=A0 -- Howard Chu<br> =C2=A0 CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"= http://www.symas.com" target=3D"_blank">http://www.symas.com</a><br> =C2=A0 Director, Highland Sun=C2=A0 =C2=A0 =C2=A0<a href=3D"http://highland= sun.com/hyc/" target=3D"_blank">http://highlandsun.com/hyc/</a><br> =C2=A0 Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.openldap.org/p= roject/" target=3D"_blank">http://www.openldap.org/project/</a><br> </font></span></blockquote></div><br></div> --047d7bd910b0d34afe0513f14c84--

1 0

(ITS#8107) olcMemberOfDangling: error doesn't prevent adding nonexistent member to group
by rtandy＠sd63.bc.ca 17 Apr '15

17 Apr '15

Full_Name: Ryan Tandy Version: RE24 OS: Ubuntu URL: Submission from: (NULL) (142.31.146.2) $ git describe OPENLDAP_REL_ENG_2_4_40-208-gfd03ec0 $ ./configure --disable-bdb --disable-hdb --enable-memberof && make -j8 && sudo make STRIP= install [...] $ slapadd -Fconfig.d -n0 dn: cn=config objectClass%3ololcGlobal dn: cn=schema,cn=config objectClass: olcSchemaConfig include: file:///usr/local/etc/openldap/schema/core.ldif include: file:///usr/local/etc/openldap/schema/cosine.ldif dn: olcDatabase={1}mdb,cn=config objectClass: olcMdbConfig olcDbDirectory: data.d olcSuffix: dc=example,dc=com olcDbIndex: objectClass eq olcAccess: to * by dn="cn=admin,dc=example,dc=com" write by * read dn: olcOverlay=memberof,olcDatabase={1}mdb,cn=config objectClass: olcMemberOf olcMemberOfDangling: error $ slapadd -Fconfig.d dn: dc=example,dc=com objectClass: domain dn: cn=admin,dc=example,dc=com objectClass: organizationalRole objectClass: simpleSecurityObject userPassword: secret $ /usr/local/libexec/slapd -h ldap://:9000 -Fnfigig.d $ ldapadd -H ldap://:9000 -x -D cn=admin,dc=example,dc=com -w secret dn: cn=testgroup,dc=example,dc=com objectClass: groupOfNames member: cn=nonexistent adding new entry "cn=testgroup,dc=example,dc=com" ldap_add: Constraint violation (19) additional info: adding non-existing object as group member $ ldapsearch -H ldap://:9000 -x -b cn=testgroup,dc=example,dc=com # extended LDIF # # LDAPv3 # base <cn=testgroup,dc=example,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL%%2# # search result search: 2 result: 32 No such object matchedDN: dc=example,dc=com # numResponses: 1 OK, that's fine. The new entry was rejected. $ ldapadd -H ldap://:9000 -x -D cn=admin,dc=example,dc=com -w secret dn: cn=testgroup,dc=example,dc=com objectClass: groupOfNames member: cn=admin,dc=example,dc=com adding new entry "cn=testgroup,dc=example,dc=com" dn: cn=testgroup,dc=example,dc=com changetype: modify add: member member: cn=nonexistent modifying entry "cn=testgroup,dc=example,dc=com" ldap_modify: Constraint violation (19) additional info: adding non-existing object as group member $ ldapsearch -H ldap://:9000 -x -b cn=testgroup,dc=example,dc=com # extended LDIF # # LDAPv3 # base <cn=testgroup,dc=example,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL # # testgroup, example.com dn: cn=testgroup,dc=example,dc=com objectClass: groupOfNames member: cn=admin,dc=example,dc=com member: cn=nonexistent cn: testgroup # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 This is unexpected. The member addition was rejected, but somehow the modification went through anyway? Seems like something spooky is going on here... 903 9%9 send_ldap_result( op, rs ); (gdb) p rc $4 = 19 (gdb) n 55315ce0 send_ldap_result: conn=1001 op=2 p=3 55315ce0 send_ldap_response: msgid=3 tag=103 err=19 ber_flush2: 56 bytes to sd 12 1214 op->o_dn = save_dn; (gdb) p rc $5 = 32768 (gdb) p rs->sr_err $6 = 19D%D Am I reading that right, send_ldap_result is somehow overwriting rc in the caller? Happens at -O0 as well as -O2.

1 0

Re: (ITS#8106) Retry pwrite operations in case of EINTR
by hyc＠symas.com 17 Apr '15

17 Apr '15

milinevskyy(a)gmail.com wrote: > Full_Name: Dmytro Milinevskyy > Version: > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (92.132.131.166) > > > On linux systems it's common to have system calls interrupted and restarted. > LMDB should retry pwrites to avoid "false" failures. In practice, writes to a file are "fast" and will always write at least one byte. But we've patched this as suggested, thanks. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8106) Retry pwrite operations in case of EINTR
by milinevskyy＠gmail.com 17 Apr '15

17 Apr '15

--f46d04426b642829070513e7a46a Content-Type: text/plain; charset=UTF-8 Proposed patch in message body as issue tracker doesn't recognizes attachments: commit c9857a7c0df4448a14a2aa9f55850df5e830069e Author: Dmytro Milinevskyy <milinevskyy(a)gmail.com> Date: Fri Apr 17 10:41:26 2015 +0200 libmdb: retry write operation in case of interrupted system diff --git a/libraries/liblmdb/mdb.c b/libraries/liblmdb/mdb.c index a95c7cd..ed7f370 100644 --- a/libraries/liblmdb/mdb.c +++ b/libraries/liblmdb/mdb.c @@ -3236,6 +3236,7 @@ mdb_page_flush(MDB_txn *txn, int keep) /* Write up to MDB_COMMIT_PAGES dirty pages at a time. */ if (pos!=next_pos || n==MDB_COMMIT_PAGES || wsize+size>MAX_WRITE) { if (n) { + retry_write: /* Write previous page(s) */ #ifdef MDB_USE_PWRITEV wres = pwritev(env->me_fd, iov, n, wpos); @@ -3243,8 +3244,10 @@ mdb_page_flush(MDB_txn *txn, int keep) if (n == 1) { wres = pwrite(env->me_fd, iov[0].iov_base, wsize, wpos); } else { + retry_seek: if (lseek(env->me_fd, wpos, SEEK_SET) == -1) { rc = ErrCode(); + if (EINTR == rc) goto retry_seek; DPRINTF(("lseek: %s", strerror(rc))); return rc; } @@ -3254,6 +3257,7 @@ mdb_page_flush(MDB_txn *txn, int keep) if (wres != wsize) { if (wres < 0) { rc = ErrCode(); + if (EINTR == rc) goto retry_write; DPRINTF(("Write error: %s", strerror(rc))); } else { rc = EIO; /* TODO: Use which error code? */ @@ -3627,7 +3631,8 @@ mdb_env_init_meta(MDB_env *env, MDB_meta *meta) int len; #define DO_PWRITE(rc, fd, ptr, size, len, pos) do { \ len = pwrite(fd, ptr, size, pos); \ - rc = (len >= 0); } while(0) + if (len == -1 && EINVAL == ErrCode()) continue; \ + rc = (len >= 0); break; } while(1) #endif DPUTS("writing new meta page"); @@ -3735,6 +3740,7 @@ mdb_env_write_meta(MDB_txn *txn) /* Write to the SYNC fd */ mfd = (flags & (MDB_NOSYNC|MDB_NOMETASYNC)) ? env->me_fd : env->me_mfd; +retry_write: #ifdef _WIN32 { memset(&ov, 0, sizeof(ov)); @@ -3747,6 +3753,7 @@ mdb_env_write_meta(MDB_txn *txn) #endif if (rc != len) { rc = rc < 0 ? ErrCode() : EIO; + if (EINTR == rc) goto retry_write; DPUTS("write failed, disk error?"); /* On a failure, the pagecache still contains the new data. * Write some old data back, to prevent it from being used. On Fri, Apr 17, 2015 at 10:46 AM, Dmytro Milinevskyy <milinevskyy(a)gmail.com> wrote: > Proposed patch in attachment. > > On Fri, Apr 17, 2015 at 10:43 AM, <openldap-its(a)openldap.org> wrote: > >> >> *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** >> >> Thanks for your report to the OpenLDAP Issue Tracking System. Your >> report has been assigned the tracking number ITS#8106. >> >> One of our support engineers will look at your report in due course. >> Note that this may take some time because our support engineers >> are volunteers. They only work on OpenLDAP when they have spare >> time. >> >> If you need to provide additional information in regards to your >> issue report, you may do so by replying to this message. Note that >> any mail sent to openldap-its(a)openldap.org with (ITS#8106) >> in the subject will automatically be attached to the issue report. >> >> mailto:openldap-its@openldap.org?subject=(ITS#8106) >> >> You may follow the progress of this report by loading the following >> URL in a web browser: >> http://www.OpenLDAP.org/its/index.cgi?findid=8106 >> >> Please remember to retain your issue tracking number (ITS#8106) >> on any further messages you send to us regarding this report. If >> you don't then you'll just waste our time and yours because we >> won't be able to properly track the report. >> >> Please note that the Issue Tracking System is not intended to >> be used to seek help in the proper use of OpenLDAP Software. >> Such requests will be closed. >> >> OpenLDAP Software is user supported. >> http://www.OpenLDAP.org/support/ >> >> -------------- >> Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. >> >> > --f46d04426b642829070513e7a46a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdiBkaXI9Imx0ciI+UHJvcG9zZWQgcGF0Y2ggaW4gbWVzc2FnZSBib2R5IGFzIGlzc3VlIHRy YWNrZXIgZG9lc24mIzM5O3QgcmVjb2duaXplcyBhdHRhY2htZW50czo8YnI+PGJyPmNvbW1pdCBj OTg1N2E3YzBkZjQ0NDhhMTRhMmFhOWY1NTg1MGRmNWU4MzAwNjllPGJyPkF1dGhvcjogRG15dHJv IE1pbGluZXZza3l5ICZsdDs8YSBocmVmPSJtYWlsdG86bWlsaW5ldnNreXlAZ21haWwuY29tIj5t aWxpbmV2c2t5eUBnbWFpbC5jb208L2E+Jmd0Ozxicj5EYXRlOsKgwqAgRnJpIEFwciAxNyAxMDo0 MToyNiAyMDE1ICswMjAwPGJyPjxicj7CoMKgwqAgbGlibWRiOiByZXRyeSB3cml0ZSBvcGVyYXRp b24gaW4gY2FzZSBvZiBpbnRlcnJ1cHRlZCBzeXN0ZW08YnI+PGJyPmRpZmYgLS1naXQgYS9saWJy YXJpZXMvbGlibG1kYi9tZGIuYyBiL2xpYnJhcmllcy9saWJsbWRiL21kYi5jPGJyPmluZGV4IGE5 NWM3Y2QuLmVkN2YzNzAgMTAwNjQ0PGJyPi0tLSBhL2xpYnJhcmllcy9saWJsbWRiL21kYi5jPGJy PisrKyBiL2xpYnJhcmllcy9saWJsbWRiL21kYi5jPGJyPkBAIC0zMjM2LDYgKzMyMzYsNyBAQCBt ZGJfcGFnZV9mbHVzaChNREJfdHhuICp0eG4sIGludCBrZWVwKTxicj7CoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqAgLyogV3JpdGUgdXAgdG8gTURCX0NPTU1JVF9QQUdFUyBkaXJ0eSBwYWdl cyBhdCBhIHRpbWUuICovPGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBpZiAocG9z IT1uZXh0X3BvcyB8fCBuPT1NREJfQ09NTUlUX1BBR0VTIHx8IHdzaXplK3NpemUmZ3Q7TUFYX1dS SVRFKSB7PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg aWYgKG4pIHs8YnI+K8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHJldHJ5X3dyaXRlOjxicj7C oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoCAvKiBXcml0ZSBwcmV2aW91cyBwYWdlKHMpICovPGJyPsKgI2lmZGVmIE1EQl9VU0VfUFdS SVRFVjxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCB3cmVzID0gcHdyaXRldihlbnYtJmd0O21lX2ZkLCBpb3YsIG4sIHdwb3Mp Ozxicj5AQCAtMzI0Myw4ICszMjQ0LDEwIEBAIG1kYl9wYWdlX2ZsdXNoKE1EQl90eG4gKnR4biwg aW50IGtlZXApPGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgIGlmIChuID09IDEpIHs8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg IHdyZXMgPSBwd3JpdGUoZW52LSZndDttZV9mZCwgaW92WzBdLmlvdl9iYXNlLCB3c2l6ZSwgd3Bv cyk7PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgIH0gZWxzZSB7PGJyPivCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHJldHJ5X3NlZWs6PGJyPsKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCBpZiAobHNlZWsoZW52LSZndDttZV9mZCwgd3BvcywgU0VFS19TRVQpID09 IC0xKSB7PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgcmMgPSBFcnJD b2RlKCk7PGJyPivCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBpZiAoRUlOVFIg PT0gcmMpIGdvdG8gcmV0cnlfc2Vlazs8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCBEUFJJTlRGKCgmcXVvdDtsc2VlazogJXMmcXVvdDssIHN0cmVycm9yKHJjKSkpOzxi cj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHJldHVybiByYzs8YnI+wqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgIH08YnI+QEAgLTMyNTQsNiArMzI1Nyw3IEBAIG1kYl9wYWdlX2Zs dXNoKE1EQl90eG4gKnR4biwgaW50IGtlZXApPGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGlmICh3cmVzICE9IHdzaXplKSB7 PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBpZiAod3JlcyAmbHQ7IDApIHs8YnI+wqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCByYyA9IEVyckNvZGUoKTs8YnI+K8KgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGlmIChFSU5UUiA9PSByYykgZ290byByZXRyeV93 cml0ZTs8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBEUFJJTlRGKCgm cXVvdDtXcml0ZSBlcnJvcjogJXMmcXVvdDssIHN0cmVycm9yKHJjKSkpOzxicj7CoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgfSBlbHNlIHs8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoCByYyA9IEVJTzsgLyogVE9ETzogVXNlIHdoaWNoIGVycm9yIGNvZGU/ICovPGJyPkBAIC0z NjI3LDcgKzM2MzEsOCBAQCBtZGJfZW52X2luaXRfbWV0YShNREJfZW52ICplbnYsIE1EQl9tZXRh ICptZXRhKTxicj7CoMKgwqDCoMKgwqDCoCBpbnQgbGVuOzxicj7CoCNkZWZpbmUgRE9fUFdSSVRF KHJjLCBmZCwgcHRyLCBzaXplLCBsZW4sIHBvcykgZG8geyBcPGJyPsKgwqDCoMKgwqDCoMKgIGxl biA9IHB3cml0ZShmZCwgcHRyLCBzaXplLCBwb3MpO8KgwqDCoMKgwqDCoCBcPGJyPi3CoMKgwqDC oMKgwqAgcmMgPSAobGVuICZndDs9IDApOyB9IHdoaWxlKDApPGJyPivCoMKgwqDCoMKgwqAgaWYg KGxlbiA9PSAtMSAmYW1wOyZhbXA7IEVJTlZBTCA9PSBFcnJDb2RlKCkpIGNvbnRpbnVlOyBcPGJy PivCoMKgwqDCoMKgwqAgcmMgPSAobGVuICZndDs9IDApOyBicmVhazsgfSB3aGlsZSgxKTxicj7C oCNlbmRpZjxicj48YnI+wqDCoMKgwqDCoMKgwqAgRFBVVFMoJnF1b3Q7d3JpdGluZyBuZXcgbWV0 YSBwYWdlJnF1b3Q7KTs8YnI+QEAgLTM3MzUsNiArMzc0MCw3IEBAIG1kYl9lbnZfd3JpdGVfbWV0 YShNREJfdHhuICp0eG4pPGJyPjxicj7CoMKgwqDCoMKgwqDCoCAvKiBXcml0ZSB0byB0aGUgU1lO QyBmZCAqLzxicj7CoMKgwqDCoMKgwqDCoCBtZmQgPSAoZmxhZ3MgJmFtcDsgKE1EQl9OT1NZTkN8 TURCX05PTUVUQVNZTkMpKSA/IGVudi0mZ3Q7bWVfZmQgOiBlbnYtJmd0O21lX21mZDs8YnI+K3Jl dHJ5X3dyaXRlOjxicj7CoCNpZmRlZiBfV0lOMzI8YnI+wqDCoMKgwqDCoMKgwqAgezxicj7CoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgbWVtc2V0KCZhbXA7b3YsIDAsIHNpemVvZihvdikp Ozxicj5AQCAtMzc0Nyw2ICszNzUzLDcgQEAgbWRiX2Vudl93cml0ZV9tZXRhKE1EQl90eG4gKnR4 bik8YnI+wqAjZW5kaWY8YnI+wqDCoMKgwqDCoMKgwqAgaWYgKHJjICE9IGxlbikgezxicj7CoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgcmMgPSByYyAmbHQ7IDAgPyBFcnJDb2RlKCkgOiBF SU87PGJyPivCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGlmIChFSU5UUiA9PSByYykgZ290 byByZXRyeV93cml0ZTs8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIERQVVRTKCZx dW90O3dyaXRlIGZhaWxlZCwgZGlzayBlcnJvcj8mcXVvdDspOzxicj7CoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqAgLyogT24gYSBmYWlsdXJlLCB0aGUgcGFnZWNhY2hlIHN0aWxsIGNvbnRh aW5zIHRoZSBuZXcgZGF0YS48YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgKiBX cml0ZSBzb21lIG9sZCBkYXRhIGJhY2ssIHRvIHByZXZlbnQgaXQgZnJvbSBiZWluZyB1c2VkLjxi cj48L2Rpdj48ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1 b3RlIj5PbiBGcmksIEFwciAxNywgMjAxNSBhdCAxMDo0NiBBTSwgRG15dHJvIE1pbGluZXZza3l5 IDxzcGFuIGRpcj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOm1pbGluZXZza3l5QGdtYWlsLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPm1pbGluZXZza3l5QGdtYWlsLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3 cm90ZTo8YnI+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAg MCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+PGRp diBkaXI9Imx0ciI+UHJvcG9zZWQgcGF0Y2ggaW4gYXR0YWNobWVudC48YnI+PC9kaXY+PGRpdiBj bGFzcz0iSE9FblpiIj48ZGl2IGNsYXNzPSJoNSI+PGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxi cj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gRnJpLCBBcHIgMTcsIDIwMTUgYXQgMTA6NDMg QU0sICA8c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIGhyZWY9Im1haWx0bzpvcGVubGRhcC1pdHNAb3Bl bmxkYXAub3JnIiB0YXJnZXQ9Il9ibGFuayI+b3BlbmxkYXAtaXRzQG9wZW5sZGFwLm9yZzwvYT4m Z3Q7PC9zcGFuPiB3cm90ZTo8YnI+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHls ZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1s ZWZ0OjFleCI+PGJyPg0KKioqIFRISVMgSVMgQU4gQVVUT01BVElDQUxMWSBHRU5FUkFURUQgUkVQ TFkgKioqPGJyPg0KPGJyPg0KVGhhbmtzIGZvciB5b3VyIHJlcG9ydCB0byB0aGUgT3BlbkxEQVAg SXNzdWUgVHJhY2tpbmcgU3lzdGVtLsKgIFlvdXI8YnI+DQpyZXBvcnQgaGFzIGJlZW4gYXNzaWdu ZWQgdGhlIHRyYWNraW5nIG51bWJlciBJVFMjODEwNi48YnI+DQo8YnI+DQpPbmUgb2Ygb3VyIHN1 cHBvcnQgZW5naW5lZXJzIHdpbGwgbG9vayBhdCB5b3VyIHJlcG9ydCBpbiBkdWUgY291cnNlLjxi cj4NCk5vdGUgdGhhdCB0aGlzIG1heSB0YWtlIHNvbWUgdGltZSBiZWNhdXNlIG91ciBzdXBwb3J0 IGVuZ2luZWVyczxicj4NCmFyZSB2b2x1bnRlZXJzLsKgIFRoZXkgb25seSB3b3JrIG9uIE9wZW5M REFQIHdoZW4gdGhleSBoYXZlIHNwYXJlPGJyPg0KdGltZS48YnI+DQo8YnI+DQpJZiB5b3UgbmVl ZCB0byBwcm92aWRlIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gaW4gcmVnYXJkcyB0byB5b3VyPGJy Pg0KaXNzdWUgcmVwb3J0LCB5b3UgbWF5IGRvIHNvIGJ5IHJlcGx5aW5nIHRvIHRoaXMgbWVzc2Fn ZS7CoCBOb3RlIHRoYXQ8YnI+DQphbnkgbWFpbCBzZW50IHRvIDxhIGhyZWY9Im1haWx0bzpvcGVu bGRhcC1pdHNAb3BlbmxkYXAub3JnIiB0YXJnZXQ9Il9ibGFuayI+b3BlbmxkYXAtaXRzQG9wZW5s ZGFwLm9yZzwvYT4gd2l0aCAoSVRTIzgxMDYpPGJyPg0KaW4gdGhlIHN1YmplY3Qgd2lsbCBhdXRv bWF0aWNhbGx5IGJlIGF0dGFjaGVkIHRvIHRoZSBpc3N1ZSByZXBvcnQuPGJyPg0KPGJyPg0KwqAg wqAgwqAgwqAgbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpvcGVubGRhcC1pdHNAb3BlbmxkYXAub3Jn IiB0YXJnZXQ9Il9ibGFuayI+b3BlbmxkYXAtaXRzQG9wZW5sZGFwLm9yZzwvYT4/c3ViamVjdD0o SVRTIzgxMDYpPGJyPg0KPGJyPg0KWW91IG1heSBmb2xsb3cgdGhlIHByb2dyZXNzIG9mIHRoaXMg cmVwb3J0IGJ5IGxvYWRpbmcgdGhlIGZvbGxvd2luZzxicj4NClVSTCBpbiBhIHdlYiBicm93c2Vy Ojxicj4NCsKgIMKgIDxhIGhyZWY9Imh0dHA6Ly93d3cuT3BlbkxEQVAub3JnL2l0cy9pbmRleC5j Z2k/ZmluZGlkPTgxMDYiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3Lk9wZW5MREFQLm9yZy9p dHMvaW5kZXguY2dpP2ZpbmRpZD04MTA2PC9hPjxicj4NCjxicj4NClBsZWFzZSByZW1lbWJlciB0 byByZXRhaW4geW91ciBpc3N1ZSB0cmFja2luZyBudW1iZXIgKElUUyM4MTA2KTxicj4NCm9uIGFu eSBmdXJ0aGVyIG1lc3NhZ2VzIHlvdSBzZW5kIHRvIHVzIHJlZ2FyZGluZyB0aGlzIHJlcG9ydC7C oCBJZjxicj4NCnlvdSBkb24mIzM5O3QgdGhlbiB5b3UmIzM5O2xsIGp1c3Qgd2FzdGUgb3VyIHRp bWUgYW5kIHlvdXJzIGJlY2F1c2Ugd2U8YnI+DQp3b24mIzM5O3QgYmUgYWJsZSB0byBwcm9wZXJs eSB0cmFjayB0aGUgcmVwb3J0Ljxicj4NCjxicj4NClBsZWFzZSBub3RlIHRoYXQgdGhlIElzc3Vl IFRyYWNraW5nIFN5c3RlbSBpcyBub3QgaW50ZW5kZWQgdG88YnI+DQpiZSB1c2VkIHRvIHNlZWsg aGVscCBpbiB0aGUgcHJvcGVyIHVzZSBvZiBPcGVuTERBUCBTb2Z0d2FyZS48YnI+DQpTdWNoIHJl cXVlc3RzIHdpbGwgYmUgY2xvc2VkLjxicj4NCjxicj4NCk9wZW5MREFQIFNvZnR3YXJlIGlzIHVz ZXIgc3VwcG9ydGVkLjxicj4NCsKgIMKgIMKgIMKgIDxhIGhyZWY9Imh0dHA6Ly93d3cuT3BlbkxE QVAub3JnL3N1cHBvcnQvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5PcGVuTERBUC5vcmcv c3VwcG9ydC88L2E+PGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0tLS08YnI+DQpDb3B5cmlnaHQgMTk5 OC0yMDA3IFRoZSBPcGVuTERBUCBGb3VuZGF0aW9uLCBBbGwgUmlnaHRzIFJlc2VydmVkLjxicj4N Cjxicj4NCjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PC9kaXY+DQo8L2Rpdj48L2Rpdj48L2Jsb2Nr cXVvdGU+PC9kaXY+PGJyPjwvZGl2Pg0K --f46d04426b642829070513e7a46a--

1 0

Re: (ITS#8106) Retry pwrite operations in case of EINTR
by milinevskyy＠gmail.com 17 Apr '15

17 Apr '15

--089e013d0c3883937b0513e79d1c Content-Type: multipart/alternative; boundary=089e013d0c3883936f0513e79d1a --089e013d0c3883936f0513e79d1a Content-Type: text/plain; charset=UTF-8 Proposed patch in attachment. On Fri, Apr 17, 2015 at 10:43 AM, <openldap-its(a)openldap.org> wrote: > > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#8106. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#8106) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=(ITS#8106) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=8106 > > Please remember to retain your issue tracking number (ITS#8106) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. > > --089e013d0c3883936f0513e79d1a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Proposed patch in attachment.<br></div><div class=3D"gmail= _extra"><br><div class=3D"gmail_quote">On Fri, Apr 17, 2015 at 10:43 AM, <= span dir=3D"ltr"><<a href=3D"mailto:openldap-its@openldap.org" target=3D= "_blank">openldap-its(a)openldap.org</a>></span> wrote:<br><blockquote cla= ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa= dding-left:1ex"><br> *** THIS IS AN AUTOMATICALLY GENERATED REPLY ***<br> <br> Thanks for your report to the OpenLDAP Issue Tracking System.=C2=A0 Your<br= > report has been assigned the tracking number ITS#8106.<br> <br> One of our support engineers will look at your report in due course.<br> Note that this may take some time because our support engineers<br> are volunteers.=C2=A0 They only work on OpenLDAP when they have spare<br> time.<br> <br> If you need to provide additional information in regards to your<br> issue report, you may do so by replying to this message.=C2=A0 Note that<br= > any mail sent to <a href=3D"mailto:openldap-its@openldap.org">openldap-its@= openldap.org</a> with (ITS#8106)<br> in the subject will automatically be attached to the issue report.<br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 mailto:<a href=3D"mailto:openldap-its@openldap.= org">openldap-its(a)openldap.org</a>?subject=3D(ITS#8106)<br> <br> You may follow the progress of this report by loading the following<br> URL in a web browser:<br> =C2=A0 =C2=A0 <a href=3D"http://www.OpenLDAP.org/its/index.cgi?findid=3D810= 6" target=3D"_blank">http://www.OpenLDAP.org/its/index.cgi?findid=3D8106</a= ><br> <br> Please remember to retain your issue tracking number (ITS#8106)<br> on any further messages you send to us regarding this report.=C2=A0 If<br> you don't then you'll just waste our time and yours because we<br> won't be able to properly track the report.<br> <br> Please note that the Issue Tracking System is not intended to<br> be used to seek help in the proper use of OpenLDAP Software.<br> Such requests will be closed.<br> <br> OpenLDAP Software is user supported.<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"http://www.OpenLDAP.org/support/" ta= rget=3D"_blank">http://www.OpenLDAP.org/support/</a><br> <br> --------------<br> Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.<br> <br> </blockquote></div><br></div> --089e013d0c3883936f0513e79d1a-- --089e013d0c3883937b0513e79d1c Content-Type: text/x-patch; charset=US-ASCII; name="0001-libmdb-retry-write-operation-in-case-of-interrupted-.patch" Content-Disposition: attachment; filename="0001-libmdb-retry-write-operation-in-case-of-interrupted-.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_i8lcpk680 RnJvbSBjOTg1N2E3YzBkZjQ0NDhhMTRhMmFhOWY1NTg1MGRmNWU4MzAwNjllIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBEbXl0cm8gTWlsaW5ldnNreXkgPG1pbGluZXZza3l5QGdtYWls LmNvbT4KRGF0ZTogRnJpLCAxNyBBcHIgMjAxNSAxMDo0MToyNiArMDIwMApTdWJqZWN0OiBbUEFU Q0hdIGxpYm1kYjogcmV0cnkgd3JpdGUgb3BlcmF0aW9uIGluIGNhc2Ugb2YgaW50ZXJydXB0ZWQg c3lzdGVtCgotLS0KIGxpYnJhcmllcy9saWJsbWRiL21kYi5jIHwgOSArKysrKysrKy0KIDEgZmls ZSBjaGFuZ2VkLCA4IGluc2VydGlvbnMoKyksIDEgZGVsZXRpb24oLSkKCmRpZmYgLS1naXQgYS9s aWJyYXJpZXMvbGlibG1kYi9tZGIuYyBiL2xpYnJhcmllcy9saWJsbWRiL21kYi5jCmluZGV4IGE5 NWM3Y2QuLmVkN2YzNzAgMTAwNjQ0Ci0tLSBhL2xpYnJhcmllcy9saWJsbWRiL21kYi5jCisrKyBi L2xpYnJhcmllcy9saWJsbWRiL21kYi5jCkBAIC0zMjM2LDYgKzMyMzYsNyBAQCBtZGJfcGFnZV9m bHVzaChNREJfdHhuICp0eG4sIGludCBrZWVwKQogCQkvKiBXcml0ZSB1cCB0byBNREJfQ09NTUlU X1BBR0VTIGRpcnR5IHBhZ2VzIGF0IGEgdGltZS4gKi8KIAkJaWYgKHBvcyE9bmV4dF9wb3MgfHwg bj09TURCX0NPTU1JVF9QQUdFUyB8fCB3c2l6ZStzaXplPk1BWF9XUklURSkgewogCQkJaWYgKG4p IHsKKyAgICAgICAgICAgICAgcmV0cnlfd3JpdGU6CiAJCQkJLyogV3JpdGUgcHJldmlvdXMgcGFn ZShzKSAqLwogI2lmZGVmIE1EQl9VU0VfUFdSSVRFVgogCQkJCXdyZXMgPSBwd3JpdGV2KGVudi0+ bWVfZmQsIGlvdiwgbiwgd3Bvcyk7CkBAIC0zMjQzLDggKzMyNDQsMTAgQEAgbWRiX3BhZ2VfZmx1 c2goTURCX3R4biAqdHhuLCBpbnQga2VlcCkKIAkJCQlpZiAobiA9PSAxKSB7CiAJCQkJCXdyZXMg PSBwd3JpdGUoZW52LT5tZV9mZCwgaW92WzBdLmlvdl9iYXNlLCB3c2l6ZSwgd3Bvcyk7CiAJCQkJ fSBlbHNlIHsKKwkJCQkgIHJldHJ5X3NlZWs6CiAJCQkJCWlmIChsc2VlayhlbnYtPm1lX2ZkLCB3 cG9zLCBTRUVLX1NFVCkgPT0gLTEpIHsKIAkJCQkJCXJjID0gRXJyQ29kZSgpOworCQkJCQkJaWYg KEVJTlRSID09IHJjKSBnb3RvIHJldHJ5X3NlZWs7CiAJCQkJCQlEUFJJTlRGKCgibHNlZWs6ICVz Iiwgc3RyZXJyb3IocmMpKSk7CiAJCQkJCQlyZXR1cm4gcmM7CiAJCQkJCX0KQEAgLTMyNTQsNiAr MzI1Nyw3IEBAIG1kYl9wYWdlX2ZsdXNoKE1EQl90eG4gKnR4biwgaW50IGtlZXApCiAJCQkJaWYg KHdyZXMgIT0gd3NpemUpIHsKIAkJCQkJaWYgKHdyZXMgPCAwKSB7CiAJCQkJCQlyYyA9IEVyckNv ZGUoKTsKKwkJCQkJCWlmIChFSU5UUiA9PSByYykgZ290byByZXRyeV93cml0ZTsKIAkJCQkJCURQ UklOVEYoKCJXcml0ZSBlcnJvcjogJXMiLCBzdHJlcnJvcihyYykpKTsKIAkJCQkJfSBlbHNlIHsK IAkJCQkJCXJjID0gRUlPOyAvKiBUT0RPOiBVc2Ugd2hpY2ggZXJyb3IgY29kZT8gKi8KQEAgLTM2 MjcsNyArMzYzMSw4IEBAIG1kYl9lbnZfaW5pdF9tZXRhKE1EQl9lbnYgKmVudiwgTURCX21ldGEg Km1ldGEpCiAJaW50IGxlbjsKICNkZWZpbmUgRE9fUFdSSVRFKHJjLCBmZCwgcHRyLCBzaXplLCBs ZW4sIHBvcykJZG8geyBcCiAJbGVuID0gcHdyaXRlKGZkLCBwdHIsIHNpemUsIHBvcyk7CVwKLQly YyA9IChsZW4gPj0gMCk7IH0gd2hpbGUoMCkKKwlpZiAobGVuID09IC0xICYmIEVJTlZBTCA9PSBF cnJDb2RlKCkpIGNvbnRpbnVlOyBcCisJcmMgPSAobGVuID49IDApOyBicmVhazsgfSB3aGlsZSgx KQogI2VuZGlmCiAKIAlEUFVUUygid3JpdGluZyBuZXcgbWV0YSBwYWdlIik7CkBAIC0zNzM1LDYg KzM3NDAsNyBAQCBtZGJfZW52X3dyaXRlX21ldGEoTURCX3R4biAqdHhuKQogCiAJLyogV3JpdGUg dG8gdGhlIFNZTkMgZmQgKi8KIAltZmQgPSAoZmxhZ3MgJiAoTURCX05PU1lOQ3xNREJfTk9NRVRB U1lOQykpID8gZW52LT5tZV9mZCA6IGVudi0+bWVfbWZkOworcmV0cnlfd3JpdGU6CiAjaWZkZWYg X1dJTjMyCiAJewogCQltZW1zZXQoJm92LCAwLCBzaXplb2Yob3YpKTsKQEAgLTM3NDcsNiArMzc1 Myw3IEBAIG1kYl9lbnZfd3JpdGVfbWV0YShNREJfdHhuICp0eG4pCiAjZW5kaWYKIAlpZiAocmMg IT0gbGVuKSB7CiAJCXJjID0gcmMgPCAwID8gRXJyQ29kZSgpIDogRUlPOworCQlpZiAoRUlOVFIg PT0gcmMpIGdvdG8gcmV0cnlfd3JpdGU7CiAJCURQVVRTKCJ3cml0ZSBmYWlsZWQsIGRpc2sgZXJy b3I/Iik7CiAJCS8qIE9uIGEgZmFpbHVyZSwgdGhlIHBhZ2VjYWNoZSBzdGlsbCBjb250YWlucyB0 aGUgbmV3IGRhdGEuCiAJCSAqIFdyaXRlIHNvbWUgb2xkIGRhdGEgYmFjaywgdG8gcHJldmVudCBp dCBmcm9tIGJlaW5nIHVzZWQuCi0tIAoyLjMuNQoK --089e013d0c3883937b0513e79d1c--

1 0

(ITS#8106) Retry pwrite operations in case of EINTR
by milinevskyy＠gmail.com 17 Apr '15

17 Apr '15

Full_Name: Dmytro Milinevskyy Version: OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (92.132.131.166) On linux systems it's common to have system calls interrupted and restarted. LMDB should retry pwrites to avoid "false" failures.

1 0

Re: (ITS#8097) update nssov to nss-pam-ldapd 0.9.4
by hyc＠symas.com 16 Apr '15

16 Apr '15

ryan(a)nardis.ca wrote: > Full_Name: Ryan Tandy > Version: master, 2.4 > OS: Debian > URL: > Submission from: (NULL) (24.68.37.4) > Thanks, pushed to git master. > updating the copied nss-pam-ldapd files: > > ftp://ftp.openldap.org/incoming/20150405_rtandy_nssov-update-nss-pam-ldapd-… > > updating nssov for those changes, see commit msg for details: > > ftp://ftp.openldap.org/incoming/20150405_rtandy_nssov-update-to-protocol-ve… > > while I'm in the code anyway, cleaning up a few compiler warnings (that were > already there, I didn't introduce them :P). Cosmetic stuff: unused variables, > return-type (void/non-void) mismatches, a couple of undeclared prototypes. > > ftp://ftp.openldap.org/incoming/20150405_rtandy_nssov-clean-up-some-compile… > > Please note, the protocol change breaks backwards compat with older versions of > the client libraries (per nss-pam-ldapd/README). > > Tested on Linux. No idea about Solaris etc, sorry. > > The DN field was removed from the pam protocol, so uid lookup happens on every > connection now. I couldn't think of a safe way to avoid that; suggestions > welcome. > > -- > > (the following statements apply to patches 2 and 3 only; patch 1 is copied from > work by Arthur de Jong, licensed LGPLv2.1) > > The attached patch files are derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the preceding patches were > developed by Ryan Tandy <ryan(a)nardis.ca>. I have not assigned rights and/or > interest in this work to any party. > > I, Ryan Tandy, hereby place the preceding modifications to OpenLDAP Software > (and only these modifications) into the public domain. Hence, these > modifications may be freely used and/or redistributed for any purpose with or > without attribution and/or other notice. > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8095) Patch
by hyc＠symas.com 16 Apr '15

16 Apr '15

rouzier(a)gmail.com wrote: > Full_Name: James Rouzier > Version: > OS: > URL: ftp://ftp.openldap.org/incoming/james-rouzier-150331.patch > Submission from: (NULL) (192.222.129.11) > > > I am working on a proof of concept of a simple key value store service using > lmdb as the back end. > I am using sendfile to avoid an extra copy. > I accomplished this by creating function to extract get the mmap ptr from the > env so I can calculate the offset of data. I'm quite reluctant to return the mmap pointer. In a WRITEMAP environment that invites all manner of undetectable/unpreventable corruptions. Have you actually measured the performance difference between using sendfile() here and plain write() or send()? The kernel doesn't physically copy the written data from user space to kernel space, it just maps in a particular page. Since LMDB data is already mmap'd, the kernel has very little work to do since the relevant pages are already present in the kernel's page tables. Ultimately sending data over TCP involves byte-by-byte iteration anyway, since TCP checksums must be computed on all outgoing data. Doesn't seem to me like sendfile can be a very significant optimization here. > > I figured that function might be useful to the bigger community. > > If it does not fit in the bigger vision of lmdb it is fine not to include it. > > > I, James Rouzier, hereby place the following modifications to OpenLDAP Software > (and only these modifications) into the public domain. Hence, these > modifications may be freely used and/or redistributed for any purpose with or > without attribution and/or other notice. > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs