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
