Re: pru & stat(2) failure / return cleanups

[Iain Hibbert <plunky%ogmig.net@localhost>]

On Mon, 7 Jul 2014, Tyler Retzlaff wrote:

> On Sun, Jul 06, 2014 at 09:44:05PM +0100, Iain Hibbert wrote:
> > On Mon, 7 Jul 2014, Tyler Retzlaff wrote:
> > >
> > >     for protocols that allocate a pcb in attach should it ever be valid
> > >     for socket->so_pcb to be NULL (except upon entry to attach)?
> > >
> > I do not remember exactly why, but in the Bluetooth (sys/netbt/) socket
> > code, error is only returned for (so_pcb == NULL) after PRU_CONTROL,
> > PRU_PURGEIF and PRU_ATTACH are handled. It probably means that I found
> > somewhere that called those functions without a pcb .. at least
> > PRU_CONTROL and PRU_PURGEIF are reached through ioctl() I don't know if
> > that is relevant
>
> okay, for the netbt protocols i'll make sure to retain existing
> behavior.

please don't provide special handling for any protocol family; PRU_PURGEIF
at least is unused with the Bluetooth protocol. I'm just pointing out that
it might be possible for them to pass a NULL so_pcb, since code handles
them before it tests for that.

> i didn't mention PRU_PURGEIF but you're right the existing
> code does handle it differently in advance of testing so_pcb.

it is only called, that I can see by if_detach() in net/if.c, and so_pcb
will definitely be NULL in that case. To be honest, this is an invasion of
the usrreq for some unrelated task IMO .. just provide another function
for this, that does not require a fake socket pointer.

> for those requests that aren't PRU_CONTROL, PRU_PURGEIF, PRU_ATTACH we
> will likely go as far as KASSERT that so_pcb is not NULL. i'm not sure if
> the gallery has any thoughts on doing so?

If you examine all the calling paths and ensure that a user *cannot* pass
a NULL so_pcb to these functions then it seems ok to me.. otherwise it
should really return EINVAL as before

iain