From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 00C5DC4363D for ; Tue, 22 Sep 2020 19:02:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BEF1C2311C for ; Tue, 22 Sep 2020 19:02:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=fooishbar-org.20150623.gappssmtp.com header.i=@fooishbar-org.20150623.gappssmtp.com header.b="nHx+oCJ4" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726614AbgIVTCt (ORCPT ); Tue, 22 Sep 2020 15:02:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51478 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726573AbgIVTCt (ORCPT ); Tue, 22 Sep 2020 15:02:49 -0400 Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [IPv6:2a00:1450:4864:20::441]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E9746C061755 for ; Tue, 22 Sep 2020 12:02:48 -0700 (PDT) Received: by mail-wr1-x441.google.com with SMTP id x14so18244425wrl.12 for ; Tue, 22 Sep 2020 12:02:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fooishbar-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rm/MUGiqEj6w9zoNKJAAAmLZqiJ10V/BIIAqAEoPPYo=; b=nHx+oCJ4c6Paf+lALa+5KspNBYN+hXRQkk9hBttFTN+rje5X8/9FAUvaCBwnGOPWQ1 F4R0U65sfyBNDYw+IPkqYN/j3Q/YMan4JXmbRcOW/ASi5k1hxBIiRxiCHJJqQK1aycZl VBAJ78k7zPaOieZI67vbAaNfJPc8l78oZiXdnreDjhWtR6rsN9vfcznLyR49mkwjUtFs E2jco4SRrE6jQD2v3CBXzKCrByqErFTzls6gcpddlM0Nz8pB508/uQX3YGIbykHJImTo tHnjh25yK6E3gcJ8UoyNvbJRSMpiFSGPo2YN4QrEg7DYjbZBzI0cK7+uQtTUwkZrNa73 1akA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rm/MUGiqEj6w9zoNKJAAAmLZqiJ10V/BIIAqAEoPPYo=; b=LL5ld1vexcKEvL3acVqHGidQwUHKHeL2c2qWPa453yiVgSOo+qJXdsmc5zwytMN7q8 JVGfn4rWOzNe+yJPyW3dWgf867ScFnrzYMaMEEQsLTtFjtA+dgphm/w5MEIHszNGG8Sx Yx0mWgiq+Y23RG3OG6a0jkT/MD7vv9QrEz1qiZ5j2ecwXbmWG0GXnALlP01qiWO30QKc POwFREC7cjQqyt5MkIHldmxyYziZF9kiIAl+tpEGLXCkc2KAJHuTQO0soAEx2FqRZ0el zHf30P44bjOe7tLGjY4Kk2d4TW2MLTXN9WYHvSn+dXLeX/dIsx5tqyCX0GGYr1Ozx2ES JToA== X-Gm-Message-State: AOAM532vOfVPE+arBck1r0J1n32DJ//apznctIUoP34tjPWudgc2UlwB uGZOMiuYJ1Bk0jfIe/GzuYGh/CgdVYSH/yPw1IKG+g== X-Google-Smtp-Source: ABdhPJwvwQBt4Q6HDn51fnSs2PQD3j8FLapI/mLE772a0J4HTg0bK9kCG9427Njb47eon1VCQkDPa5MIGFa14BvVrEY= X-Received: by 2002:adf:e292:: with SMTP id v18mr6915557wri.256.1600801367216; Tue, 22 Sep 2020 12:02:47 -0700 (PDT) MIME-Version: 1.0 References: <20180705101043.4883-1-daniel.vetter@ffwll.ch> <20180705102121.5091-1-daniel.vetter@ffwll.ch> <20200922133636.GA2369@xpredator> In-Reply-To: From: Daniel Stone Date: Tue, 22 Sep 2020 20:02:35 +0100 Message-ID: Subject: Re: [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets To: Daniel Vetter Cc: Marius Vlad , Pekka Paalanen , Intel Graphics Development , stable , DRI Development , Daniel Vetter Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org Hi, On Tue, 22 Sep 2020 at 17:02, Daniel Vetter wrote: > On Tue, Sep 22, 2020 at 4:14 PM Daniel Stone wrote: > > I think we need a guarantee that this never happens if ALLOW_MODESET > > is always used in blocking mode, plus in future a cap we can use to > > detect that we won't be getting spurious EBUSY events. > > > > I really don't want to ever paper over this, because it's one of the > > clearest indications that userspace has its timing/signalling wrong. > > Ok so the hang-up last time around iirc was that I broke igt by making > a few things more synchronous. Let's hope I'm not also breaking stuff > with the WARN_ON ... > > New plan: > - make this patch here only document existing behaviour and enforce it > with the WARN_ON > - new uapi would be behind a flag or something, with userspace and > everything hanging off it. > > Thoughts? What do you mean by 'new uapi'? The proposal that the kernel communicates back which object IDs have been added to the state behind your back? That it's been made automatically blocking? Something else? Cheers, Daniel (the other one) From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 56139C2D0E2 for ; Tue, 22 Sep 2020 19:02:54 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 113F72311C for ; Tue, 22 Sep 2020 19:02:54 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=fooishbar-org.20150623.gappssmtp.com header.i=@fooishbar-org.20150623.gappssmtp.com header.b="nHx+oCJ4" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 113F72311C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=fooishbar.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 7EF806E2DF; Tue, 22 Sep 2020 19:02:51 +0000 (UTC) Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com [IPv6:2a00:1450:4864:20::442]) by gabe.freedesktop.org (Postfix) with ESMTPS id A64626E2DF for ; Tue, 22 Sep 2020 19:02:48 +0000 (UTC) Received: by mail-wr1-x442.google.com with SMTP id e16so18315850wrm.2 for ; Tue, 22 Sep 2020 12:02:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fooishbar-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rm/MUGiqEj6w9zoNKJAAAmLZqiJ10V/BIIAqAEoPPYo=; b=nHx+oCJ4c6Paf+lALa+5KspNBYN+hXRQkk9hBttFTN+rje5X8/9FAUvaCBwnGOPWQ1 F4R0U65sfyBNDYw+IPkqYN/j3Q/YMan4JXmbRcOW/ASi5k1hxBIiRxiCHJJqQK1aycZl VBAJ78k7zPaOieZI67vbAaNfJPc8l78oZiXdnreDjhWtR6rsN9vfcznLyR49mkwjUtFs E2jco4SRrE6jQD2v3CBXzKCrByqErFTzls6gcpddlM0Nz8pB508/uQX3YGIbykHJImTo tHnjh25yK6E3gcJ8UoyNvbJRSMpiFSGPo2YN4QrEg7DYjbZBzI0cK7+uQtTUwkZrNa73 1akA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rm/MUGiqEj6w9zoNKJAAAmLZqiJ10V/BIIAqAEoPPYo=; b=nJUp1g8dUtOpcboYldeOF9X/TKbbRmYdcArHLxD8Sw8u6BjZSQHSFvDa180Hq4gzI8 V24F4U3mEsea8G4cfLcZwiYZR//rvw8dtNsdw9Hck07PPUjo4Cls/REpT8bcgs+p5Bf+ hmmNLLztquFs2SSNQC4PU55YK5uAzCAZzBdNuVEypLgwlnhvL9w9DFgzJDjLi1RgGY+5 KG0DlHBHCOxOZygv5FLrA58Yx1j71XQ95vA/L4RxRUUQVlIBR2fNVDke8UkxjaxZ8yql nYl/95jE4xc3Q+tlQSbLRjN2PESVpRNc4r6VkbnJyX+5PcSFMf6CFa8CfZtIADScw/BD /sUg== X-Gm-Message-State: AOAM533B10MvjFHsHQ0AdfCBGtSiC/kZ8HD4FUhcd7KqKS+Pj+aXlX8a IxDNdAO98mztoPFj8iqAlQ5qHmzKNOAZXoE5o0p/yA== X-Google-Smtp-Source: ABdhPJwvwQBt4Q6HDn51fnSs2PQD3j8FLapI/mLE772a0J4HTg0bK9kCG9427Njb47eon1VCQkDPa5MIGFa14BvVrEY= X-Received: by 2002:adf:e292:: with SMTP id v18mr6915557wri.256.1600801367216; Tue, 22 Sep 2020 12:02:47 -0700 (PDT) MIME-Version: 1.0 References: <20180705101043.4883-1-daniel.vetter@ffwll.ch> <20180705102121.5091-1-daniel.vetter@ffwll.ch> <20200922133636.GA2369@xpredator> In-Reply-To: From: Daniel Stone Date: Tue, 22 Sep 2020 20:02:35 +0100 Message-ID: Subject: Re: [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets To: Daniel Vetter X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Intel Graphics Development , DRI Development , stable , Daniel Vetter , Pekka Paalanen , Marius Vlad Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Hi, On Tue, 22 Sep 2020 at 17:02, Daniel Vetter wrote: > On Tue, Sep 22, 2020 at 4:14 PM Daniel Stone wrote: > > I think we need a guarantee that this never happens if ALLOW_MODESET > > is always used in blocking mode, plus in future a cap we can use to > > detect that we won't be getting spurious EBUSY events. > > > > I really don't want to ever paper over this, because it's one of the > > clearest indications that userspace has its timing/signalling wrong. > > Ok so the hang-up last time around iirc was that I broke igt by making > a few things more synchronous. Let's hope I'm not also breaking stuff > with the WARN_ON ... > > New plan: > - make this patch here only document existing behaviour and enforce it > with the WARN_ON > - new uapi would be behind a flag or something, with userspace and > everything hanging off it. > > Thoughts? What do you mean by 'new uapi'? The proposal that the kernel communicates back which object IDs have been added to the state behind your back? That it's been made automatically blocking? Something else? Cheers, Daniel (the other one) _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C6D6BC4363D for ; Tue, 22 Sep 2020 19:02:52 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6EEFF2311C for ; Tue, 22 Sep 2020 19:02:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=fooishbar-org.20150623.gappssmtp.com header.i=@fooishbar-org.20150623.gappssmtp.com header.b="nHx+oCJ4" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6EEFF2311C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=fooishbar.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 748CF89ED3; Tue, 22 Sep 2020 19:02:51 +0000 (UTC) Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com [IPv6:2a00:1450:4864:20::442]) by gabe.freedesktop.org (Postfix) with ESMTPS id 99DE089ED3 for ; Tue, 22 Sep 2020 19:02:48 +0000 (UTC) Received: by mail-wr1-x442.google.com with SMTP id z1so18283922wrt.3 for ; Tue, 22 Sep 2020 12:02:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fooishbar-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rm/MUGiqEj6w9zoNKJAAAmLZqiJ10V/BIIAqAEoPPYo=; b=nHx+oCJ4c6Paf+lALa+5KspNBYN+hXRQkk9hBttFTN+rje5X8/9FAUvaCBwnGOPWQ1 F4R0U65sfyBNDYw+IPkqYN/j3Q/YMan4JXmbRcOW/ASi5k1hxBIiRxiCHJJqQK1aycZl VBAJ78k7zPaOieZI67vbAaNfJPc8l78oZiXdnreDjhWtR6rsN9vfcznLyR49mkwjUtFs E2jco4SRrE6jQD2v3CBXzKCrByqErFTzls6gcpddlM0Nz8pB508/uQX3YGIbykHJImTo tHnjh25yK6E3gcJ8UoyNvbJRSMpiFSGPo2YN4QrEg7DYjbZBzI0cK7+uQtTUwkZrNa73 1akA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rm/MUGiqEj6w9zoNKJAAAmLZqiJ10V/BIIAqAEoPPYo=; b=Xzqm4ifPCWqTJjgx5xLY01SSt8ZXhb90B8qPWuYm+8wyrmQ1ftWkU2VyEEcRM39YDq GAYkEKppu/HgI4V+CK9aKYJZkMXiPlDhBP+jMCJ9Yet2kUCaZ0gicLCJ85PLgMRe8BBh TX4JEz1vjgqEyiXsl5FbNss6NlGz0WpU/fsS9a8/+WbWddGcQYJOQ0Heo5fI6tgJ3yy3 bqMTaD1n9rR4Pb8B6j/+MP3ImOF6gyDk50CzfVmWzvvX34oq2HgVqwxfiZ15vbJILpAA qCVNbo/JH+HHdNaduiKV7WRBJgUNqn/JcHODOzT9YPtS7sL5uGcg3EU0rh/Q2ysIuqH1 b9KQ== X-Gm-Message-State: AOAM530dILHvFmXgUkizm7pLBi1KpeaMqwp/kQc10FWfQ+DCMIhDdqZB Qi6QKNCKBZHt5/Zq9TQMXROoiaKuQzWnFO/RK2w66g== X-Google-Smtp-Source: ABdhPJwvwQBt4Q6HDn51fnSs2PQD3j8FLapI/mLE772a0J4HTg0bK9kCG9427Njb47eon1VCQkDPa5MIGFa14BvVrEY= X-Received: by 2002:adf:e292:: with SMTP id v18mr6915557wri.256.1600801367216; Tue, 22 Sep 2020 12:02:47 -0700 (PDT) MIME-Version: 1.0 References: <20180705101043.4883-1-daniel.vetter@ffwll.ch> <20180705102121.5091-1-daniel.vetter@ffwll.ch> <20200922133636.GA2369@xpredator> In-Reply-To: From: Daniel Stone Date: Tue, 22 Sep 2020 20:02:35 +0100 Message-ID: To: Daniel Vetter Subject: Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Intel Graphics Development , DRI Development , stable , Daniel Vetter , Pekka Paalanen , Marius Vlad Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" Hi, On Tue, 22 Sep 2020 at 17:02, Daniel Vetter wrote: > On Tue, Sep 22, 2020 at 4:14 PM Daniel Stone wrote: > > I think we need a guarantee that this never happens if ALLOW_MODESET > > is always used in blocking mode, plus in future a cap we can use to > > detect that we won't be getting spurious EBUSY events. > > > > I really don't want to ever paper over this, because it's one of the > > clearest indications that userspace has its timing/signalling wrong. > > Ok so the hang-up last time around iirc was that I broke igt by making > a few things more synchronous. Let's hope I'm not also breaking stuff > with the WARN_ON ... > > New plan: > - make this patch here only document existing behaviour and enforce it > with the WARN_ON > - new uapi would be behind a flag or something, with userspace and > everything hanging off it. > > Thoughts? What do you mean by 'new uapi'? The proposal that the kernel communicates back which object IDs have been added to the state behind your back? That it's been made automatically blocking? Something else? Cheers, Daniel (the other one) _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx