Date: Wed, 27 Nov 2002 12:33:50 +1100 From: Tim Robbins <tjr@FreeBSD.org> To: Robert Watson <rwatson@FreeBSD.org> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/netsmb smb_trantcp.c Message-ID: <20021127123350.A11691@dilbert.robbins.dropbear.id.au> In-Reply-To: <Pine.NEB.3.96L.1021126190200.10316A-100000@fledge.watson.org>; from rwatson@FreeBSD.org on Tue, Nov 26, 2002 at 07:02:42PM -0500 References: <200211262353.gAQNrSLi021861@repoman.freebsd.org> <Pine.NEB.3.96L.1021126190200.10316A-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Nov 26, 2002 at 07:02:42PM -0500, Robert Watson wrote:
>
> On Tue, 26 Nov 2002, Tim J. Robbins wrote:
>
> > tjr 2002/11/26 15:53:28 PST
> >
> > Modified files:
> > sys/netsmb smb_trantcp.c
> > Log:
> > Fix a fatal typo introduced in revision 1.13 that caused the mbuf chains to
> > be created incorrectly for requests larger than NB_SORECEIVE_CHUNK bytes.
> >
> > Approved by: re
>
> Tim, thanks for working on this! Do we know what shape we're in now WRT
> smbfs stability and functionality generally? Can I check off smbfs
> entirely in our TODO list, or is this just a piece of the picture?
A bug in m_getm() is still preventing it from working properly. I'll send
the patch to re@ for approval shortly. After I commit that, smbfs should
being working as well on -current as it does on -stable.
I've seen these two panics in the past few days while stressing out the
code. I think they exist in -stable too.
"panic: mutex srslock not owned", coming from this in netsmb/smb_iod.c:
/*
* Invalidate all outstanding requests for this connection
*/
SMB_IOD_RQLOCK(iod);
TAILQ_FOREACH(rqp, &iod->iod_rqlist, sr_link) {
if (rqp->sr_flags & SMBR_INTERNAL)
SMBRQ_SUNLOCK(rqp);
^^^^^^^^^^^^^^^^^^^
On uniprocessor 4.x kernels, SMBRQ_SUNLOCK expands to nothing at all, so
trying to unlock something that isn't locked does not get detected.
I still can't figure out why the unlock is here at all, but it's unsafe
and will cause panics on -current and 4.x SMP kernels.
"panic: getnewvnode: free vnode isn't", unknown cause.
So, smbfs works fine as long as you are careful, don't use umount -f, and
don't disconnect the client from the server without unmounting the share.
Tim
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021127123350.A11691>