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.9 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 9D0A2C4363D for ; Tue, 22 Sep 2020 16:02:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 14859208A9 for ; Tue, 22 Sep 2020 16:02:00 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="AbruHceP" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726709AbgIVQB7 (ORCPT ); Tue, 22 Sep 2020 12:01:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52060 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726666AbgIVQB7 (ORCPT ); Tue, 22 Sep 2020 12:01:59 -0400 Received: from mail-oi1-x244.google.com (mail-oi1-x244.google.com [IPv6:2607:f8b0:4864:20::244]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 73FF6C061755 for ; Tue, 22 Sep 2020 09:01:59 -0700 (PDT) Received: by mail-oi1-x244.google.com with SMTP id x14so21580060oic.9 for ; Tue, 22 Sep 2020 09:01:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jzGx9lNDQDNvXf55+zZV1XJczdG5Tj1hGWl7xVKxg1M=; b=AbruHcePTxOWEF854e6hnz/8QaFNhQAY+slB4rUkja6Zj6kCCbk3umIijEqzQanieU yeIQ1xS/LWBxCCGI5gpPR66Oa8uZl/04jVVfDBb0GtWtUkxkz1CcbrmWQ3Qwvl31mzpp BL8DTdMQ49vHk7PU5rBIHpBnBg4g3ZlYD3v3Q= 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=jzGx9lNDQDNvXf55+zZV1XJczdG5Tj1hGWl7xVKxg1M=; b=QqvPhEHNoGmeSoeNYA/QLJKN+iBT+rzwGnFlnodgIeJyGkivrYWrzSIwBW4FMSnfE+ zuNOamSNdbJY1sYY4aBTWQUBIvmD2qK9ubroDKB5Q1K6Zf+iXD7Tqwi3NxnZsX3l9W/t d+ioskAooOmKkkKtExsJZY8iq2BG/jZ8z83u853t/t5n9naDgPy+PAZ7sKQnc0+y++LW IcZ4dh+hFsTKk555hOCCyHcopOtzIbSWJ/sktikV7KncPE9NXOE7MwZ7LFn1NScwfMkw 7lJWdvGnIFIEjxmiVgPhiGw4mv0z9k7hBqp2Nhmhwigliv0PZZThXkpU19NDq7BY3z/A pfBg== X-Gm-Message-State: AOAM531WwvQ8FRO8wTz/KOZRwXoO3H7OlGNpcDGfgXeD8qlAC/40+biC TpxGEccWtLKH8bxoCraIXH5tS1Pj2ZgeH6Sr8N1AMQ== X-Google-Smtp-Source: ABdhPJxUCOo0K3uccb6V78Xey0Gvm3PTUf1Xm+2P+JTQizT3twxEF7VlbI4OYn7TQy4fV9tVym4U9rJE/5W8CN474ZY= X-Received: by 2002:aca:49c2:: with SMTP id w185mr2629161oia.101.1600790518782; Tue, 22 Sep 2020 09:01:58 -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 Vetter Date: Tue, 22 Sep 2020 18:01:47 +0200 Message-ID: Subject: Re: [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets To: Daniel Stone 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 On Tue, Sep 22, 2020 at 4:14 PM Daniel Stone wrote: > > On Tue, 22 Sep 2020 at 15:04, Daniel Vetter wrote: > > On Tue, Sep 22, 2020 at 3:36 PM Marius Vlad wrote: > > > Gentle ping. I've tried out Linus's master tree and, and like Pekka, > > > I've noticed this isn't integrated/added. > > > > Defacto the uapi we have now is that userspace needs to ignore "spurious" EBUSY. > > This really, really, really, bites. > > 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? Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch 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 24842C4363D for ; Tue, 22 Sep 2020 16:02:07 +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 061652388B for ; Tue, 22 Sep 2020 16:02:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="AbruHceP" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 061652388B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch 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 A79436E8A8; Tue, 22 Sep 2020 16:02:02 +0000 (UTC) Received: from mail-oi1-x244.google.com (mail-oi1-x244.google.com [IPv6:2607:f8b0:4864:20::244]) by gabe.freedesktop.org (Postfix) with ESMTPS id 00FF06E8A8 for ; Tue, 22 Sep 2020 16:01:59 +0000 (UTC) Received: by mail-oi1-x244.google.com with SMTP id x69so21543910oia.8 for ; Tue, 22 Sep 2020 09:01:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jzGx9lNDQDNvXf55+zZV1XJczdG5Tj1hGWl7xVKxg1M=; b=AbruHcePTxOWEF854e6hnz/8QaFNhQAY+slB4rUkja6Zj6kCCbk3umIijEqzQanieU yeIQ1xS/LWBxCCGI5gpPR66Oa8uZl/04jVVfDBb0GtWtUkxkz1CcbrmWQ3Qwvl31mzpp BL8DTdMQ49vHk7PU5rBIHpBnBg4g3ZlYD3v3Q= 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=jzGx9lNDQDNvXf55+zZV1XJczdG5Tj1hGWl7xVKxg1M=; b=YopVpEIMXs8pzp437/ssf09u0ZKUy2+nmb9MXt0/17N4UZkZcaZ0d6WwFYBHPRpd9Q Nf4WzEjLlvnGaAdS+QIGkO36LyjAmtsh1td/oVWHKrTxs2StKCw8aVbNcM98yj3MAvum XUuSkqV5Chj1CvVJh5jrGaxdz5ete3JlVeFJ2ayH5WaF8yYhBx6uBnWfr5MnD15KE04J 1Le76KCMIWeiyhz1FLfYDzP5Usv+MofmH91ANu4tRWNR0jQzCioRWSDArjgoShDOxRnO UHFlhKnAU7Pw5wCFnxNXGcvXsq5n8mRX1KfxtUIdCqF2MvNhuoaipTEZTl422tFd2tlp oVjA== X-Gm-Message-State: AOAM5313/H7/h//E8JSA4ciH6pJzoVrnI7YkZjvPjl81m+RW9r6aiasd oqjPLOo/PW6kCw4W1WmIZLyggXspPdsWAjtwh6W4cg== X-Google-Smtp-Source: ABdhPJxUCOo0K3uccb6V78Xey0Gvm3PTUf1Xm+2P+JTQizT3twxEF7VlbI4OYn7TQy4fV9tVym4U9rJE/5W8CN474ZY= X-Received: by 2002:aca:49c2:: with SMTP id w185mr2629161oia.101.1600790518782; Tue, 22 Sep 2020 09:01:58 -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 Vetter Date: Tue, 22 Sep 2020 18:01:47 +0200 Message-ID: Subject: Re: [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets To: Daniel Stone 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" On Tue, Sep 22, 2020 at 4:14 PM Daniel Stone wrote: > > On Tue, 22 Sep 2020 at 15:04, Daniel Vetter wrote: > > On Tue, Sep 22, 2020 at 3:36 PM Marius Vlad wrote: > > > Gentle ping. I've tried out Linus's master tree and, and like Pekka, > > > I've noticed this isn't integrated/added. > > > > Defacto the uapi we have now is that userspace needs to ignore "spurious" EBUSY. > > This really, really, really, bites. > > 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? Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ 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 22319C4727D for ; Tue, 22 Sep 2020 16:02:04 +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 20D60208A9 for ; Tue, 22 Sep 2020 16:02:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="AbruHceP" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 20D60208A9 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch 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 385806E89B; Tue, 22 Sep 2020 16:02:02 +0000 (UTC) Received: from mail-oi1-x244.google.com (mail-oi1-x244.google.com [IPv6:2607:f8b0:4864:20::244]) by gabe.freedesktop.org (Postfix) with ESMTPS id 009506E89B for ; Tue, 22 Sep 2020 16:01:59 +0000 (UTC) Received: by mail-oi1-x244.google.com with SMTP id a3so21618997oib.4 for ; Tue, 22 Sep 2020 09:01:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jzGx9lNDQDNvXf55+zZV1XJczdG5Tj1hGWl7xVKxg1M=; b=AbruHcePTxOWEF854e6hnz/8QaFNhQAY+slB4rUkja6Zj6kCCbk3umIijEqzQanieU yeIQ1xS/LWBxCCGI5gpPR66Oa8uZl/04jVVfDBb0GtWtUkxkz1CcbrmWQ3Qwvl31mzpp BL8DTdMQ49vHk7PU5rBIHpBnBg4g3ZlYD3v3Q= 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=jzGx9lNDQDNvXf55+zZV1XJczdG5Tj1hGWl7xVKxg1M=; b=DXWEgkx4fFSopECa5LSJs4ixuZVY0+fK7ajOj3Qbt/ma4F1FeHEGMAalofz7Mc89U4 /AJolbqQw0c3PbgQqz+0um0nP776jyyg02sci3NnKvDytfIJd8qXZjL4D8Qtslk6sf7m 03V0y0prDvrLZbXtZBkbf24V00ISa9Lp7lbQz8n7fQO1e6fo4koHmLjoFRHUxqbZzMnQ Mi6Y4RED2YZKa+CMVOUObtKXoNGnJn5Tn0LttMpgWiziBu/5KiH3iLI2oeZ0QZhEIxEW wq8kYBa6+wlNUHVIQSPt1FFyDVneoo8chu1irFkq2ETxMcDomkILPgh6HRpgNQGKwGWt R6Tw== X-Gm-Message-State: AOAM5317hruy7i8fx0Tues8UNcdhMGw3zb23X+fTeuGVylc8vBSataJL zr+TPU40TX/gdgt6z7q5JUyqpbImAn0xf4r4/swN8Q== X-Google-Smtp-Source: ABdhPJxUCOo0K3uccb6V78Xey0Gvm3PTUf1Xm+2P+JTQizT3twxEF7VlbI4OYn7TQy4fV9tVym4U9rJE/5W8CN474ZY= X-Received: by 2002:aca:49c2:: with SMTP id w185mr2629161oia.101.1600790518782; Tue, 22 Sep 2020 09:01:58 -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 Vetter Date: Tue, 22 Sep 2020 18:01:47 +0200 Message-ID: To: Daniel Stone 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" On Tue, Sep 22, 2020 at 4:14 PM Daniel Stone wrote: > > On Tue, 22 Sep 2020 at 15:04, Daniel Vetter wrote: > > On Tue, Sep 22, 2020 at 3:36 PM Marius Vlad wrote: > > > Gentle ping. I've tried out Linus's master tree and, and like Pekka, > > > I've noticed this isn't integrated/added. > > > > Defacto the uapi we have now is that userspace needs to ignore "spurious" EBUSY. > > This really, really, really, bites. > > 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? Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx