Date: Thu, 6 Aug 2009 16:32:25 -0400 (EDT) From: Rick Macklem <rmacklem@uoguelph.ca> To: Julian Elischer <julian@elischer.org> Cc: Robert Watson <rwatson@FreeBSD.org>, jeff@FreeBSD.org, "Bjoern A. Zeeb" <bz@FreeBSD.org>, freebsd-current@FreeBSD.org, kib@FreeBSD.org, Navdeep Parhar <np@FreeBSD.org>, Larry Rosenman <ler@lerctr.org>, lstewart@FreeBSD.org Subject: Re: reproducible panic in netisr Message-ID: <Pine.GSO.4.63.0908061625200.6808@muncher.cs.uoguelph.ca> In-Reply-To: <4A7B27DD.20503@elischer.org> References: <20090804225806.GA54680@hub.freebsd.org> <20090805054115.O93661@maildrop.int.zabbadoz.net> <20090805063417.GA10969@doormat.home> <alpine.BSF.2.00.0908060011490.59996@fledge.watson.org> <alpine.BSF.2.00.0908060834120.21318@thebighonker.lerctr.org> <alpine.BSF.2.00.0908061508520.62916@fledge.watson.org> <Pine.GSO.4.63.0908061038120.22077@muncher.cs.uoguelph.ca> <4A7AF25D.40608@elischer.org> <Pine.GSO.4.63.0908061131220.3240@muncher.cs.uoguelph.ca> <4A7B27DD.20503@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 6 Aug 2009, Julian Elischer wrote:
>> Righto, yes. So does that imply that the alignment provided by crget()
>> { which uses malloc() } is sufficient for td->td_ucred or is td->td_ucred
>> a special case?
>
> It should be enough.
>
Ok, that's good news.
>
> we should probably do the right thign refcount-wise for the ucred
> but refcount (atomic) ops are expensive.
>
In the clnt_rc.c case, it does do a crdup(), although I think a
crhold() would have been sufficient. In the nlm, there is a case
where the mount point cred gets used without a crhold() and that
does cause panics for pho@'s tests related to "umount -f". I have
a fix for that one, which is waiting for a Doug R. review. (It
only affects "umount -f", which I think still has other issues,
so I haven't tried to push for it getting into head.)
So, yes, I think that the refcount issue is being handled, rick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.63.0908061625200.6808>