From Tomas.Heran at Sun.COM Fri May 2 03:34:50 2008 From: Tomas.Heran at Sun.COM (Tomas.Heran at Sun.COM) Date: Fri, 2 May 2008 03:34:50 -0700 (PDT) Subject: [Duckwater-discuss] ldaplist does support projects database Message-ID: <20080502103450.D5CD5153492@mail.opensolaris.org> Author: Tomas Heran Repository: /hg/duckwater/duckwater-docs Latest revision: 4b6e20d4cf358a1ec09a932c72b8c4b6a43f4c21 Total changesets: 1 Log message: ldaplist does support projects database Files: update: manpages/standalone_manpages/ldaplist.1.diff update: manpages/standalone_manpages/ldaplist.1.txt.standalone From Tomas.Heran at Sun.COM Mon May 26 04:23:14 2008 From: Tomas.Heran at Sun.COM (Tomas Heran) Date: Mon, 26 May 2008 13:23:14 +0200 Subject: [Duckwater-discuss] Code-review request for Duckwater Phase 0 Message-ID: <483A9DA2.9010408@sun.com> 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 Wed May 28 14:42:29 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 28 May 2008 16:42:29 -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: <20080528214228.GE1039@Sun.COM> On Mon, May 26, 2008 at 01:23:14PM +0200, Tomas Heran wrote: > http://cr.opensolaris.org/~the/duckwater_phase0/ - usr/src/cmd/ldap/ns_ldap/standalone.h Why is there code in this file? From Nicolas.Williams at sun.com Wed May 28 15:42:44 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 28 May 2008 17:42:44 -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: <20080528224243.GG1039@Sun.COM> On Mon, May 26, 2008 at 01:23:14PM +0200, Tomas Heran wrote: > http://cr.opensolaris.org/~the/duckwater_phase0/ Batch 1 (my previous comment is batch 0): - Why is ns_standalone_conf_t not in a header for libsldap? - usr/src/cmd/ldap/ns_ldap/standalone.h:separatePort() - usr/src/cmd/ldap/ns_ldap/ldapaddent.c:count_tokens() I much prefer this: if ((cp = strchr(s, delim)) == NULL) (or != NULL) rather than: cp = strchr(s, delim); if (cp == NULL) (or != NULL). count_tokens() could be: static int count_tokens(char *string, char delim) { int i = 0; char *s; if (string == NULL || *string == '\0') return (0); /* Count delimiters */ while ((s = strchr(string, delim)) != NULL && *s != '\0') i++; return (i + 1); } - Also, count_tokens() returns 0 for empty strings, but if there's any delimiter characters in the string then it returns the number of such chars + 1. So empty tokens sometimes count and sometimes don't. Weird. - count_tokens()'s callers don't check for empty tokens (see above for a related comment). Yes, you don't expect malformed project entries, but when users are importing hand-maintained project entries we can expect this sort of mistake and tolerate it. Meanwhile we seem to tolerate missing fields of project entries: genent_project() doesn't check that index == 5 at the end of the while loop. - count_tokens()'s callers use strotk() when they should use strtok_r(), or even strsep() since that's included in the same file. - ldapaddent.c:4337-4338,4353-4354 4336 + (void) fprintf(stderr, 4337 + gettext("The -w option is mutually " 4338 + "exclusive of -j. -w is ignored.\n")); Shouldn't this be prefixed with "Warning: "? - ldapaddent.c:4401 4401 + gettext("Distinguished Name to bind to directory" 4402 + " must be specified. use option -D.\n")); Shouldn't this message point say something like "DN must be specified unless SASL/GSSAPI is used"? Nico -- From Igor.Zymin at Sun.COM Thu May 29 02:34:50 2008 From: Igor.Zymin at Sun.COM (Igor Zymin) Date: Thu, 29 May 2008 11:34:50 +0200 Subject: [Duckwater-discuss] Code-review request for Duckwater Phase 0 In-Reply-To: <20080528224243.GG1039@Sun.COM> References: <483A9DA2.9010408@sun.com> <20080528224243.GG1039@Sun.COM> Message-ID: <483E78BA.6050908@Sun.COM> Nicolas Williams wrote: > On Mon, May 26, 2008 at 01:23:14PM +0200, Tomas Heran wrote: > >> http://cr.opensolaris.org/~the/duckwater_phase0/ >> > > Batch 1 (my previous comment is batch 0): > The code in the usr/src/cmd/ldap/ns_ldap/standalone.h file contains bits used by ldapaddent and ldaplist. They use the same defaults for establishing a standalone connection and the process the host/port attribute similarly. For instance, ldapaddent and ldaplist by default use ldap_cachmgr if no standalone options are provided by the user. Other applications can request standalone mode by default. So, as I understand, defaults are more or less application dependent. ldapaddent, ldaplist, and ldapclient expect the host/port attribute provided in the following way: -h [:port] Other LDAP client applications use the -h/-p options. So, again, it is up to an application how to process input information. The standalone bits of libsldap require an address and a port be provided separately. > - Why is ns_standalone_conf_t not in a header for libsldap? > The structure is defined in the libsldap/common/ns_sldap.h Nico, does this answer you Qs? Igor > - usr/src/cmd/ldap/ns_ldap/standalone.h:separatePort() > - usr/src/cmd/ldap/ns_ldap/ldapaddent.c:count_tokens() > > I much prefer this: > > if ((cp = strchr(s, delim)) == NULL) > > (or != NULL) rather than: > > cp = strchr(s, delim); > > if (cp == NULL) > > (or != NULL). > > count_tokens() could be: > > static int > count_tokens(char *string, char delim) > { > int i = 0; > char *s; > > if (string == NULL || *string == '\0') > return (0); > > /* Count delimiters */ > while ((s = strchr(string, delim)) != NULL && *s != '\0') > i++; > > return (i + 1); > } > > - Also, count_tokens() returns 0 for empty strings, but if there's any > delimiter characters in the string then it returns the number of such > chars + 1. So empty tokens sometimes count and sometimes don't. > > Weird. > > - count_tokens()'s callers don't check for empty tokens (see above for > a related comment). Yes, you don't expect malformed project entries, > but when users are importing hand-maintained project entries we can > expect this sort of mistake and tolerate it. > > Meanwhile we seem to tolerate missing fields of project entries: > > genent_project() doesn't check that index == 5 at the end of the > while loop. > > - count_tokens()'s callers use strotk() when they should use > strtok_r(), or even strsep() since that's included in the same file. > > > - ldapaddent.c:4337-4338,4353-4354 > > > 4336 + (void) fprintf(stderr, > 4337 + gettext("The -w option is mutually " > 4338 + "exclusive of -j. -w is ignored.\n")); > > Shouldn't this be prefixed with "Warning: "? > > - ldapaddent.c:4401 > > > 4401 + gettext("Distinguished Name to bind to directory" > 4402 + " must be specified. use option -D.\n")); > > Shouldn't this message point say something like "DN must be specified > unless SASL/GSSAPI is used"? > > > Nico > From Tomas.Heran at Sun.COM Thu May 29 04:45:06 2008 From: Tomas.Heran at Sun.COM (Tomas Heran) Date: Thu, 29 May 2008 13:45:06 +0200 Subject: [Duckwater-discuss] Code-review request for Duckwater Phase 0 In-Reply-To: <20080528224243.GG1039@Sun.COM> References: <483A9DA2.9010408@sun.com> <20080528224243.GG1039@Sun.COM> Message-ID: <483E9742.7020002@sun.com> What do others think about the warning/error message changes Nico proposes? T. Nicolas Williams wrote: > - ldapaddent.c:4337-4338,4353-4354 > > > 4336 + (void) fprintf(stderr, > 4337 + gettext("The -w option is mutually " > 4338 + "exclusive of -j. -w is ignored.\n")); > > Shouldn't this be prefixed with "Warning: "? > > - ldapaddent.c:4401 > > > 4401 + gettext("Distinguished Name to bind to directory" > 4402 + " must be specified. use option -D.\n")); > > Shouldn't this message point say something like "DN must be specified > unless SASL/GSSAPI is used"? > > > Nico From Igor.Zymin at Sun.COM Thu May 29 05:11:00 2008 From: Igor.Zymin at Sun.COM (Igor Zymin) Date: Thu, 29 May 2008 14:11:00 +0200 Subject: [Duckwater-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: <483E9D54.4050807@Sun.COM> I would agree with them. The first message Nico mentioned is a warning indeed. And there are several similar messages informing about ignorance of options throughout ldapaddent/ldaplist . I think all of them should be extended with the "Warning: " prefix. And WRT the second error message, I like the one suggested by Nico. It is more informative. I'd put both variants together. Something like "DN must be specified unless SASL/GSSAPI is used. Use option -D." Igor Tomas Heran wrote: > What do others think about the warning/error message changes Nico > proposes? > > T. > > Nicolas Williams wrote: > >> - ldapaddent.c:4337-4338,4353-4354 >> >> >> 4336 + (void) fprintf(stderr, >> 4337 + gettext("The -w option is mutually " >> 4338 + "exclusive of -j. -w is ignored.\n")); >> >> Shouldn't this be prefixed with "Warning: "? >> >> - ldapaddent.c:4401 >> >> >> 4401 + gettext("Distinguished Name to bind to directory" >> 4402 + " must be specified. use option -D.\n")); >> >> Shouldn't this message point say something like "DN must be specified >> unless SASL/GSSAPI is used"? >> >> >> Nico >> > _______________________________________________ > duckwater-discuss mailing list > duckwater-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/duckwater-discuss > From Serge.Dussud at Sun.COM Thu May 29 07:11:36 2008 From: Serge.Dussud at Sun.COM (Serge Dussud) Date: Thu, 29 May 2008 16:11:36 +0200 Subject: [Duckwater-discuss] Code-review request for Duckwater Phase 0 In-Reply-To: <483A9DA2.9010408@sun.com> References: <483A9DA2.9010408@sun.com> Message-ID: <483EB998.1070308@Sun.COM> Hi Tomas, attached is my 1st round of comments. To be continued. Cheers, Serge 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 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dw0-review1.txt URL: From Doug.Leavitt at Sun.COM Thu May 29 08:30:26 2008 From: Doug.Leavitt at Sun.COM (Doug.Leavitt at Sun.COM) Date: Thu, 29 May 2008 08:30:26 -0700 (PDT) Subject: [Duckwater-discuss] minor edits. posts to OSo (sparks) 5/28/08 Message-ID: <20080529153026.817AA15BAE1@mail.opensolaris.org> Author: Doug Leavitt Repository: /hg/duckwater/duckwater-docs Latest revision: 9e99939f25e14a685264cd6275e02cbd1034bf81 Total changesets: 1 Log message: minor edits. posts to OSo (sparks) 5/28/08 Files: update: NativeLDAP2Arch.odt update: NativeLDAP2Arch.pdf From Doug.Leavitt at Sun.COM Thu May 29 08:35:12 2008 From: Doug.Leavitt at Sun.COM (Doug Leavitt) Date: Thu, 29 May 2008 10:35:12 -0500 Subject: [Duckwater-discuss] minor edits to NativeLDAP spec pushed Message-ID: <483ECD30.8060902@sun.com> I just pushed a couple of minor edits out to the duckwater-docs gate: changeset: 29:9e99939f25e1 tag: tip user: Doug Leavitt date: Thu May 29 10:27:19 2008 -0500 files: NativeLDAP2Arch.odt NativeLDAP2Arch.pdf description: minor edits. posts to OSo (sparks) 5/28/08 I have also put the current copy of the pdf in the documentation page for sparks: http://www.opensolaris.org/os/project/sparks/Documentation/ The last revision was put int he Duckwater phase 0 PSARC materials, but it's not easily found. This might be a better [easier to find] home for it. I thought it would get lost in all the duckwater docs. Doug. From Nicolas.Williams at sun.com Thu May 29 12:56:06 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 29 May 2008 14:56:06 -0500 Subject: [Duckwater-discuss] [sparks-discuss] Code-review request for Duckwater Phase 0 In-Reply-To: <20080528224243.GG1039@Sun.COM> References: <483A9DA2.9010408@sun.com> <20080528224243.GG1039@Sun.COM> Message-ID: <20080529195605.GF2735@Sun.COM> On Wed, May 28, 2008 at 05:42:44PM -0500, Nicolas Williams wrote: > - Why is ns_standalone_conf_t not in a header for libsldap? Never mind that question. This is a d'oh. From Nicolas.Williams at sun.com Thu May 29 14:29:45 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 29 May 2008 16:29:45 -0500 Subject: [Duckwater-discuss] [sparks-discuss] Code-review request for Duckwater Phase 0 In-Reply-To: <20080528224243.GG1039@Sun.COM> References: <483A9DA2.9010408@sun.com> <20080528224243.GG1039@Sun.COM> Message-ID: <20080529212945.GB2734@Sun.COM> On Wed, May 28, 2008 at 05:42:44PM -0500, Nicolas Williams wrote: > > http://cr.opensolaris.org/~the/duckwater_phase0/ Batch 2 (my previous comment is batch 0): - ldapclient.c:1389-1390 1389 /* INET6_ADDRSTRLEN + ":<5-digit port>" + some round-up */ 1390 #define MAX_HOSTADDR_LEN 64 Don't put computation in comments, put it in the macro definition: /* IPv6 host address + ":" + 5-digit port + slop just in case */ #define MAX_HOSTADDR_LEN (INET6_ADDRSTRLEN + 6 + 12) No, INET6_ADDRSTRLEN isn't likely to change, ever, but still. Among other things cscope will find the reference to INET6_ADDRSTRLEN in the macro definition of MAX_HOSTADDR_LEN, but it won't find it in the comment. - ldapclient.c:1457 1457 /* __ns_ldap_setServer(TRUE); */ Don't comment/#if 0 out code. Remove it. - ldapclient.c:1468 Do we need to check if arglist->defaultServerList != NULL here? (It's hard to follow all the places where it's set/checked, so I'll be lazy and just ask.) - ldapclient.c:1469-1471 Personally I prefer not surrounding single statement if/else/while/for/... bodies in curly braces. I realize that's not the style in native LDAP code, I just want to record my revulsion. - ldapclient:1473-1491,1539-1556 This code needs a comment block. Why does having bindDN != NULL imply proxy creds and NS_LDAP_AUTH_SIMPLE??? - ldapclient:1624-1626,1630-1633 1624 CLIENT_FPRINTF(stderr, gettext("Security " 1625 "Warning: init credential level not found " 1626 "in DUAConfigProfile.\n")); "Security Warning"? Just make that a "Warning". - ldapclient.c:usage() The usage message hasn't been updated... That's it for ldapclient.c. - ldaplist.c:221 cstyle: indent comment blocks so they line up with the following statement. - ldaplist.c:274 273 if (optarg != NULL && 274 optarg[0] == '-' && optarg[1] == '\0') { 275 /* Ask for a password later */ 276 break; 277 } What, no empty string passwords? - ldaplist.c:393-394,399 393 * The bind DN and password have already 394 * been dropped by libsldap. This code only 395 * prints a corresponding message on 396 * the terminal window. "The bind DN and password have already been dropped by libsldap" is a bit meaningless. We could, for example, use the "bind DN" as the SASL authzid. For most DSes this is pointless when using SASL/GSSAPI since the authzid is usually/always derived from the client's principal name/credentials. The password could be used to do an implicit kinit(1) (or keylogin(1), or whatever) too. What we really want to say is that "for now we have no use for bind DN and password when using SASL/GSSAPI." The error/warning message is OK though, but a "Warning: " prefix would be nice. - usr/src/cmd/ldap/Makefile - usr/src/cmd/ldap/Makefile.com - usr/src/cmd/ldap/ns_ldap/idsconfig.sh - usr/src/cmd/ldap/req.flg - usr/src/cmd/ldapcachemgr/Makefile No comments. Nico -- From Nicolas.Williams at sun.com Thu May 29 14:58:33 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 29 May 2008 16:58:33 -0500 Subject: [Duckwater-discuss] Code-review request for Duckwater Phase 0 In-Reply-To: <483E78BA.6050908@Sun.COM> References: <483A9DA2.9010408@sun.com> <20080528224243.GG1039@Sun.COM> <483E78BA.6050908@Sun.COM> Message-ID: <20080529215833.GP2735@Sun.COM> On Thu, May 29, 2008 at 11:34:50AM +0200, Igor Zymin wrote: > The code in the usr/src/cmd/ldap/ns_ldap/standalone.h file contains > bits used by ldapaddent and ldaplist. They use the same defaults for > establishing a standalone connection and the process the host/port > attribute similarly. That's fine, but we don't place common code in header files. We place common code in: - libraries - or in source files where all the programs that need it will find it, e.g., - $SRC/cmd/ldap/utils.c - $SRC/cmd/ldap/common.c - $SRC/cmd/ldap/common/blah,blah,blah.c > > - Why is ns_standalone_conf_t not in a header for libsldap? > > > The structure is defined in the libsldap/common/ns_sldap.h Yeah, this was a brain-fart. I meant why is the structure initialized in a common source file. Nico -- From Nicolas.Williams at sun.com Thu May 29 15:55:40 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 29 May 2008 17:55:40 -0500 Subject: [Duckwater-discuss] [sparks-discuss] Code-review request for Duckwater Phase 0 In-Reply-To: <20080529212945.GB2734@Sun.COM> References: <483A9DA2.9010408@sun.com> <20080528224243.GG1039@Sun.COM> <20080529212945.GB2734@Sun.COM> Message-ID: <20080529225540.GE2734@Sun.COM> On Thu, May 29, 2008 at 04:29:45PM -0500, Nicolas Williams wrote: > > > http://cr.opensolaris.org/~the/duckwater_phase0/ Batch 3: - usr/src/cmd/ldap/*.c Please see to it that passwords are scrubbed before exiting (e.g., with memset()). - usr/src/cmd/ldapcachemgr/cachemgr.h:58 I don't understand the comment, please clarify. - cachmgr.h:50 What is MAX_CHG_THREADS for? 50 +#define MAX_CHG_THREADS 65535 If we can have that many threads then why set a limit at all? In cachemgr.c we see: 122 121 #define LDAP_TABLES 1 /* ldap */ 123 122 #define TABLE_THREADS 10 124 123 #define COMMON_THREADS 20 125 124 #define CACHE_MISS_THREADS (COMMON_THREADS + LDAP_TABLES * TABLE_THREADS) 126 125 #define CACHE_HIT_THREADS 20 126 +#define MAX_SERVER_THREADS (CACHE_HIT_THREADS + CACHE_MISS_THREADS + \ 127 + MAX_CHG_THREADS) Hmm, why are we defining *_THREADS in different places? I'll figure out what change threads are in a minute, but if it's what I think it is then I think 65535 is a bit too large. Also, if I understand correctly we could have practically every process blocked waiting for ldap_cachemgr to do something, is that correct? If so, then I think this is a bit sub-optimal. I'd much, much rather we find a way to avoid such waits. I don't mind lots of processes blocking on nscd, for example, if they are calling getXbyYs and the name service backends are blocking. A *big* comment block at the top of the file would greatly help a reviewer understand what's going on. As it is I don't know where to start; I'm tempted to bringover so I can build a cscope DB, which would slow down the review. - usr/src/cmd/ldapcachemgr/cachemgr_change.c:70 cstyle: please put a blank line between local variable declarations and the first statement of a function. - cachemgr_change.c:chg_get_statusChange() and cachemgr.c:switcher() I'm rather concerned at the apparent lack of authorization checks for some things here. Item (1) in cachemgr_change.c:234-238, for example, doesn't consider the possibility that a NS_STATUS_CHANGE_OP_START request came from an attacker, leading to "cleanup ...". More later. Nico -- From Milan.Jurik at Sun.COM Fri May 30 07:21:16 2008 From: Milan.Jurik at Sun.COM (Milan Jurik) Date: Fri, 30 May 2008 16:21:16 +0200 Subject: [Duckwater-discuss] Code-review request for Duckwater Phase 0 In-Reply-To: <483A9DA2.9010408@sun.com> References: <483A9DA2.9010408@sun.com> Message-ID: <1212157275.27652.251.camel@xylabone> Hi, usr/src/cmd/ldapcachemgr/Makefile ================================= [00] 65 -LDLIBS += -lsldap -lldap -lnsl 65 +LDLIBS += -lumem -lsldap Just to be sure - is libumem default memory allocator for ldapcachemgr now? usr/src/cmd/ldapcachemgr/cachemgr.h: =================================== [01] 58 + * In ldap_cachemgr, it return -99 for some case, start with -100 here Where does it return what? [02] lines 69-73 and 88-98 - it would be better to use tabs before comments [03] 122 +extern int is_nscd(pid_t pid); /* in cachemgr.c */ - is_call_from_nscd(), to not confuse libsldap and ldap_cachemgr implementations? usr/src/cmd/ldapcachemgr/cachemgr.c =================================== [04] 579 + * kick off the thread which cleans ups waiting threads for - typo - cleans ups - too much "s"? [05] 583 + if (thr_create(NULL, NULL, 584 + (void *(*)(void*))chg_cleanup_waiting_threads, 0, 0, NULL) != 0) { - the second parameter should be 0 (type is size_t) - do you need to retype chg_cleanup_waiting_threads() ? I think it is correct type already - the 4th argument should be NULL (type is (void *)) [06] 585 + logit("thr_create() chg_cleanup_waiting_thread call failed\n"); 587 + gettext("ldap_cachemgr: thr_create() " 588 + "chg_cleanup_waiting_threads call failed")); - thr_create call failed in chg_cleanup_waiting_thread usr/src/cmd/ldapcachemgr/cachemgr_getldap.c =========================================== [07] 165 + int up; /* TRUE: up, FALSE, down */ - if it is boolean, why not to use boolean_t ? [08] 615 + exitrc = NS_LDAP_SUCCESS; - already initialized exitrc for NS_LDAP_SUCCESS, duplicite line [09] 880 - int reset_bindtime) 771 + int reset_bindtime, info_op_t op) - double tab? [10] 1123 - int matched = FALSE, len, rc = 0; 1124 - char *ret_addr = NULL, *ret_addrFQDN = NULL; 893 + int matched = FALSE, len, rc = 0, main_nscd; 894 + char *ret_addr = NULL, *ret_addrFQDN = NULL, *new_addr; - don't increase mix of initialized and uninitialized variables, it decresase readability, split lines, please [11] 1237 - continue; 1004 + break; - is it possible to remove just one server at time? [12] lines 1893-1965 - why not as static function, to avoid /* FALL THROUGH */? [13] 2585 - int rc, rc1; 2388 + int rc, rc1, changed = 0; - again, don't mix initialized and uninitialized variables [14] 2695 +test_server_change(server_info_t *head) { 2766 +create_buf_and_notify(char *input, ns_server_status_t st) { 2828 +remove_server_thread(void *arg) { 2851 +remove_server(char *addr) { 2860 +set_server_status(char *input, server_info_t *head) { 2805 +static int contact_server(char *addr) { - bracket on own line, the last one has even type on the same line [15] 2697 + int len = 0, num = 0, ds_len, new_len, tlen = 0; 2698 + char *tmp_buf = NULL, *ptr, *status; - again, don't mix initialized and uninitialized variables [16] - at least small comment to every new function would be welcomed [17] test_server_change() and create_buf_and_notify() - where do you free tmp_buf? [18] 2853 + if (thr_create(NULL, NULL, (void *(*)(void*))remove_server_thread, - the second parameter is size_t, not pointer usr/src/lib/libsldap/common/ns_cache_door.h =========================================== [19] 89 + uint32_t data_size; /* if server change: size of data */ 90 + char data[sizeof (int)]; /* real size is data_size */ 95 + uint32_t data_size; /* length of the config string */ 96 + char config_str[sizeof (int)]; /* real size is data_size */ - so which one is truth? uint32_t or int ? Both "doublelines" claim different things usr/src/lib/libsldap/common/ns_cache_door.c =========================================== [20] - OK, just minor comments to function would be welcomed usr/src/cmd/ldapcachemgr/cachemgr_change.c ========================================== [21] - all functions have definition with bracket on the same line [22] 77 static void 78 chg_config_cookie_increment_seq_num(void) { 79 (void) mutex_lock(&config_cookie_lock); 80 config_cookie.seq_num++; 81 (void) mutex_unlock(&config_cookie_lock); 82 } - do we need to lock for atomic incrementation? [23] 91 static int 92 chg_cookie_equal(ldap_get_chg_cookie_t *c1, ldap_get_chg_cookie_t *c2) { - this could be nice to have it as boolean_t [24] 101 static int - 2 spaces between static and int? [25] 109 info->chg_num++; 110 if (info->chg_num > max_threads_allowed) { 111 info->chg_num--; - only question: are you preventing race condition by this ++, >, -- ? [26] - only question: is waiting list thread specific or must be locked by callers (I see no locking there)? [27] 260 int rc = CHG_SUCCESS, len, return_now; - again, don't mix initialized and uninitialized variables [28] 492 * The door server thead which has the door client pid will be marked - typo - thead -> thread [29] 510 if (thr_create(NULL, NULL, 511 (void *(*)(void*))chg_cleanup_waiting_threads, - the second parameter is size_t, 0 - do you need to retype chg_cleanup_waiting_threads()? Best regards, Milan From Tomas.Heran at Sun.COM Fri May 30 07:55:32 2008 From: Tomas.Heran at Sun.COM (Tomas Heran) Date: Fri, 30 May 2008 16:55:32 +0200 Subject: [Duckwater-discuss] Code-review request for Duckwater Phase 0 In-Reply-To: <1212157275.27652.251.camel@xylabone> References: <483A9DA2.9010408@sun.com> <1212157275.27652.251.camel@xylabone> Message-ID: <48401564.3010606@sun.com> Thanks! Your comments and our replies and progress addressing your comments will be tracked here: http://opensolaris.org/os/project/duckwater/duckwater_phase0/codereview/milan_ldapcachemgr/ Tomas Milan Jurik wrote: > Hi, > > usr/src/cmd/ldapcachemgr/Makefile > ================================= > [00] > > 65 -LDLIBS += -lsldap -lldap -lnsl > 65 +LDLIBS += -lumem -lsldap > > Just to be sure - is libumem default memory allocator for ldapcachemgr > now? > > > usr/src/cmd/ldapcachemgr/cachemgr.h: > =================================== > [01] > 58 + * In ldap_cachemgr, it return -99 for some case, start with > -100 here > > Where does it return what? > > [02] lines 69-73 and 88-98 > > - it would be better to use tabs before comments > > [03] > 122 +extern int is_nscd(pid_t pid); /* in cachemgr.c */ > > - is_call_from_nscd(), to not confuse libsldap and ldap_cachemgr > implementations? > > usr/src/cmd/ldapcachemgr/cachemgr.c > =================================== > [04] > 579 + * kick off the thread which cleans ups waiting > threads for > > - typo - cleans ups - too much "s"? > > [05] > 583 + if (thr_create(NULL, NULL, > 584 + (void *(*)(void*))chg_cleanup_waiting_threads, 0, > 0, NULL) != 0) { > > - the second parameter should be 0 (type is size_t) > > - do you need to retype chg_cleanup_waiting_threads() ? I think it is > correct type already > > - the 4th argument should be NULL (type is (void *)) > > [06] > 585 + logit("thr_create() > chg_cleanup_waiting_thread call failed\n"); > > 587 + gettext("ldap_cachemgr: thr_create() " > 588 + "chg_cleanup_waiting_threads call failed")); > > > - thr_create call failed in chg_cleanup_waiting_thread > > usr/src/cmd/ldapcachemgr/cachemgr_getldap.c > =========================================== > [07] > 165 + int up; /* TRUE: up, FALSE, down */ > > - if it is boolean, why not to use boolean_t ? > > [08] > 615 + exitrc = NS_LDAP_SUCCESS; > > - already initialized exitrc for NS_LDAP_SUCCESS, duplicite line > > [09] > 880 - int reset_bindtime) > 771 + int reset_bindtime, info_op_t op) > > - double tab? > > [10] > 1123 - int matched = FALSE, len, rc = 0; > 1124 - char *ret_addr = NULL, *ret_addrFQDN = NULL; > 893 + int matched = FALSE, len, rc = 0, main_nscd; > 894 + char *ret_addr = NULL, *ret_addrFQDN = NULL, *new_addr; > > - don't increase mix of initialized and uninitialized variables, it decresase readability, split lines, please > > [11] > 1237 - continue; > 1004 + break; > > - is it possible to remove just one server at time? > > > [12] lines 1893-1965 > > - why not as static function, to avoid /* FALL THROUGH */? > > [13] > 2585 - int rc, rc1; > 2388 + int rc, rc1, changed = 0; > > - again, don't mix initialized and uninitialized variables > > [14] > 2695 +test_server_change(server_info_t *head) { > 2766 +create_buf_and_notify(char *input, ns_server_status_t st) { > 2828 +remove_server_thread(void *arg) { > 2851 +remove_server(char *addr) { > 2860 +set_server_status(char *input, server_info_t *head) { > 2805 +static int contact_server(char *addr) { > > - bracket on own line, the last one has even type on the same line > > [15] > 2697 + int len = 0, num = 0, ds_len, new_len, tlen = 0; > 2698 + char *tmp_buf = NULL, *ptr, *status; > > - again, don't mix initialized and uninitialized variables > > [16] > - at least small comment to every new function would be welcomed > > [17] > test_server_change() and create_buf_and_notify() > > - where do you free tmp_buf? > > [18] > > 2853 + if (thr_create(NULL, NULL, (void *(*)(void*))remove_server_thread, > > - the second parameter is size_t, not pointer > > usr/src/lib/libsldap/common/ns_cache_door.h > =========================================== > [19] > 89 + uint32_t data_size; /* if server change: size of data */ > 90 + char data[sizeof (int)]; /* real size is data_size */ > > 95 + uint32_t data_size; /* length of the config string */ > 96 + char config_str[sizeof (int)]; /* real size is data_size */ > > - so which one is truth? uint32_t or int ? Both "doublelines" claim different things > > usr/src/lib/libsldap/common/ns_cache_door.c > =========================================== > [20] > - OK, just minor comments to function would be welcomed > > usr/src/cmd/ldapcachemgr/cachemgr_change.c > ========================================== > [21] > > - all functions have definition with bracket on the same line > > [22] > 77 static void > 78 chg_config_cookie_increment_seq_num(void) { > 79 (void) mutex_lock(&config_cookie_lock); > 80 config_cookie.seq_num++; > 81 (void) mutex_unlock(&config_cookie_lock); > 82 } > > - do we need to lock for atomic incrementation? > > [23] > 91 static int > 92 chg_cookie_equal(ldap_get_chg_cookie_t *c1, ldap_get_chg_cookie_t *c2) { > > - this could be nice to have it as boolean_t > > [24] > 101 static int > > - 2 spaces between static and int? > > [25] > 109 info->chg_num++; > 110 if (info->chg_num > max_threads_allowed) { > 111 info->chg_num--; > > - only question: are you preventing race condition by this ++, >, -- ? > > [26] > - only question: is waiting list thread specific or must be locked by callers (I see no locking there)? > > [27] > 260 int rc = CHG_SUCCESS, len, return_now; > > - again, don't mix initialized and uninitialized variables > > [28] > 492 * The door server thead which has the door client pid will be marked > > - typo - thead -> thread > > [29] > 510 if (thr_create(NULL, NULL, > 511 (void *(*)(void*))chg_cleanup_waiting_threads, > > - the second parameter is size_t, 0 > > - do you need to retype chg_cleanup_waiting_threads()? > > Best regards, > > Milan > From Milan.Jurik at Sun.COM Fri May 30 09:05:51 2008 From: Milan.Jurik at Sun.COM (Milan Jurik) Date: Fri, 30 May 2008 18:05:51 +0200 Subject: [Duckwater-discuss] Code-review request for Duckwater Phase 0 In-Reply-To: <48401564.3010606@sun.com> References: <483A9DA2.9010408@sun.com> <1212157275.27652.251.camel@xylabone> <48401564.3010606@sun.com> Message-ID: <1212163551.27652.302.camel@xylabone> Tomas, OK, and [22] you can remove, it's correct. Friday in hot weather, not good time for code review :-) Best regards, Milan V p?, 30. 05. 2008 v 16:55, Tomas Heran p??e: > Thanks! > > Your comments and our replies and progress addressing your comments will > be tracked here: > > http://opensolaris.org/os/project/duckwater/duckwater_phase0/codereview/milan_ldapcachemgr/ > > Tomas > > Milan Jurik wrote: > > Hi, > > > > usr/src/cmd/ldapcachemgr/Makefile > > ================================= > > [00] > > > > 65 -LDLIBS += -lsldap -lldap -lnsl > > 65 +LDLIBS += -lumem -lsldap > > > > Just to be sure - is libumem default memory allocator for ldapcachemgr > > now? > > > > > > usr/src/cmd/ldapcachemgr/cachemgr.h: > > =================================== > > [01] > > 58 + * In ldap_cachemgr, it return -99 for some case, start with > > -100 here > > > > Where does it return what? > > > > [02] lines 69-73 and 88-98 > > > > - it would be better to use tabs before comments > > > > [03] > > 122 +extern int is_nscd(pid_t pid); /* in cachemgr.c */ > > > > - is_call_from_nscd(), to not confuse libsldap and ldap_cachemgr > > implementations? > > > > usr/src/cmd/ldapcachemgr/cachemgr.c > > =================================== > > [04] > > 579 + * kick off the thread which cleans ups waiting > > threads for > > > > - typo - cleans ups - too much "s"? > > > > [05] > > 583 + if (thr_create(NULL, NULL, > > 584 + (void *(*)(void*))chg_cleanup_waiting_threads, 0, > > 0, NULL) != 0) { > > > > - the second parameter should be 0 (type is size_t) > > > > - do you need to retype chg_cleanup_waiting_threads() ? I think it is > > correct type already > > > > - the 4th argument should be NULL (type is (void *)) > > > > [06] > > 585 + logit("thr_create() > > chg_cleanup_waiting_thread call failed\n"); > > > > 587 + gettext("ldap_cachemgr: thr_create() " > > 588 + "chg_cleanup_waiting_threads call failed")); > > > > > > - thr_create call failed in chg_cleanup_waiting_thread > > > > usr/src/cmd/ldapcachemgr/cachemgr_getldap.c > > =========================================== > > [07] > > 165 + int up; /* TRUE: up, FALSE, down */ > > > > - if it is boolean, why not to use boolean_t ? > > > > [08] > > 615 + exitrc = NS_LDAP_SUCCESS; > > > > - already initialized exitrc for NS_LDAP_SUCCESS, duplicite line > > > > [09] > > 880 - int reset_bindtime) > > 771 + int reset_bindtime, info_op_t op) > > > > - double tab? > > > > [10] > > 1123 - int matched = FALSE, len, rc = 0; > > 1124 - char *ret_addr = NULL, *ret_addrFQDN = NULL; > > 893 + int matched = FALSE, len, rc = 0, main_nscd; > > 894 + char *ret_addr = NULL, *ret_addrFQDN = NULL, *new_addr; > > > > - don't increase mix of initialized and uninitialized variables, it decresase readability, split lines, please > > > > [11] > > 1237 - continue; > > 1004 + break; > > > > - is it possible to remove just one server at time? > > > > > > [12] lines 1893-1965 > > > > - why not as static function, to avoid /* FALL THROUGH */? > > > > [13] > > 2585 - int rc, rc1; > > 2388 + int rc, rc1, changed = 0; > > > > - again, don't mix initialized and uninitialized variables > > > > [14] > > 2695 +test_server_change(server_info_t *head) { > > 2766 +create_buf_and_notify(char *input, ns_server_status_t st) { > > 2828 +remove_server_thread(void *arg) { > > 2851 +remove_server(char *addr) { > > 2860 +set_server_status(char *input, server_info_t *head) { > > 2805 +static int contact_server(char *addr) { > > > > - bracket on own line, the last one has even type on the same line > > > > [15] > > 2697 + int len = 0, num = 0, ds_len, new_len, tlen = 0; > > 2698 + char *tmp_buf = NULL, *ptr, *status; > > > > - again, don't mix initialized and uninitialized variables > > > > [16] > > - at least small comment to every new function would be welcomed > > > > [17] > > test_server_change() and create_buf_and_notify() > > > > - where do you free tmp_buf? > > > > [18] > > > > 2853 + if (thr_create(NULL, NULL, (void *(*)(void*))remove_server_thread, > > > > - the second parameter is size_t, not pointer > > > > usr/src/lib/libsldap/common/ns_cache_door.h > > =========================================== > > [19] > > 89 + uint32_t data_size; /* if server change: size of data */ > > 90 + char data[sizeof (int)]; /* real size is data_size */ > > > > 95 + uint32_t data_size; /* length of the config string */ > > 96 + char config_str[sizeof (int)]; /* real size is data_size */ > > > > - so which one is truth? uint32_t or int ? Both "doublelines" claim different things > > > > usr/src/lib/libsldap/common/ns_cache_door.c > > =========================================== > > [20] > > - OK, just minor comments to function would be welcomed > > > > usr/src/cmd/ldapcachemgr/cachemgr_change.c > > ========================================== > > [21] > > > > - all functions have definition with bracket on the same line > > > > [22] > > 77 static void > > 78 chg_config_cookie_increment_seq_num(void) { > > 79 (void) mutex_lock(&config_cookie_lock); > > 80 config_cookie.seq_num++; > > 81 (void) mutex_unlock(&config_cookie_lock); > > 82 } > > > > - do we need to lock for atomic incrementation? > > > > [23] > > 91 static int > > 92 chg_cookie_equal(ldap_get_chg_cookie_t *c1, ldap_get_chg_cookie_t *c2) { > > > > - this could be nice to have it as boolean_t > > > > [24] > > 101 static int > > > > - 2 spaces between static and int? > > > > [25] > > 109 info->chg_num++; > > 110 if (info->chg_num > max_threads_allowed) { > > 111 info->chg_num--; > > > > - only question: are you preventing race condition by this ++, >, -- ? > > > > [26] > > - only question: is waiting list thread specific or must be locked by callers (I see no locking there)? > > > > [27] > > 260 int rc = CHG_SUCCESS, len, return_now; > > > > - again, don't mix initialized and uninitialized variables > > > > [28] > > 492 * The door server thead which has the door client pid will be marked > > > > - typo - thead -> thread > > > > [29] > > 510 if (thr_create(NULL, NULL, > > 511 (void *(*)(void*))chg_cleanup_waiting_threads, > > > > - the second parameter is size_t, 0 > > > > - do you need to retype chg_cleanup_waiting_threads()? > > > > 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 Fri May 30 09:07:58 2008 From: Serge.Dussud at Sun.COM (Serge Dussud) Date: Fri, 30 May 2008 18:07:58 +0200 Subject: [Duckwater-discuss] Code-review request for Duckwater Phase 0 (round 2) In-Reply-To: <483EB998.1070308@Sun.COM> References: <483A9DA2.9010408@sun.com> <483EB998.1070308@Sun.COM> Message-ID: <4840265E.8070203@Sun.COM> round 2 of comments attached. Serge -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dw0-review2.txt URL: From Tomas.Heran at Sun.COM Fri May 30 09:11:48 2008 From: Tomas.Heran at Sun.COM (Tomas Heran) Date: Fri, 30 May 2008 18:11:48 +0200 Subject: [Duckwater-discuss] Code-review request for Duckwater Phase 0 In-Reply-To: <1212163551.27652.302.camel@xylabone> References: <483A9DA2.9010408@sun.com> <1212157275.27652.251.camel@xylabone> <48401564.3010606@sun.com> <1212163551.27652.302.camel@xylabone> Message-ID: <48402744.6010604@sun.com> Hopefully Saturday and Sunday would work better for you ;) T. Milan Jurik wrote: > Tomas, > > OK, and [22] you can remove, it's correct. Friday in hot weather, not > good time for code review :-) > > Best regards, > > Milan > > V p?, 30. 05. 2008 v 16:55, Tomas Heran p??e: >> Thanks! >> >> Your comments and our replies and progress addressing your comments will >> be tracked here: >> >> http://opensolaris.org/os/project/duckwater/duckwater_phase0/codereview/milan_ldapcachemgr/ >> >> Tomas >> >> Milan Jurik wrote: >>> Hi, >>> >>> usr/src/cmd/ldapcachemgr/Makefile >>> ================================= >>> [00] >>> >>> 65 -LDLIBS += -lsldap -lldap -lnsl >>> 65 +LDLIBS += -lumem -lsldap >>> >>> Just to be sure - is libumem default memory allocator for ldapcachemgr >>> now? >>> >>> >>> usr/src/cmd/ldapcachemgr/cachemgr.h: >>> =================================== >>> [01] >>> 58 + * In ldap_cachemgr, it return -99 for some case, start with >>> -100 here >>> >>> Where does it return what? >>> >>> [02] lines 69-73 and 88-98 >>> >>> - it would be better to use tabs before comments >>> >>> [03] >>> 122 +extern int is_nscd(pid_t pid); /* in cachemgr.c */ >>> >>> - is_call_from_nscd(), to not confuse libsldap and ldap_cachemgr >>> implementations? >>> >>> usr/src/cmd/ldapcachemgr/cachemgr.c >>> =================================== >>> [04] >>> 579 + * kick off the thread which cleans ups waiting >>> threads for >>> >>> - typo - cleans ups - too much "s"? >>> >>> [05] >>> 583 + if (thr_create(NULL, NULL, >>> 584 + (void *(*)(void*))chg_cleanup_waiting_threads, 0, >>> 0, NULL) != 0) { >>> >>> - the second parameter should be 0 (type is size_t) >>> >>> - do you need to retype chg_cleanup_waiting_threads() ? I think it is >>> correct type already >>> >>> - the 4th argument should be NULL (type is (void *)) >>> >>> [06] >>> 585 + logit("thr_create() >>> chg_cleanup_waiting_thread call failed\n"); >>> >>> 587 + gettext("ldap_cachemgr: thr_create() " >>> 588 + "chg_cleanup_waiting_threads call failed")); >>> >>> >>> - thr_create call failed in chg_cleanup_waiting_thread >>> >>> usr/src/cmd/ldapcachemgr/cachemgr_getldap.c >>> =========================================== >>> [07] >>> 165 + int up; /* TRUE: up, FALSE, down */ >>> >>> - if it is boolean, why not to use boolean_t ? >>> >>> [08] >>> 615 + exitrc = NS_LDAP_SUCCESS; >>> >>> - already initialized exitrc for NS_LDAP_SUCCESS, duplicite line >>> >>> [09] >>> 880 - int reset_bindtime) >>> 771 + int reset_bindtime, info_op_t op) >>> >>> - double tab? >>> >>> [10] >>> 1123 - int matched = FALSE, len, rc = 0; >>> 1124 - char *ret_addr = NULL, *ret_addrFQDN = NULL; >>> 893 + int matched = FALSE, len, rc = 0, main_nscd; >>> 894 + char *ret_addr = NULL, *ret_addrFQDN = NULL, *new_addr; >>> >>> - don't increase mix of initialized and uninitialized variables, it decresase readability, split lines, please >>> >>> [11] >>> 1237 - continue; >>> 1004 + break; >>> >>> - is it possible to remove just one server at time? >>> >>> >>> [12] lines 1893-1965 >>> >>> - why not as static function, to avoid /* FALL THROUGH */? >>> >>> [13] >>> 2585 - int rc, rc1; >>> 2388 + int rc, rc1, changed = 0; >>> >>> - again, don't mix initialized and uninitialized variables >>> >>> [14] >>> 2695 +test_server_change(server_info_t *head) { >>> 2766 +create_buf_and_notify(char *input, ns_server_status_t st) { >>> 2828 +remove_server_thread(void *arg) { >>> 2851 +remove_server(char *addr) { >>> 2860 +set_server_status(char *input, server_info_t *head) { >>> 2805 +static int contact_server(char *addr) { >>> >>> - bracket on own line, the last one has even type on the same line >>> >>> [15] >>> 2697 + int len = 0, num = 0, ds_len, new_len, tlen = 0; >>> 2698 + char *tmp_buf = NULL, *ptr, *status; >>> >>> - again, don't mix initialized and uninitialized variables >>> >>> [16] >>> - at least small comment to every new function would be welcomed >>> >>> [17] >>> test_server_change() and create_buf_and_notify() >>> >>> - where do you free tmp_buf? >>> >>> [18] >>> >>> 2853 + if (thr_create(NULL, NULL, (void *(*)(void*))remove_server_thread, >>> >>> - the second parameter is size_t, not pointer >>> >>> usr/src/lib/libsldap/common/ns_cache_door.h >>> =========================================== >>> [19] >>> 89 + uint32_t data_size; /* if server change: size of data */ >>> 90 + char data[sizeof (int)]; /* real size is data_size */ >>> >>> 95 + uint32_t data_size; /* length of the config string */ >>> 96 + char config_str[sizeof (int)]; /* real size is data_size */ >>> >>> - so which one is truth? uint32_t or int ? Both "doublelines" claim different things >>> >>> usr/src/lib/libsldap/common/ns_cache_door.c >>> =========================================== >>> [20] >>> - OK, just minor comments to function would be welcomed >>> >>> usr/src/cmd/ldapcachemgr/cachemgr_change.c >>> ========================================== >>> [21] >>> >>> - all functions have definition with bracket on the same line >>> >>> [22] >>> 77 static void >>> 78 chg_config_cookie_increment_seq_num(void) { >>> 79 (void) mutex_lock(&config_cookie_lock); >>> 80 config_cookie.seq_num++; >>> 81 (void) mutex_unlock(&config_cookie_lock); >>> 82 } >>> >>> - do we need to lock for atomic incrementation? >>> >>> [23] >>> 91 static int >>> 92 chg_cookie_equal(ldap_get_chg_cookie_t *c1, ldap_get_chg_cookie_t *c2) { >>> >>> - this could be nice to have it as boolean_t >>> >>> [24] >>> 101 static int >>> >>> - 2 spaces between static and int? >>> >>> [25] >>> 109 info->chg_num++; >>> 110 if (info->chg_num > max_threads_allowed) { >>> 111 info->chg_num--; >>> >>> - only question: are you preventing race condition by this ++, >, -- ? >>> >>> [26] >>> - only question: is waiting list thread specific or must be locked by callers (I see no locking there)? >>> >>> [27] >>> 260 int rc = CHG_SUCCESS, len, return_now; >>> >>> - again, don't mix initialized and uninitialized variables >>> >>> [28] >>> 492 * The door server thead which has the door client pid will be marked >>> >>> - typo - thead -> thread >>> >>> [29] >>> 510 if (thr_create(NULL, NULL, >>> 511 (void *(*)(void*))chg_cleanup_waiting_threads, >>> >>> - the second parameter is size_t, 0 >>> >>> - do you need to retype chg_cleanup_waiting_threads()? >>> >>> Best regards, >>> >>> Milan >>> >> _______________________________________________ >> duckwater-discuss mailing list >> duckwater-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/duckwater-discuss > From Nicolas.Williams at sun.com Fri May 30 10:43:19 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 30 May 2008 12:43:19 -0500 Subject: [Duckwater-discuss] [sparks-discuss] Code-review request for Duckwater Phase 0 In-Reply-To: <20080529225540.GE2734@Sun.COM> References: <483A9DA2.9010408@sun.com> <20080528224243.GG1039@Sun.COM> <20080529212945.GB2734@Sun.COM> <20080529225540.GE2734@Sun.COM> Message-ID: <20080530174319.GA2735@Sun.COM> On Thu, May 29, 2008 at 05:55:40PM -0500, Nicolas Williams wrote: > Also, if I understand correctly we could have practically every > process blocked waiting for ldap_cachemgr to do something, is that > correct? If so, then I think this is a bit sub-optimal. I'd much, > much rather we find a way to avoid such waits. I don't mind lots of > processes blocking on nscd, for example, if they are calling getXbyYs > and the name service backends are blocking. After talking to Michen and looking at the code I have these additional comments: - 2^16 threads created with default stack size (1MB for 32-bit programs) is just not possible in a 32-bit program (since that would require a virtual memory address space of 2^36 bytes just for the stacks. So at a bare minimum MAX_CHG_THREADS is set to a number so large that were it tested then ldap_cachemgr would run out of resources. - To date all the other door calls served ldap_cachemgr are non-blocking. Now we're adding a door call that blocks on a condition variable. This means that if the status change door calls consume all available door server threads then the other door calls will block too. I recommend creating a separate door for these blocking calls. Bind a small number of threads to it, or maybe even just one -- no need to have thousands of threads blocking on a condition variable in ldap_cachemgr when they can be blocking on one in the door's knob in the kernel. This way you can have far, far fewer threads in ldap_cachemgr, which a much, much smaller memory footprint. - Please file a CR for determining what stack size we need in ldap_cachemgr and setting its threads' stack sizes to that. Nico -- From Nicolas.Williams at sun.com Fri May 30 11:36:14 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 30 May 2008 13:36:14 -0500 Subject: [Duckwater-discuss] [sparks-discuss] Code-review request for Duckwater Phase 0 In-Reply-To: <20080530174319.GA2735@Sun.COM> References: <483A9DA2.9010408@sun.com> <20080528224243.GG1039@Sun.COM> <20080529212945.GB2734@Sun.COM> <20080529225540.GE2734@Sun.COM> <20080530174319.GA2735@Sun.COM> Message-ID: <20080530183614.GB2735@Sun.COM> 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: 1) Have ldap_cachemgr create a pipe(2) and serve one end to all clients that need to wait for a DS to be available. The client threads will block poll(2)ing on that end of the pipe, and ldap_cachemgr will close the other end when a DS is available. You'll need to prevent a TOCTTOU race by having a "give me a DS or give me a pipe" door call, and you'll need a mutex in ldap_cachemgr around updates to the global var that holds the pipe file descriptors. 2) A variant of the pipe approach: instead of a pipe use a door (not fattach(2)ed anywhere) with no server threads. Clients will block on the door knob by attemting a door_call(2), and the server will wake them by slamming the door (i.e., closing it). This may actually perform better than (1), as I think this approach trivially translates in to a simple condition variable wait/broadcast in the kernel on the door's knob. 3) Use condition variables and mutexes stored in shared memory[*]. Looking at manpages and code this should work, but I see no real code in ONNV that exercises shared synch objects (just filebench), so it's probably not a good idea. I don't recommend this. But if you wanted to do this you'd have ldap_cachemgr create a tmp file, unlink it, mmap() it in, initialize a shared condvar and a shared mutex, and send dup()ed file descriptors for it to its door clients (which would also mmap() it in). I strongly recommend (1) or (2). Nico [*] Shared synch objects need not have the same address in every process. The wait channel for shared synch objects is derived from the vnode and offset into it that the caller-provided synch object address maps to. Brilliant. See _cond_wait() -> cond_wait_common() -> cond_wait_kernel() -> cond_sleep_kernel() lwp_cond_wait() -> get_lwpchan() -> lwpchan_get_mapping() -> as_getmemid() -> SEGOP_GETMEMID() -> seg.*_getmemid(). Three cheers for cscope, hip hip, hurray! From Nicolas.Williams at sun.com Fri May 30 13:12:10 2008 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 30 May 2008 15:12:10 -0500 Subject: [Duckwater-discuss] [sparks-discuss] Code-review request for Duckwater Phase 0 In-Reply-To: <20080530183614.GB2735@Sun.COM> References: <483A9DA2.9010408@sun.com> <20080528224243.GG1039@Sun.COM> <20080529212945.GB2734@Sun.COM> <20080529225540.GE2734@Sun.COM> <20080530174319.GA2735@Sun.COM> <20080530183614.GB2735@Sun.COM> Message-ID: <20080530201210.GF2735@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 --