Date: Mon, 10 Jun 2013 14:04:12 +0200 From: Julian Stecklina <jsteckli@os.inf.tu-dresden.de> To: John Baldwin <jhb@freebsd.org>, freebsd-stable@freebsd.org Subject: Re: Reproducable Infiniband panic Message-ID: <51B5C0BC.2000402@os.inf.tu-dresden.de> In-Reply-To: <201306071206.52994.jhb@freebsd.org> References: <51B07705.207@os.inf.tu-dresden.de> <201306061457.52278.jhb@freebsd.org> <51B1A2D6.4030901@os.inf.tu-dresden.de> <201306071206.52994.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 06/07/2013 06:06 PM, John Baldwin wrote: > On Friday, June 07, 2013 5:07:34 am Julian Stecklina wrote: >> On 06/06/2013 08:57 PM, John Baldwin wrote: >>> On Thursday, June 06, 2013 9:54:35 am Andriy Gapon wrote: >> [...] >>>> The problem seems to be in incorrect interaction between devfs_close_f > and >>>> linux_file_dtor. The latter expects curthread->td_fpop to have a valid > reasonable >>>> value. But the former sets curthread->td_fpop to fp only around > vnops.fo_close() >>>> call and then restores it back to some (what?) previous value before > calling >>>> devfs_fpdrop->devfs_destroy_cdevpriv. In this case the previous value is > NULL. >>> >>> It is normally NULL in this case. Why does linux_file_dtor even look at >>> td_fpop? >>> >>> Ah. I think it should not do that and make the data it uses in the dtor > more >>> self-contained: [...] Seems to fix my panic. Thanks! Julian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51B5C0BC.2000402>