From patchwork Fri May 18 08:46:39 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: 10408817 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 A29B1602CB for ; Fri, 18 May 2018 08:46:46 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 905B028462 for ; Fri, 18 May 2018 08:46:46 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 838F42888D; Fri, 18 May 2018 08:46:46 +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 50FD128462 for ; Fri, 18 May 2018 08:46:44 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id A88DD6EC85; Fri, 18 May 2018 08:46:42 +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 919146EC85 for ; Fri, 18 May 2018 08:46:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by netline-mail3.netline.ch (Postfix) with ESMTP id 058A52A6046; Fri, 18 May 2018 10:46:41 +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 5kc5U2nylIPU; Fri, 18 May 2018 10:46:40 +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 387152A6045; Fri, 18 May 2018 10:46:40 +0200 (CEST) Received: from localhost ([::1]) by thor with esmtp (Exim 4.91) (envelope-from ) id 1fJb27-0001mY-Jo; Fri, 18 May 2018 10:46:39 +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> <662c84bf-ac38-db28-1a11-b17719c9b8d0@daenzer.net> From: =?UTF-8?Q?Michel_D=c3=a4nzer?= Message-ID: <12c806f9-f283-5bed-d137-7719ba73205a@daenzer.net> Date: Fri, 18 May 2018 10:46:39 +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: 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 09:05 PM, Andrey Grodzovsky wrote: > On 05/17/2018 10:48 AM, Michel Dänzer wrote: >> 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. > > Tried it, didn't help. I still see other processes calling .flush for > /dev/dri/card0 Try the attached xserver patch on top. With these patches, I no longer see any DRM file descriptors being opened without O_CLOEXEC running Xorg -pogo in strace. Anyway, the kernel can't rely on userspace using O_CLOEXEC. If the flush callback being called from multiple processes is an issue, maybe the flush callback isn't appropriate after all. diff --git a/hw/xfree86/drivers/modesetting/driver.c b/hw/xfree86/drivers/modesetting/driver.c index 5d8906d63..306541f33 100644 --- a/hw/xfree86/drivers/modesetting/driver.c +++ b/hw/xfree86/drivers/modesetting/driver.c @@ -200,12 +200,12 @@ open_hw(const char *dev) int fd; if (dev) - fd = open(dev, O_RDWR, 0); + fd = open(dev, O_RDWR | O_CLOEXEC, 0); else { dev = getenv("KMSDEVICE"); - if ((NULL == dev) || ((fd = open(dev, O_RDWR, 0)) == -1)) { + if ((NULL == dev) || ((fd = open(dev, O_RDWR | O_CLOEXEC, 0)) == -1)) { dev = "/dev/dri/card0"; - fd = open(dev, O_RDWR, 0); + fd = open(dev, O_RDWR | O_CLOEXEC, 0); } } if (fd == -1) diff --git a/hw/xfree86/os-support/linux/lnx_platform.c b/hw/xfree86/os-support/linux/lnx_platform.c index 11af52c46..70374ace8 100644 --- a/hw/xfree86/os-support/linux/lnx_platform.c +++ b/hw/xfree86/os-support/linux/lnx_platform.c @@ -43,7 +43,7 @@ get_drm_info(struct OdevAttributes *attribs, char *path, int delayed_index) } if (fd == -1) - fd = open(path, O_RDWR, O_CLOEXEC); + fd = open(path, O_RDWR | O_CLOEXEC, 0); if (fd == -1) return FALSE;