kern/103127: Kernel panic while using thread features in Squid 2.6

[John Baldwin]

On Friday 22 September 2006 16:13, John-Mark Gurney wrote:
> John Baldwin wrote this message on Fri, Sep 22, 2006 at 14:25 -0400:
> > On Thursday 21 September 2006 22:37, John-Mark Gurney wrote:
> > > John Baldwin wrote this message on Thu, Sep 21, 2006 at 21:52 -0400:
> > > > On Wednesday 20 September 2006 17:05, John-Mark Gurney wrote:
> > > > > Synopsis: Kernel panic while using thread features in Squid 2.6
> > > > > 
> > > > > State-Changed-From-To: open->feedback
> > > > > State-Changed-By: jmg
> > > > > State-Changed-When: Wed Sep 20 21:04:55 UTC 2006
> > > > > State-Changed-Why: 
> > > > > waiting for people to test the patch of badfo_kqfilter that is 
attached
> > > > > to the bug..
> > > > 
> > > > Should it possibly return EBADF rather than EINVAL?
> > > 
> > > If we got this far, we have to have a valid fd, maybe ENXIO?
> > 
> > badfo_* are used for bad (invalid) file descriptors. :)  All the other 
badfo_* 
> > functions return EBADF (except for poll, since it returns an event mask 
> > rather than an errno).
> 
> except we did have a valid fd since we did an fget on the
> descriptor, and that would fail if it was bad:
>         if ((fp = fget_locked(fdp, fd)) == NULL || fp->f_ops == &badfileops) 
{
>                 FILEDESC_UNLOCK(fdp);
>                 return (EBADF);
>         }
> 
> or can f_ops change in the middle?
> 
> >From my reading it looks like it can can during a close, but if the
> application is doing a simultanious close and attaching a knote, that's
> a race condition, and we techincally still have a valid fd till was
> can't fget the fd anymore...  just MO of course...

No, not really.  We did an fget() and have a valid file pointer, but the file 
was closed in between fget() and using of the file.  Once the file is closed, 
it's bad, and EBADF is the appropriate way to smack the userland app upside 
the head for its bug.

-- 
John Baldwin