[OpenAFS-devel] Re: OpenAFS Master Repository branch, master, updated. BP--openafs-stable-1_6_x-32-g2ea508e

[Matt W. Benjamin]

Yes, sure.  Unless someone else objects, I'll make soclose unconditional.  I was thinking about nixing it with the previous patch, but decided we should deal with it separately.

Matt

----- "Benjamin Kaduk" <kaduk@mit.edu> wrote:

> On Wed, 25 Aug 2010, Matt W. Benjamin wrote:
> 
> > Hi Ben,
> >
> > I have tested both unmounting /afs, and rebooting with AFS mounted. 
> I 
> > haven't attempted to load and start AFS again after unmounting.  So
> I 
> > don't think this could be a regression.
> 
> Would you mind testing the mount-unmount-unload-reload-mount cycle
> when 
> you get a chance?  My test box is having some issues at the moment
> (it's 
> unclear if this is FreeBSD HEAD making it harder for us to hook the 
> syscall table or an afsd regression or me doing something stupid).
> 
> >
> > More importantly, consider two points.  First, the race between 
> > osi_NetReceive and osi_StopListener with immediate soclose typically
> 
> > results in the osi_NetReceive thread attempting illegal accesses to
> 
> > various objects associated with rx_socket.  Second, we perform we
> can
> 
> I do believe I've seen panics from that race, yes.
> 
> > only perform one legitimate soclose on rx_socket, and we do perform
> it, 
> > conditionally, after the wait.  The conditionally part may point to
> an 
> > issue--I don't actually remember who introduced the notion of making
> 
> > soclose conditional on so_is_disconn--if in fact we do omit to
> soclose, 
> > I'd suggest removing the condition (and supporting macro).
> 
> That is probably reasonable. Though, of course, finding out if we do
> omit 
> the call to soclose depends on testing it, which we apparently haven't
> 
> done recently.
> Given that """
>   * soclose() destroys a socket after possibly waiting for it to
> disconnect.
>   * This is a public interface that socket consumers should use to
> close and
>   * release a socket when done with it.
> """
> it would seem that the so_is_disconn check is probably bogus.
> 
> -Ben

-- 

Matt Benjamin

The Linux Box
206 South Fifth Ave. Suite 150
Ann Arbor, MI  48104

http://linuxbox.com

tel. 734-761-4689
fax. 734-769-8938
cel. 734-216-5309