From sacadmin Wed Nov 28 13:44:24 2007 Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lASLiNOG008289; Wed, 28 Nov 2007 13:44:23 -0800 (PST) Received: (from sommerfe@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id lASLiNaH008285; Wed, 28 Nov 2007 13:44:23 -0800 (PST) Date: Wed, 28 Nov 2007 13:44:23 -0800 (PST) From: William Sommerfeld Message-Id: <200711282144.lASLiNaH008285@sac.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Subject: db_credp update [PSARC/2007/670 Self Review] Status: RO Content-Length: 553 Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: db_credp update 1.2. Name of Document Author/Supplier: Author: Erik Nordmark 1.3 Date of This Document: 28 November, 2007 4. Technical Description See the case directory for more detail 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: Automatic 6.6. ARC Exposure: open From sommerfeld@sun.com Wed Nov 28 13:45:10 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lASLjA4C008322 for ; Wed, 28 Nov 2007 13:45:10 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lASLj9TK000131; Wed, 28 Nov 2007 21:45:09 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JS80010BKF8QD00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 28 Nov 2007 13:45:08 -0800 (PST) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JS800KZ0KF7RX40@nwk-avmta-1.sfbay.Sun.COM>; Wed, 28 Nov 2007 13:45:07 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lASLj6Cc044649; Wed, 28 Nov 2007 16:45:06 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id lASLj5pe020425; Wed, 28 Nov 2007 16:45:06 -0500 (EST) Date: Wed, 28 Nov 2007 16:45:05 -0500 From: Bill Sommerfeld Subject: 2007/670 db_credp update To: PSARC-EXT Cc: Erik Nordmark Message-id: <1196286305.19477.107.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.12.1 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 3223 I'm filing the following self-reviewed case for Erik Nordmark. It proposes changes to Consolidation Private interfaces which increase the robustness of db_credp handling. A Patch release binding is requested. The motivation for the changes are: 6619593 Simplify and strengthen db_credp handling 6619596 Add getpeerucred() support to SCTP SOCK_STREAM PSARC 2002/188 ("Least Privilege for Solaris") introduced DB_CRED, allocb_tmpl etc as follows: -------------------------------------------------------------------------- |DB_CRED DB_CREDDEF |Consolidation |STREAMS | | |Private |macros | +-------------------------------------------+--------------+-------------+ |allocb_tmpl |Evolving |Kernel | | | |function to | | | |allocate mblk| | | |from template| +-------------------------------------------+--------------+-------------+ |allocb_cred allocb_cred_wait |Consolidation |Kernel | | |Private |function to | | | |allocate mblk| | | |with cred | +-------------------------------------------+--------------+-------------+ |mblk_setcred |Consolidation |Kernel | | |Private |function to | | | |set cred in | | | |mblk | -------------------------------------------------------------------------- This case implements the following changes: - It removes the DB_CREDDEF macro. - No changes to allocb_tmpl. - allocb_cred, allocb_cred_wait, and mblk_setcred are modified to take an additional pid_t argument (to more easily ensure that db_cpid and db_credp are consistent) - Adding two new Consolidation Private interfaces cred_t *msg_getcred(mblk_t *, pid_t *); cred_t *msg_extractcred(mblk_t *, pid_t *) The pid_t pointer can be NULL if the caller doesn't care. msg_getcred() finds the first non-NULL db_credp in the message b_cont chain and returns it, plus any db_cpid in that mblk. msg_extractcred() is a variant of msg_getcred() which clears the db_credp it finds hence returns with a held cred_t (or NULL). That avoids a crhold/rele pair in performance critical paths. SCTP in PSARC 2003/586 introduced some consolidation private interfaces that are modified by this case. Those are: | struct sctp_upcalls_s | Consolidation Private | | | SCTP_ITF_VER | Consolidation Private | | This fasttrack will add an additional function pointer, su_ucred, to the upcall structure in order to pass cred_t and pid_t from SCTP to sockfs, and as result of that addition we are increasing the SCTP_ITF_VER version number. From carlsonj@phorcys.east.sun.com Wed Nov 28 13:54:10 2007 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lASLs9wu008581 for ; Wed, 28 Nov 2007 13:54:09 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lASLrxAj001732; Thu, 29 Nov 2007 05:54:06 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JS80090DKU6SA00@nwk-avmta-2.sfbay.sun.com>; Wed, 28 Nov 2007 13:54:06 -0800 (PST) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JS800732KU4HW40@nwk-avmta-2.sfbay.sun.com>; Wed, 28 Nov 2007 13:54:05 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id lASLrAOi024673; Wed, 28 Nov 2007 16:53:10 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id lASLr9xq024670; Wed, 28 Nov 2007 16:53:09 -0500 (EST) Date: Wed, 28 Nov 2007 16:53:09 -0500 From: James Carlson Subject: Re: 2007/670 db_credp update In-reply-to: <1196286305.19477.107.camel@thunk> To: Bill Sommerfeld Cc: PSARC-EXT , Erik Nordmark Message-id: <18253.58181.524326.980921@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <1196286305.19477.107.camel@thunk> Status: RO Content-Length: 1474 Bill Sommerfeld writes: > - Adding two new Consolidation Private interfaces > cred_t *msg_getcred(mblk_t *, pid_t *); > cred_t *msg_extractcred(mblk_t *, pid_t *) > The pid_t pointer can be NULL if the caller doesn't care. > > msg_getcred() finds the first non-NULL db_credp in > the message b_cont chain and returns it, plus any db_cpid in that mblk. > msg_extractcred() is a variant of msg_getcred() which clears the db_credp it > finds hence returns with a held cred_t (or NULL). That avoids a crhold/rele > pair in performance critical paths. The behavior of msg_extractcred seems a little unclear. Is it possible for an mblk_t b_cont chain to have two or more mblk_t entries with non-NULL db_credp? If so, then extracting can have the strange side-effect of uncovering old creds unless the function continues through the rest of the b_cont chain, clearing out and discarding any creds it finds. > This fasttrack will add an additional function pointer, su_ucred, to the > upcall structure in order to pass cred_t and pid_t from SCTP to sockfs, > and as result of that addition we are increasing the SCTP_ITF_VER > version number. Version number? Are there users of this interface outside of ON? -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From erik.nordmark@sun.com Wed Nov 28 15:00:07 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lASN06Fo009479 for ; Wed, 28 Nov 2007 15:00:07 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lASN01XU010905; Wed, 28 Nov 2007 23:00:03 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JS80010DNW1HL00@brm-avmta-1.central.sun.com>; Wed, 28 Nov 2007 16:00:01 -0700 (MST) Received: from jurassic.eng.sun.com ([129.146.226.130]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JS800CBJNW0OE70@brm-avmta-1.central.sun.com>; Wed, 28 Nov 2007 16:00:00 -0700 (MST) Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lASMxxl3331255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Nov 2007 15:00:00 -0800 (PST) Date: Wed, 28 Nov 2007 14:59:59 -0800 From: Erik Nordmark Subject: Re: 2007/670 db_credp update In-reply-to: <18253.58181.524326.980921@gargle.gargle.HOWL> To: James Carlson Cc: Bill Sommerfeld , PSARC-EXT Message-id: <474DF2EF.7060802@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <1196286305.19477.107.camel@thunk> <18253.58181.524326.980921@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.4 (X11/20070723) Status: RO Content-Length: 1802 James Carlson wrote: > The behavior of msg_extractcred seems a little unclear. Is it > possible for an mblk_t b_cont chain to have two or more mblk_t entries > with non-NULL db_credp? If so, then extracting can have the strange > side-effect of uncovering old creds unless the function continues > through the rest of the b_cont chain, clearing out and discarding any > creds it finds. That isn't the use case for msg_extractcred(). The use case if the need to efficiently move a cred/cpid from one message (e.g., a TCP/IP packet with a SYN) to another message (e.g., a T_CONN_IND) and then discard the original message. Functionally that can be done using msg_getcred+crhold+mblk_setcred+freemsg, but that incurs the overhead of an extra crhold+crrele, and Casper told me that those refcnt manipulations might be expensive. Since there was existing code which (through manual manipulation of db_credp/db_cpid) did that without the extra crhold/rele, it made sense to not degrade performance by introducing an extra consolidation private interface for this. >> This fasttrack will add an additional function pointer, su_ucred, to the >> upcall structure in order to pass cred_t and pid_t from SCTP to sockfs, >> and as result of that addition we are increasing the SCTP_ITF_VER >> version number. > > Version number? Yes, the ARC review process encourages folks to think about versioning their interfaces ;-) > Are there users of this interface outside of ON? There are no contracted users of this interface. However, we know that one customer which has a kernel protocol stack on top of SCTP has been told about this interface (including its lack of stability) and we are working with them to have them be able to easily move to the new version of the interface. Erik From carlsonj@phorcys.east.sun.com Thu Nov 29 04:45:48 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lATCjlKc029289 for ; Thu, 29 Nov 2007 04:45:47 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lATCjdxf006848; Thu, 29 Nov 2007 12:45:45 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JS90020PQ47QM00@brm-avmta-1.central.sun.com>; Thu, 29 Nov 2007 05:45:43 -0700 (MST) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JS900DAQQ460MF0@brm-avmta-1.central.sun.com>; Thu, 29 Nov 2007 05:45:42 -0700 (MST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id lATCimoN026188; Thu, 29 Nov 2007 07:44:48 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id lATCimsZ026185; Thu, 29 Nov 2007 07:44:48 -0500 (EST) Date: Thu, 29 Nov 2007 07:44:47 -0500 From: James Carlson Subject: Re: 2007/670 db_credp update In-reply-to: <474DF2EF.7060802@sun.com> To: Erik Nordmark Cc: Bill Sommerfeld , PSARC-EXT Message-id: <18254.46143.889641.756662@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <1196286305.19477.107.camel@thunk> <18253.58181.524326.980921@gargle.gargle.HOWL> <474DF2EF.7060802@sun.com> Status: RO Content-Length: 1678 Erik Nordmark writes: > James Carlson wrote: > > > The behavior of msg_extractcred seems a little unclear. Is it > > possible for an mblk_t b_cont chain to have two or more mblk_t entries > > with non-NULL db_credp? If so, then extracting can have the strange > > side-effect of uncovering old creds unless the function continues > > through the rest of the b_cont chain, clearing out and discarding any > > creds it finds. > > That isn't the use case for msg_extractcred(). > The use case if the need to efficiently move a cred/cpid from one > message (e.g., a TCP/IP packet with a SYN) to another message (e.g., a > T_CONN_IND) and then discard the original message. OK. It sounds like that usage pattern is part of the interface definition. > > Version number? > > Yes, the ARC review process encourages folks to think about versioning > their interfaces ;-) Indeed. Though just adding a version number usually doesn't do the trick, and is often meaningless if there's only one consumer in the same consolidation. :-/ > > Are there users of this interface outside of ON? > > There are no contracted users of this interface. > > However, we know that one customer which has a kernel protocol stack on > top of SCTP has been told about this interface (including its lack of > stability) and we are working with them to have them be able to easily > move to the new version of the interface. OK; that's a good reason. Thanks ... -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sommerfeld@sun.com Thu Nov 29 06:54:28 2007 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lATEsR6N001549 for ; Thu, 29 Nov 2007 06:54:27 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lATEsJ3L011208; Thu, 29 Nov 2007 22:54:22 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JS900F07W2KP300@nwk-avmta-1.sfbay.Sun.COM>; Thu, 29 Nov 2007 06:54:20 -0800 (PST) Received: from localhost.east.sun.com ([129.148.19.3]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JS9007ZPW2JWX40@nwk-avmta-1.sfbay.Sun.COM>; Thu, 29 Nov 2007 06:54:19 -0800 (PST) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id lATEqIBO006408; Thu, 29 Nov 2007 09:52:18 -0500 (EST) Received: (from sommerfeld@localhost) by localhost.east.sun.com (8.14.1+Sun/8.14.1/Submit) id lATEqIdT006407; Thu, 29 Nov 2007 09:52:18 -0500 (EST) Date: Thu, 29 Nov 2007 09:52:17 -0500 From: Bill Sommerfeld Subject: Re: 2007/670 db_credp update In-reply-to: <474DF2EF.7060802@sun.com> To: Erik Nordmark Cc: James Carlson , PSARC-EXT Message-id: <1196347937.6305.30.camel@localhost> MIME-version: 1.0 X-Mailer: Evolution 2.12.0 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <1196286305.19477.107.camel@thunk> <18253.58181.524326.980921@gargle.gargle.HOWL> <474DF2EF.7060802@sun.com> X-Authentication-warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Status: RO Content-Length: 546 On Wed, 2007-11-28 at 14:59 -0800, Erik Nordmark wrote: > That isn't the use case for msg_extractcred(). > The use case if the need to efficiently move a cred/cpid from one > message (e.g., a TCP/IP packet with a SYN) to another message (e.g., a > T_CONN_IND) and then discard the original message. Random idea: If msg_extractcred() freed the message it was passed, it would be harder to use incorrectly and might actually work for all current use cases. Can we do that without making the code around it overly convoluted? - Bill From erik.nordmark@sun.com Tue Dec 4 14:04:35 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lB4M4Y7n013474 for ; Tue, 4 Dec 2007 14:04:34 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lB4M4Xw4004274; Tue, 4 Dec 2007 14:04:33 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSJ00B0PPBI8Q00@brm-avmta-1.central.sun.com>; Tue, 04 Dec 2007 15:04:30 -0700 (MST) Received: from jurassic.eng.sun.com ([129.146.17.55]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSJ00M97PBIJNC0@brm-avmta-1.central.sun.com>; Tue, 04 Dec 2007 15:04:30 -0700 (MST) Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lB4M4T41625068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 04 Dec 2007 14:04:30 -0800 (PST) Date: Tue, 04 Dec 2007 14:04:25 -0800 From: Erik Nordmark Subject: Re: 2007/670 db_credp update In-reply-to: <1196347937.6305.30.camel@localhost> To: Bill Sommerfeld Cc: James Carlson , PSARC-EXT Message-id: <4755CEE9.8020508@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <1196286305.19477.107.camel@thunk> <18253.58181.524326.980921@gargle.gargle.HOWL> <474DF2EF.7060802@sun.com> <1196347937.6305.30.camel@localhost> User-Agent: Thunderbird 2.0.0.4 (X11/20070723) Status: RO Content-Length: 1924 Bill Sommerfeld wrote: > On Wed, 2007-11-28 at 14:59 -0800, Erik Nordmark wrote: >> That isn't the use case for msg_extractcred(). >> The use case if the need to efficiently move a cred/cpid from one >> message (e.g., a TCP/IP packet with a SYN) to another message (e.g., a >> T_CONN_IND) and then discard the original message. > > Random idea: > > If msg_extractcred() freed the message it was passed, it would be harder > to use incorrectly and might actually work for all current use cases. > > Can we do that without making the code around it overly convoluted? The dangers of writing from memory and not from code ... The above is one of the cases when the code uses msg_extractcred. But there is another type of use where the mblk is not discarded but instead the cred it moved. An example of the latter use pattern is handling a RPC request (NFS/UDP) in the kernel when a cred is in the T_UNITDATA_IND message and needs to be moved/reused for the T_UNITDATA_REQ. It is desirable to not have to do extra crhold/crrele in that case. Going back to Jim's original concern it was: > The behavior of msg_extractcred seems a little unclear. Is it > possible for an mblk_t b_cont chain to have two or more mblk_t entries > with non-NULL db_credp? If so, then extracting can have the strange > side-effect of uncovering old creds unless the function continues > through the rest of the b_cont chain, clearing out and discarding any > creds it finds. From the semantics of db_credp it is undefined when it means to have a message with more than one mblk with db_credp set; the credentials are associated with the message. In that undefined case msg_extractcred will behave in a predictable manner (take the first non-NULL db_credp just like msg_getcred). Given the usage of this private interface I don't see a need to slow it down to handle a case whose behavior is undefined to start with. Erik From sommerfeld@sun.com Wed Dec 5 09:48:16 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lB5HmFrF005288 for ; Wed, 5 Dec 2007 09:48:16 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lB5HlxH3010319; Wed, 5 Dec 2007 17:48:12 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSL00B0584BKV00@brm-avmta-1.central.sun.com>; Wed, 05 Dec 2007 10:48:11 -0700 (MST) Received: from localhost.east.sun.com ([129.148.19.3]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSL005L984AV540@brm-avmta-1.central.sun.com>; Wed, 05 Dec 2007 10:48:10 -0700 (MST) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id lB5HmAL4003143; Wed, 05 Dec 2007 12:48:10 -0500 (EST) Received: (from sommerfeld@localhost) by localhost.east.sun.com (8.14.1+Sun/8.14.1/Submit) id lB5HmA5Z003142; Wed, 05 Dec 2007 12:48:10 -0500 (EST) Date: Wed, 05 Dec 2007 12:48:09 -0500 From: Bill Sommerfeld Subject: Re: 2007/670 db_credp update In-reply-to: <4755CEE9.8020508@sun.com> To: Erik Nordmark Cc: James Carlson , PSARC-EXT Message-id: <1196876889.1077.62.camel@localhost> MIME-version: 1.0 X-Mailer: Evolution 2.12.0 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <1196286305.19477.107.camel@thunk> <18253.58181.524326.980921@gargle.gargle.HOWL> <474DF2EF.7060802@sun.com> <1196347937.6305.30.camel@localhost> <4755CEE9.8020508@sun.com> X-Authentication-warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Status: RO Content-Length: 1221 On Tue, 2007-12-04 at 14:04 -0800, Erik Nordmark wrote: > An example of the latter use pattern is handling a RPC request (NFS/UDP) > in the kernel when a cred is in the T_UNITDATA_IND message and needs to > be moved/reused for the T_UNITDATA_REQ. It is desirable to not have to > do extra crhold/crrele in that case. ok. never mind then. > From the semantics of db_credp it is undefined when it means to have a > message with more than one mblk with db_credp set; the credentials are > associated with the message. > > In that undefined case msg_extractcred will behave in a predictable > manner (take the first non-NULL db_credp just like msg_getcred). Given > the usage of this private interface I don't see a need to slow it down > to handle a case whose behavior is undefined to start with. this is a code review-ish comment (but is architectural to the extent that innocuous behavior in response to undefined input can evolve into de-facto expected behavior over time): if the behavior is undefined, then IMHO it makes sense to make steps into undefined territory fail in a DEBUG kernel (via asserts, etc.,) to make it less likely that code manipulating message creds works by accident. - Bill