From patchwork Thu May 17 14:48:19 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Michel_D=C3=A4nzer?= X-Patchwork-Id: 10406883 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id CF6BE60353 for ; Thu, 17 May 2018 14:48:25 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id BCCE02793B for ; Thu, 17 May 2018 14:48:25 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id AF9CE27DCD; Thu, 17 May 2018 14:48:25 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=2.0 tests=BAYES_00, MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id E337A2793B for ; Thu, 17 May 2018 14:48:24 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 872016E94A; Thu, 17 May 2018 14:48:23 +0000 (UTC) X-Original-To: dri-devel@lists.freedesktop.org Delivered-To: dri-devel@lists.freedesktop.org Received: from netline-mail3.netline.ch (mail.netline.ch [148.251.143.178]) by gabe.freedesktop.org (Postfix) with ESMTP id 9E40E6E949 for ; Thu, 17 May 2018 14:48:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by netline-mail3.netline.ch (Postfix) with ESMTP id 010FF2A6045; Thu, 17 May 2018 16:48:20 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at netline-mail3.netline.ch Received: from netline-mail3.netline.ch ([127.0.0.1]) by localhost (netline-mail3.netline.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id wm8TFZIsFgzf; Thu, 17 May 2018 16:48:20 +0200 (CEST) Received: from thor (145.233.60.188.dynamic.wline.res.cust.swisscom.ch [188.60.233.145]) by netline-mail3.netline.ch (Postfix) with ESMTPSA id ED3AE2A6042; Thu, 17 May 2018 16:48:19 +0200 (CEST) Received: from localhost ([::1]) by thor with esmtp (Exim 4.91) (envelope-from ) id 1fJKCZ-00058m-9Z; Thu, 17 May 2018 16:48:19 +0200 Subject: Re: [PATCH 2/3] drm/scheduler: Don't call wait_event_killable for signaled process. To: Andrey Grodzovsky References: <87muxsbmkp.fsf@xmission.com> <8840ac96-50c4-f94d-eb7c-f007940163f3@amd.com> <877eowa5qh.fsf@xmission.com> <20180425135552.GD7592@redhat.com> <20180425171757.GA10441@redhat.com> <874ljyu98e.fsf@xmission.com> <20180430160006.GB10583@redhat.com> <79b2ce10-2cd7-b6f2-551e-0b4ae21072af@amd.com> <28de0150-0a31-f51a-4f56-0a71f741e07e@amd.com> <3ff3a5f4-c109-bf86-2772-9d88abc419df@amd.com> From: =?UTF-8?Q?Michel_D=c3=a4nzer?= Message-ID: <662c84bf-ac38-db28-1a11-b17719c9b8d0@daenzer.net> Date: Thu, 17 May 2018 16:48:19 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <3ff3a5f4-c109-bf86-2772-9d88abc419df@amd.com> Content-Language: en-CA X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "Koenig, Christian" , ML dri-devel Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" X-Virus-Scanned: ClamAV using ClamSMTP On 2018-05-17 01:18 PM, Andrey Grodzovsky wrote: > Hi Michele and others, I am trying to implement the approach bellow to > resolve AMDGPU's hang when commands are stuck in pipe during process exit. > > I noticed that once I implemented the file_operation.flush callback  > then during run of X, i see the flush callback gets called not only for > Xorg process but for other > > processes such as 'xkbcomp' and even 'sh', it seems like Xorg passes his > FDs to children, Christian mentioned he remembered a discussion to > always set FD_CLOEXEC flag when opening the hardware device file, so > > we suspect a bug in Xorg with regard to this behavior. Try the libdrm patch below. Note that the X server passes DRM file descriptors to DRI3 clients. diff --git a/xf86drm.c b/xf86drm.c index 3a9d0ed2..c09437b0 100644 --- a/xf86drm.c +++ b/xf86drm.c @@ -405,7 +405,7 @@ wait_for_udev: } #endif - fd = open(buf, O_RDWR, 0); + fd = open(buf, O_RDWR | O_CLOEXEC, 0); drmMsg("drmOpenDevice: open result is %d, (%s)\n", fd, fd < 0 ? strerror(errno) : "OK"); if (fd >= 0) @@ -425,7 +425,7 @@ wait_for_udev: chmod(buf, devmode); } } - fd = open(buf, O_RDWR, 0); + fd = open(buf, O_RDWR | O_CLOEXEC, 0); drmMsg("drmOpenDevice: open result is %d, (%s)\n", fd, fd < 0 ? strerror(errno) : "OK"); if (fd >= 0) @@ -474,7 +474,7 @@ static int drmOpenMinor(int minor, int create, int type) }; sprintf(buf, dev_name, DRM_DIR_NAME, minor); - if ((fd = open(buf, O_RDWR, 0)) >= 0) + if ((fd = open(buf, O_RDWR | O_CLOEXEC, 0)) >= 0) return fd; return -errno; }