From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Wed, 17 Nov 2010 08:45:00 +0200 From: Lucio De Re To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20101117064500.GA3597@fangle.proxima.alt.za> References: <1e1e3d7c4781c86aa3a270cecdbaadbb@coraid.com> <4ee4b7c2dd207e953599fc618df2c456@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4ee4b7c2dd207e953599fc618df2c456@gmx.de> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [9fans] That deadlock, again Topicbox-Message-UUID: 83ca96c8-ead6-11e9-9d60-3106f5b1d025 On Wed, Nov 17, 2010 at 06:22:33AM +0100, cinap_lenrek@gmx.de wrote: > > qpc is the just the caller of the last successfull *acquired* qlock. > what we know is that the exportfs proc spins in the q->use taslock > called by qlock() right? this already seems wired... q->use is held > just long enougth to test q->locked and manipulate the queue. also > sched() will avoid switching to another proc while we are holding tas > locks. > I think I'm with you, probably not quite to the same depth of understanding. > i would like to know which qlock is the kernel is trying to acquire > on behalf of exportfs that is also reachable from the etherread4 > code. > ... and from whatever the other proc is that also contributes to this jam. I don't have the name right in front of me, but I will post it separately. As far as I know it's always those two that interfere with exportfs and usually together, only a short time apart. > one could move: > > up->qpc = getcallerpc(&q); > > from qlock() before the lock(&q->use); so we can see from where that > qlock gets called that hangs the exportfs call, or add another magic > debug pointer (qpctry) to the proc stucture and print it in dumpaproc(). > I think I'll do the latter; even though it's more complex, it can be a useful debugging tool in future. I wouldn't leave in the kernel code, but it would be worth being able to refer to it when the occasion arises. How do you expect this qpctry to be initialised/set? ++L