[OpenAFS-devel] Re: OpenAFS Master Repository branch, master, updated.
BP--openafs-stable-1_6_x-32-g2ea508e
Matt W. Benjamin
matt@linuxbox.com
Wed, 25 Aug 2010 20:37:28 -0400 (EDT)
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