Pawel Jakub Dawidek
pjd at FreeBSD.org
Thu Mar 25 03:12:40 PST 2004
On Tue, Mar 23, 2004 at 06:16:31PM -0500, Robert Watson wrote:
+> > For example: 'td' can be NULL? It is offten tested, but not always,
+> > Line 290:
+> > if (sin->sin_addr.s_addr != INADDR_ANY)
+> > if (prison_ip(td->td_ucred, 0, &sin->sin_addr.s_addr))
+> > return(EINVAL);
+> > td_ucred is used, but 'td' is not tested.
+> > If this is always current thread, it can't be NULL, right? If this not
+> > have to be current thread, we cannot touch td_ucred here, because (from
+> > proc.h):
+> Prior to FreeBSD 5.x, curproc could be NULL in interrupt context. With
+> the introduction of curthread and the move to interrupt threads, curthread
+> became always non-NULL. However, sometimes the use of curthread may not
+> make sense. :-) I think I'd prefer it if we passed an explicit
+> credential into a number of these situations, which could be NULL if "the
+> system" was requesting a service as opposed to an explicit user process.
+> However, I'm not 100% convinced that is the right approach either. Note
+> that we have some similar "confusions" relating to use of cached
+> credentials in sockets, etc. The whole issue probably needs to be
+> discussed after some detailed analysis, and revisited.
Ok, I've add few line at start of in_pcbbind_setup():
if (td == NULL)
printf("NULL td in %s\n", __func__);
if (td != curthread)
printf("td != curthread in %s\n", __func__);
And I'm seeing 2nd printf() while mounting NFS file systems.
If so, I think using td->td_ucred in this function isn't safe...
Pawel Jakub Dawidek http://www.FreeBSD.org
pjd at FreeBSD.org http://garage.freebsd.pl
FreeBSD committer Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20040325/7e81fd69/attachment.bin
More information about the freebsd-net