From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Arend van Spriel" Subject: Re: [BUG 3.7-rc1] nouveau cli->mutex possible recursive locking detected Date: Wed, 24 Oct 2012 14:45:12 +0200 Message-ID: <5087E2D8.9010703@broadcom.com> References: <20121016124348.GB2274@redhat.com> <5087CD85.4010201@broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5087CD85.4010201@broadcom.com> Sender: linux-kernel-owner@vger.kernel.org To: Stanislaw Gruszka Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Ben Skeggs List-Id: dri-devel@lists.freedesktop.org On 10/24/2012 01:14 PM, Arend van Spriel wrote: > On 10/16/2012 02:43 PM, Stanislaw Gruszka wrote: >> I have this lockdep warning on wireless-testing tree based >> on 3.7-rc1 (no other patches except wireless bits). >> >> ============================================= >> Restarting tasks ... done. >> [ INFO: possible recursive locking detected ] >> 3.7.0-rc1-wl+ #2 Not tainted >> --------------------------------------------- >> Xorg/2269 is trying to acquire lock: >> (&cli->mutex){+.+.+.}, at: [] >> nouveau_bo_move_m2mf+0x5f/0x170 [nouveau] >> >> but task is already holding lock: >> (&cli->mutex){+.+.+.}, at: [] >> nouveau_abi16_get+0x34/0x100 [nouveau] >> > > I have observed the same bug so I built and tested v3.7-rc2 tag with > lockdep enabled. It has the same problem and it results in a failure to > resume after suspend. See below. > > Gr. AvS digging into the trace: nouveau_gem_ioctl_pushbuf() calls nouveau_abi16_get() which grabs the mutex. Assume this should protect the chan variable passed to nouveau_gem_pushbuf_validate(), which does a bit more that validate as it ends up in nouveau_bo_move_m2mf() which uses the drm->chan. However, it deadlocks before that. Gr. AvS