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
