Date: Wed, 4 Feb 2015 10:44:28 +0000 From: "hiren (hiren panchasara)" <phabric-noreply@FreeBSD.org> To: freebsd-net@freebsd.org Subject: [Differential] [Commented On] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests). Message-ID: <af527b6ed8ef372cc67e3dd6a11d8c48@localhost.localdomain> In-Reply-To: <differential-rev-PHID-DREV-vhk6ww63dvpj6egspuyt-req@FreeBSD.org> References: <differential-rev-PHID-DREV-vhk6ww63dvpj6egspuyt-req@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
hiren added a comment. >>! In D1711#59, @rrs wrote: > Hiren: > > Ok looking at kern_timeout.c thats a call to > class->lc_lock(c_lock, lock_status); > > If my 10.x matches yours. > > And the call inside that kern_rwlock.c:757 > is > > v = rw->rw_lock; > owner = (struct thread *)RW_OWNER(v); > > I would imagine v is probably a freed lock or some such.. not sure. > If you have a vmcore sending the registers would be helpful. And for that > matter if you have a vmcore if you could get in the frame of kern_timeout > and tell me what > c_lock > c_func > are that would be helpful. I have not tested this with my test framework for locks > that pass in a lock.. If the c_func is not some private thing but something in > BSD I can puzzle out what sub-system is using the callout this way and > try to reproduce a test that will blow up this way on me as well. > > Assuming of course its not the caller that has freed the > lock ahead of the callout system running... panic #3 happened on stable-10+this patch. I've setup a -head box with this patch to reproduce the problem. In any case, I'll try to get vmcore and other details tomorrow. REVISION DETAIL https://reviews.freebsd.org/D1711 To: rrs, gnn, rwatson, lstewart, jhb, kostikbel, hselasky, adrian, imp, sbruno Cc: hiren, jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?af527b6ed8ef372cc67e3dd6a11d8c48>