From patchwork Tue Mar 19 10:50:47 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Maarten Lankhorst X-Patchwork-Id: 2301781 Return-Path: X-Original-To: patchwork-intel-gfx@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork2.kernel.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) by patchwork2.kernel.org (Postfix) with ESMTP id EBEBFDFB79 for ; Tue, 19 Mar 2013 15:31:48 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 07C8CE5C91 for ; Tue, 19 Mar 2013 08:31:49 -0700 (PDT) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from youngberry.canonical.com (youngberry.canonical.com [91.189.89.112]) by gabe.freedesktop.org (Postfix) with ESMTP id 66599E5F45; Tue, 19 Mar 2013 03:50:49 -0700 (PDT) Received: from 5ed48cef.cm-7-5c.dynamic.ziggo.nl ([94.212.140.239] helo=[192.168.1.128]) by youngberry.canonical.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1UHu80-0003T5-5o; Tue, 19 Mar 2013 10:50:48 +0000 Message-ID: <51484307.3040906@canonical.com> Date: Tue, 19 Mar 2013 11:50:47 +0100 From: Maarten Lankhorst User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Chris Wilson , Bryce Harrington , intel-gfx@lists.freedesktop.org, "X.Org Devel List" , "dri-devel@lists.freedesktop.org" , Timo Aaltonen References: <1363639911-21239-1-git-send-email-bryce@canonical.com> <20130319092146.GC3872@cantiga.alporthouse.com> <514837A6.5010301@canonical.com> <20130319102707.GD3872@cantiga.alporthouse.com> In-Reply-To: <20130319102707.GD3872@cantiga.alporthouse.com> X-Mailman-Approved-At: Tue, 19 Mar 2013 08:31:08 -0700 Subject: Re: [Intel-gfx] [PATCH v2 0/7] xfree86: Handle drm race condition X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+patchwork-intel-gfx=patchwork.kernel.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+patchwork-intel-gfx=patchwork.kernel.org@lists.freedesktop.org Hey, Op 19-03-13 11:27, Chris Wilson schreef: > On Tue, Mar 19, 2013 at 11:02:14AM +0100, Maarten Lankhorst wrote: >> Hey, >> >> Op 19-03-13 10:21, Chris Wilson schreef: >>> On Mon, Mar 18, 2013 at 01:51:44PM -0700, Bryce Harrington wrote: >>>> Update: Squashes a couple commits to avoid potential hang if >>>> git bisecting. No other changes from v1. >>> I'd probably drop the last EAGAIN patch as that is part of the libdrm >>> API, but other than that it looks to be a reasonably self-contained w/a >>> for this perplexing problem. >>> >>> Reviewed-by: Chris Wilson >>> -Chris >>> >> And completely wrong, version I pushed to ubuntu's xorg-server for comparison: >> >> Nacked-by: Maarten Lankhorst > So you pushed the busy-spin into drmSetMaster(), which is just a tighter > variant of the above. > > Anything which adds the minimal delay, warns about that delay, and > works around the issue is fine by me. > -Chris Here's what I think is happening, based on the information I have. Because of the delayed fput in recent kernels, it is possible for plymouth to exit and not drop master right away. It's put onto a workqueue to be freed slightly later. Xorg-server starts in the meantime, opens a fd, but because the fd hasn't been closed by plymouth yet, it didn't get implicitly authenticated and it didn't get drm master either. The drmSetMaster call is needed, but the spinning is really just waiting for the workqueue to run. bryce's patch never worked, it just caused it to try drmsetinterfaceversion for a few seconds before timing out. That call was failing because his patch series never tried to obtain drm master. The get_drm_info call also makes it more likely to run into the same problem as well. It opens the fd and immediately closes it again. This will re-trigger the race.. For testing I did a small patch in the drm core that drops drm master when opening device. The patch is attached inline below. radeon and intel driver both fail to load with it. Intel doesn't return an error, and falls back silently to modesetting. radeon however complains similar to this: [ 42.876] (==) RADEON(G0): Depth 24, (--) framebuffer bpp 32 [ 42.876] (II) RADEON(G0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps) [ 42.876] (==) RADEON(G0): Default visual is TrueColor [ 42.876] (==) RADEON(G0): RGB weight 888 [ 42.876] (II) RADEON(G0): Using 8 bits per RGB (8 bit DAC) [ 42.876] (--) RADEON(G0): Chipset: "TURKS" (ChipID = 0x6741) [ 42.961] (EE) RADEON(G0): [drm] failed to set drm interface version. [ 42.961] (EE) RADEON(G0): Kernel modesetting setup failed I've seen this error before in one of the races, so it's not just a theoretical issue. Just another possible failure mode. I think all drivers have to be fixed to handle this case correctly, and they should probably all do the same spinning as well. diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c index f369429..1d3099f 100644 --- a/drivers/gpu/drm/drm_fops.c +++ b/drivers/gpu/drm/drm_fops.c @@ -339,6 +339,7 @@ static int drm_open_helper(struct inode *inode, struct file *filp, } } mutex_unlock(&dev->struct_mutex); + drm_dropmaster_ioctl(dev, NULL, priv); } else { /* get a reference to the master */ priv->master = drm_master_get(priv->minor->master);