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
