Re: reproducible panic in netisr

Rick Macklem wrote:
> 
> 
> On Thu, 6 Aug 2009, Julian Elischer wrote:
> 
>> Rick Macklem wrote:
>>>
>>>
>>> On Thu, 6 Aug 2009, Robert Watson wrote:
>>>
>>>> other places where we have very strong alignment requirements on 
>>>> i386/amd64, such as the td_ucred pointer that we check for change on 
>>>> system calls/traps to see if we need to refresh the thread's 
>>>> credential from the process credential.
>>>>
>>> Does this imply that the krpc/nlm/nfs hack of:
>>>     oldcred = td->td_ucred;
>>>     td->td_ucred = "some other cred ptr, such as the mount one"
>>>     ...
>>>     td->td_ucred = oldcred;
>>>
>>> could be dangerous?
>>>
>>> Maybe it should be converted to code that replaces the contents instead
>>> of replacing the *cred? (Variants of the above live in a bunch of places
>>> in the krpc, nlm and nfs code, due to the fact that the socket functions
>>> use td->td_ucred in various places.)
>>
>> no, creds are read-only .. you never change a cred.
>> You alwasy make a new one ans use it, becasue you may be shareing your 
>> cred with hundreds of other sibling threads or processes. (they are 
>> refcounted)
>>
> Righto, yes. So does that imply that the alignment provided by crget()
> { which uses malloc() } is sufficient for td->td_ucred or is td->td_ucred
> a special case?

It should be enough.

> 
> rick
> ps: The above hack, which came up in a separate discussion yesterday,
>     isn't gonna be easy to get rid of, imho. A whole bunch of network
>     related functions use td->td_ucred and the only fix I can see would
>     be to add "*cred" arguments to them all, so that the krpc/nlm/nfs
>     code could pass the correct *cred in. (It is set to the one used at
>     mount time for network reconnects, etc.)

we should probably do the right thign refcount-wise for the ucred
but refcount (atomic) ops are expensive.

> 
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"