From Milan.Jurik at Sun.COM Mon Jun 2 07:28:19 2008 From: Milan.Jurik at Sun.COM (Milan Jurik) Date: Mon, 02 Jun 2008 16:28:19 +0200 Subject: [Duckwater-discuss] Code-review request for Duckwater Phase 0 In-Reply-To: <48402744.6010604@sun.com> References: <483A9DA2.9010408@sun.com> <1212157275.27652.251.camel@xylabone> <48401564.3010606@sun.com> <1212163551.27652.302.camel@xylabone> <48402744.6010604@sun.com> Message-ID: <1212416898.2043.206.camel@xylabone> Hi Tomas, V p?, 30. 05. 2008 v 18:11, Tomas Heran p??e: > Hopefully Saturday and Sunday would work better for you ;) > I'm not spending weekends in reviews usually ;-) ----- usr/src/lib/libsldap/common/ns_reads.c [30] 1647 + /* need to get a new MT connection, return the old one */ 1695 + /* need to get a new MT connection, return the old one */ - as the sentence, big letter and missing dot: It needs ... . And maybe: "It needs to get a new MT connection, return the old one if available." [31] 1693 + /* need to use the referred server now */ "It needs to ... ." [32] - how will CLEAR RESULTS work for non-MT connections? 2059 2086 if (cookie->conn != NULL && cookie->conn->ld != NULL && 2060 - cookie->connectionId != -1 && cookie->msgId != 0) { 2087 + (cookie->connectionId != -1 || 2088 + (cookie->conn_user != NULL && 2089 + cookie->conn_user->conn_mt != NULL)) && 2090 + cookie->msgId != 0) { conn_user == NULL and we will not drop connection in _DropConnection() (old code path) Now is msgId not used as indicator of active connection for all cases. [33] 2192 + /* Check if we've reached MAX retries */ - missing dot at the end of the sentence. [34] 2192 + /* Check if we've reached MAX retries */ 2194 + if (cookie->retries > 2) { MAX == 2? [35] - DO_SEARCH, NEXT_RESULT, MULTI_RESULT cases as independent static functions to avoid indentation issues? Also NEXT_RESULT and MULTI_RESULT duplicates a lot of code now, it should be shared. [36] 2778 + * MT connection not usable, 2779 + * close it - missing dot (and "is not usable") [37] Batch API interface should be reviewed by somebody who knows it well. I have not enough experience with it yet. [38] 3306 + * the input DN (with no retry) 3409 + * the input DN (with retry) - missing dot [39] 3310 +find_domainname( 3413 +__s_api_find_domainname( 3434 +firstEntry( 3612 +__ns_ldap_firstEntry( 3316 3641 __ns_ldap_nextEntry( - cstyle - not tab, but 4 chars for the next line for parameters? Or do you plan to add comment to every parameter? [40] __ns_ldap_getAcctMgmt() - should we keep connection and retry for pam account management? Couldn't this leave access to system for active user even after disabling the account? usr/src/lib/libsldap/common/ns_writes.c ======================================= [41] 925 + /* need to use the referred server now */ - It needs ... . (Big char and dot, sentence) [42] 1527 + /* Project ID */ 1528 + /* 1529 + * ibuf is 11 chars big, which should be enough for string 1530 + * representation of 32bit number + nul-car 1531 + */ - two comments for same part of code, couldn't it be merged? - missing dot at the end of the sentence [43] 1532 + (void) snprintf(ibuf, sizeof (ibuf), "%u", ptr->pj_projid); - are you sure that snprintf() cannot fail here? ----- Best regards, Milan From Serge.Dussud at Sun.COM Mon Jun 2 11:11:20 2008 From: Serge.Dussud at Sun.COM (Serge Dussud) Date: Mon, 02 Jun 2008 20:11:20 +0200 Subject: [Duckwater-discuss] Code-review request for Duckwater Phase 0 (round 3) In-Reply-To: <4840265E.8070203@Sun.COM> References: <483A9DA2.9010408@sun.com> <483EB998.1070308@Sun.COM> <4840265E.8070203@Sun.COM> Message-ID: <484437C8.6010203@Sun.COM> round 3 of comments attached. Serge -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dw0-review3.txt URL: From Nicolas.Williams at sun.com Mon Jun 2 15:19:07 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 2 Jun 2008 17:19:07 -0500 Subject: [Duckwater-discuss] Code-review request for Duckwater Phase 0 In-Reply-To: <483A9DA2.9010408@sun.com> References: <483A9DA2.9010408@sun.com> Message-ID: <20080602221907.GF2734@Sun.COM> On Mon, May 26, 2008 at 01:23:14PM +0200, Tomas Heran wrote: > http://cr.opensolaris.org/~the/duckwater_phase0/ - usr/src/lib/libsldap/common/ns_standalone.c -- High level comment I'm hoping some day we'll actually fix all the libsldap interfaces to take an ns_standalone_conf_t argument (with NULL -> native LDAP config). As long as we're not using libsldap for nss_ad, of course, we don't need this with any urgency. - ns_standalone.c:58-59 Why not include instead of declaring str2hostent() and str2hostent6()? - ns_standalone.c:101-103 101 * A flag indicating that a particular thread is 102 * in the 'ldap_cachemgr' mode. It is stored by thread as 103 * a thread specific data. I can't parse the second sentence. What is stored by which thread? - about locking... ns_standalone.c:87,99,205-207 84 typedef struct dir_server_list { 85 dir_server_t **nsServers; 86 87 rwlock_t listDestroyLock; 88 } dir_server_list_t; What is listDestroyLock for? Why isn't listReplaceLock (line 99) good enough? Why is listReplaceLock used for purposes other than the one the comment says it's for? 95 /* 96 * The mutex ensuring that only one thread performs 97 * the initialization of the list. 98 */ 99 mutex_t listReplaceLock; 200 int 201 __s_api_isStandalone() 202 { 203 int mode; 204 205 (void) mutex_lock(&dir_servers.listReplaceLock); 206 mode = dir_servers.standalone; 207 (void) mutex_unlock(&dir_servers.listReplaceLock); 208 209 return (mode); 210 } I would think that you could get rid of dir_server_list_t and just put the two fields of it in the same struct where listReplaceLock lives. - ns_standalone.c:85 Presumably this is a NULL terminated array of pointers to dir_server_t... - ns_standalone:138-148 OK, so, like, what is "ldap_cachemgr mode"? I signed up to review this file, but, what other files must I read in order to understand comments like this one? - ns_standalone.c:75,ns_sldap.h:510-530 Why define two structures for much the same purpose? Why does dir_server_t have "char *ip" whereas ns_dir_server_t has "char *server"? You do need a hostname for SASL/GSSAPI. Even ignoring the propriety of ldapclient(1M) using IP addresses instead of names, what, does libsldap in standalone mode resolve IP addresses to names on every LDAP w/ SASL/GSSAPI bind connection?? - ns_sldap.h:502 OK, so NS_BEC is reserved for future use, but what does it stand for, why do we allocate it now, and why, if it isn't used now, do we reference it elsewhere in this file (and others??)? - ns_sldap.h:ns_dir_server_t,ns_standalone_conf_t So, ns_standalone_conf_t's contents, size and layout are public interfaces? That can't be what we want. - ns_sldap.h:559-564 559 + * This function "informs" libsldap that a client application has specified 560 + * a directory to use. The function obtains a DUAProfile, credentials, 561 + * and naming context. During all further operations on behalf 562 + * of the application requested a standalone schema libsldap will use 563 + * the information obtained by __ns_ldap_initStandalone() instead of 564 + * invoking door_call(3C). The last sentence has grammar issues. What is "a standalone schema"? A door_call() to... what door server? - ns_sldap.h:567-576 Cstyle: don't comment argument lists with large inline comment blocks, just move the comments up to the block comment above the function. This comment applies throughout this file. - ns_sldap.h:__ns_ldap_getConnectionInfo() Er, where does the DUA profile name fit here?? Also, if this function is here specifically do look at the DUA then maybe its name ought to reflect that, no? Compare to __ns_ldap_getRootDSE(), whose name is quite explicit about its purpose... In other words, please rename this function to something like __ns_ldap_getConnectionInfoFromDUA(). - ns_sldap.h:623 623 + * a separate thread and then waits until all the treads finish. s/treads/threads/ - ns_standalone.c:120 120 #pragma init(createStandaloneKey) We need to start thinking about not doing this anymore. For now keep it this way. - ns_standalone.c:278-299 Say what? We've just spent quite a bit of computational and I/O resources reading /etc/nsswitch.conf and we worry about the performance of one more free() and malloc()?? OK, but, talk about premature optimization. - ns_standalone.c:301-334 This block of code needs a block comment. Let me see if I understand what it does: - 301: check if "ldap" appears - 303-307: terminate linep at the first whitespace preceding "ldap". Hmmm, what if the token "fooldap" appears in nsswitch.conf? Why, then you get "foo\0dap" -- probably not what you wanted. - 308: copy linep into the TSD area - 309: skip "ldap" (or "\0dap"; see above) - 310-331: skip any "[]" and append a space and the rest of the line to the TSD area. Again, what happens if instead of "ldap" we have "ldapfoo"? Think of third party LDAP modules (say, "padl_ldap"). - Interestingly we warn about problems with nsswitch.conf, but not about malformed -- we silently ignore those. Odd, no? - 333: if there was no "ldap" then just copy the whole thing So, this code removes "ldap", except for the one buglet I mention above... - ns_standalone.c:339-359 Wait, didn't we just merge 'hosts' and 'ipnodes'? Aren't we aliasing the two here by storing whichever one is requested in hostService->conf (TSD)?? This seems... wrong. Meanwhile, I now understand that we only call get_db() to get either the 'hosts' or 'ipnodes' db config from nsswitch.conf, which must be why we're removing 'ldap' from it. (But what if it only says "ldap" -- is that supported?) - ns_standalone.c:_filter_gethostbyaddr_r() Oh man, there has got to be a better way to do this. - ns_standalone.c:__s_api_ip2hostname() So now I'm all confused. Lots of things don't look right here. __s_api_hostname2ip() doesn't call _filter_gethostbyaddr_r(), but __s_api_ip2hostname() does. __s_api_hostname2ip() does a lot of initialization that _filter_gethostbyaddr_r() doesn't do... Also, not described anywhere is how this works. If I'm reading this correctly what happens is that these lookups are being done with the in-process switch, and the the nss_db_initf_t argument to nss_search() is used to override the default configuration for that backend (to be the one returned by get_db(), which is what's in nsswitch.conf minus "ldap"). Keep in mind I'm not an expert in nsswitch code. So describing this stuff is useful to reviewers like me. - ns_standalone.c:convert_to_door_line() What if a value includes DOORLINESEP? - ns_standalone.c:789 789 * This function looks up for the base DN of a directory serving s/for// - ns_standalone.c:820-831 So, why not log (to LOG_DEBUG?) here that the server is lame? - ns_standalone.c:getDirBaseDN() So we look for naming contexts that have a nisDomainObject with nisdomain= and return not found if we find none. But where is it written that there must be such an object? Not in RFC2307. - ns_standalone.c:962,966 962 /* If successful, the root DSE was found. */ 966 * If the root DSE was not found, the server does s/root DSE/DUA profile/ Careful with that cut-n-paste Eugene! - ns_standalone.c:domainname2baseDN() domainname2baseDN() ought to return NULL if buf_len is too small. - ns_standalone.c:1069 1069 /* For the time being, it is a default configuration */ 1070 ns_config_t *config_struct = __s_api_create_config(); I don't understand the comment. Looking at __s_api_create_config() I think there's no need for a comment. Meanwhile, I much prefer not to have function calls in local variable declaration initializations. In this case you could have fewer lines of code by first checking that all inputs are correct, only then calling __s_api_create_config() (this saves you calls to __s_api_destroy_config() at lines 1087 and 1080, and the need for curly braces around one-statement if bodies. - ns_standalone.c:1097 1096 * If no credentials are specified, try to establish a connection 1097 * as anonimous s/anonimous/anonymous/ - ns_standalone.c:1123,1142 NS_LDAP_INTERNAL, really? - ns_standalone.c:1114 Why does __s_api_hostname2ip() return a pointer when the only call site treats it as a boolean?? - ns_standalone.c:__s_api_hostname2ip() I'm going to hold my nose. - ns_standalone.c:1166 Er, no: default here should be an error, and there should be an explicit switch arm for AF_INET. - ns_standalone.c:1432-1460 if (ldap_rc != LDAP_SUCCESS) { } would be better. More later. More than half-way through now. Nico -- From Nicolas.Williams at sun.com Mon Jun 2 15:43:56 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 2 Jun 2008 17:43:56 -0500 Subject: [Duckwater-discuss] Code-review request for Duckwater Phase 0 In-Reply-To: <20080602221907.GF2734@Sun.COM> References: <483A9DA2.9010408@sun.com> <20080602221907.GF2734@Sun.COM> Message-ID: <20080602224356.GL2735@Sun.COM> On Mon, Jun 02, 2008 at 05:19:07PM -0500, Nicolas Williams wrote: > More later. More than half-way through now. Or, rather, tomorrow. That's a lot of code to comb through. From Michen.Chang at Sun.COM Mon Jun 2 20:31:27 2008 From: Michen.Chang at Sun.COM (Michen Chang) Date: Mon, 02 Jun 2008 22:31:27 -0500 Subject: [Duckwater-discuss] Code-review request for Duckwater Phase 0 (round 3) In-Reply-To: <484437C8.6010203@Sun.COM> References: <483A9DA2.9010408@sun.com> <483EB998.1070308@Sun.COM> <4840265E.8070203@Sun.COM> <484437C8.6010203@Sun.COM> Message-ID: <4844BB0F.70603@sun.com> Hi Serge, Thanks for the review. I have integrated your comments (batch 1/2/3). Please see http://opensolaris.org/os/project/duckwater/duckwater_phase0/codereview/serge_libsldap/ Tomas, My webrev is here: http://jurassic.eng/net/ns-web.sfbay/tank/panjim-export/ldap/users/michen/ws/sldap-comment-0602/webrev This also address Nico's concern about too many peruser nscds using the ldap_cachemgr status change feature. One line change to allow only the main nscd to use it. -- Michen Serge Dussud wrote: > > > round 3 of comments attached. > > Serge > ------------------------------------------------------------------------ > > > usr/src/lib/libsldap/common/ns_connmgmt.c > > SD-57: l195-1197 > could you state explicitly which locks are supposed to be taken > when entering this function (match_conn_mt)? > > SD-58: match_conn_mt and unlocking cm->lock > I am not a fan of unlokcing mutex that were taken by the caller, this makes > code harder to read IMO. > In this case match_conn_mt() is called in only 1 place if I am not mistaken > (in __s_api_conn_mt_get()) and it looks to me that it would be easier and > safier for the caller to mutex_unlock() when match_conn_mt() is B_FALSE. > > SD-59: 1218-1231 > I don't get the logic here: > - why closing a connn_mt that was for write and that's been idle long > enough ? > - what is the test on cu->type != NS_CONN_USER_WRITE for ? according to > the comment, shall we not just close the conn_mt regardless of what cu > type is ? > - 'long enough' seems to be no user (cu_cnt == 0) and no access for 60s, > should 60 be configurable ? part of the profile ? > > SD-60: 1225 > NS_LDAP_INTERNAL does not seem very appropriate. Could we add a new return > code ? besides, NS_LDAP_INTERNAL requires details in errorp, which is NULL > here > > SD-61: 1234-1250 > so this means that NS_CONN_USER_AUTH and NS_CONN_USER_TEST can not share > conn_mt. Worth clarifyning were conn_mt is defined ? see SD-54 as well. > > SD-62: 1261 > why don't we check_and_close_conn() for nscd ? > > SD-63: 1276 & 1273 > shouldn't the test be (safer) >= instead of == ? > > SD-64: 1256-1278 > should'nt we test also NS_CONN_MT_UNINITED, NS_CONN_MT_CONNECT_ERROR and > NS_CONN_MT_CLOSING ? > > SD-65: __s_api_conn_mt_get() (and frineds: _s_api_conn_mt_add(), ...) > that's an 'API' function, could we get more wording on what the parameters > are (shall be) and what return code shall be expected ? > > SD-66: 1317-1318 > I find the comment and the following test hard to read. > What about something like: we want to reuse MT connection only if > keep-connection flag is set or if MT was requested (or active) > > SD-67: 1326, typo > coonection -> connection > > SD-68: 1324 > worth adding a comment that we're taking the lock of cmg ? (or changing > macro name to make it explicit ?) > > SD-69: 1370-1374 > I don't understadn the logic, can you add a comment ? > Why NS_CONN_USER_CONNECT_ERROR in 1 case and NS_CONN_USER_FINDING else ? > > SD-70: 1384/1385 > add same comment as 1376 > > SD-71: 1397-1400 > why do we 'hide' NS_LDAP_MEMORY ? > > SD-72: 1403 and following > shouldn't we add_cu2cn() ? > > SD-73: 1413 > why NOTFOUND ? why not SUCCESS ? > > SD-74: 1438-1442 > why do we do this here ? shouldn't this have been done elsewhere ? > > SD-75: 1483 & 490 > what's the purpose of ns_conn_free ? it's only used here if I am not > mistaken > > SD-76: err2cm() > err2cm() assumes its caller will take care of releasing errorp, since > it copies it into ep (assuming __s_api_copy_error() does what its name > implies). > > Have you checked for memory leaks ? it seems to me that at least 1 code > path would produce some: > shutdown_all_conn_mt() allocates ep, gives it to: > close_conn_mt() as errorp which then might call err2cm(). > If I am not mistaken, neither close_conn_mt() nor shutdown_all_conn_mt() > release the initial ep. > > > ------------------------------------------------------------------------ > > _______________________________________________ > duckwater-discuss mailing list > duckwater-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/duckwater-discuss > From Serge.Dussud at Sun.COM Tue Jun 3 00:03:46 2008 From: Serge.Dussud at Sun.COM (Serge Dussud) Date: Tue, 03 Jun 2008 09:03:46 +0200 Subject: [Duckwater-discuss] Code-review request for Duckwater Phase 0 (round 3) In-Reply-To: <4844BB0F.70603@sun.com> References: <483A9DA2.9010408@sun.com> <483EB998.1070308@Sun.COM> <4840265E.8070203@Sun.COM> <484437C8.6010203@Sun.COM> <4844BB0F.70603@sun.com> Message-ID: <4844ECD2.1050406@Sun.COM> Thanks Michen, no sure how to follow-up, should I edit http://opensolaris.org/os/project/duckwater/duckwater_phase0/codereview/serge_libsldap/ ? (how do I do that ?) Anyway, here are my main follow-up comments for now: - IIUC, is_nscd is used in several places to identify the main nscd (that's what your answers to SD-04 and SD-62 suggest). However, is_nscd is B_TRUE as well for per-user NSCD (see init_conn_mgmt()). Am I not understanding correctly or is there something wrong ? - that'd be great to have at some point a write-up/TOI/arch document about how configuration changes are handled in different scenarios (MN, PUN or non-MN processes, standalone). Will (or has) the NL2 arch doc be updated accordingly ? there are also a number of new APIs for connection enhancements, will (or do) they appear in the NL2 arch doc ? - about checking mutexes problem: our main nevada page (tools section) refers to warlock. People of these list may have other preferred tools. Serge Michen Chang wrote: > > Hi Serge, > > Thanks for the review. I have integrated your comments (batch 1/2/3). > Please see > http://opensolaris.org/os/project/duckwater/duckwater_phase0/codereview/serge_libsldap/ > > > Tomas, My webrev is here: > http://jurassic.eng/net/ns-web.sfbay/tank/panjim-export/ldap/users/michen/ws/sldap-comment-0602/webrev > > > This also address Nico's concern about too many peruser nscds using > the ldap_cachemgr status change feature. One line change to allow > only the main nscd to use it. > > -- > Michen > > Serge Dussud wrote: >> >> >> round 3 of comments attached. >> >> Serge >> ------------------------------------------------------------------------ >> >> >> usr/src/lib/libsldap/common/ns_connmgmt.c >> >> SD-57: l195-1197 >> could you state explicitly which locks are supposed to be taken >> when entering this function (match_conn_mt)? >> >> SD-58: match_conn_mt and unlocking cm->lock >> I am not a fan of unlokcing mutex that were taken by the caller, >> this makes >> code harder to read IMO. >> In this case match_conn_mt() is called in only 1 place if I am not >> mistaken >> (in __s_api_conn_mt_get()) and it looks to me that it would be >> easier and >> safier for the caller to mutex_unlock() when match_conn_mt() is >> B_FALSE. >> >> SD-59: 1218-1231 >> I don't get the logic here: >> - why closing a connn_mt that was for write and that's been idle long >> enough ? >> - what is the test on cu->type != NS_CONN_USER_WRITE for ? >> according to >> the comment, shall we not just close the conn_mt regardless of >> what cu type is ? >> - 'long enough' seems to be no user (cu_cnt == 0) and no access >> for 60s, >> should 60 be configurable ? part of the profile ? >> >> SD-60: 1225 >> NS_LDAP_INTERNAL does not seem very appropriate. Could we add a >> new return >> code ? besides, NS_LDAP_INTERNAL requires details in errorp, which >> is NULL >> here >> >> SD-61: 1234-1250 >> so this means that NS_CONN_USER_AUTH and NS_CONN_USER_TEST can not >> share >> conn_mt. Worth clarifyning were conn_mt is defined ? see SD-54 as >> well. >> >> SD-62: 1261 >> why don't we check_and_close_conn() for nscd ? >> SD-63: 1276 & 1273 >> shouldn't the test be (safer) >= instead of == ? >> SD-64: 1256-1278 >> should'nt we test also NS_CONN_MT_UNINITED, >> NS_CONN_MT_CONNECT_ERROR and NS_CONN_MT_CLOSING ? >> SD-65: __s_api_conn_mt_get() (and frineds: _s_api_conn_mt_add(), ...) >> that's an 'API' function, could we get more wording on what the >> parameters >> are (shall be) and what return code shall be expected ? >> SD-66: 1317-1318 >> I find the comment and the following test hard to read. What >> about something like: we want to reuse MT connection only if >> keep-connection flag is set or if MT was requested (or active) >> >> SD-67: 1326, typo >> coonection -> connection >> >> SD-68: 1324 >> worth adding a comment that we're taking the lock of cmg ? (or >> changing macro name to make it explicit ?) >> >> SD-69: 1370-1374 >> I don't understadn the logic, can you add a comment ? >> Why NS_CONN_USER_CONNECT_ERROR in 1 case and NS_CONN_USER_FINDING >> else ? >> SD-70: 1384/1385 >> add same comment as 1376 >> >> SD-71: 1397-1400 >> why do we 'hide' NS_LDAP_MEMORY ? >> >> SD-72: 1403 and following >> shouldn't we add_cu2cn() ? >> >> SD-73: 1413 >> why NOTFOUND ? why not SUCCESS ? >> >> SD-74: 1438-1442 >> why do we do this here ? shouldn't this have been done elsewhere ? >> SD-75: 1483 & 490 >> what's the purpose of ns_conn_free ? it's only used here if I am not >> mistaken >> >> SD-76: err2cm() >> err2cm() assumes its caller will take care of releasing errorp, since >> it copies it into ep (assuming __s_api_copy_error() does what its name >> implies). >> Have you checked for memory leaks ? it seems to me that at least 1 >> code >> path would produce some: >> shutdown_all_conn_mt() allocates ep, gives it to: >> close_conn_mt() as errorp which then might call err2cm(). >> If I am not mistaken, neither close_conn_mt() nor >> shutdown_all_conn_mt() >> release the initial ep. >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> duckwater-discuss mailing list >> duckwater-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/duckwater-discuss >> > From Tomas.Heran at Sun.COM Tue Jun 3 01:16:31 2008 From: Tomas.Heran at Sun.COM (Tomas Heran) Date: Tue, 03 Jun 2008 10:16:31 +0200 Subject: [Duckwater-discuss] Code-review request for Duckwater Phase 0 (round 3) In-Reply-To: <4844BB0F.70603@sun.com> References: <483A9DA2.9010408@sun.com> <483EB998.1070308@Sun.COM> <4840265E.8070203@Sun.COM> <484437C8.6010203@Sun.COM> <4844BB0F.70603@sun.com> Message-ID: <4844FDDF.5090706@sun.com> Michen Chang wrote: > > Tomas, My webrev is here: > http://jurassic.eng/net/ns-web.sfbay/tank/panjim-export/ldap/users/michen/ws/sldap-comment-0602/webrev > I've uploaded your webrev for everybody to see here: http://cr.opensolaris.org/~the/duckwater_phase0_incr_michen/ Tomas From David.Maxera at Sun.COM Tue Jun 3 05:57:57 2008 From: David.Maxera at Sun.COM (david maxera - Sun Microsystems - Prague Czech Republic) Date: Tue, 03 Jun 2008 14:57:57 +0200 Subject: [Duckwater-discuss] [sparks-discuss] Code-review request for Duckwater Phase 0 In-Reply-To: <483A9DA2.9010408@sun.com> References: <483A9DA2.9010408@sun.com> Message-ID: <48453FD5.9080506@sun.com> Hi, I reviewed common/ns_connmgmt.h and common/ns_connmgmt.c. My comments: common/ns_connmgmt.h 262 - 281: is there reason why these declarations arent "extern"? common/ns_connmgmt.c 390, 391: I understand this is here for performace, to avoid expensive mutex_lock in the typical case. However, is it really safe? "checkedPpid" and "isPeruserNscd" could be changed by another thread between the lines 390 and 391, couldn't it? common/ns_connmgmt.c 442, 443: the same as above common/ns_connmgmt.c 575: Why atomic_inc_uint() inside mutex_locked block? The same is at line 665 common/ns_connmgmt.c 589: Why is "mypid" static? common/ns_connmgmt.c 600: You dont need to test for cmg->pid != mypid here, it is already guaranteed by the previous conditions. common/ns_connmgmt.c 636 - 640: Souldn't these lines be locked somehow too? common/ns_connmgmt.c 1015: According to the coding standards, it should explicitelly compare "server" to NULL and "*server" to '\0' (this comment applies only if Tomas is the author ;-)). David Tomas Heran wrote: > Dear All, > > we'd like to request a code review of our latest changes to LDAP naming > tools and infrastructure to improve connection and server management in > libsldap and ldap_cachemgr(1M) and to introduce "standalone" feature to > LDAP naming tools. This integration (when done) will deliver first set > of features promised by Duckwater project. We call it internally > Duckwater Phase 0. > > The information about the changes, RFEs and CRs and updated manual > pages can be found here: > http://www.opensolaris.org/os/project/duckwater/duckwater_phase0 > > The webrev with the changes is here: > http://cr.opensolaris.org/~the/duckwater_phase0/ > > Thanks, > Tomas > _______________________________________________ > sparks-discuss mailing list > sparks-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/sparks-discuss From Serge.Dussud at Sun.COM Tue Jun 3 07:56:45 2008 From: Serge.Dussud at Sun.COM (Serge Dussud) Date: Tue, 03 Jun 2008 16:56:45 +0200 Subject: [Duckwater-discuss] Code-review request for Duckwater Phase 0 (round 4) In-Reply-To: <484437C8.6010203@Sun.COM> References: <483A9DA2.9010408@sun.com> <483EB998.1070308@Sun.COM> <4840265E.8070203@Sun.COM> <484437C8.6010203@Sun.COM> Message-ID: <48455BAD.60607@Sun.COM> round 4 of comments attached. Serge From Serge.Dussud at Sun.COM Tue Jun 3 08:00:53 2008 From: Serge.Dussud at Sun.COM (Serge Dussud) Date: Tue, 03 Jun 2008 17:00:53 +0200 Subject: [Duckwater-discuss] Code-review request for Duckwater Phase 0 (round 4) In-Reply-To: <48455BAD.60607@Sun.COM> References: <483A9DA2.9010408@sun.com> <483EB998.1070308@Sun.COM> <4840265E.8070203@Sun.COM> <484437C8.6010203@Sun.COM> <48455BAD.60607@Sun.COM> Message-ID: <48455CA5.6030100@Sun.COM> re-sent with comments attached ... Serge Dussud wrote: > > > round 4 of comments attached. > > Serge > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dw0-review4.txt URL: From Chin-Long.Shu at Sun.COM Tue Jun 3 10:45:54 2008 From: Chin-Long.Shu at Sun.COM (Chin-Long Shu) Date: Tue, 03 Jun 2008 12:45:54 -0500 Subject: [Duckwater-discuss] [sparks-discuss] Code-review request for Duckwater Phase 0 (round 3) In-Reply-To: <4844BB0F.70603@sun.com> References: <483A9DA2.9010408@sun.com> <483EB998.1070308@Sun.COM> <4840265E.8070203@Sun.COM> <484437C8.6010203@Sun.COM> <4844BB0F.70603@sun.com> Message-ID: <48458352.5020006@Sun.COM> This new webrev address mainly Milan's and Nicol's comments. The major chang is only main nacd can make GETSTATUSCHANGE call and the logic in chg_get_statusChange() is changed accordingly. The other change is the number counting code is moved to switcher so it have more accurate counting. The previous code only counts START op threads, but not STOP op threads. http://jurassic.eng/net/ns-web.sfbay/tank/panjim-export/ldap/users/chinlong/ws/new_libsldap_10a/webrev/ From julian.pullen at sun.com Tue Jun 3 10:48:46 2008 From: julian.pullen at sun.com (Julian Pullen) Date: Tue, 03 Jun 2008 18:48:46 +0100 Subject: [Duckwater-discuss] Code-review request for Duckwater Phase 0 In-Reply-To: <483A9DA2.9010408@sun.com> References: <483A9DA2.9010408@sun.com> Message-ID: <484583FE.2000506@sun.com> Tomas, Here are some comments on libsldap. ns_connect.c ------------ __s_api_requestServer() line 184. I think the code should be 184 if (*error != NULL) { 185 (void) __ns_ldap_freeError(error); 186 } createSession() line 2200. I would use an if (useSSL) and not "?" to make it more readable ns_common.c ----------- __s_api_copy_error() Why use calloc if you going to copy the ns_ldap_error_t to the new allocated memory. More tomorrow. Regards Julian Tomas Heran wrote: > Dear All, > > we'd like to request a code review of our latest changes to LDAP naming > tools and infrastructure to improve connection and server management in > libsldap and ldap_cachemgr(1M) and to introduce "standalone" feature to > LDAP naming tools. This integration (when done) will deliver first set > of features promised by Duckwater project. We call it internally > Duckwater Phase 0. > > The information about the changes, RFEs and CRs and updated manual > pages can be found here: > http://www.opensolaris.org/os/project/duckwater/duckwater_phase0 > > The webrev with the changes is here: > http://cr.opensolaris.org/~the/duckwater_phase0/ > > Thanks, > Tomas From Nicolas.Williams at sun.com Tue Jun 3 11:10:01 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 3 Jun 2008 13:10:01 -0500 Subject: [Duckwater-discuss] Code-review request for Duckwater Phase 0 In-Reply-To: <20080602224356.GL2735@Sun.COM> References: <483A9DA2.9010408@sun.com> <20080602221907.GF2734@Sun.COM> <20080602224356.GL2735@Sun.COM> Message-ID: <20080603181000.GH2734@Sun.COM> - General comment Clearly libsldap cannot be used in standalone mode if nscd isn't running, right? - ns_standalone.c:1586-1589 Comments like this one are unnecessary. - ns_standalone.c:1597 1597 * set up an error indication and keep the server. s/set up/log/ s/ indication// - ns_standalone.c:1574,1592,... Why call thr_exit() when you can just return? - ns_standalone.c:1601,1617,... We really need to be careful with log levels. LOG_WARNING here could be annoying. This should be LOG_INFO. LOG_WARNING should be used if *no* servers can be "loaded." (I.e., where these threads are joined we should check if we have any servers available, and if not *then* warn.) I'll review all log levels in this file separately. - ns_standalone.c:1568-1569 Comments please. Also, it seems to me that you could get rid of s*_mem_blocks -- "(sc_counter == CHUNK_SIZE * sc_mem_blocks - 1)" then becomes "((sc_counter + 1) % CHUNK_SIZE == 0)" and "CHUNK_SIZE * ++sc_mem_blocks" becomes "sc_counter + 1 + CHUNK_SIZE - ((sc_counter + 1) % CHUNK_SIZE)". But I don't care that much. - ns_standalone.c:1651-1658,1681-1688 Seems to me you could just replace this with server->saslMech[sm_counter + 1] = NULL; and server->controls[sc_counter + 1] = NULL; respectively. - ns_standalone.c:1717 This is NOTREACHED, but then, see above comment about just returning instead of calling thr_exit(3C)... - ns_standalone.c:1750 Er, isn't the point here that the caller can provide their own server list? But here we call __s_api_getServers(), which returns the native LDAP client's list, and I see that __s_api_getServers() hasn't been modified to do otherwise. I see the answer in __ns_ldap_initStandalone(). - ns_standalone.c:1807-1809 Seems to me this comment belongs earlier in this function. Or even that it's superfluous. - ns_standalone.c:1814 This is a great place to specify a reasonable, non-default thread stack size. 128KB? Same thing elsewhere in this file. - ns_standalone.c:1825-1826 Perhaps ENOMEM happens because we're asking for too many threads. So perhaps you could loop to join all the threads started so far. Thoughts? - ns_standalone.c:create_ns_servers_entry() Why bother allocating a variable through which to return a status code when we already have a place in the void *param (dir_server_t) argument to store it in? Save yourself lines 1566-1567, 1573-1575, 1849-1842, 2487-2491, ... - ns_standalone.c:1849-1852 OK, so failure to find one server's rootDSE/whatever due to ENOMEM should lead to failure altogether? That seems a bit reactionary. - ns_standalone.c:1917 Where's tls:sasl/GSSAPI"? - ns_standalone.c:1955 Why strcmp() instead of strcasecmp()? Why are "tls" and "sasl" lower-cased but the SASL mech names upper-cased? - ns_standalone.c:1946,1964 Again, LOG_WARNING?! - ns_standalone.c:1978 1978 * invoking door_call(3C). s/invoking door_call(3C)/door_call(3C)ing ldap_cachemgr/ (It's not door_call() that's interesting here to the reader, but *who* the door_call() is to.) - ns_standalone.c:2005 2005 gettext("Bind DN and bind password must coexist\n")); "coexist"?? s/coexist/both be provided/ - ns_standalone.c:2015-2026 How soon will NS_BEC be implemented? I hate to see dead code related to a future feature that will never arrive... - ns_standalone.c:2001-2012 We can't specify a bind DN/authzid with SASL/GSSAPI? (I know it's mostly pointless. Just asking.) - ns_standalone.c:2064-2087 If SA_CERT_PATH is not specified, will it be obtained from the native LDAP config? (IMO it should be.) - ns_standalone.c:2106 LOG_ERR is *way* overkill here. - ns_standalone.c:2131-2142 See above comment re: dead code. - ns_standalone.c:2148 The comment here isn't very useful. Please re-formulate it. - ns_standalone.c:2162-2163 But there is no door server function invoking this function, right? Either way please update the comment. - ns_standalone.c:2168-2172 "send" what where? s/send/return/, no? Just because you're copying most of this function from getldap_get_serverInfo() (in ldap_cachemgr) doesn't mean you can just copy/paste the block comment. - ns_standalone.c:2229,2231,2234 Either use 'i' or 0 as the index, but don't mix things up! Actually, do please just use 0. - ns_standalone.c:2253-2254 Join these two lines please. - ns_standalone.c:__s_api_findRootDSE() Does standalone mode support more than one server, or not? If not then ISTM that there's a lot of code that can be thrown out (or that support for multiple servers could easily be added). - ns_standalone.c:2357 2357 gettext("There is no available servers")); Replace with "No servers are available". - ns_standalone.c:2370 'ret' is not described in the block comment. See above comments about copy/paste... - ns_standalone.c:1838 There's no timeout mechanism here. Is that OK? It hink the lack of a timeout mechanism at 2486 is OK, but here I'm not so sure. And I realize that implementing a timeout here would mean using a condition variable instead of thr_join(). It would also mean cancelling timed out threads, which probably can't safely be done today. So if there's no timeout mechanism way below then I guess we just have to deal (leaking timed out threads is not acceptable). Done! Nico -- From Satish.Murugesan at Sun.COM Tue Jun 3 16:15:20 2008 From: Satish.Murugesan at Sun.COM (Satish Murugesan) Date: Tue, 03 Jun 2008 16:15:20 -0700 Subject: [Duckwater-discuss] [sparks-discuss] Code-review request for Duckwater Phase 0 In-Reply-To: <483E9742.7020002@sun.com> References: <483A9DA2.9010408@sun.com> <20080528224243.GG1039@Sun.COM> <483E9742.7020002@sun.com> Message-ID: <4845D088.2010009@sun.com> Tomas, My comments on ldapaddent.c so far: line 4261: why is standaloneDefaults for ns_standalone_request_type_t is NS_CACHEMGR ? Isn't NS_LDAP_SERVER more apt.. as standalone is used for -h option mainly ?? line 4295: The message could be clearer. we could say " no other option should be specified with dump option -d" 4368 case 'r': Why is this -r option undocumented ? Not in Usage, not in man page. ? 4422 : __ns_ldap_initStandalone() is invoked by default. At this time, wouldn't it be better to call initStandalone only if request type is NS_LDAP_SERVER or NS_BEC ? 386: usage of NS_LDAP_KEEP_CONN with __ns_ldap_addTypedEntry() 1. do you see performance improvement when run in standalone mode. ie., without ldapcachemgr in picture. 2. Have we made sure the connection management code does not drop the connection if the calling process is not nscd. And that is going to be case for ldapaddent. 3. Do we have some performance stats (standalone, configured), compared to old ldapaddent? 480 & 492 : In usage message, 6 different types of using ldapaddent are listed. Pls see if some usage formats can be combined, like the -d option via standlone or configured option can be combined. ----- Have not looked at the genent_project() code closely yet, but will email comments on it later if any. --- Reviewed standalone.h as well. Looks good, but will have to agree with Nico that its not common to have code in the header file. thanks,. Satish From Michen.Chang at Sun.COM Tue Jun 3 22:05:01 2008 From: Michen.Chang at Sun.COM (Michen Chang) Date: Wed, 04 Jun 2008 00:05:01 -0500 Subject: [Duckwater-discuss] [sparks-discuss] Code-review request for Duckwater Phase 0 In-Reply-To: <48453FD5.9080506@sun.com> References: <483A9DA2.9010408@sun.com> <48453FD5.9080506@sun.com> Message-ID: <4846227D.4010904@sun.com> Hi David, Thanks for the review. david maxera - Sun Microsystems - Prague Czech Republic wrote: > Hi, > > I reviewed common/ns_connmgmt.h and common/ns_connmgmt.c. My comments: > > common/ns_connmgmt.h 262 - 281: is there reason why these declarations > arent "extern"? > This is following the same practice in ns_internal.h, ns_cache_door.h, etc. > common/ns_connmgmt.c 390, 391: I understand this is here for performace, > to avoid expensive mutex_lock in the typical case. However, is it really > safe? "checkedPpid" and "isPeruserNscd" could be changed by another > thread between the lines 390 and 391, couldn't it? > But would the change (e.g. ,checkedPpid changed from -1 to my_ppid) cause problem ? And why ? I don't see it's a problem. > common/ns_connmgmt.c 442, 443: the same as above > > common/ns_connmgmt.c 575: Why atomic_inc_uint() inside mutex_locked > block? The same is at line 665 > Because in different places in the file, the refcount may be atomic_inc'ed or atomic_dec'ed without the lock being held. > common/ns_connmgmt.c 589: Why is "mypid" static? > It's not necessary. Will change. > common/ns_connmgmt.c 600: You dont need to test for cmg->pid != mypid > here, it is already guaranteed by the previous conditions. > Yes. Will remove. > common/ns_connmgmt.c 636 - 640: Souldn't these lines be locked somehow too? > Yes. It can be more robust. Code rearranged. > common/ns_connmgmt.c 1015: According to the coding standards, it should > explicitelly compare "server" to NULL and "*server" to '\0' (this > comment applies only if Tomas is the author ;-)). > :-) The author is not Tomas. Thanks, Michen > > David > > > > Tomas Heran wrote: > >> Dear All, >> >> we'd like to request a code review of our latest changes to LDAP naming >> tools and infrastructure to improve connection and server management in >> libsldap and ldap_cachemgr(1M) and to introduce "standalone" feature to >> LDAP naming tools. This integration (when done) will deliver first set >> of features promised by Duckwater project. We call it internally >> Duckwater Phase 0. >> >> The information about the changes, RFEs and CRs and updated manual >> pages can be found here: >> http://www.opensolaris.org/os/project/duckwater/duckwater_phase0 >> >> The webrev with the changes is here: >> http://cr.opensolaris.org/~the/duckwater_phase0/ >> >> Thanks, >> Tomas >> _______________________________________________ >> sparks-discuss mailing list >> sparks-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/sparks-discuss >> > _______________________________________________ > sparks-discuss mailing list > sparks-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/sparks-discuss > From Tomas.Heran at Sun.COM Wed Jun 4 01:31:38 2008 From: Tomas.Heran at Sun.COM (Tomas Heran) Date: Wed, 04 Jun 2008 10:31:38 +0200 Subject: [Duckwater-discuss] [sparks-discuss] Code-review request for Duckwater Phase 0 (round 3) In-Reply-To: <48458352.5020006@Sun.COM> References: <483A9DA2.9010408@sun.com> <483EB998.1070308@Sun.COM> <4840265E.8070203@Sun.COM> <484437C8.6010203@Sun.COM> <4844BB0F.70603@sun.com> <48458352.5020006@Sun.COM> Message-ID: <484652EA.9090605@sun.com> I've uploaded the webrev to http://cr.opensolaris.org/~the/duckwater_phase0_incr_chinlong/ Tomas Chin-Long Shu wrote: > This new webrev address mainly Milan's and Nicol's comments. > The major chang is only main nacd can make GETSTATUSCHANGE call and the > logic in chg_get_statusChange() is changed accordingly. > The other change is the number counting code is moved to switcher so it > have more accurate counting. The previous code only counts START op > threads, but not STOP op threads. > > http://jurassic.eng/net/ns-web.sfbay/tank/panjim-export/ldap/users/chinlong/ws/new_libsldap_10a/webrev/ > From David.Maxera at Sun.COM Wed Jun 4 05:36:18 2008 From: David.Maxera at Sun.COM (david maxera - Sun Microsystems - Prague Czech Republic) Date: Wed, 04 Jun 2008 14:36:18 +0200 Subject: [Duckwater-discuss] [sparks-discuss] Code-review request for Duckwater Phase 0 In-Reply-To: <4846227D.4010904@sun.com> References: <483A9DA2.9010408@sun.com> <48453FD5.9080506@sun.com> <4846227D.4010904@sun.com> Message-ID: <48468C42.90504@sun.com> Hi Michen, >> common/ns_connmgmt.c 390, 391: I understand this is here for performace, >> to avoid expensive mutex_lock in the typical case. However, is it really >> safe? "checkedPpid" and "isPeruserNscd" could be changed by another >> thread between the lines 390 and 391, couldn't it? >> > > But would the change (e.g. ,checkedPpid changed from -1 to my_ppid) > cause problem ? And why ? I don't see it's a problem. > > >> common/ns_connmgmt.c 442, 443: the same as above Oh. I didn't realize that all the threads have actually the same ppidpid. >> common/ns_connmgmt.c 442, 443: the same as above >> >> common/ns_connmgmt.c 575: Why atomic_inc_uint() inside mutex_locked >> block? The same is at line 665 >> > > Because in different places in the file, the refcount may be > atomic_inc'ed or atomic_dec'ed without the lock being > held. I see. David From Michen.Chang at Sun.COM Wed Jun 4 06:43:06 2008 From: Michen.Chang at Sun.COM (Michen Chang) Date: Wed, 04 Jun 2008 08:43:06 -0500 Subject: [Duckwater-discuss] Code-review request for Duckwater Phase 0 (round 3) In-Reply-To: <4844ECD2.1050406@Sun.COM> References: <483A9DA2.9010408@sun.com> <483EB998.1070308@Sun.COM> <4840265E.8070203@Sun.COM> <484437C8.6010203@Sun.COM> <4844BB0F.70603@sun.com> <4844ECD2.1050406@Sun.COM> Message-ID: <48469BEA.3070804@sun.com> I have integrated Serge's batch 4 and David comments on ns_connmgmt.[h|c]. The updated webrev is here: http://jurassic.eng/net/ns-web.sfbay/tank/panjim-export/ldap/users/michen/ws/sldap-comment-0602/webrev/ Also please see comments inline ... Serge Dussud wrote: > > Thanks Michen, > > no sure how to follow-up, should I edit > http://opensolaris.org/os/project/duckwater/duckwater_phase0/codereview/serge_libsldap/ > ? (how do I do that ?) I guess a question for Tomas. I am having problem signing in this morning. But I will update it more when I can. > > Anyway, here are my main follow-up comments for now: > > - IIUC, is_nscd is used in several places to identify the main nscd > (that's what your answers to SD-04 and SD-62 suggest). However, > is_nscd is B_TRUE as well for per-user NSCD (see init_conn_mgmt()). Am > I not understanding correctly or is there something wrong ? I took a look and add comments to make it clear. I also added a new member 'is_peruser_nscd' in ns_conn_mgmt_t, and changed code accordingly, so it should be very clear now. > > - that'd be great to have at some point a write-up/TOI/arch document > about how configuration changes are handled in different scenarios > (MN, PUN or non-MN processes, standalone). Will (or has) the NL2 arch > doc be updated accordingly ? there are also a number of new APIs for > connection enhancements, will (or do) they appear in the NL2 arch doc ? We will manage the write-up/TOI/arch document after the putback. As for the connection management APIs, they are the internal __s_api_* type, not the __ns_ldap_*, so we have no plan to document them in the NL2 arch doc. > > - about checking mutexes problem: our main nevada page (tools section) > refers to warlock. People of these list may have other preferred tools. Will give warlock a try. Thanks, Michen > > Serge > > > > > Michen Chang wrote: >> >> Hi Serge, >> >> Thanks for the review. I have integrated your comments (batch 1/2/3). >> Please see >> http://opensolaris.org/os/project/duckwater/duckwater_phase0/codereview/serge_libsldap/ >> >> >> Tomas, My webrev is here: >> http://jurassic.eng/net/ns-web.sfbay/tank/panjim-export/ldap/users/michen/ws/sldap-comment-0602/webrev >> >> >> This also address Nico's concern about too many peruser nscds using >> the ldap_cachemgr status change feature. One line change to allow >> only the main nscd to use it. >> >> -- >> Michen >> >> Serge Dussud wrote: >>> >>> >>> round 3 of comments attached. >>> >>> Serge >>> ------------------------------------------------------------------------ >>> >>> >>> >>> usr/src/lib/libsldap/common/ns_connmgmt.c >>> >>> SD-57: l195-1197 >>> could you state explicitly which locks are supposed to be taken >>> when entering this function (match_conn_mt)? >>> >>> SD-58: match_conn_mt and unlocking cm->lock >>> I am not a fan of unlokcing mutex that were taken by the caller, >>> this makes >>> code harder to read IMO. >>> In this case match_conn_mt() is called in only 1 place if I am >>> not mistaken >>> (in __s_api_conn_mt_get()) and it looks to me that it would be >>> easier and >>> safier for the caller to mutex_unlock() when match_conn_mt() is >>> B_FALSE. >>> >>> SD-59: 1218-1231 >>> I don't get the logic here: >>> - why closing a connn_mt that was for write and that's been idle >>> long >>> enough ? >>> - what is the test on cu->type != NS_CONN_USER_WRITE for ? >>> according to >>> the comment, shall we not just close the conn_mt regardless of >>> what cu type is ? >>> - 'long enough' seems to be no user (cu_cnt == 0) and no access >>> for 60s, >>> should 60 be configurable ? part of the profile ? >>> >>> SD-60: 1225 >>> NS_LDAP_INTERNAL does not seem very appropriate. Could we add a >>> new return >>> code ? besides, NS_LDAP_INTERNAL requires details in errorp, >>> which is NULL >>> here >>> >>> SD-61: 1234-1250 >>> so this means that NS_CONN_USER_AUTH and NS_CONN_USER_TEST can >>> not share >>> conn_mt. Worth clarifyning were conn_mt is defined ? see SD-54 as >>> well. >>> >>> SD-62: 1261 >>> why don't we check_and_close_conn() for nscd ? >>> SD-63: 1276 & 1273 >>> shouldn't the test be (safer) >= instead of == ? >>> SD-64: 1256-1278 >>> should'nt we test also NS_CONN_MT_UNINITED, >>> NS_CONN_MT_CONNECT_ERROR and NS_CONN_MT_CLOSING ? >>> SD-65: __s_api_conn_mt_get() (and frineds: _s_api_conn_mt_add(), ...) >>> that's an 'API' function, could we get more wording on what the >>> parameters >>> are (shall be) and what return code shall be expected ? >>> SD-66: 1317-1318 >>> I find the comment and the following test hard to read. What >>> about something like: we want to reuse MT connection only if >>> keep-connection flag is set or if MT was requested (or active) >>> >>> SD-67: 1326, typo >>> coonection -> connection >>> >>> SD-68: 1324 >>> worth adding a comment that we're taking the lock of cmg ? (or >>> changing macro name to make it explicit ?) >>> >>> SD-69: 1370-1374 >>> I don't understadn the logic, can you add a comment ? >>> Why NS_CONN_USER_CONNECT_ERROR in 1 case and >>> NS_CONN_USER_FINDING else ? >>> SD-70: 1384/1385 >>> add same comment as 1376 >>> >>> SD-71: 1397-1400 >>> why do we 'hide' NS_LDAP_MEMORY ? >>> >>> SD-72: 1403 and following >>> shouldn't we add_cu2cn() ? >>> >>> SD-73: 1413 >>> why NOTFOUND ? why not SUCCESS ? >>> >>> SD-74: 1438-1442 >>> why do we do this here ? shouldn't this have been done elsewhere ? >>> SD-75: 1483 & 490 >>> what's the purpose of ns_conn_free ? it's only used here if I am not >>> mistaken >>> >>> SD-76: err2cm() >>> err2cm() assumes its caller will take care of releasing errorp, >>> since >>> it copies it into ep (assuming __s_api_copy_error() does what its >>> name >>> implies). >>> Have you checked for memory leaks ? it seems to me that at least >>> 1 code >>> path would produce some: >>> shutdown_all_conn_mt() allocates ep, gives it to: >>> close_conn_mt() as errorp which then might call err2cm(). >>> If I am not mistaken, neither close_conn_mt() nor >>> shutdown_all_conn_mt() >>> release the initial ep. >>> >>> ------------------------------------------------------------------------ >>> >>> >>> _______________________________________________ >>> duckwater-discuss mailing list >>> duckwater-discuss at opensolaris.org >>> http://mail.opensolaris.org/mailman/listinfo/duckwater-discuss >>> >> From Tomas.Heran at Sun.COM Wed Jun 4 07:04:49 2008 From: Tomas.Heran at Sun.COM (Tomas Heran) Date: Wed, 04 Jun 2008 16:04:49 +0200 Subject: [Duckwater-discuss] Code-review request for Duckwater Phase 0 (round 3) In-Reply-To: <48469BEA.3070804@sun.com> References: <483A9DA2.9010408@sun.com> <483EB998.1070308@Sun.COM> <4840265E.8070203@Sun.COM> <484437C8.6010203@Sun.COM> <4844BB0F.70603@sun.com> <4844ECD2.1050406@Sun.COM> <48469BEA.3070804@sun.com> Message-ID: <4846A101.2050503@sun.com> Michen Chang wrote: > Serge Dussud wrote: >> >> Thanks Michen, >> >> no sure how to follow-up, should I edit >> http://opensolaris.org/os/project/duckwater/duckwater_phase0/codereview/serge_libsldap/ >> ? (how do I do that ?) > > I guess a question for Tomas. I am having problem signing in > this morning. But I will update it more when I can. Serge, unless I make you leader of Duckwater project on opensolaris.org, you cannot modify the pages. So I believe the most straightforward way to follow up through email. T. From Serge.Dussud at Sun.COM Wed Jun 4 07:16:36 2008 From: Serge.Dussud at Sun.COM (Serge Dussud) Date: Wed, 04 Jun 2008 16:16:36 +0200 Subject: [Duckwater-discuss] Code-review request for Duckwater Phase 0 (round 3) In-Reply-To: <4846A101.2050503@sun.com> References: <483A9DA2.9010408@sun.com> <483EB998.1070308@Sun.COM> <4840265E.8070203@Sun.COM> <484437C8.6010203@Sun.COM> <4844BB0F.70603@sun.com> <4844ECD2.1050406@Sun.COM> <48469BEA.3070804@sun.com> <4846A101.2050503@sun.com> Message-ID: <4846A3C4.20408@Sun.COM> Tomas Heran wrote: > > > Michen Chang wrote: >> Serge Dussud wrote: >>> >>> Thanks Michen, >>> >>> no sure how to follow-up, should I edit >>> http://opensolaris.org/os/project/duckwater/duckwater_phase0/codereview/serge_libsldap/ >>> ? (how do I do that ?) >> >> I guess a question for Tomas. I am having problem signing in >> this morning. But I will update it more when I can. > > Serge, unless I make you leader of Duckwater project on opensolaris.org, > you cannot modify the pages. So I believe the most straightforward way > to follow up through email. sure, I'll do that. Serge > > T. From Serge.Dussud at Sun.COM Wed Jun 4 07:18:17 2008 From: Serge.Dussud at Sun.COM (Serge Dussud) Date: Wed, 04 Jun 2008 16:18:17 +0200 Subject: [Duckwater-discuss] Code-review request for Duckwater Phase 0 (round 5) In-Reply-To: <48455BAD.60607@Sun.COM> References: <483A9DA2.9010408@sun.com> <483EB998.1070308@Sun.COM> <4840265E.8070203@Sun.COM> <484437C8.6010203@Sun.COM> <48455BAD.60607@Sun.COM> Message-ID: <4846A429.30503@Sun.COM> round 5 of comments attached. Serge -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dw0-review5.txt URL: From Tomas.Heran at Sun.COM Wed Jun 4 07:11:29 2008 From: Tomas.Heran at Sun.COM (Tomas Heran) Date: Wed, 04 Jun 2008 16:11:29 +0200 Subject: [Duckwater-discuss] Duckwater Phase 0 code-review deadline Message-ID: <4846A291.4080804@sun.com> Gentlemen, we decided to set another deadline for the code-review for tomorrow morning Austin time. So, if you still have stuff to review, please make sure to send your comments today. Thanks, Tomas From Tomas.Heran at Sun.COM Wed Jun 4 09:23:38 2008 From: Tomas.Heran at Sun.COM (Tomas Heran) Date: Wed, 04 Jun 2008 18:23:38 +0200 Subject: [Duckwater-discuss] Duckwater Phase 0 code-review deadline In-Reply-To: <4846A291.4080804@sun.com> References: <4846A291.4080804@sun.com> Message-ID: <4846C18A.4000903@sun.com> FYI ... the current status of received comments per file is this: RECEIVED COMMENTS FILE ===================== ================================================== Nico usr/src/cmd/ldap/Makefile Nico usr/src/cmd/ldap/Makefile.com Nico usr/src/cmd/ldap/ns_ldap/idsconfig.sh Nico, Satish usr/src/cmd/ldap/ns_ldap/ldapaddent.c Nico, Ajay usr/src/cmd/ldap/ns_ldap/ldapclient.c Nico, Ajay usr/src/cmd/ldap/ns_ldap/ldaplist.c Nico usr/src/cmd/ldap/ns_ldap/standalone.h Nico usr/src/cmd/ldap/req.flg Nico, Milan usr/src/cmd/ldapcachemgr/Makefile Milan usr/src/cmd/ldapcachemgr/cachemgr.c Nico, Milan usr/src/cmd/ldapcachemgr/cachemgr.h Nico, Milan usr/src/cmd/ldapcachemgr/cachemgr_change.c Milan usr/src/cmd/ldapcachemgr/cachemgr_getldap.c usr/src/lib/Makefile Serge usr/src/lib/libsldap/Makefile.com Serge usr/src/lib/libsldap/common/mapfile-vers Milan, Serge usr/src/lib/libsldap/common/ns_cache_door.c Milan, Serge usr/src/lib/libsldap/common/ns_cache_door.h Julian, Serge usr/src/lib/libsldap/common/ns_common.c Serge, Ashok usr/src/lib/libsldap/common/ns_config.c Serge usr/src/lib/libsldap/common/ns_confmgr.c Julian, Serge usr/src/lib/libsldap/common/ns_connect.c Serge, David usr/src/lib/libsldap/common/ns_connmgmt.c Serge, David usr/src/lib/libsldap/common/ns_connmgmt.h usr/src/lib/libsldap/common/ns_init.c usr/src/lib/libsldap/common/ns_internal.h Milan usr/src/lib/libsldap/common/ns_reads.c Ajay usr/src/lib/libsldap/common/ns_sldap.h Nico, Ashok usr/src/lib/libsldap/common/ns_standalone.c Milan usr/src/lib/libsldap/common/ns_writes.c T. Tomas Heran wrote: > Gentlemen, > > we decided to set another deadline for the code-review for tomorrow > morning Austin time. So, if you still have stuff to review, please make > sure to send your comments today. > > Thanks, > Tomas > From julian.pullen at sun.com Wed Jun 4 09:59:17 2008 From: julian.pullen at sun.com (Julian Pullen) Date: Wed, 04 Jun 2008 17:59:17 +0100 Subject: [Duckwater-discuss] Code-review request for Duckwater Phase 0 In-Reply-To: <484583FE.2000506@sun.com> References: <483A9DA2.9010408@sun.com> <484583FE.2000506@sun.com> Message-ID: <4846C9E5.9080904@sun.com> Tomas, Some more comments. ns_confmgr.c ------------ __s_api_create_config_door_str() line 309 the snprintf has a parameter "attr" for which there is no print format. Again more tomorrow. Regards Julian Julian Pullen wrote: > Tomas, > > Here are some comments on libsldap. > > ns_connect.c > ------------ > __s_api_requestServer() line 184. I think the code should be > > 184 if (*error != NULL) { > 185 (void) __ns_ldap_freeError(error); > 186 } > > > > createSession() line 2200. I would use an if (useSSL) and not "?" > to make it more readable > > > ns_common.c > ----------- > __s_api_copy_error() Why use calloc if you going to copy > the ns_ldap_error_t to the new allocated memory. > > More tomorrow. > > Regards > > Julian > > > > Tomas Heran wrote: >> Dear All, >> >> we'd like to request a code review of our latest changes to LDAP naming >> tools and infrastructure to improve connection and server management in >> libsldap and ldap_cachemgr(1M) and to introduce "standalone" feature to >> LDAP naming tools. This integration (when done) will deliver first set >> of features promised by Duckwater project. We call it internally >> Duckwater Phase 0. >> >> The information about the changes, RFEs and CRs and updated manual >> pages can be found here: >> http://www.opensolaris.org/os/project/duckwater/duckwater_phase0 >> >> The webrev with the changes is here: >> http://cr.opensolaris.org/~the/duckwater_phase0/ >> >> Thanks, >> Tomas > From Tomas.Heran at Sun.COM Thu Jun 5 02:23:19 2008 From: Tomas.Heran at Sun.COM (Tomas Heran) Date: Thu, 05 Jun 2008 11:23:19 +0200 Subject: [Duckwater-discuss] [Fwd: Review Comments : Re: [Fwd: Code-review request for Duckwater Phase 0]] Message-ID: <4847B087.5090109@sun.com> Ajay's and Ashok's comments. I'm trying to put them to DW page on opensolaris.org but it's misbehaving again! :-( Tomas -------- Original Message -------- Subject: Review Comments : Re: [Fwd: [Duckwater-discuss] Code-review request for Duckwater Phase 0] Date: Tue, 03 Jun 2008 17:22:07 +0530 From: Ajaykumar Venkatesulu Reply-To: Ajaykumar.Venkatesulu at Sun.COM To: Tomas Heran CC: Milan Jurik , Ashok Kumar T References: <4843BDDC.6080605 at Sun.COM> <4843CBFD.9040604 at sun.com> <4843F063.9080405 at sun.com> <48441686.3030008 at Sun.COM> <1212422135.2043.222.camel at xylabone> <48441B52.1090603 at Sun.COM> <484426C9.2070506 at sun.com> <484427CF.60900 at sun.com> <4844DB29.6010800 at Sun.COM> <4844FE1B.30000 at sun.com> Hi Tomas, Not sure about the alias for mailing the review comments.Please update the page with review comments or if it is required to send a mail to the alias let me know the details. Myself and Ashok has the following comments/suggestions : Ajay's review comments : ---------------------- ns_sldap.h : ------------ line 495 * NSBEC: I think "_" is missed i.e should be : NS_BEC Also on lines 533 & 539 ldaplist.c ---------- line 340 standalone_cfg.SA_AUTH = authmech == NULL ? NULL : &auth; Just a comment : for readability purpose standalone_cfg.SA_AUTH = ( authmech == NULL ) ? NULL : &auth; lines 393-397 comments should say only "SASL/GSSAPI auth method will be used" ldapclient.c : -------------- 1457 /* __ns_ldap_setServer(TRUE); */ one line comment is required i.e why is it not required now or this should be deleted. Ashok review comment's : ------------------------ * ns_config.c: line 795: Usage of free() before assigning NULL to current_config would safe. standalone.h: Function separatePort(): We are not taking care of syntax errors like that of '...]...[....' ns_standalone.c: Function get_db(): line 228, 242, 311, 317: It would safe if we can check for the end of buffer in the while loop when checking for space. Typo in line 284: longer then -> longer than lines 290: Most of the customers complain that certain application has exited without printing any log/error message. Introducing more exit messages would help understand why the application has exited. In this line we would like to have memory allocation error message here. line 406: Return value of nss_search(). What if the res is NSS_NOTFOUND? Function __s_api_ip2hostname(): Do we need to check for syntax errors like that of [[]] or ...]...[... User could be crazy guy like me :-) lines where inet_pton() is used: what if inet_pton() fails and returns -1. Don't we need to check for failure? Thanks, Ajay Tomas Heran wrote: > Thanks. You help is very appreciated! > > Tomas > > Ajaykumar Venkatesulu wrote: >> Tomas, >> >> I will mail my review comments by end of day. >> >> Thanks, >> Ajay >> >> Satish Murugesan wrote: >>> Tomas, >>> >>> I am looking at ldapaddent today. Will email my comments by Tuesday AM. >>> >>> thanks, >>> Satish >>> >>> Tomas Heran wrote: >>>> Nico promised to have a look at standalone bits in libsldap. I still >>>> haven't seen anything from Satish neither Ajay. Will you guys make it? >>>> >>>> Julian got back from vacation today. We asked him to review libsldap >>>> too. He'll be working on that tomorrow morning. >>>> >>>> Also, people were asking what files needs more reviewing. Here's a list >>>> of files and people I've received comments about those files so far. >>>> It's clear that libsldap needs more work: >>>> >>>> RECEIVED COMMENTS FILE >>>> ================= >>>> ====================================================== >>>> Nico new/usr/src/cmd/ldap/Makefile >>>> Nico new/usr/src/cmd/ldap/Makefile.com >>>> Nico new/usr/src/cmd/ldap/ns_ldap/idsconfig.sh >>>> Nico new/usr/src/cmd/ldap/ns_ldap/ldapaddent.c >>>> Nico new/usr/src/cmd/ldap/ns_ldap/ldapclient.c >>>> Nico new/usr/src/cmd/ldap/ns_ldap/ldaplist.c >>>> Nico new/usr/src/cmd/ldap/ns_ldap/standalone.h >>>> Nico new/usr/src/cmd/ldap/req.flg >>>> Nico, Milan new/usr/src/cmd/ldapcachemgr/Makefile >>>> Milan new/usr/src/cmd/ldapcachemgr/cachemgr.c >>>> Nico, Milan new/usr/src/cmd/ldapcachemgr/cachemgr.h >>>> Nico, Milan new/usr/src/cmd/ldapcachemgr/cachemgr_change.c >>>> Milan new/usr/src/cmd/ldapcachemgr/cachemgr_getldap.c >>>> new/usr/src/lib/Makefile >>>> new/usr/src/lib/libsldap/Makefile.com >>>> new/usr/src/lib/libsldap/common/mapfile-vers >>>> Milan new/usr/src/lib/libsldap/common/ns_cache_door.c >>>> Milan new/usr/src/lib/libsldap/common/ns_cache_door.h >>>> new/usr/src/lib/libsldap/common/ns_common.c >>>> new/usr/src/lib/libsldap/common/ns_config.c >>>> new/usr/src/lib/libsldap/common/ns_confmgr.c >>>> new/usr/src/lib/libsldap/common/ns_connect.c >>>> Serge new/usr/src/lib/libsldap/common/ns_connmgmt.c >>>> Serge new/usr/src/lib/libsldap/common/ns_connmgmt.h >>>> new/usr/src/lib/libsldap/common/ns_init.c >>>> new/usr/src/lib/libsldap/common/ns_internal.h >>>> Milan new/usr/src/lib/libsldap/common/ns_reads.c >>>> new/usr/src/lib/libsldap/common/ns_sldap.h >>>> new/usr/src/lib/libsldap/common/ns_standalone.c >>>> Milan new/usr/src/lib/libsldap/common/ns_writes.c >>>> >>>> ==== >>>> >>>> We agreed that the changes to address code-reviewers' comments will be >>>> provided to you guys as "incremental" webrev(s). The original webrev >>>> will stay as it is. The new webrev(s) will clearly identify which >>>> comments/issues/etc. are addressed. >>>> >>>> Tomas >>>> >>>> Serge Dussud wrote: >>>>> >>>>> sure (I still hope to send comments tonight). However, several >>>>> reviewers on the same files for libsldap & ldap_cachemgr changes >>>>> would be worth it IMO. >>>>> >>>>> Serge >>>>> >>>>> Milan Jurik wrote: >>>>>> Hi Serge, >>>>>> >>>>>> I plan to look at ns_connect.c tomorrow if you are still in >>>>>> ns_connmgmt.c >>>>>> >>>>>> Best regards, >>>>>> >>>>>> Milan >>>>>> >>>>>> V po, 02. 06. 2008 v 17:49, Serge Dussud p??e: >>>>>>> An incremental webrev could help as well. Thanks ! >>>>>>> >>>>>>> Tomas, is the deadline still tomorrow ? it's going to be >>>>>>> challenging for me I think (was not able to allocate much time on >>>>>>> this yet today ...). Also, is there anyone else reviewing the >>>>>>> libsldap changes ? Those probably deserves several pair of eyes >>>>>>> to look at them IMO. >>>>>>> >>>>>>> Serge >>>>>>> >>>>>>> >>>>>>> Michen Chang wrote: >>>>>>>> People should continue reviewing and our goal is to get it done by >>>>>>>> tomorrow AM. >>>>>>>> >>>>>>>> These's very little change in libsldap but some changes in >>>>>>>> ldap_cachemgr. >>>>>>>> >>>>>>>> Chin-Long has made the changes for ldap_cachemgr, so the webrev can >>>>>>>> be updated to reflect the change since Milan has done reviewing >>>>>>>> the ldap_cachemgr. OR Chin-Long can show his new changes now to >>>>>>>> Milan/Nico and point out the changes to others in the final webrev. >>>>>>>> Whichever is faster and easier is better. >>>>>>>> >>>>>>>> Let us know. >>>>>>>> >>>>>>>> -- >>>>>>>> Michen >>>>>>>> >>>>>>>> Tomas Heran wrote: >>>>>>>>> Michen, Chin-Long, >>>>>>>>> >>>>>>>>> are you guys going to do the changes now? Should people stop >>>>>>>>> reviewing >>>>>>>>> code until further notice? >>>>>>>>> >>>>>>>>> Tomas >>>>>>>>> >>>>>>>>> Serge Dussud wrote: >>>>>>>>>> Tomas, Milan, >>>>>>>>>> >>>>>>>>>> I guess this meens that the code review is on hold until new >>>>>>>>>> webrev is provided, right ? >>>>>>>>>> >>>>>>>>>> Serge >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -------- Original Message -------- >>>>>>>>>> Subject: Re: [sparks-discuss] [Duckwater-discuss] Code-review >>>>>>>>>> request for Duckwater Phase 0 >>>>>>>>>> Date: Fri, 30 May 2008 15:12:10 -0500 >>>>>>>>>> From: Nicolas Williams >>>>>>>>>> To: Tomas Heran >>>>>>>>>> CC: sparks-discuss at opensolaris.org, Duckwater Discuss >>>>>>>>>> >>>>>>>>>> References: <483A9DA2.9010408 at sun.com> >>>>>>>>>> <20080528224243.GG1039 at Sun.COM> >>>>>>>>>> <20080529212945.GB2734 at Sun.COM> >>>>>>>>>> <20080529225540.GE2734 at Sun.COM> >>>>>>>>>> <20080530174319.GA2735 at Sun.COM> <20080530183614.GB2735 at Sun.COM> >>>>>>>>>> >>>>>>>>>> On Fri, May 30, 2008 at 01:36:14PM -0500, Nicolas Williams wrote: >>>>>>>>>>> So, we want a way for many threads in libsldap using programs >>>>>>>>>>> to be able >>>>>>>>>>> to wait indefinitely until ldap_cachemgr finds a suitable, >>>>>>>>>>> live DS, then >>>>>>>>>>> wake up all those threads. >>>>>>>>>>> >>>>>>>>>>> The current scheme in the code I've reviewed has problems >>>>>>>>>>> (see previous >>>>>>>>>>> post). >>>>>>>>>>> >>>>>>>>>>> There are several ways to do what is desired. Here are some: >>>>>>>>>> I spoke to Michen. >>>>>>>>>> >>>>>>>>>> There's really no need for more than one thread to use the new >>>>>>>>>> ldap_cachemgr status change feature: one thread in nscd. >>>>>>>>>> >>>>>>>>>> That's because per-user nscds are short-lived anyways. >>>>>>>>>> >>>>>>>>>> Michen will look at the changes to make it so. >>>>>>>>>> >>>>>>>>>> That will address all my issues about this feature. >>>>>>>>>> >>>>>>>>>> Also, the change status notification feature is somewhat more >>>>>>>>>> complex >>>>>>>>>> than I'd thought, since there's server up and down change >>>>>>>>>> notifications. >>>>>>>>>> That means that if we had lots of client threads then we'd need >>>>>>>>>> something somewhat more involved than the designs I described. >>>>>>>>>> >>>>>>>>>> Nico >>>>>> >>> >> From julian.pullen at sun.com Thu Jun 5 02:34:52 2008 From: julian.pullen at sun.com (Julian Pullen) Date: Thu, 05 Jun 2008 10:34:52 +0100 Subject: [Duckwater-discuss] Code-review request for Duckwater Phase 0 In-Reply-To: <484583FE.2000506@sun.com> References: <483A9DA2.9010408@sun.com> <484583FE.2000506@sun.com> Message-ID: <4847B33C.8020509@sun.com> Tomas, I have now been through all the usr/src/lib/libsldap/common/*.[ch] file with the exception of ns_standalone.c once. I will now look through ns_confmgr.c and ns_connect.c again. Regards Julian Julian Pullen wrote: > Tomas, > > Here are some comments on libsldap. > > ns_connect.c > ------------ > __s_api_requestServer() line 184. I think the code should be > > 184 if (*error != NULL) { > 185 (void) __ns_ldap_freeError(error); > 186 } > > > > createSession() line 2200. I would use an if (useSSL) and not "?" > to make it more readable > > > ns_common.c > ----------- > __s_api_copy_error() Why use calloc if you going to copy > the ns_ldap_error_t to the new allocated memory. > > More tomorrow. > > Regards > > Julian > > > > Tomas Heran wrote: >> Dear All, >> >> we'd like to request a code review of our latest changes to LDAP naming >> tools and infrastructure to improve connection and server management in >> libsldap and ldap_cachemgr(1M) and to introduce "standalone" feature to >> LDAP naming tools. This integration (when done) will deliver first set >> of features promised by Duckwater project. We call it internally >> Duckwater Phase 0. >> >> The information about the changes, RFEs and CRs and updated manual >> pages can be found here: >> http://www.opensolaris.org/os/project/duckwater/duckwater_phase0 >> >> The webrev with the changes is here: >> http://cr.opensolaris.org/~the/duckwater_phase0/ >> >> Thanks, >> Tomas > From Tomas.Heran at Sun.COM Thu Jun 5 02:41:48 2008 From: Tomas.Heran at Sun.COM (Tomas Heran) Date: Thu, 05 Jun 2008 11:41:48 +0200 Subject: [Duckwater-discuss] Code-review request for Duckwater Phase 0 (round 3) In-Reply-To: <4846A3A6.4020506@sun.com> References: <483A9DA2.9010408@sun.com> <483EB998.1070308@Sun.COM> <4840265E.8070203@Sun.COM> <484437C8.6010203@Sun.COM> <4844BB0F.70603@sun.com> <4844ECD2.1050406@Sun.COM> <48469BEA.3070804@sun.com> <4846A163.9090908@sun.com> <4846A3A6.4020506@sun.com> Message-ID: <4847B4DC.80302@sun.com> The old incremental webrev is here: http://cr.opensolaris.org/~the/duckwater_phase0_incr_michen-Jun-2/ The updated is: http://cr.opensolaris.org/~the/duckwater_phase0_incr_michen/ Tomas Michen Chang wrote: > > Yes all the changes I've made so far (It's the same workspace). > > If possible, please move duckwater_phase0_incr_michen to > something like duckwater_phase0_incr_michen-v1 (or v1->date) > and use duckwater_phase0_incr_michen as the most current one. > > We also need to coordinate if more than one person change the > same files. > > Thanks, > Michen > > > Tomas Heran wrote: >> >> >> Michen Chang wrote: >>> >>> I have integrated Serge's batch 4 and David comments on >>> ns_connmgmt.[h|c]. >>> The updated webrev is here: >>> http://jurassic.eng/net/ns-web.sfbay/tank/panjim-export/ldap/users/michen/ws/sldap-comment-0602/webrev/ >>> >> >> Does this webrev include all the changes you've made so far? Should I >> update your incremental webrev on >> http://cr.opensolaris.org/~the/duckwater_phase0_incr_michen/ ? >> >> T. > From Tomas.Heran at Sun.COM Thu Jun 5 03:16:57 2008 From: Tomas.Heran at Sun.COM (Tomas Heran) Date: Thu, 05 Jun 2008 12:16:57 +0200 Subject: [Duckwater-discuss] [Fwd: Review Comments : Re: [Fwd: Code-review request for Duckwater Phase 0]] In-Reply-To: <4847B087.5090109@sun.com> References: <4847B087.5090109@sun.com> Message-ID: <4847BD19.7020808@sun.com> Ajay's and Ashok's comments are here: http://www.opensolaris.org/os/project/duckwater/duckwater_phase0/codereview/ajay_ashok/ T. Tomas Heran wrote: > Ajay's and Ashok's comments. > > I'm trying to put them to DW page on opensolaris.org but it's > misbehaving again! :-( > > Tomas > > -------- Original Message -------- > Subject: Review Comments : Re: [Fwd: [Duckwater-discuss] Code-review > request for Duckwater Phase 0] > Date: Tue, 03 Jun 2008 17:22:07 +0530 > From: Ajaykumar Venkatesulu > Reply-To: Ajaykumar.Venkatesulu at Sun.COM > To: Tomas Heran > CC: Milan Jurik , Ashok Kumar T > References: <4843BDDC.6080605 at Sun.COM> <4843CBFD.9040604 at sun.com> > <4843F063.9080405 at sun.com> <48441686.3030008 at Sun.COM> > <1212422135.2043.222.camel at xylabone> <48441B52.1090603 at Sun.COM> > <484426C9.2070506 at sun.com> <484427CF.60900 at sun.com> > <4844DB29.6010800 at Sun.COM> <4844FE1B.30000 at sun.com> > > Hi Tomas, > > > Not sure about the alias for mailing the review comments.Please update > the page with review comments or if it is required to send a mail to the > alias let me know the details. > > > Myself and Ashok has the following comments/suggestions : > > > Ajay's review comments : > ---------------------- > > ns_sldap.h : > ------------ > > line 495 * NSBEC: > > I think "_" is missed i.e should be : NS_BEC > > Also on lines 533 & 539 > > > ldaplist.c > ---------- > > line 340 standalone_cfg.SA_AUTH = authmech == NULL ? NULL : &auth; > > Just a comment : for readability purpose > > standalone_cfg.SA_AUTH = ( authmech == NULL ) ? NULL : &auth; > > > lines 393-397 comments should say only "SASL/GSSAPI auth method will be > used" > > ldapclient.c : > -------------- > > 1457 /* __ns_ldap_setServer(TRUE); */ > > one line comment is required i.e why is it not required now or this > should be deleted. > > > Ashok review comment's : > ------------------------ > > * ns_config.c: > line 795: Usage of free() before assigning NULL to > current_config would safe. > > > standalone.h: Function separatePort(): > We are not taking care of syntax errors like that of > '...]...[....' > > ns_standalone.c: Function get_db(): > line 228, 242, 311, 317: It would safe if we can check for > the end of buffer in the while loop when checking for space. > > Typo in line 284: longer then -> longer than > lines 290: Most of the customers complain that > certain application has exited without printing any log/error message. > Introducing more exit messages would help > understand why the application has exited. In this line we would > like to have memory allocation error > message here. > line 406: Return value of nss_search(). What if the > res is NSS_NOTFOUND? Function > __s_api_ip2hostname(): Do we need to check for syntax errors like that > of [[]] or ...]...[... > User could be crazy guy like me :-) > > lines where inet_pton() is used: what if inet_pton() fails > and returns -1. Don't we need to check for failure? > > > > Thanks, > Ajay > > > > Tomas Heran wrote: >> Thanks. You help is very appreciated! >> >> Tomas >> >> Ajaykumar Venkatesulu wrote: >>> Tomas, >>> >>> I will mail my review comments by end of day. >>> >>> Thanks, >>> Ajay >>> >>> Satish Murugesan wrote: >>>> Tomas, >>>> >>>> I am looking at ldapaddent today. Will email my comments by Tuesday AM. >>>> >>>> thanks, >>>> Satish >>>> >>>> Tomas Heran wrote: >>>>> Nico promised to have a look at standalone bits in libsldap. I still >>>>> haven't seen anything from Satish neither Ajay. Will you guys make it? >>>>> >>>>> Julian got back from vacation today. We asked him to review libsldap >>>>> too. He'll be working on that tomorrow morning. >>>>> >>>>> Also, people were asking what files needs more reviewing. Here's a list >>>>> of files and people I've received comments about those files so far. >>>>> It's clear that libsldap needs more work: >>>>> >>>>> RECEIVED COMMENTS FILE >>>>> ================= >>>>> ====================================================== >>>>> Nico new/usr/src/cmd/ldap/Makefile >>>>> Nico new/usr/src/cmd/ldap/Makefile.com >>>>> Nico new/usr/src/cmd/ldap/ns_ldap/idsconfig.sh >>>>> Nico new/usr/src/cmd/ldap/ns_ldap/ldapaddent.c >>>>> Nico new/usr/src/cmd/ldap/ns_ldap/ldapclient.c >>>>> Nico new/usr/src/cmd/ldap/ns_ldap/ldaplist.c >>>>> Nico new/usr/src/cmd/ldap/ns_ldap/standalone.h >>>>> Nico new/usr/src/cmd/ldap/req.flg >>>>> Nico, Milan new/usr/src/cmd/ldapcachemgr/Makefile >>>>> Milan new/usr/src/cmd/ldapcachemgr/cachemgr.c >>>>> Nico, Milan new/usr/src/cmd/ldapcachemgr/cachemgr.h >>>>> Nico, Milan new/usr/src/cmd/ldapcachemgr/cachemgr_change.c >>>>> Milan new/usr/src/cmd/ldapcachemgr/cachemgr_getldap.c >>>>> new/usr/src/lib/Makefile >>>>> new/usr/src/lib/libsldap/Makefile.com >>>>> new/usr/src/lib/libsldap/common/mapfile-vers >>>>> Milan new/usr/src/lib/libsldap/common/ns_cache_door.c >>>>> Milan new/usr/src/lib/libsldap/common/ns_cache_door.h >>>>> new/usr/src/lib/libsldap/common/ns_common.c >>>>> new/usr/src/lib/libsldap/common/ns_config.c >>>>> new/usr/src/lib/libsldap/common/ns_confmgr.c >>>>> new/usr/src/lib/libsldap/common/ns_connect.c >>>>> Serge new/usr/src/lib/libsldap/common/ns_connmgmt.c >>>>> Serge new/usr/src/lib/libsldap/common/ns_connmgmt.h >>>>> new/usr/src/lib/libsldap/common/ns_init.c >>>>> new/usr/src/lib/libsldap/common/ns_internal.h >>>>> Milan new/usr/src/lib/libsldap/common/ns_reads.c >>>>> new/usr/src/lib/libsldap/common/ns_sldap.h >>>>> new/usr/src/lib/libsldap/common/ns_standalone.c >>>>> Milan new/usr/src/lib/libsldap/common/ns_writes.c >>>>> >>>>> ==== >>>>> >>>>> We agreed that the changes to address code-reviewers' comments will be >>>>> provided to you guys as "incremental" webrev(s). The original webrev >>>>> will stay as it is. The new webrev(s) will clearly identify which >>>>> comments/issues/etc. are addressed. >>>>> >>>>> Tomas >>>>> >>>>> Serge Dussud wrote: >>>>>> sure (I still hope to send comments tonight). However, several >>>>>> reviewers on the same files for libsldap & ldap_cachemgr changes >>>>>> would be worth it IMO. >>>>>> >>>>>> Serge >>>>>> >>>>>> Milan Jurik wrote: >>>>>>> Hi Serge, >>>>>>> >>>>>>> I plan to look at ns_connect.c tomorrow if you are still in >>>>>>> ns_connmgmt.c >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> Milan >>>>>>> >>>>>>> V po, 02. 06. 2008 v 17:49, Serge Dussud p??e: >>>>>>>> An incremental webrev could help as well. Thanks ! >>>>>>>> >>>>>>>> Tomas, is the deadline still tomorrow ? it's going to be >>>>>>>> challenging for me I think (was not able to allocate much time on >>>>>>>> this yet today ...). Also, is there anyone else reviewing the >>>>>>>> libsldap changes ? Those probably deserves several pair of eyes >>>>>>>> to look at them IMO. >>>>>>>> >>>>>>>> Serge >>>>>>>> >>>>>>>> >>>>>>>> Michen Chang wrote: >>>>>>>>> People should continue reviewing and our goal is to get it done by >>>>>>>>> tomorrow AM. >>>>>>>>> >>>>>>>>> These's very little change in libsldap but some changes in >>>>>>>>> ldap_cachemgr. >>>>>>>>> >>>>>>>>> Chin-Long has made the changes for ldap_cachemgr, so the webrev can >>>>>>>>> be updated to reflect the change since Milan has done reviewing >>>>>>>>> the ldap_cachemgr. OR Chin-Long can show his new changes now to >>>>>>>>> Milan/Nico and point out the changes to others in the final webrev. >>>>>>>>> Whichever is faster and easier is better. >>>>>>>>> >>>>>>>>> Let us know. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Michen >>>>>>>>> >>>>>>>>> Tomas Heran wrote: >>>>>>>>>> Michen, Chin-Long, >>>>>>>>>> >>>>>>>>>> are you guys going to do the changes now? Should people stop >>>>>>>>>> reviewing >>>>>>>>>> code until further notice? >>>>>>>>>> >>>>>>>>>> Tomas >>>>>>>>>> >>>>>>>>>> Serge Dussud wrote: >>>>>>>>>>> Tomas, Milan, >>>>>>>>>>> >>>>>>>>>>> I guess this meens that the code review is on hold until new >>>>>>>>>>> webrev is provided, right ? >>>>>>>>>>> >>>>>>>>>>> Serge >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -------- Original Message -------- >>>>>>>>>>> Subject: Re: [sparks-discuss] [Duckwater-discuss] Code-review >>>>>>>>>>> request for Duckwater Phase 0 >>>>>>>>>>> Date: Fri, 30 May 2008 15:12:10 -0500 >>>>>>>>>>> From: Nicolas Williams >>>>>>>>>>> To: Tomas Heran >>>>>>>>>>> CC: sparks-discuss at opensolaris.org, Duckwater Discuss >>>>>>>>>>> >>>>>>>>>>> References: <483A9DA2.9010408 at sun.com> >>>>>>>>>>> <20080528224243.GG1039 at Sun.COM> >>>>>>>>>>> <20080529212945.GB2734 at Sun.COM> >>>>>>>>>>> <20080529225540.GE2734 at Sun.COM> >>>>>>>>>>> <20080530174319.GA2735 at Sun.COM> <20080530183614.GB2735 at Sun.COM> >>>>>>>>>>> >>>>>>>>>>> On Fri, May 30, 2008 at 01:36:14PM -0500, Nicolas Williams wrote: >>>>>>>>>>>> So, we want a way for many threads in libsldap using programs >>>>>>>>>>>> to be able >>>>>>>>>>>> to wait indefinitely until ldap_cachemgr finds a suitable, >>>>>>>>>>>> live DS, then >>>>>>>>>>>> wake up all those threads. >>>>>>>>>>>> >>>>>>>>>>>> The current scheme in the code I've reviewed has problems >>>>>>>>>>>> (see previous >>>>>>>>>>>> post). >>>>>>>>>>>> >>>>>>>>>>>> There are several ways to do what is desired. Here are some: >>>>>>>>>>> I spoke to Michen. >>>>>>>>>>> >>>>>>>>>>> There's really no need for more than one thread to use the new >>>>>>>>>>> ldap_cachemgr status change feature: one thread in nscd. >>>>>>>>>>> >>>>>>>>>>> That's because per-user nscds are short-lived anyways. >>>>>>>>>>> >>>>>>>>>>> Michen will look at the changes to make it so. >>>>>>>>>>> >>>>>>>>>>> That will address all my issues about this feature. >>>>>>>>>>> >>>>>>>>>>> Also, the change status notification feature is somewhat more >>>>>>>>>>> complex >>>>>>>>>>> than I'd thought, since there's server up and down change >>>>>>>>>>> notifications. >>>>>>>>>>> That means that if we had lots of client threads then we'd need >>>>>>>>>>> something somewhat more involved than the designs I described. >>>>>>>>>>> >>>>>>>>>>> Nico > > _______________________________________________ > duckwater-discuss mailing list > duckwater-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/duckwater-discuss From Tomas.Heran at Sun.COM Thu Jun 5 04:35:50 2008 From: Tomas.Heran at Sun.COM (Tomas Heran) Date: Thu, 05 Jun 2008 13:35:50 +0200 Subject: [Duckwater-discuss] Password scubbing Message-ID: <4847CF96.4060203@sun.com> > [20] usr/src/cmd/ldap/*.c > > Please see to it that passwords are scrubbed before exiting (e.g., > with memset()). Would it be OK if I filed a CR for this for now? T. From Serge.Dussud at Sun.COM Thu Jun 5 07:04:26 2008 From: Serge.Dussud at Sun.COM (Serge Dussud - Sun Microsystems) Date: Thu, 05 Jun 2008 16:04:26 +0200 Subject: [Duckwater-discuss] [sparks-discuss] Code-review request for Duckwater Phase 0 (round 6) In-Reply-To: <4846A429.30503@Sun.COM> References: <483A9DA2.9010408@sun.com> <483EB998.1070308@Sun.COM> <4840265E.8070203@Sun.COM> <484437C8.6010203@Sun.COM> <48455BAD.60607@Sun.COM> <4846A429.30503@Sun.COM> Message-ID: <4847F26A.2060709@sun.com> usr/src/lib/libsldap/common/ns_connect.c SD-122: 689 should it be __s_api_isStandalone() as in other parts of the code ? SD-123: 694 check strdup() returning null SD-124: 961-962 add a comment to say that we're going in only if MT connection layer is not used. SD-125: _DropConnection() same as a previous comment: why getting rid of threadID in certain DEBUG messages ? SD-126: 1022-1023 why do we get rid of the cehcks on nscd here, and keep them in findConnection() ? SD-127: 1031 do we still use shared ? shouldn't it remove from the structure ? if not, where do we set it ? SD-128: 1345-1346 what are we doing here ? should this be done before ? SD-129: createTLSSession() syslog message uses the prefix 'openConnection' instead of createTLSSession. SD-130: 2041 anough -> enough SD-131: 2050 already done in 2033 From julian.pullen at sun.com Thu Jun 5 07:13:43 2008 From: julian.pullen at sun.com (Julian Pullen) Date: Thu, 05 Jun 2008 15:13:43 +0100 Subject: [Duckwater-discuss] Code-review request for Duckwater Phase 0 In-Reply-To: <4847B33C.8020509@sun.com> References: <483A9DA2.9010408@sun.com> <484583FE.2000506@sun.com> <4847B33C.8020509@sun.com> Message-ID: <4847F497.7020008@sun.com> Tomas, Second review of ns_connect.c ----------------------------- I have a style comment on ns_connect.c. Though out this module if it finds a connection problem you call ldap_unbind to close the connection opened ldap connection. You don't after you have performed an unbind set ld to NULL. The caller openConnection does not know what has happened and has assumed that ld is valid if performBind returns success. Someone could in error try to use an invalid ld. Setting to NULL after an unbind would stop this from happening. You do have to pass &ld to the routine that calls ldap_unbind. addConnection() line 490 should be. 489 sessionPool = calloc(sessionPoolSize, 490 sizeof (Connection *)); line 512 should be 511 (void) memset(cl + sessionPoolSize, 0, 512 SESSION_CACHE_INC * sizeof (Connection *)); Regards Julian Julian Pullen wrote: > Tomas, > > I have now been through all the usr/src/lib/libsldap/common/*.[ch] file > with the exception of ns_standalone.c once. > > I will now look through ns_confmgr.c and ns_connect.c again. > > Regards > > Julian > > Julian Pullen wrote: >> Tomas, >> >> Here are some comments on libsldap. >> >> ns_connect.c >> ------------ >> __s_api_requestServer() line 184. I think the code should be >> >> 184 if (*error != NULL) { >> 185 (void) __ns_ldap_freeError(error); >> 186 } >> >> >> >> createSession() line 2200. I would use an if (useSSL) and not "?" >> to make it more readable >> >> >> ns_common.c >> ----------- >> __s_api_copy_error() Why use calloc if you going to copy >> the ns_ldap_error_t to the new allocated memory. >> >> More tomorrow. >> >> Regards >> >> Julian >> >> >> >> Tomas Heran wrote: >>> Dear All, >>> >>> we'd like to request a code review of our latest changes to LDAP naming >>> tools and infrastructure to improve connection and server management in >>> libsldap and ldap_cachemgr(1M) and to introduce "standalone" feature to >>> LDAP naming tools. This integration (when done) will deliver first set >>> of features promised by Duckwater project. We call it internally >>> Duckwater Phase 0. >>> >>> The information about the changes, RFEs and CRs and updated manual >>> pages can be found here: >>> http://www.opensolaris.org/os/project/duckwater/duckwater_phase0 >>> >>> The webrev with the changes is here: >>> http://cr.opensolaris.org/~the/duckwater_phase0/ >>> >>> Thanks, >>> Tomas > _______________________________________________ > duckwater-discuss mailing list > duckwater-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/duckwater-discuss From Doug.Leavitt at Sun.COM Thu Jun 5 07:29:25 2008 From: Doug.Leavitt at Sun.COM (Doug Leavitt) Date: Thu, 05 Jun 2008 09:29:25 -0500 Subject: [Duckwater-discuss] Password scubbing In-Reply-To: <4847CF96.4060203@sun.com> References: <4847CF96.4060203@sun.com> Message-ID: <4847F845.5060801@sun.com> Fine by me. It's been this behavior for 10+ years. Besides the proxy password is trivially readable anyways, regardless of any scrubbing. in a non-tls environment you simply: $ truss -rall -wall ldaplist | pg This used to work and was simpler as well: (haven't tried is recently) #!/usr/sbin/dtrace -Fs /* getproxypw.d */ /* * see if the ldap proxy pw can be retrieved from libsldap */ pid$1:libsldap:dvalue:entry { printf("%s", stringof(copyinstr(arg0))); } pid$1:libsldap:dvalue:return { printf("%s", stringof(copyinstr(arg1))); } Doug. Tomas Heran wrote: >> [20] usr/src/cmd/ldap/*.c >> >> Please see to it that passwords are scrubbed before exiting (e.g., >> with memset()). > > Would it be OK if I filed a CR for this for now? > > T. > _______________________________________________ > duckwater-discuss mailing list > duckwater-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/duckwater-discuss From Doug.Leavitt at Sun.COM Thu Jun 5 07:51:35 2008 From: Doug.Leavitt at Sun.COM (Doug Leavitt) Date: Thu, 05 Jun 2008 09:51:35 -0500 Subject: [Duckwater-discuss] Password scubbing In-Reply-To: <4847F845.5060801@sun.com> References: <4847CF96.4060203@sun.com> <4847F845.5060801@sun.com> Message-ID: <4847FD77.3060202@sun.com> I should caveat this somewhat. The tests below worked pre-sparks. Post-sparks, you need to be root (or have acceptable rbac permissions) AND be able to truss/dtrace nscd. So the hole is much smaller. With proxy passwords, there is still a point where truss/dtrace can grab the in memory passwrd when it's in the clear. Thats why per-user w/kerberos should be more appealing to the security conscious. Doug. Doug Leavitt wrote: > Fine by me. It's been this behavior for 10+ years. Besides > the proxy password is trivially readable anyways, regardless > of any scrubbing. > > in a non-tls environment you simply: > > $ truss -rall -wall ldaplist | pg > > This used to work and was simpler as well: (haven't tried is recently) > > #!/usr/sbin/dtrace -Fs > /* > getproxypw.d > */ > > /* > * see if the ldap proxy pw can be retrieved from libsldap > */ > > pid$1:libsldap:dvalue:entry > { > printf("%s", stringof(copyinstr(arg0))); > > } > > pid$1:libsldap:dvalue:return > { > printf("%s", stringof(copyinstr(arg1))); > } > > > Doug. > > Tomas Heran wrote: >>> [20] usr/src/cmd/ldap/*.c >>> >>> Please see to it that passwords are scrubbed before exiting (e.g., >>> with memset()). >> Would it be OK if I filed a CR for this for now? >> >> T. >> _______________________________________________ >> duckwater-discuss mailing list >> duckwater-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/duckwater-discuss > _______________________________________________ > duckwater-discuss mailing list > duckwater-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/duckwater-discuss From Nicolas.Williams at sun.com Thu Jun 5 08:26:00 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 5 Jun 2008 10:26:00 -0500 Subject: [Duckwater-discuss] Password scubbing In-Reply-To: <4847F845.5060801@sun.com> References: <4847CF96.4060203@sun.com> <4847F845.5060801@sun.com> Message-ID: <20080605152559.GF2735@Sun.COM> On Thu, Jun 05, 2008 at 09:29:25AM -0500, Doug Leavitt wrote: > Fine by me. It's been this behavior for 10+ years. Besides > the proxy password is trivially readable anyways, regardless > of any scrubbing. But the standalone commands can now prompt and read passwords from files... These need not be proxy passwords. I'm not terribly concerned with this right now, so fixing this later is OKish with me. But it is common practice in Solaris security code to scrub memory holding passwords. From Milan.Jurik at Sun.COM Thu Jun 5 09:56:03 2008 From: Milan.Jurik at Sun.COM (Milan Jurik) Date: Thu, 05 Jun 2008 18:56:03 +0200 Subject: [Duckwater-discuss] [sparks-discuss] Code-review request for Duckwater Phase 0 (round 3) In-Reply-To: <484652EA.9090605@sun.com> References: <483A9DA2.9010408@sun.com> <483EB998.1070308@Sun.COM> <4840265E.8070203@Sun.COM> <484437C8.6010203@Sun.COM> <4844BB0F.70603@sun.com> <48458352.5020006@Sun.COM> <484652EA.9090605@sun.com> Message-ID: <1212684963.3794.103.camel@localhost.localdomain> Hi, looks good, just minors: usr/src/cmd/ldapcachemgr/cachemgr_getldap.c =========================================== [01] 890 + int matched = FALSE, len, rc = 0; - still mix of initialized and uninitialized variables. By default it is better to have one initialized variable definition per line. Or joining only when initialized with the same value. [02] 2880 + * this is called in removing server case. - BIG This ;-) usr/src/cmd/ldapcachemgr/cachemgr_change.c ========================================== [03] 241 + * When the call is START op, It checks if main_nscd.pid is 0. If it is, it - small "it check" ;-) [04] 248 + * ldap_cachemgr's cookie, it door returns config change. - "it door" - too many words? [05] 291 + * one at a time. If it's the same pid - "once at time" ? [06] 260 + int rc = CHG_SUCCESS, thread_alive = 0; [...] 283 + thread_alive = 1; [...] 302 + while (thread_alive && chg_main_nscd.in_progress) { [...] - the only places I see local variable thread_alive - why in while loop? - also, the meaning of this variable isn't "thread is alive", is it? [07] 635 + * Check if the door client making door call a nscd or peruser nscd and output - missing verb? Best regards, Milan Tomas Heran p??e v St 04. 06. 2008 v 10:31 +0200: > I've uploaded the webrev to > http://cr.opensolaris.org/~the/duckwater_phase0_incr_chinlong/ > > Tomas > > Chin-Long Shu wrote: > > This new webrev address mainly Milan's and Nicol's comments. > > The major chang is only main nacd can make GETSTATUSCHANGE call and the > > logic in chg_get_statusChange() is changed accordingly. > > The other change is the number counting code is moved to switcher so it > > have more accurate counting. The previous code only counts START op > > threads, but not STOP op threads. > > > > http://jurassic.eng/net/ns-web.sfbay/tank/panjim-export/ldap/users/chinlong/ws/new_libsldap_10a/webrev/ > > > _______________________________________________ > duckwater-discuss mailing list > duckwater-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/duckwater-discuss From julian.pullen at sun.com Thu Jun 5 10:27:43 2008 From: julian.pullen at sun.com (Julian Pullen) Date: Thu, 05 Jun 2008 18:27:43 +0100 Subject: [Duckwater-discuss] [sparks-discuss] Code-review request for Duckwater Phase 0 In-Reply-To: <4847F497.7020008@sun.com> References: <483A9DA2.9010408@sun.com> <484583FE.2000506@sun.com> <4847B33C.8020509@sun.com> <4847F497.7020008@sun.com> Message-ID: <4848220F.1050705@sun.com> Tomas, Second review of ns_confmgr.c ----------------------------- set_attr() line 262 should be 260 /* This double call is made due to the presence of */ 261 /* two sets of LDAP config. attribute names. */ 262 if (__s_api_get_profiletype(attr_name, &idx) < 0 || 263 __s_api_get_versiontype(config_struct, attr_name, &idx) < 0) { __ns_ldap_LoadDoorInfo() Lines 520-543 require some explanation of why we are doing this. (Copying a string to the end of a new stucture ldap_config_out_t and reassigning it to the original string pointer.) Regards Julian Julian Pullen wrote: > Tomas, > > Second review of ns_connect.c > ----------------------------- > > I have a style comment on ns_connect.c. > > Though out this module if it finds a connection problem you call ldap_unbind > to close the connection opened ldap connection. You don't after you have > performed an unbind set ld to NULL. The caller openConnection does not know > what has happened and has assumed that ld is valid if performBind returns success. > Someone could in error try to use an invalid ld. Setting to NULL after an unbind > would stop this from happening. You do have to pass &ld to the routine that calls > ldap_unbind. > > addConnection() line 490 should be. > > 489 sessionPool = calloc(sessionPoolSize, > 490 sizeof (Connection *)); > > line 512 should be > 511 (void) memset(cl + sessionPoolSize, 0, > 512 SESSION_CACHE_INC * sizeof (Connection *)); > > > Regards > > Julian > > > Julian Pullen wrote: >> Tomas, >> >> I have now been through all the usr/src/lib/libsldap/common/*.[ch] file >> with the exception of ns_standalone.c once. >> >> I will now look through ns_confmgr.c and ns_connect.c again. >> >> Regards >> >> Julian >> >> Julian Pullen wrote: >>> Tomas, >>> >>> Here are some comments on libsldap. >>> >>> ns_connect.c >>> ------------ >>> __s_api_requestServer() line 184. I think the code should be >>> >>> 184 if (*error != NULL) { >>> 185 (void) __ns_ldap_freeError(error); >>> 186 } >>> >>> >>> >>> createSession() line 2200. I would use an if (useSSL) and not "?" >>> to make it more readable >>> >>> >>> ns_common.c >>> ----------- >>> __s_api_copy_error() Why use calloc if you going to copy >>> the ns_ldap_error_t to the new allocated memory. >>> >>> More tomorrow. >>> >>> Regards >>> >>> Julian >>> >>> >>> >>> Tomas Heran wrote: >>>> Dear All, >>>> >>>> we'd like to request a code review of our latest changes to LDAP naming >>>> tools and infrastructure to improve connection and server management in >>>> libsldap and ldap_cachemgr(1M) and to introduce "standalone" feature to >>>> LDAP naming tools. This integration (when done) will deliver first set >>>> of features promised by Duckwater project. We call it internally >>>> Duckwater Phase 0. >>>> >>>> The information about the changes, RFEs and CRs and updated manual >>>> pages can be found here: >>>> http://www.opensolaris.org/os/project/duckwater/duckwater_phase0 >>>> >>>> The webrev with the changes is here: >>>> http://cr.opensolaris.org/~the/duckwater_phase0/ >>>> >>>> Thanks, >>>> Tomas >> _______________________________________________ >> duckwater-discuss mailing list >> duckwater-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/duckwater-discuss > _______________________________________________ > sparks-discuss mailing list > sparks-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/sparks-discuss From Serge.Dussud at Sun.COM Thu Jun 5 10:24:21 2008 From: Serge.Dussud at Sun.COM (Serge Dussud - Sun Microsystems) Date: Thu, 05 Jun 2008 19:24:21 +0200 Subject: [Duckwater-discuss] Code-review request for Duckwater Phase 0 (round 3) In-Reply-To: <48469BEA.3070804@sun.com> References: <483A9DA2.9010408@sun.com> <483EB998.1070308@Sun.COM> <4840265E.8070203@Sun.COM> <484437C8.6010203@Sun.COM> <4844BB0F.70603@sun.com> <4844ECD2.1050406@Sun.COM> <48469BEA.3070804@sun.com> Message-ID: <48482145.7020200@sun.com> >> >> Anyway, here are my main follow-up comments for now: >> >> - IIUC, is_nscd is used in several places to identify the main nscd >> (that's what your answers to SD-04 and SD-62 suggest). However, >> is_nscd is B_TRUE as well for per-user NSCD (see init_conn_mgmt()). >> Am I not understanding correctly or is there something wrong ? > > > I took a look and add comments to make it clear. I also added a new > member 'is_peruser_nscd' in ns_conn_mgmt_t, and changed code > accordingly, so it should be very clear now. thanks, it is indeed. Follow-up on your answers and recent changes to ns_connmgmt.h and ns_connmgmt.c: - related to SD-18: * ns_connmgmt.c, 566 (new files): man nscd -> main nscd - related to SD-34: that's not what I meant: in case we call free_conn_mgmt(cmg) (i.e., state is NS_CONN_MGMT_DETACHED), I think we shall set cmg to NULL before returning. But that might be useless. Also, are you sure about the new code added ? setting cmg to null whereas it's not been free'd ? - related to SD-42: typo on new line 871: conneciton -> connection - related to SD-56: 1184/1187 I don't get the rationale here. Are we saying the the server that we were given by ldap_cachemgr might be down now ? why is that ? Also, is __s_api_removeServer() about checking the status of a given server ? maybe the name shall be changed if that's the case. mc> These lines are not needed anymore. It does not work mc> the way I thought it should, so removed. Indeed ? these lines still seem to be there. Serge From Michen.Chang at Sun.COM Thu Jun 5 12:31:41 2008 From: Michen.Chang at Sun.COM (Michen.Chang at Sun.COM) Date: Thu, 05 Jun 2008 14:31:41 -0500 Subject: [Duckwater-discuss] Code-review request for Duckwater Phase 0 (round 3) In-Reply-To: <48482145.7020200@sun.com> References: <483A9DA2.9010408@sun.com> <483EB998.1070308@Sun.COM> <4840265E.8070203@Sun.COM> <484437C8.6010203@Sun.COM> <4844BB0F.70603@sun.com> <4844ECD2.1050406@Sun.COM> <48469BEA.3070804@sun.com> <48482145.7020200@sun.com> Message-ID: <48483F1D.2010703@Sun.COM> Serge Dussud - Sun Microsystems wrote: > > > >>> >>> Anyway, here are my main follow-up comments for now: >>> >>> - IIUC, is_nscd is used in several places to identify the main nscd >>> (that's what your answers to SD-04 and SD-62 suggest). However, >>> is_nscd is B_TRUE as well for per-user NSCD (see init_conn_mgmt()). >>> Am I not understanding correctly or is there something wrong ? >> >> >> I took a look and add comments to make it clear. I also added a new >> member 'is_peruser_nscd' in ns_conn_mgmt_t, and changed code >> accordingly, so it should be very clear now. > > > thanks, it is indeed. Follow-up on your answers and recent changes to > ns_connmgmt.h and ns_connmgmt.c: > > - related to SD-18: > * ns_connmgmt.c, 566 (new files): man nscd -> main nscd Thanks. Will fix. > > - related to SD-34: that's not what I meant: in case we call > free_conn_mgmt(cmg) (i.e., state is > NS_CONN_MGMT_DETACHED), I think we shall set cmg to NULL before > returning. But that might be useless. > Yes. That would be useless. > Also, are you sure about the new code added ? setting cmg to null > whereas it's not been free'd ? That would be a bug. It refcount reaches zero but the state is not NS_CONN_MGMT_DETACHED. Return NULL will help us catch the bug. > > - related to SD-42: typo on new line 871: conneciton -> connection > Thanks. Will fix. > - related to SD-56: 1184/1187 > > I don't get the rationale here. Are we saying the the server that > we were given by ldap_cachemgr might be down now ? why is that ? > > Also, is __s_api_removeServer() about checking the status of a > given server ? maybe the name shall be changed if that's the case. > > mc> These lines are not needed anymore. It does not work > mc> the way I thought it should, so removed. > > Indeed ? these lines still seem to be there. > Thanks for catching this. I meant to remove. Will remove. -- Michen From Chin-Long.Shu at Sun.COM Thu Jun 5 12:58:42 2008 From: Chin-Long.Shu at Sun.COM (Chin-Long Shu) Date: Thu, 05 Jun 2008 14:58:42 -0500 Subject: [Duckwater-discuss] [sparks-discuss] Code-review request for Duckwater Phase 0 (round 3) In-Reply-To: <1212684963.3794.103.camel@localhost.localdomain> References: <483A9DA2.9010408@sun.com> <483EB998.1070308@Sun.COM> <4840265E.8070203@Sun.COM> <484437C8.6010203@Sun.COM> <4844BB0F.70603@sun.com> <48458352.5020006@Sun.COM> <484652EA.9090605@sun.com> <1212684963.3794.103.camel@localhost.localdomain> Message-ID: <48484572.7020107@Sun.COM> Milan Jurik wrote: > Hi, > > looks good, just minors: > > usr/src/cmd/ldapcachemgr/cachemgr_getldap.c > =========================================== > [01] > 890 + int matched = FALSE, len, rc = 0; > > - still mix of initialized and uninitialized variables. By default it is > better to have one initialized variable definition per line. Or joining > only when initialized with the same value. > Will fix it. > [02] > 2880 + * this is called in removing server case. > > - BIG This ;-) > Will fix it. > usr/src/cmd/ldapcachemgr/cachemgr_change.c > ========================================== > [03] > 241 + * When the call is START op, It checks if main_nscd.pid is > 0. If it is, it > > - small "it check" ;-) > Will fix it. > [04] > 248 + * ldap_cachemgr's cookie, it door returns config change. > > - "it door" - too many words? > Will fix it. > [05] > 291 + * one at a time. If it's the > same pid > > - "once at time" ? > I did mean one door call at a time. one at a time means one by one. > [06] > > 260 + int rc = CHG_SUCCESS, thread_alive = 0; > [...] > 283 + thread_alive = 1; > [...] > 302 + while (thread_alive && > chg_main_nscd.in_progress) { > [...] > > - the only places I see local variable thread_alive - why in while loop? > > - also, the meaning of this variable isn't "thread is alive", is it? > This is an edge case when a main nscd core or is not shutdown properly and STOP op is not sent. The hanging thread is not cleaned up by periodic cleanup yet. So thread_alive should maybe another_main_nscd_thread_alive. When it's not true, don't bother to cond_wait(&chg_main_nscd_cv, &chg_main_nscd_lock);. > > > [07] > 635 + * Check if the door client making door call a nscd or > peruser nscd and output > > - missing verb? > Will fix it. > Best regards, > > Milan > > Tomas Heran p??e v St 04. 06. 2008 v 10:31 +0200: > >> I've uploaded the webrev to >> http://cr.opensolaris.org/~the/duckwater_phase0_incr_chinlong/ >> >> Tomas >> >> Chin-Long Shu wrote: >> >>> This new webrev address mainly Milan's and Nicol's comments. >>> The major chang is only main nacd can make GETSTATUSCHANGE call and the >>> logic in chg_get_statusChange() is changed accordingly. >>> The other change is the number counting code is moved to switcher so it >>> have more accurate counting. The previous code only counts START op >>> threads, but not STOP op threads. >>> >>> http://jurassic.eng/net/ns-web.sfbay/tank/panjim-export/ldap/users/chinlong/ws/new_libsldap_10a/webrev/ >>> >>> >> _______________________________________________ >> duckwater-discuss mailing list >> duckwater-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/duckwater-discuss >> > > _______________________________________________ > duckwater-discuss mailing list > duckwater-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/duckwater-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tomas.Heran at Sun.COM Thu Jun 5 13:41:58 2008 From: Tomas.Heran at Sun.COM (Tomas.Heran at Sun.COM) Date: Thu, 5 Jun 2008 13:41:58 -0700 (PDT) Subject: [Duckwater-discuss] Correct copy-n-paste error in ldaplist manpage. Message-ID: <20080605204158.AD9DA14CCC8@mail.opensolaris.org> Author: Tomas Heran Repository: /hg/duckwater/duckwater-docs Latest revision: 01f598c1fccf53cd96d2e20b6265bf5118e10309 Total changesets: 1 Log message: Correct copy-n-paste error in ldaplist manpage. Files: update: manpages/standalone_manpages/ldaplist.1.diff update: manpages/standalone_manpages/ldaplist.1.txt.standalone From Milan.Jurik at Sun.COM Fri Jun 6 00:58:10 2008 From: Milan.Jurik at Sun.COM (Milan Jurik) Date: Fri, 06 Jun 2008 09:58:10 +0200 Subject: [Duckwater-discuss] [sparks-discuss] Code-review request for Duckwater Phase 0 (round 3) In-Reply-To: <48484572.7020107@Sun.COM> References: <483A9DA2.9010408@sun.com> <483EB998.1070308@Sun.COM> <4840265E.8070203@Sun.COM> <484437C8.6010203@Sun.COM> <4844BB0F.70603@sun.com> <48458352.5020006@Sun.COM> <484652EA.9090605@sun.com> <1212684963.3794.103.camel@localhost.localdomain> <48484572.7020107@Sun.COM> Message-ID: <1212739090.3795.35.camel@localhost.localdomain> Hi, > > [06] > > > > 260 + int rc = CHG_SUCCESS, thread_alive = 0; > > [...] > > 283 + thread_alive = 1; > > [...] > > 302 + while (thread_alive && > > chg_main_nscd.in_progress) { > > [...] > > > > - the only places I see local variable thread_alive - why in while loop? > > > > - also, the meaning of this variable isn't "thread is alive", is it? > > > This is an edge case when a main nscd core or is not shutdown properly > and STOP op is not sent. The hanging thread is not cleaned up by > periodic cleanup yet. > So thread_alive should maybe another_main_nscd_thread_alive. > When it's not true, don't bother to cond_wait(&chg_main_nscd_cv, > &chg_main_nscd_lock);. > - just another_thread_alive is enough :-) - still, why it is in while loop? Isn't it just precondition to enter this while loop? Best regards, Milan From Michen.Chang at Sun.COM Fri Jun 6 06:32:32 2008 From: Michen.Chang at Sun.COM (Michen Chang) Date: Fri, 06 Jun 2008 08:32:32 -0500 Subject: [Duckwater-discuss] [sparks-discuss] Code-review request for Duckwater Phase 0 In-Reply-To: <4847F497.7020008@sun.com> References: <483A9DA2.9010408@sun.com> <484583FE.2000506@sun.com> <4847B33C.8020509@sun.com> <4847F497.7020008@sun.com> Message-ID: <48493C70.5070506@sun.com> Hi Julian, Julian Pullen wrote: > Tomas, > > Second review of ns_connect.c > ----------------------------- > > I have a style comment on ns_connect.c. > > Though out this module if it finds a connection problem you call ldap_unbind > to close the connection opened ldap connection. You don't after you have > performed an unbind set ld to NULL. The caller openConnection does not know > what has happened and has assumed that ld is valid if performBind returns success. > Someone could in error try to use an invalid ld. Setting to NULL after an unbind > would stop this from happening. You do have to pass &ld to the routine that calls > ldap_unbind. > Do you suggest we change the code now or just something to consider for future enhancement ? From what I can tell, This will not cause any problems for us unless I missed some code when looking into this. It seems that all the places in ns_connect.c, returning an error rc always happenes after a call to ldap_unbind in the performBind code path. And in openConnection(), the local ld will not be returned in *ldp if ret_code is an error one: 1390 if (ret_code == NS_LDAP_SUCCESS || 1391 ret_code == NS_LDAP_SUCCESS_WITH_INFO) { 1392 *ldp = ld; 1393 } So is there anything I missed and should be investigating more ? Please let me know. > addConnection() line 490 should be. > > 489 sessionPool = calloc(sessionPoolSize, > 490 sizeof (Connection *)); > > line 512 should be > 511 (void) memset(cl + sessionPoolSize, 0, > 512 SESSION_CACHE_INC * sizeof (Connection *)); > Will fix. Thanks, Michen > > Regards > > Julian > > > Julian Pullen wrote: > >> Tomas, >> >> I have now been through all the usr/src/lib/libsldap/common/*.[ch] file >> with the exception of ns_standalone.c once. >> >> I will now look through ns_confmgr.c and ns_connect.c again. >> >> Regards >> >> Julian >> >> Julian Pullen wrote: >> >>> Tomas, >>> >>> Here are some comments on libsldap. >>> >>> ns_connect.c >>> ------------ >>> __s_api_requestServer() line 184. I think the code should be >>> >>> 184 if (*error != NULL) { >>> 185 (void) __ns_ldap_freeError(error); >>> 186 } >>> >>> >>> >>> createSession() line 2200. I would use an if (useSSL) and not "?" >>> to make it more readable >>> >>> >>> ns_common.c >>> ----------- >>> __s_api_copy_error() Why use calloc if you going to copy >>> the ns_ldap_error_t to the new allocated memory. >>> >>> More tomorrow. >>> >>> Regards >>> >>> Julian >>> >>> >>> >>> Tomas Heran wrote: >>> >>>> Dear All, >>>> >>>> we'd like to request a code review of our latest changes to LDAP naming >>>> tools and infrastructure to improve connection and server management in >>>> libsldap and ldap_cachemgr(1M) and to introduce "standalone" feature to >>>> LDAP naming tools. This integration (when done) will deliver first set >>>> of features promised by Duckwater project. We call it internally >>>> Duckwater Phase 0. >>>> >>>> The information about the changes, RFEs and CRs and updated manual >>>> pages can be found here: >>>> http://www.opensolaris.org/os/project/duckwater/duckwater_phase0 >>>> >>>> The webrev with the changes is here: >>>> http://cr.opensolaris.org/~the/duckwater_phase0/ >>>> >>>> Thanks, >>>> Tomas >>>> >> _______________________________________________ >> duckwater-discuss mailing list >> duckwater-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/duckwater-discuss >> > _______________________________________________ > sparks-discuss mailing list > sparks-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/sparks-discuss > From julian.pullen at sun.com Fri Jun 6 07:27:21 2008 From: julian.pullen at sun.com (Julian Pullen) Date: Fri, 06 Jun 2008 15:27:21 +0100 Subject: [Duckwater-discuss] [sparks-discuss] Code-review request for Duckwater Phase 0 In-Reply-To: <48493C70.5070506@sun.com> References: <483A9DA2.9010408@sun.com> <484583FE.2000506@sun.com> <4847B33C.8020509@sun.com> <4847F497.7020008@sun.com> <48493C70.5070506@sun.com> Message-ID: <48494949.7030806@sun.com> Michen, My first comment is about style. You don't have to do it, but I recommend it. It is the same as if you free a pointer it is safest to set the pointer to NULL. You cant then use it in error. Regards Julian Michen Chang wrote: > Hi Julian, > > Julian Pullen wrote: >> Tomas, >> >> Second review of ns_connect.c >> ----------------------------- >> >> I have a style comment on ns_connect.c. >> >> Though out this module if it finds a connection problem you call ldap_unbind >> to close the connection opened ldap connection. You don't after you have >> performed an unbind set ld to NULL. The caller openConnection does not know >> what has happened and has assumed that ld is valid if performBind returns success. >> Someone could in error try to use an invalid ld. Setting to NULL after an unbind >> would stop this from happening. You do have to pass &ld to the routine that calls >> ldap_unbind. >> > > Do you suggest we change the code now or just something to consider > for future enhancement ? From what I can tell, This will not cause any > problems for us unless I missed some code when looking into this. It seems > that all the places in ns_connect.c, returning an error rc always happenes > after a call to ldap_unbind in the performBind code path. And in > openConnection(), the local ld will not be returned in *ldp if ret_code > is an error one: > > 1390 if (ret_code == NS_LDAP_SUCCESS || > 1391 ret_code == NS_LDAP_SUCCESS_WITH_INFO) { > 1392 *ldp = ld; > 1393 } > > > So is there anything I missed and should be investigating more ? > Please let me know. > >> addConnection() line 490 should be. >> >> 489 sessionPool = calloc(sessionPoolSize, >> 490 sizeof (Connection *)); >> >> line 512 should be >> 511 (void) memset(cl + sessionPoolSize, 0, >> 512 SESSION_CACHE_INC * sizeof (Connection *)); >> > > Will fix. > > Thanks, > Michen > >> Regards >> >> Julian >> >> >> Julian Pullen wrote: >> >>> Tomas, >>> >>> I have now been through all the usr/src/lib/libsldap/common/*.[ch] file >>> with the exception of ns_standalone.c once. >>> >>> I will now look through ns_confmgr.c and ns_connect.c again. >>> >>> Regards >>> >>> Julian >>> >>> Julian Pullen wrote: >>> >>>> Tomas, >>>> >>>> Here are some comments on libsldap. >>>> >>>> ns_connect.c >>>> ------------ >>>> __s_api_requestServer() line 184. I think the code should be >>>> >>>> 184 if (*error != NULL) { >>>> 185 (void) __ns_ldap_freeError(error); >>>> 186 } >>>> >>>> >>>> >>>> createSession() line 2200. I would use an if (useSSL) and not "?" >>>> to make it more readable >>>> >>>> >>>> ns_common.c >>>> ----------- >>>> __s_api_copy_error() Why use calloc if you going to copy >>>> the ns_ldap_error_t to the new allocated memory. >>>> >>>> More tomorrow. >>>> >>>> Regards >>>> >>>> Julian >>>> >>>> >>>> >>>> Tomas Heran wrote: >>>> >>>>> Dear All, >>>>> >>>>> we'd like to request a code review of our latest changes to LDAP naming >>>>> tools and infrastructure to improve connection and server management in >>>>> libsldap and ldap_cachemgr(1M) and to introduce "standalone" feature to >>>>> LDAP naming tools. This integration (when done) will deliver first set >>>>> of features promised by Duckwater project. We call it internally >>>>> Duckwater Phase 0. >>>>> >>>>> The information about the changes, RFEs and CRs and updated manual >>>>> pages can be found here: >>>>> http://www.opensolaris.org/os/project/duckwater/duckwater_phase0 >>>>> >>>>> The webrev with the changes is here: >>>>> http://cr.opensolaris.org/~the/duckwater_phase0/ >>>>> >>>>> Thanks, >>>>> Tomas >>>>> >>> _______________________________________________ >>> duckwater-discuss mailing list >>> duckwater-discuss at opensolaris.org >>> http://mail.opensolaris.org/mailman/listinfo/duckwater-discuss >>> >> _______________________________________________ >> sparks-discuss mailing list >> sparks-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/sparks-discuss >> > > _______________________________________________ > duckwater-discuss mailing list > duckwater-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/duckwater-discuss From Chin-Long.Shu at Sun.COM Fri Jun 6 08:23:06 2008 From: Chin-Long.Shu at Sun.COM (Chin-Long Shu) Date: Fri, 06 Jun 2008 10:23:06 -0500 Subject: [Duckwater-discuss] [sparks-discuss] Code-review request for Duckwater Phase 0 (round 3) In-Reply-To: <1212739090.3795.35.camel@localhost.localdomain> References: <483A9DA2.9010408@sun.com> <483EB998.1070308@Sun.COM> <4840265E.8070203@Sun.COM> <484437C8.6010203@Sun.COM> <4844BB0F.70603@sun.com> <48458352.5020006@Sun.COM> <484652EA.9090605@sun.com> <1212684963.3794.103.camel@localhost.localdomain> <48484572.7020107@Sun.COM> <1212739090.3795.35.camel@localhost.localdomain> Message-ID: <4849565A.3070005@Sun.COM> Milan Jurik wrote: > Hi, > > >>> [06] >>> >>> 260 + int rc = CHG_SUCCESS, thread_alive = 0; >>> [...] >>> 283 + thread_alive = 1; >>> [...] >>> 302 + while (thread_alive && >>> chg_main_nscd.in_progress) { >>> [...] >>> >>> - the only places I see local variable thread_alive - why in while loop? >>> >>> - also, the meaning of this variable isn't "thread is alive", is it? >>> >>> >> This is an edge case when a main nscd core or is not shutdown properly >> and STOP op is not sent. The hanging thread is not cleaned up by >> periodic cleanup yet. >> So thread_alive should maybe another_main_nscd_thread_alive. >> When it's not true, don't bother to cond_wait(&chg_main_nscd_cv, >> &chg_main_nscd_lock);. >> >> > > - just another_thread_alive is enough :-) > > - still, why it is in while loop? Isn't it just precondition to enter > this while loop? > > You're correct. I have changed it to if (another_main_nscd_thread_alive) { while (chg_main_nscd.in_progress) { ................... } } webrev refreshed > Best regards, > > Milan > > _______________________________________________ > duckwater-discuss mailing list > duckwater-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/duckwater-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Nicolas.Williams at sun.com Fri Jun 6 14:44:25 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 6 Jun 2008 16:44:25 -0500 Subject: [Duckwater-discuss] [sparks-discuss] Code-review request for Duckwater Phase 0 In-Reply-To: <20080603181000.GH2734@Sun.COM> References: <483A9DA2.9010408@sun.com> <20080602221907.GF2734@Sun.COM> <20080602224356.GL2735@Sun.COM> <20080603181000.GH2734@Sun.COM> Message-ID: <20080606214425.GR2735@Sun.COM> I've reviewed your replies to my comments. There are a few comments without replies, but I'm generally satisfied. I did add some replies though in the web page. From Tomas.Heran at Sun.COM Fri Jun 6 15:22:28 2008 From: Tomas.Heran at Sun.COM (Tomas Heran) Date: Sat, 07 Jun 2008 00:22:28 +0200 Subject: [Duckwater-discuss] Tomas' incremental webrev Message-ID: <4849B8A4.3040506@sun.com> Just for the record ... here's the incremental webrev of all the changes I made addressing people's comments: http://cr.opensolaris.org/~the/duckwater_phase0_incr_tomas/ Tomas. From Tomas.Heran at Sun.COM Mon Jun 9 02:38:37 2008 From: Tomas.Heran at Sun.COM (Tomas Heran) Date: Mon, 09 Jun 2008 11:38:37 +0200 Subject: [Duckwater-discuss] Final Duckwater Phase 0 webrev Message-ID: <484CFA1D.1040803@sun.com> Dear All, here's the final final Duckwater Phase 0 webrev: http://cr.opensolaris.org/~the/duckwater_phase0_final/ We have tried to address most of your comments and we thank you all for reviewing our new code and sending in your valuable comments - you help is most appreciated! Tomas From Tomas.Heran at Sun.COM Mon Jun 9 03:53:49 2008 From: Tomas.Heran at Sun.COM (Tomas Heran) Date: Mon, 09 Jun 2008 12:53:49 +0200 Subject: [Duckwater-discuss] Final Duckwater Phase 0 webrev In-Reply-To: <484CFA1D.1040803@sun.com> References: <484CFA1D.1040803@sun.com> Message-ID: <484D0BBD.2010000@sun.com> Upon request from a few of you, here's a webrev showing all the changes we've made as result of your comments. It has been generated using "wx webrev -p " - thanks go to Julian for telling me about this handy little trick :-) http://cr.opensolaris.org/~the/duckwater_phase0_incr/ Tomas Tomas Heran wrote: > Dear All, > > here's the final final Duckwater Phase 0 webrev: > http://cr.opensolaris.org/~the/duckwater_phase0_final/ > > We have tried to address most of your comments and we thank you all for > reviewing our new code and sending in your valuable comments - you help > is most appreciated! > > Tomas > From julian.pullen at sun.com Mon Jun 9 05:16:10 2008 From: julian.pullen at sun.com (Julian Pullen) Date: Mon, 09 Jun 2008 13:16:10 +0100 Subject: [Duckwater-discuss] Final Duckwater Phase 0 webrev In-Reply-To: <484CFA1D.1040803@sun.com> References: <484CFA1D.1040803@sun.com> Message-ID: <484D1F0A.6010400@sun.com> Tomas, I did not get any reply about my comment below. I have checked the source and it has not changed. Regards Julian Second review of ns_confmgr.c ----------------------------- set_attr() line 262 should be 260 /* This double call is made due to the presence of */ 261 /* two sets of LDAP config. attribute names. */ 262 if (__s_api_get_profiletype(attr_name, &idx) < 0 || 263 __s_api_get_versiontype(config_struct, attr_name, &idx) < 0) { Tomas Heran wrote: > Dear All, > > here's the final final Duckwater Phase 0 webrev: > http://cr.opensolaris.org/~the/duckwater_phase0_final/ > > We have tried to address most of your comments and we thank you all for > reviewing our new code and sending in your valuable comments - you help > is most appreciated! > > Tomas > From Tomas.Heran at Sun.COM Mon Jun 9 05:29:34 2008 From: Tomas.Heran at Sun.COM (Tomas Heran) Date: Mon, 09 Jun 2008 14:29:34 +0200 Subject: [Duckwater-discuss] Final Duckwater Phase 0 webrev In-Reply-To: <484D1F0A.6010400@sun.com> References: <484CFA1D.1040803@sun.com> <484D1F0A.6010400@sun.com> Message-ID: <484D222E.1080609@sun.com> Julian Pullen wrote: > Tomas, > > I did not get any reply about my comment below. I have checked the > source and it has not changed. > > Regards > > Julian > > Second review of ns_confmgr.c > ----------------------------- > > set_attr() line 262 should be > > 260 /* This double call is made due to the presence of */ > 261 /* two sets of LDAP config. attribute names. */ > 262 if (__s_api_get_profiletype(attr_name, &idx) < 0 || > 263 __s_api_get_versiontype(config_struct, attr_name, &idx) > < 0) { We must've missed it. Sorry about that. We probably don't have time to fix it now, but will fix it as a separate CR. Tomas From Milan.Jurik at Sun.COM Mon Jun 9 06:00:23 2008 From: Milan.Jurik at Sun.COM (Milan Jurik) Date: Mon, 09 Jun 2008 15:00:23 +0200 Subject: [Duckwater-discuss] Final Duckwater Phase 0 webrev In-Reply-To: <484D222E.1080609@sun.com> References: <484CFA1D.1040803@sun.com> <484D1F0A.6010400@sun.com> <484D222E.1080609@sun.com> Message-ID: <1213016423.3784.110.camel@localhost.localdomain> Hi Tomas, Tomas Heran p??e v Po 09. 06. 2008 v 14:29 +0200: > > Julian Pullen wrote: > > Tomas, > > > > I did not get any reply about my comment below. I have checked the > > source and it has not changed. > > > > Regards > > > > Julian > > > > Second review of ns_confmgr.c > > ----------------------------- > > > > set_attr() line 262 should be > > > > 260 /* This double call is made due to the presence of */ > > 261 /* two sets of LDAP config. attribute names. */ > > 262 if (__s_api_get_profiletype(attr_name, &idx) < 0 || > > 263 __s_api_get_versiontype(config_struct, attr_name, &idx) > > < 0) { > > We must've missed it. Sorry about that. We probably don't have time to > fix it now, but will fix it as a separate CR. > What time? Are we under time pressure? When? Why? It is not acceptable to putback something where we know about CRs already (I agreed with one my RFE case, code refactoring, but not in this case). This one is very simple to fix and I see no reason for putback. And btw. I see e.g. that even comment is not formatted as it should be. Actually if it will not be fixed before RTI, please, remove my name from code reviewers list. Best regards, Milan From Chin-Long.Shu at Sun.COM Mon Jun 9 06:10:00 2008 From: Chin-Long.Shu at Sun.COM (Chin-Long Shu) Date: Mon, 09 Jun 2008 08:10:00 -0500 Subject: [Duckwater-discuss] Final Duckwater Phase 0 webrev In-Reply-To: <484D1F0A.6010400@sun.com> References: <484CFA1D.1040803@sun.com> <484D1F0A.6010400@sun.com> Message-ID: <484D2BA8.1020005@sun.com> I added reply to the web page for your another comment on ns_confmgr.c w.r.t. __ns_ldap_LoadDoorInfo. Julian Pullen wrote: > Tomas, > > I did not get any reply about my comment below. I have checked the > source and it has not changed. > > Regards > > Julian > > Second review of ns_confmgr.c > ----------------------------- > > set_attr() line 262 should be > > 260 /* This double call is made due to the presence of */ > 261 /* two sets of LDAP config. attribute names. */ > 262 if (__s_api_get_profiletype(attr_name, &idx) < 0 || > 263 __s_api_get_versiontype(config_struct, attr_name, &idx) < 0) { > > > Tomas Heran wrote: > >> Dear All, >> >> here's the final final Duckwater Phase 0 webrev: >> http://cr.opensolaris.org/~the/duckwater_phase0_final/ >> >> We have tried to address most of your comments and we thank you all for >> reviewing our new code and sending in your valuable comments - you help >> is most appreciated! >> >> Tomas >> >> > _______________________________________________ > duckwater-discuss mailing list > duckwater-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/duckwater-discuss > From julian.pullen at sun.com Mon Jun 9 06:15:28 2008 From: julian.pullen at sun.com (Julian Pullen) Date: Mon, 09 Jun 2008 14:15:28 +0100 Subject: [Duckwater-discuss] Final Duckwater Phase 0 webrev In-Reply-To: <1213016423.3784.110.camel@localhost.localdomain> References: <484CFA1D.1040803@sun.com> <484D1F0A.6010400@sun.com> <484D222E.1080609@sun.com> <1213016423.3784.110.camel@localhost.localdomain> Message-ID: <484D2CF0.4060806@sun.com> Milan, The I have spoken to Tomas about the bug and we think it is very unlikely to happen. The bug will be recorded via a CR. We are trying to get the software back in the current build. I don't like changing things at last minute. We would rather fix the bug after the current build. Regards Julian Milan Jurik wrote: > Hi Tomas, > > Tomas Heran p??e v Po 09. 06. 2008 v 14:29 +0200: >> Julian Pullen wrote: >>> Tomas, >>> >>> I did not get any reply about my comment below. I have checked the >>> source and it has not changed. >>> >>> Regards >>> >>> Julian >>> >>> Second review of ns_confmgr.c >>> ----------------------------- >>> >>> set_attr() line 262 should be >>> >>> 260 /* This double call is made due to the presence of */ >>> 261 /* two sets of LDAP config. attribute names. */ >>> 262 if (__s_api_get_profiletype(attr_name, &idx) < 0 || >>> 263 __s_api_get_versiontype(config_struct, attr_name, &idx) >>> < 0) { >> We must've missed it. Sorry about that. We probably don't have time to >> fix it now, but will fix it as a separate CR. >> > > What time? Are we under time pressure? When? Why? It is not acceptable > to putback something where we know about CRs already (I agreed with one > my RFE case, code refactoring, but not in this case). This one is very > simple to fix and I see no reason for putback. > > And btw. I see e.g. that even comment is not formatted as it should be. > > Actually if it will not be fixed before RTI, please, remove my name from > code reviewers list. > > Best regards, > > Milan > From Milan.Jurik at Sun.COM Mon Jun 9 06:31:35 2008 From: Milan.Jurik at Sun.COM (Milan Jurik) Date: Mon, 09 Jun 2008 15:31:35 +0200 Subject: [Duckwater-discuss] Final Duckwater Phase 0 webrev In-Reply-To: <484D2CF0.4060806@sun.com> References: <484CFA1D.1040803@sun.com> <484D1F0A.6010400@sun.com> <484D222E.1080609@sun.com> <1213016423.3784.110.camel@localhost.localdomain> <484D2CF0.4060806@sun.com> Message-ID: <1213018295.3784.124.camel@localhost.localdomain> Julian, Julian Pullen p??e v Po 09. 06. 2008 v 14:15 +0100: > Milan, > > The I have spoken to Tomas about the bug and we think it is very > unlikely to happen. The bug will be recorded via a CR. We are trying > to get the software back in the current build. I don't like changing > things at last minute. We would rather fix the bug after the current > build. > Actually I know it is low priority but I also see it's very simple fix. So it will give 1 day delay at most. And I see no reason to go to build 92 just because 92 is closing today. We were under time pressure from development team for code review, many things should be reviewed more and now we know about CRs even before RTI. That's strange. We are speaking about 13+ lines affecting a lot of from LDAP client. And we see open questions even few minutes before RTI. Just an example - some people are saying that our code review process is better than widely known Unix-like kernel "code review process". But they are not ignoring known bugs in submitted patches (yet). Best regards, Milan > > Regards > > Julian > > Milan Jurik wrote: > > Hi Tomas, > > > > Tomas Heran p??e v Po 09. 06. 2008 v 14:29 +0200: > >> Julian Pullen wrote: > >>> Tomas, > >>> > >>> I did not get any reply about my comment below. I have checked the > >>> source and it has not changed. > >>> > >>> Regards > >>> > >>> Julian > >>> > >>> Second review of ns_confmgr.c > >>> ----------------------------- > >>> > >>> set_attr() line 262 should be > >>> > >>> 260 /* This double call is made due to the presence of */ > >>> 261 /* two sets of LDAP config. attribute names. */ > >>> 262 if (__s_api_get_profiletype(attr_name, &idx) < 0 || > >>> 263 __s_api_get_versiontype(config_struct, attr_name, &idx) > >>> < 0) { > >> We must've missed it. Sorry about that. We probably don't have time to > >> fix it now, but will fix it as a separate CR. > >> > > > > What time? Are we under time pressure? When? Why? It is not acceptable > > to putback something where we know about CRs already (I agreed with one > > my RFE case, code refactoring, but not in this case). This one is very > > simple to fix and I see no reason for putback. > > > > And btw. I see e.g. that even comment is not formatted as it should be. > > > > Actually if it will not be fixed before RTI, please, remove my name from > > code reviewers list. > > > > Best regards, > > > > Milan > > From Serge.Dussud at Sun.COM Mon Jun 9 06:34:16 2008 From: Serge.Dussud at Sun.COM (Serge Dussud) Date: Mon, 09 Jun 2008 15:34:16 +0200 Subject: [Duckwater-discuss] Code-review request for Duckwater Phase 0 (round 3) In-Reply-To: <48483F1D.2010703@Sun.COM> References: <483A9DA2.9010408@sun.com> <483EB998.1070308@Sun.COM> <4840265E.8070203@Sun.COM> <484437C8.6010203@Sun.COM> <4844BB0F.70603@sun.com> <4844ECD2.1050406@Sun.COM> <48469BEA.3070804@sun.com> <48482145.7020200@sun.com> <48483F1D.2010703@Sun.COM> Message-ID: <484D3158.1010402@Sun.COM> Following-up on the remaining comments: I don't see any answer to SD-97, SD-98. SD-103: __s_api_make_error() and MKERROR: could you open a CR so that we do not forget to combine both in a soon future ? Serge Michen.Chang at Sun.COM wrote: > Serge Dussud - Sun Microsystems wrote: >> >> >> >>>> >>>> Anyway, here are my main follow-up comments for now: >>>> >>>> - IIUC, is_nscd is used in several places to identify the main nscd >>>> (that's what your answers to SD-04 and SD-62 suggest). However, >>>> is_nscd is B_TRUE as well for per-user NSCD (see init_conn_mgmt()). >>>> Am I not understanding correctly or is there something wrong ? >>> >>> >>> I took a look and add comments to make it clear. I also added a new >>> member 'is_peruser_nscd' in ns_conn_mgmt_t, and changed code >>> accordingly, so it should be very clear now. >> >> >> thanks, it is indeed. Follow-up on your answers and recent changes to >> ns_connmgmt.h and ns_connmgmt.c: >> >> - related to SD-18: >> * ns_connmgmt.c, 566 (new files): man nscd -> main nscd > > Thanks. Will fix. > >> >> - related to SD-34: that's not what I meant: in case we call >> free_conn_mgmt(cmg) (i.e., state is >> NS_CONN_MGMT_DETACHED), I think we shall set cmg to NULL before >> returning. But that might be useless. >> > > Yes. That would be useless. > > >> Also, are you sure about the new code added ? setting cmg to null >> whereas it's not been free'd ? > > That would be a bug. It refcount reaches zero but the state is not > NS_CONN_MGMT_DETACHED. Return NULL will help us > catch the bug. > >> >> - related to SD-42: typo on new line 871: conneciton -> connection >> > > Thanks. Will fix. > >> - related to SD-56: 1184/1187 >> >> I don't get the rationale here. Are we saying the the server that >> we were given by ldap_cachemgr might be down now ? why is that ? >> >> Also, is __s_api_removeServer() about checking the status of a >> given server ? maybe the name shall be changed if that's the case. >> >> mc> These lines are not needed anymore. It does not work >> mc> the way I thought it should, so removed. >> >> Indeed ? these lines still seem to be there. >> > > Thanks for catching this. I meant to remove. Will remove. > > -- > Michen > From Tomas.Heran at Sun.COM Mon Jun 9 07:55:19 2008 From: Tomas.Heran at Sun.COM (Tomas Heran) Date: Mon, 09 Jun 2008 16:55:19 +0200 Subject: [Duckwater-discuss] Code-review request for Duckwater Phase 0 (round 3) In-Reply-To: <484D3158.1010402@Sun.COM> References: <483A9DA2.9010408@sun.com> <483EB998.1070308@Sun.COM> <4840265E.8070203@Sun.COM> <484437C8.6010203@Sun.COM> <4844BB0F.70603@sun.com> <4844ECD2.1050406@Sun.COM> <48469BEA.3070804@sun.com> <48482145.7020200@sun.com> <48483F1D.2010703@Sun.COM> <484D3158.1010402@Sun.COM> Message-ID: <484D4457.9070602@sun.com> Serge Dussud wrote: > Following-up on the remaining comments: > > I don't see any answer to SD-97, SD-98. SD-97: why do we depend on libresolv ? Tomas: libresolv is not needed actually. SD-98: what is C99MODE about ? to which CR fix does it apply ? Tomas: C99MODE is not needed really (well, if the "inline" hint is not used in the code, which IMO, it is not needed either). Also, C99MODE is used usr/src/cmd/ldap - for ldaplist, ldapaddent and ldapclient. And it's not needed there either. Both of these are "copy-n-paste" between Duckwater-all gate and Duckwater-phase0. In Duckwater-all gate, I believe both are needed. We'll be discussing shortly when and how to address these. Tomas From Michen.Chang at Sun.COM Mon Jun 9 08:01:51 2008 From: Michen.Chang at Sun.COM (Michen Chang) Date: Mon, 09 Jun 2008 10:01:51 -0500 Subject: [Duckwater-discuss] Code-review request for Duckwater Phase 0 (round 3) In-Reply-To: <484D3158.1010402@Sun.COM> References: <483A9DA2.9010408@sun.com> <483EB998.1070308@Sun.COM> <4840265E.8070203@Sun.COM> <484437C8.6010203@Sun.COM> <4844BB0F.70603@sun.com> <4844ECD2.1050406@Sun.COM> <48469BEA.3070804@sun.com> <48482145.7020200@sun.com> <48483F1D.2010703@Sun.COM> <484D3158.1010402@Sun.COM> Message-ID: <484D45DF.1010903@sun.com> Serge Dussud wrote: > Following-up on the remaining comments: > > I don't see any answer to SD-97, SD-98. > I have requested Igor to answer but he is traveling. Tomas will answer your questions. > SD-103: __s_api_make_error() and MKERROR: could you open a CR so that we > do not forget to combine both in a soon future ? > I will file a low priority RFE after putback. I can not log a CR for code not yet integrated yet. Thanks for reviewing, Michen > Serge > > > Michen.Chang at Sun.COM wrote: > >> Serge Dussud - Sun Microsystems wrote: >> >>> >>> >>>>> Anyway, here are my main follow-up comments for now: >>>>> >>>>> - IIUC, is_nscd is used in several places to identify the main nscd >>>>> (that's what your answers to SD-04 and SD-62 suggest). However, >>>>> is_nscd is B_TRUE as well for per-user NSCD (see init_conn_mgmt()). >>>>> Am I not understanding correctly or is there something wrong ? >>>>> >>>> I took a look and add comments to make it clear. I also added a new >>>> member 'is_peruser_nscd' in ns_conn_mgmt_t, and changed code >>>> accordingly, so it should be very clear now. >>>> >>> thanks, it is indeed. Follow-up on your answers and recent changes to >>> ns_connmgmt.h and ns_connmgmt.c: >>> >>> - related to SD-18: >>> * ns_connmgmt.c, 566 (new files): man nscd -> main nscd >>> >> Thanks. Will fix. >> >> >>> - related to SD-34: that's not what I meant: in case we call >>> free_conn_mgmt(cmg) (i.e., state is >>> NS_CONN_MGMT_DETACHED), I think we shall set cmg to NULL before >>> returning. But that might be useless. >>> >>> >> Yes. That would be useless. >> >> >> >>> Also, are you sure about the new code added ? setting cmg to null >>> whereas it's not been free'd ? >>> >> That would be a bug. It refcount reaches zero but the state is not >> NS_CONN_MGMT_DETACHED. Return NULL will help us >> catch the bug. >> >> >>> - related to SD-42: typo on new line 871: conneciton -> connection >>> >>> >> Thanks. Will fix. >> >> >>> - related to SD-56: 1184/1187 >>> >>> I don't get the rationale here. Are we saying the the server that >>> we were given by ldap_cachemgr might be down now ? why is that ? >>> >>> Also, is __s_api_removeServer() about checking the status of a >>> given server ? maybe the name shall be changed if that's the case. >>> >>> mc> These lines are not needed anymore. It does not work >>> mc> the way I thought it should, so removed. >>> >>> Indeed ? these lines still seem to be there. >>> >>> >> Thanks for catching this. I meant to remove. Will remove. >> >> -- >> Michen >> >> > _______________________________________________ > duckwater-discuss mailing list > duckwater-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/duckwater-discuss > From Chin-Long.Shu at Sun.COM Mon Jun 9 08:50:39 2008 From: Chin-Long.Shu at Sun.COM (Chin-Long Shu) Date: Mon, 09 Jun 2008 10:50:39 -0500 Subject: [Duckwater-discuss] Final Duckwater Phase 0 webrev In-Reply-To: <484D2CF0.4060806@sun.com> References: <484CFA1D.1040803@sun.com> <484D1F0A.6010400@sun.com> <484D222E.1080609@sun.com> <1213016423.3784.110.camel@localhost.localdomain> <484D2CF0.4060806@sun.com> Message-ID: <484D514F.3080606@Sun.COM> I looked into the code again and it's a very confusing one but I don't think it's a bug. Please see SD-108 of Serge's comment and Igor's answer in the opensoalris.org webpage. Also some background info in SD-110. http://opensolaris.org/os/project/duckwater/duckwater_phase0/codereview/serge_libsldap/ It's meant to be if (-A && -B) { ......... return (NS_LDAP_CONFIG); } So A is true || B is TRUE is fine. Change it to (-A || -B) will make it return error when A is false and B is true when it's OK. Julian Pullen wrote: > Milan, > > The I have spoken to Tomas about the bug and we think it is very > unlikely to happen. The bug will be recorded via a CR. We are trying > to get the software back in the current build. I don't like changing > things at last minute. We would rather fix the bug after the current > build. > > > Regards > > Julian > > Milan Jurik wrote: > >> Hi Tomas, >> >> Tomas Heran p??e v Po 09. 06. 2008 v 14:29 +0200: >> >>> Julian Pullen wrote: >>> >>>> Tomas, >>>> >>>> I did not get any reply about my comment below. I have checked the >>>> source and it has not changed. >>>> >>>> Regards >>>> >>>> Julian >>>> >>>> Second review of ns_confmgr.c >>>> ----------------------------- >>>> >>>> set_attr() line 262 should be >>>> >>>> 260 /* This double call is made due to the presence of */ >>>> 261 /* two sets of LDAP config. attribute names. */ >>>> 262 if (__s_api_get_profiletype(attr_name, &idx) < 0 || >>>> 263 __s_api_get_versiontype(config_struct, attr_name, &idx) >>>> < 0) { >>>> >>> We must've missed it. Sorry about that. We probably don't have time to >>> fix it now, but will fix it as a separate CR. >>> >>> >> What time? Are we under time pressure? When? Why? It is not acceptable >> to putback something where we know about CRs already (I agreed with one >> my RFE case, code refactoring, but not in this case). This one is very >> simple to fix and I see no reason for putback. >> >> And btw. I see e.g. that even comment is not formatted as it should be. >> >> Actually if it will not be fixed before RTI, please, remove my name from >> code reviewers list. >> >> Best regards, >> >> Milan >> >> > _______________________________________________ > duckwater-discuss mailing list > duckwater-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/duckwater-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Milan.Jurik at Sun.COM Mon Jun 9 09:05:56 2008 From: Milan.Jurik at Sun.COM (Milan Jurik) Date: Mon, 09 Jun 2008 18:05:56 +0200 Subject: [Duckwater-discuss] Final Duckwater Phase 0 webrev In-Reply-To: <484D514F.3080606@Sun.COM> References: <484CFA1D.1040803@sun.com> <484D1F0A.6010400@sun.com> <484D222E.1080609@sun.com> <1213016423.3784.110.camel@localhost.localdomain> <484D2CF0.4060806@sun.com> <484D514F.3080606@Sun.COM> Message-ID: <1213027556.3784.164.camel@localhost.localdomain> Hi, Chin-Long Shu p??e v Po 09. 06. 2008 v 10:50 -0500: > I looked into the code again and it's a very confusing one but I don't > think it's a bug. > Please see SD-108 of Serge's comment and Igor's answer in the > opensoalris.org webpage. Also some background info in SD-110. > http://opensolaris.org/os/project/duckwater/duckwater_phase0/codereview/serge_libsldap/ > > It's meant to be > if (-A && -B) { > ......... > return (NS_LDAP_CONFIG); > } > So A is true || B is TRUE is fine. > > Change it to (-A || -B) will make it return error when A is false and > B is true when it's OK. > But what about opposite, just B is false and A is true ? Is it valid? Anyway, it needs to be fixed in comment (but that wouldn't stop RTI because it wouldn't have impact on source code). Best regards, Milan > > > Julian Pullen wrote: > > Milan, > > > > The I have spoken to Tomas about the bug and we think it is very > > unlikely to happen. The bug will be recorded via a CR. We are trying > > to get the software back in the current build. I don't like changing > > things at last minute. We would rather fix the bug after the current > > build. > > > > > > Regards > > > > Julian > > > > Milan Jurik wrote: > > > > > Hi Tomas, > > > > > > Tomas Heran p??e v Po 09. 06. 2008 v 14:29 +0200: > > > > > > > Julian Pullen wrote: > > > > > > > > > Tomas, > > > > > > > > > > I did not get any reply about my comment below. I have checked the > > > > > source and it has not changed. > > > > > > > > > > Regards > > > > > > > > > > Julian > > > > > > > > > > Second review of ns_confmgr.c > > > > > ----------------------------- > > > > > > > > > > set_attr() line 262 should be > > > > > > > > > > 260 /* This double call is made due to the presence of */ > > > > > 261 /* two sets of LDAP config. attribute names. */ > > > > > 262 if (__s_api_get_profiletype(attr_name, &idx) < 0 || > > > > > 263 __s_api_get_versiontype(config_struct, attr_name, &idx) > > > > > < 0) { > > > > > > > > > We must've missed it. Sorry about that. We probably don't have time to > > > > fix it now, but will fix it as a separate CR. > > > > > > > > > > > What time? Are we under time pressure? When? Why? It is not acceptable > > > to putback something where we know about CRs already (I agreed with one > > > my RFE case, code refactoring, but not in this case). This one is very > > > simple to fix and I see no reason for putback. > > > > > > And btw. I see e.g. that even comment is not formatted as it should be. > > > > > > Actually if it will not be fixed before RTI, please, remove my name from > > > code reviewers list. > > > > > > Best regards, > > > > > > Milan > > > > > > > > _______________________________________________ > > duckwater-discuss mailing list > > duckwater-discuss at opensolaris.org > > http://mail.opensolaris.org/mailman/listinfo/duckwater-discuss > > > From Chin-Long.Shu at Sun.COM Mon Jun 9 09:16:22 2008 From: Chin-Long.Shu at Sun.COM (Chin-Long Shu) Date: Mon, 09 Jun 2008 11:16:22 -0500 Subject: [Duckwater-discuss] Final Duckwater Phase 0 webrev In-Reply-To: <1213027556.3784.164.camel@localhost.localdomain> References: <484CFA1D.1040803@sun.com> <484D1F0A.6010400@sun.com> <484D222E.1080609@sun.com> <1213016423.3784.110.camel@localhost.localdomain> <484D2CF0.4060806@sun.com> <484D514F.3080606@Sun.COM> <1213027556.3784.164.camel@localhost.localdomain> Message-ID: <484D5756.2010200@Sun.COM> Milan Jurik wrote: > Hi, > > Chin-Long Shu p??e v Po 09. 06. 2008 v 10:50 -0500: > >> I looked into the code again and it's a very confusing one but I don't >> think it's a bug. >> Please see SD-108 of Serge's comment and Igor's answer in the >> opensoalris.org webpage. Also some background info in SD-110. >> http://opensolaris.org/os/project/duckwater/duckwater_phase0/codereview/serge_libsldap/ >> >> It's meant to be >> if (-A && -B) { >> ......... >> return (NS_LDAP_CONFIG); >> } >> So A is true || B is TRUE is fine. >> >> Change it to (-A || -B) will make it return error when A is false and >> B is true when it's OK. >> >> > > But what about opposite, just B is false and A is true ? Is it valid? > Anyway, it needs to be fixed in comment (but that wouldn't stop RTI > because it wouldn't have impact on source code). > It's still valid. > Best regards, > > Milan > > >> Julian Pullen wrote: >> >>> Milan, >>> >>> The I have spoken to Tomas about the bug and we think it is very >>> unlikely to happen. The bug will be recorded via a CR. We are trying >>> to get the software back in the current build. I don't like changing >>> things at last minute. We would rather fix the bug after the current >>> build. >>> >>> >>> Regards >>> >>> Julian >>> >>> Milan Jurik wrote: >>> >>> >>>> Hi Tomas, >>>> >>>> Tomas Heran p??e v Po 09. 06. 2008 v 14:29 +0200: >>>> >>>> >>>>> Julian Pullen wrote: >>>>> >>>>> >>>>>> Tomas, >>>>>> >>>>>> I did not get any reply about my comment below. I have checked the >>>>>> source and it has not changed. >>>>>> >>>>>> Regards >>>>>> >>>>>> Julian >>>>>> >>>>>> Second review of ns_confmgr.c >>>>>> ----------------------------- >>>>>> >>>>>> set_attr() line 262 should be >>>>>> >>>>>> 260 /* This double call is made due to the presence of */ >>>>>> 261 /* two sets of LDAP config. attribute names. */ >>>>>> 262 if (__s_api_get_profiletype(attr_name, &idx) < 0 || >>>>>> 263 __s_api_get_versiontype(config_struct, attr_name, &idx) >>>>>> < 0) { >>>>>> >>>>>> >>>>> We must've missed it. Sorry about that. We probably don't have time to >>>>> fix it now, but will fix it as a separate CR. >>>>> >>>>> >>>>> >>>> What time? Are we under time pressure? When? Why? It is not acceptable >>>> to putback something where we know about CRs already (I agreed with one >>>> my RFE case, code refactoring, but not in this case). This one is very >>>> simple to fix and I see no reason for putback. >>>> >>>> And btw. I see e.g. that even comment is not formatted as it should be. >>>> >>>> Actually if it will not be fixed before RTI, please, remove my name from >>>> code reviewers list. >>>> >>>> Best regards, >>>> >>>> Milan >>>> >>>> >>>> >>> _______________________________________________ >>> duckwater-discuss mailing list >>> duckwater-discuss at opensolaris.org >>> http://mail.opensolaris.org/mailman/listinfo/duckwater-discuss >>> >>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Milan.Jurik at Sun.COM Mon Jun 9 09:37:27 2008 From: Milan.Jurik at Sun.COM (Milan Jurik) Date: Mon, 09 Jun 2008 18:37:27 +0200 Subject: [Duckwater-discuss] Final Duckwater Phase 0 webrev In-Reply-To: <484D5756.2010200@Sun.COM> References: <484CFA1D.1040803@sun.com> <484D1F0A.6010400@sun.com> <484D222E.1080609@sun.com> <1213016423.3784.110.camel@localhost.localdomain> <484D2CF0.4060806@sun.com> <484D514F.3080606@Sun.COM> <1213027556.3784.164.camel@localhost.localdomain> <484D5756.2010200@Sun.COM> Message-ID: <1213029447.3784.176.camel@localhost.localdomain> Hi Chin-long, Chin-Long Shu p??e v Po 09. 06. 2008 v 11:16 -0500: > Milan Jurik wrote: > > Hi, > > > > Chin-Long Shu p??e v Po 09. 06. 2008 v 10:50 -0500: > > > > > I looked into the code again and it's a very confusing one but I don't > > > think it's a bug. > > > Please see SD-108 of Serge's comment and Igor's answer in the > > > opensoalris.org webpage. Also some background info in SD-110. > > > http://opensolaris.org/os/project/duckwater/duckwater_phase0/codereview/serge_libsldap/ > > > > > > It's meant to be > > > if (-A && -B) { > > > ......... > > > return (NS_LDAP_CONFIG); > > > } > > > So A is true || B is TRUE is fine. > > > > > > Change it to (-A || -B) will make it return error when A is false and > > > B is true when it's OK. > > > > > > > > > > But what about opposite, just B is false and A is true ? Is it valid? > > Anyway, it needs to be fixed in comment (but that wouldn't stop RTI > > because it wouldn't have impact on source code). > > > It's still valid. More time spent on the evaluation and yes, you are right, just in case we didn't pass both of them, we have issue. Ufff, Tomas, fix the comment, please :-) So, we have few RFEs around code, these should be logged asap. Any other comment missed? I'm not sure I will be able to pass through finel incremental today, but I could try. Best regards, Milan From Tomas.Heran at Sun.COM Mon Jun 9 09:56:07 2008 From: Tomas.Heran at Sun.COM (Tomas Heran) Date: Mon, 09 Jun 2008 18:56:07 +0200 Subject: [Duckwater-discuss] Final Duckwater Phase 0 webrev In-Reply-To: <1213029447.3784.176.camel@localhost.localdomain> References: <484CFA1D.1040803@sun.com> <484D1F0A.6010400@sun.com> <484D222E.1080609@sun.com> <1213016423.3784.110.camel@localhost.localdomain> <484D2CF0.4060806@sun.com> <484D514F.3080606@Sun.COM> <1213027556.3784.164.camel@localhost.localdomain> <484D5756.2010200@Sun.COM> <1213029447.3784.176.camel@localhost.localdomain> Message-ID: <484D60A7.60109@sun.com> There are a few pending changes which we will address as soon as possible (tomorrow hopefully). These include: - SD-97 - will require small change in Makefile - SD-98 - small change in Makefile and a few changes in code - SD-108 (same issue in set_attr Julian pointed out) - comment change - SD-82 - Michen believes this should be OK ... is being discussed between Michen and Serge Is there anything else I left out? Once we're done, I'll send a webrev just for those as well as update the final webrev. Tomas Milan Jurik wrote: > > So, we have few RFEs around code, these should be logged asap. Any other > comment missed? I'm not sure I will be able to pass through finel > incremental today, but I could try. > From Tomas.Heran at Sun.COM Mon Jun 9 14:12:37 2008 From: Tomas.Heran at Sun.COM (Tomas Heran) Date: Mon, 09 Jun 2008 23:12:37 +0200 Subject: [Duckwater-discuss] Final Duckwater Phase 0 webrev In-Reply-To: <484D60A7.60109@sun.com> References: <484CFA1D.1040803@sun.com> <484D1F0A.6010400@sun.com> <484D222E.1080609@sun.com> <1213016423.3784.110.camel@localhost.localdomain> <484D2CF0.4060806@sun.com> <484D514F.3080606@Sun.COM> <1213027556.3784.164.camel@localhost.localdomain> <484D5756.2010200@Sun.COM> <1213029447.3784.176.camel@localhost.localdomain> <484D60A7.60109@sun.com> Message-ID: <484D9CC5.8060309@sun.com> So, Michen and Chin-Long did the changes already, so here's the incremental webrev - it's been generated by, so there's pretty much all of the files without any change, but I'm sure you'll be able to plough through it (ns_standalone.c, ns_connmgmt.c, ns_confmgr.c and libsldap/Makefile.com): http://cr.opensolaris.org/~the/duckwater_phase0_incr_jun_09/ OK with you, Serge? Final (now I really mean it) all changes vs. onnv webrev is here: http://cr.opensolaris.org/~the/duckwater_phase0_final/ Tomas Tomas Heran wrote: > There are a few pending changes which we will address as soon as > possible (tomorrow hopefully). These include: > > - SD-97 - will require small change in Makefile > - SD-98 - small change in Makefile and a few changes in code > - SD-108 (same issue in set_attr Julian pointed out) - comment change > - SD-82 - Michen believes this should be OK ... is being discussed > between Michen and Serge > > Is there anything else I left out? > > Once we're done, I'll send a webrev just for those as well as update > the final webrev. > > Tomas > > Milan Jurik wrote: >> So, we have few RFEs around code, these should be logged asap. Any other >> comment missed? I'm not sure I will be able to pass through finel >> incremental today, but I could try. >> > > _______________________________________________ > duckwater-discuss mailing list > duckwater-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/duckwater-discuss From julian.pullen at sun.com Tue Jun 10 02:30:15 2008 From: julian.pullen at sun.com (Julian Pullen) Date: Tue, 10 Jun 2008 10:30:15 +0100 Subject: [Duckwater-discuss] Final Duckwater Phase 0 webrev In-Reply-To: <1213029447.3784.176.camel@localhost.localdomain> References: <484CFA1D.1040803@sun.com> <484D1F0A.6010400@sun.com> <484D222E.1080609@sun.com> <1213016423.3784.110.camel@localhost.localdomain> <484D2CF0.4060806@sun.com> <484D514F.3080606@Sun.COM> <1213027556.3784.164.camel@localhost.localdomain> <484D5756.2010200@Sun.COM> <1213029447.3784.176.camel@localhost.localdomain> Message-ID: <484E49A7.2020208@sun.com> Chin-Long, If the current code is correct then it requires a comment to that attr_name can be either of these 2 fields. Regards Julian Milan Jurik wrote: > Hi Chin-long, > > Chin-Long Shu p??e v Po 09. 06. 2008 v 11:16 -0500: >> Milan Jurik wrote: >>> Hi, >>> >>> Chin-Long Shu p??e v Po 09. 06. 2008 v 10:50 -0500: >>> >>>> I looked into the code again and it's a very confusing one but I don't >>>> think it's a bug. >>>> Please see SD-108 of Serge's comment and Igor's answer in the >>>> opensoalris.org webpage. Also some background info in SD-110. >>>> http://opensolaris.org/os/project/duckwater/duckwater_phase0/codereview/serge_libsldap/ >>>> >>>> It's meant to be >>>> if (-A && -B) { >>>> ......... >>>> return (NS_LDAP_CONFIG); >>>> } >>>> So A is true || B is TRUE is fine. >>>> >>>> Change it to (-A || -B) will make it return error when A is false and >>>> B is true when it's OK. >>>> >>>> >>> But what about opposite, just B is false and A is true ? Is it valid? >>> Anyway, it needs to be fixed in comment (but that wouldn't stop RTI >>> because it wouldn't have impact on source code). >>> >> It's still valid. > > More time spent on the evaluation and yes, you are right, just in case > we didn't pass both of them, we have issue. Ufff, Tomas, fix the > comment, please :-) > > So, we have few RFEs around code, these should be logged asap. Any other > comment missed? I'm not sure I will be able to pass through finel > incremental today, but I could try. > > Best regards, > > Milan > > _______________________________________________ > duckwater-discuss mailing list > duckwater-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/duckwater-discuss > From Tomas.Heran at Sun.COM Tue Jun 10 02:32:45 2008 From: Tomas.Heran at Sun.COM (Tomas Heran) Date: Tue, 10 Jun 2008 11:32:45 +0200 Subject: [Duckwater-discuss] Final Duckwater Phase 0 webrev In-Reply-To: <484E49A7.2020208@sun.com> References: <484CFA1D.1040803@sun.com> <484D1F0A.6010400@sun.com> <484D222E.1080609@sun.com> <1213016423.3784.110.camel@localhost.localdomain> <484D2CF0.4060806@sun.com> <484D514F.3080606@Sun.COM> <1213027556.3784.164.camel@localhost.localdomain> <484D5756.2010200@Sun.COM> <1213029447.3784.176.camel@localhost.localdomain> <484E49A7.2020208@sun.com> Message-ID: <484E4A3D.9060408@sun.com> Julian, Chin-Long already updated the comment and you can see it in the incremental webrev as well as in the final webrev I sent later yesterday. Tomas Julian Pullen wrote: > Chin-Long, > > If the current code is correct then it requires a comment to > that attr_name can be either of these 2 fields. > > Regards > > Julian > > Milan Jurik wrote: >> Hi Chin-long, >> >> Chin-Long Shu p??e v Po 09. 06. 2008 v 11:16 -0500: >>> Milan Jurik wrote: >>>> Hi, >>>> >>>> Chin-Long Shu p??e v Po 09. 06. 2008 v 10:50 -0500: >>>> >>>>> I looked into the code again and it's a very confusing one but I don't >>>>> think it's a bug. >>>>> Please see SD-108 of Serge's comment and Igor's answer in the >>>>> opensoalris.org webpage. Also some background info in SD-110. >>>>> http://opensolaris.org/os/project/duckwater/duckwater_phase0/codereview/serge_libsldap/ >>>>> >>>>> >>>>> It's meant to be >>>>> if (-A && -B) { >>>>> ......... >>>>> return (NS_LDAP_CONFIG); >>>>> } >>>>> So A is true || B is TRUE is fine. >>>>> >>>>> Change it to (-A || -B) will make it return error when A is false and >>>>> B is true when it's OK. >>>>> >>>>> >>>> But what about opposite, just B is false and A is true ? Is it valid? >>>> Anyway, it needs to be fixed in comment (but that wouldn't stop RTI >>>> because it wouldn't have impact on source code). >>>> >>> It's still valid. >> >> More time spent on the evaluation and yes, you are right, just in case >> we didn't pass both of them, we have issue. Ufff, Tomas, fix the >> comment, please :-) >> >> So, we have few RFEs around code, these should be logged asap. Any other >> comment missed? I'm not sure I will be able to pass through finel >> incremental today, but I could try. >> >> Best regards, >> >> Milan >> >> _______________________________________________ >> duckwater-discuss mailing list >> duckwater-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/duckwater-discuss >> From Serge.Dussud at Sun.COM Tue Jun 10 03:29:14 2008 From: Serge.Dussud at Sun.COM (Serge Dussud) Date: Tue, 10 Jun 2008 12:29:14 +0200 Subject: [Duckwater-discuss] Final Duckwater Phase 0 webrev In-Reply-To: <484D9CC5.8060309@sun.com> References: <484CFA1D.1040803@sun.com> <484D1F0A.6010400@sun.com> <484D222E.1080609@sun.com> <1213016423.3784.110.camel@localhost.localdomain> <484D2CF0.4060806@sun.com> <484D514F.3080606@Sun.COM> <1213027556.3784.164.camel@localhost.localdomain> <484D5756.2010200@Sun.COM> <1213029447.3784.176.camel@localhost.localdomain> <484D60A7.60109@sun.com> <484D9CC5.8060309@sun.com> Message-ID: <484E577A.5010409@Sun.COM> Looks good, thanks. Serge Tomas Heran wrote: > So, Michen and Chin-Long did the changes already, so here's the > incremental webrev - it's been generated by, so there's pretty much > all of the files without any change, but I'm sure you'll be able to > plough through it (ns_standalone.c, ns_connmgmt.c, ns_confmgr.c and > libsldap/Makefile.com): > > http://cr.opensolaris.org/~the/duckwater_phase0_incr_jun_09/ > > OK with you, Serge? > > Final (now I really mean it) all changes vs. onnv webrev is here: > > http://cr.opensolaris.org/~the/duckwater_phase0_final/ > > Tomas > > Tomas Heran wrote: >> There are a few pending changes which we will address as soon as >> possible (tomorrow hopefully). These include: >> >> - SD-97 - will require small change in Makefile >> - SD-98 - small change in Makefile and a few changes in code >> - SD-108 (same issue in set_attr Julian pointed out) - comment change >> - SD-82 - Michen believes this should be OK ... is being discussed >> between Michen and Serge >> >> Is there anything else I left out? >> >> Once we're done, I'll send a webrev just for those as well as update >> the final webrev. >> >> Tomas >> >> Milan Jurik wrote: >>> So, we have few RFEs around code, these should be logged asap. Any other >>> comment missed? I'm not sure I will be able to pass through finel >>> incremental today, but I could try. >>> >> >> _______________________________________________ >> duckwater-discuss mailing list >> duckwater-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/duckwater-discuss From Tomas.Heran at Sun.COM Wed Jun 11 01:16:29 2008 From: Tomas.Heran at Sun.COM (Tomas Heran) Date: Wed, 11 Jun 2008 10:16:29 +0200 Subject: [Duckwater-discuss] So it's done now Message-ID: <484F89DD.9040901@sun.com> Dear code-reviewers, as some of you might have noticed already, late last night, we managed to integrate the code into the gate. I'd like to thank you all again for your hard work reviewing and re-reviewing the Duckwater Phase 0 code. Your help is invaluable and most appreciated! On behalf of the DW team, Tomas