Date: Wed, 4 Feb 2015 07:30:50 +0000 From: "rrs (Randall Stewart)" <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: <48e7206f1f28e06b09422fab39999099@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
rrs added a comment. 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... 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?48e7206f1f28e06b09422fab39999099>