Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp25786816rwd; Mon, 3 Jul 2023 00:38:01 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4oiRJJa/9sjMle95TyeSGJmF4kdtXQYpQdqJ54o7disUWkRMaIYY2TVJcS1C8LjGRaFd4t X-Received: by 2002:a05:6a20:320e:b0:11f:2714:f6f3 with SMTP id hl14-20020a056a20320e00b0011f2714f6f3mr5962938pzc.11.1688369880740; Mon, 03 Jul 2023 00:38:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1688369880; cv=none; d=google.com; s=arc-20160816; b=azywIISkCb4puW2+sesCc7CB0fpllu9Z6PdUY1c5Vnvat2m78D1Zq2HqabvxLkvlmB VDVWFCUpNTG+TUuc0bTbuWc79jVAZGry2+ajSgPU8McENbxK/kITQUU5f3EK8G7yLIln xr/N5pwPmaprBVNOjvnK6OPIeUhJh/zV8SG39LhxJZQQ7M8xGKrJYMRHjanjQHQMC8n9 frXw6T9ckOI+TdPYAOFoxIzuYw02gm1zXHujs+zbrWKhdM6Aumk5hmoXp/Gqa+EKyKul X/+7baRFyZ0nq8BvdY8IQc/JvNlYh9GReRh2X9NlLnYpmgkfKEIheo5rxzIS9urYE8hH zjbw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:mime-version:date :message-id:dkim-signature; bh=JDNJNCwhoG+0ydNvsWCgQAPOCFx9yNIpNg5RG4lrTFc=; fh=WHQ6qakpCp99iDtP6YC7hoHAeSTjMfkPlTKd3eT3ARg=; b=TEiaxxerx02Nn2KR7y2nD8mCDq18Ths26CHLZv6Am24Ctjs0RzFaDmu9SlVzdk/NAJ hgAsebIb80OG4PHVrDJGDFJXbs/tySGllO9TaqOi/LmthFEfGxrIr4WJ3SUur2XnsSD4 p9tlC+Lcg3tSo3aZ+pjmeOpUZtWkXUrvvge4CuAG+I6mP74guO2wInNlrzBmvyoaxbsQ ooQ1PPgAhWe5JzC/cABseG/8pb4AHI9b0PTW1h0NuAqO9IjnViKXMz6EH9euHloik1W9 91CfEuRk9SlH04snY8Gmk///z79b+M0AKbdRne3wJMIElgBlXwqnEDuhLxg97Fd4k3/N wzAQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@mailbox.org header.s=mail20150812 header.b=uWzB5PEq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=mailbox.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id y13-20020a17090322cd00b001b86671b3f1si8132220plg.190.2023.07.03.00.37.48; Mon, 03 Jul 2023 00:38:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@mailbox.org header.s=mail20150812 header.b=uWzB5PEq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=mailbox.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229950AbjGCHMk (ORCPT + 99 others); Mon, 3 Jul 2023 03:12:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53682 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229608AbjGCHMi (ORCPT ); Mon, 3 Jul 2023 03:12:38 -0400 Received: from mout-p-101.mailbox.org (mout-p-101.mailbox.org [80.241.56.151]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AE07FCC for ; Mon, 3 Jul 2023 00:12:36 -0700 (PDT) Received: from smtp1.mailbox.org (smtp1.mailbox.org [10.196.197.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-101.mailbox.org (Postfix) with ESMTPS id 4QvcZ868zmz9sTc; Mon, 3 Jul 2023 09:12:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailbox.org; s=mail20150812; t=1688368352; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=JDNJNCwhoG+0ydNvsWCgQAPOCFx9yNIpNg5RG4lrTFc=; b=uWzB5PEqTbeBjl2FMU9jiApj7p/ZTTvmBwYysJPhNe3nP2k+MMFSaV8oYukXBCgb+SXuMl 8+zLLt+byMxA4coMGnS66mLAvQC4Kf3JKGaUx/NHSMudjil7YmYLGyL4oZgVZBOkZakg8E ed1lZuSHky7P7pZBJmsgbNGKgI20ap2wGJNReVVtijfHSz68ljAMpY+YuzCiAeB6Qihx3M GgLhSrjYOeDYy+RH3CTd5udiosINbE3uGCJnRG7ilRZ1VQAibodlkoRxzQw/EkX5vFn6EL QpEtZmsPjumFqMty4ZT1IUeEmchWHxj03wd5ad+nCbEH6ax3ux7TuBEGlIx4TQ== Message-ID: <7c1e6df5-1ad4-be3c-b95d-92dc62a8c537@mailbox.org> Date: Mon, 3 Jul 2023 09:12:29 +0200 MIME-Version: 1.0 Subject: Re: [PATCH v5 1/1] drm/doc: Document DRM device reset expectations Content-Language: de-CH-frami, en-CA To: =?UTF-8?B?TWFyZWsgT2zFocOhaw==?= Cc: pierre-eric.pelloux-prayer@amd.com, Sebastian Wick , amd-gfx@lists.freedesktop.org, =?UTF-8?Q?Andr=c3=a9_Almeida?= , =?UTF-8?Q?Timur_Krist=c3=b3f?= , Randy Dunlap , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, alexander.deucher@amd.com, Pekka Paalanen , Samuel Pitoiset , kernel-dev@igalia.com, Pekka Paalanen , christian.koenig@amd.com References: <20230627132323.115440-1-andrealmeid@igalia.com> From: =?UTF-8?Q?Michel_D=c3=a4nzer?= In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-MBO-RS-ID: d01efb6d83f21620a65 X-MBO-RS-META: 5z8b3itq5tq11yiwuxjwbw1bdzf74g3m X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 6/30/23 22:32, Marek Olšák wrote: > On Fri, Jun 30, 2023 at 11:11 AM Michel Dänzer > wrote: >> On 6/30/23 16:59, Alex Deucher wrote: >>> On Fri, Jun 30, 2023 at 10:49 AM Sebastian Wick >>> > wrote: >>>> On Tue, Jun 27, 2023 at 3:23 PM André Almeida > wrote: >>>>> >>>>> +Robustness >>>>> +---------- >>>>> + >>>>> +The only way to try to keep an application working after a reset is if it >>>>> +complies with the robustness aspects of the graphical API that it is using. >>>>> + >>>>> +Graphical APIs provide ways to applications to deal with device resets. However, >>>>> +there is no guarantee that the app will use such features correctly, and the >>>>> +UMD can implement policies to close the app if it is a repeating offender, >>>>> +likely in a broken loop. This is done to ensure that it does not keep blocking >>>>> +the user interface from being correctly displayed. This should be done even if >>>>> +the app is correct but happens to trigger some bug in the hardware/driver. >>>> >>>> I still don't think it's good to let the kernel arbitrarily kill >>>> processes that it thinks are not well-behaved based on some heuristics >>>> and policy. >>>> >>>> Can't this be outsourced to user space? Expose the information about >>>> processes causing a device and let e.g. systemd deal with coming up >>>> with a policy and with killing stuff. >>> >>> I don't think it's the kernel doing the killing, it would be the UMD. >>> E.g., if the app is guilty and doesn't support robustness the UMD can >>> just call exit(). >> >> It would be safer to just ignore API calls[0], similarly to what is done until the application destroys the context with robustness. Calling exit() likely results in losing any unsaved work, whereas at least some applications might otherwise allow saving the work by other means. > > That's a terrible idea. Ignoring API calls would be identical to a freeze. You might as well disable GPU recovery because the result would be the same. No GPU recovery would affect everything using the GPU, whereas this affects only non-robust applications. > - non-robust contexts: call exit(1) immediately, which is the best way to recover That's not the UMD's call to make. >> [0] Possibly accompanied by a one-time message to stderr along the lines of "GPU reset detected but robustness not enabled in context, ignoring OpenGL API calls". -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and Xwayland developer