From owner-freebsd-stable@FreeBSD.ORG  Mon Jun 10 12:04:15 2013
Return-Path: <owner-freebsd-stable@FreeBSD.ORG>
Delivered-To: freebsd-stable@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
 [IPv6:2001:1900:2254:206a::19:1])
 by hub.freebsd.org (Postfix) with ESMTP id 520B8D0E;
 Mon, 10 Jun 2013 12:04:15 +0000 (UTC)
 (envelope-from jsteckli@os.inf.tu-dresden.de)
Received: from os.inf.tu-dresden.de (os.inf.tu-dresden.de
 [IPv6:2002:8d4c:3001:48::99])
 by mx1.freebsd.org (Postfix) with ESMTP id 188A611E4;
 Mon, 10 Jun 2013 12:04:14 +0000 (UTC)
Received: from [2002:8d4c:3001:48:ea40:f2ff:fee2:6328]
 by os.inf.tu-dresden.de with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim
 4.80.1) id 1Um0pZ-0006rl-GY; Mon, 10 Jun 2013 14:04:13 +0200
Message-ID: <51B5C0BC.2000402@os.inf.tu-dresden.de>
Date: Mon, 10 Jun 2013 14:04:12 +0200
From: Julian Stecklina <jsteckli@os.inf.tu-dresden.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20130514 Thunderbird/17.0.6
MIME-Version: 1.0
To: John Baldwin <jhb@freebsd.org>, freebsd-stable@freebsd.org
Subject: Re: Reproducable Infiniband panic
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>
In-Reply-To: <201306071206.52994.jhb@freebsd.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-BeenThere: freebsd-stable@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-stable>,
 <mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
 <mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Jun 2013 12:04:15 -0000

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