While I was reviewing the rest of the kernel tree, I also found... /cboss/p4/rwatson/trustedbsd/mac/sys/fs/fifofs/fifo_vnops.c:
error = sosend(wso, (struct sockaddr *)0, ap->a_uio, 0, /cboss/p4/rwatson/trustedbsd/mac/sys/fs/portalfs/portal_vnops.c: error = sosend(so, (struct sockaddr *) 0, &auio, These also strike me as similarly incorrect and fixable. Of course, fifofs and portalfs are both home to much evil, so... Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories On Wed, 2 Oct 2002, Robert Watson wrote: > > I was groping around through the socket code today looking for more places > to sprinkle mandatory access control magic, and noticed that in most parts > of the system call and protocol-independent socket implementation, > sosend() is never invoked directly: instead, pru_sosend() is invoked, and > protocols have the option of implementing pru_sosend() using the central > sosend(), or providing their own optimized implementation. However, the > exception to this appears to be in the nfsclient code, where sosend is > invoked directly on the socket: > > bootp_subr.c- > bootp_subr.c: error = sosend(so, (struct sockaddr *) &dst, > bootp_subr.c- &auio, NULL, NULL, 0, td); > bootp_subr.c- if (error != 0) { > > ... > > krpc_subr.c- } > krpc_subr.c: error = sosend(so, (struct sockaddr *)sa, NULL, m, > krpc_subr.c- NULL, 0, td); > krpc_subr.c- if (error) { > > It strikes me that instead it should be calling: > > error = so->so_proto->pr_usrreqs->pru_sosend(...) > > So that protocols can implement sosend as they see fit. The NFS server > code appears to do this fine. Is this interpretation correct? > > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > [EMAIL PROTECTED] Network Associates Laboratories > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message