From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fanzine2.igalia.com (fanzine2.igalia.com [213.97.179.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 397BC318BA6 for ; Fri, 6 Mar 2026 08:43:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=213.97.179.56 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772786586; cv=none; b=dSw5E/q7sjc9UGoq/fr2neejvLnhaMjdah1M28zvfYwwEwMwSJIwFlepwE6lDgLDDURVWfRSNif8P0z38xGOuiMiRkBlTSiVKEPHmEigYm3JaURGZpJa+Nxqwa6fL51ryVYxBRn8puhSN+wu+nDDsZwIyrqgUzYBbyEUIMXrYjY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772786586; c=relaxed/simple; bh=2lZ/JJq2T3I8By6PWjZG2YKMIlBfnBOdYdjjW+ZCtxE=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=ijWrAlzenmrfdpgkG95uGesQELRcUe6gxVT7pKMXbgS2N7QAV0Phw8Ar7lbnawXPsVd1iqnlqjgaUpMlAlldQ9A5efRf79NmG04F1zVKN3fvZY7BdWHEWK5kk6lRThbNrF4eTPX5olGztY8qO2RTWGQ5v6vOEydr7TxVst8OFi0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=igalia.com; spf=pass smtp.mailfrom=igalia.com; dkim=pass (2048-bit key) header.d=igalia.com header.i=@igalia.com header.b=C11R0y9x; arc=none smtp.client-ip=213.97.179.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=igalia.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=igalia.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=igalia.com header.i=@igalia.com header.b="C11R0y9x" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Wrmge17ypn1Y/rBKuh3QziCUXSnQXoXxYFxoJxj3o2s=; b=C11R0y9xCzFinlMQrL6387Gwdz LnVKDWqLDJfoS2rTSSMm9vRUfZuyNQxTsf/ISVVP7FBruBP+q9yLwDkVB3Ei8PQE4BAslGNIBb2us mndvI+HpI31pVmnNMa7Fi2P4NwO0x60Pmv1Oi34vEsuB00vTHQT0LFosNwc5YezCLn58e+XRXTx+8 KiUfYCx5cxNoYj8gBGbzntNtW4v9DjRF+I/srU+xk6KpKhnGMJVfJR/PJAS9Tvk5qE6GheKKJJLGm Z4CVCYNDmLVGaC15vPr/3I/eAmBw7/FDVciKI4up84d0rMBn/mOqzxjbZg8ldlcXsM2J9B2CH+8EB fI9r1Lyw==; Received: from [90.240.106.137] (helo=[192.168.0.101]) by fanzine2.igalia.com with esmtpsa (Cipher TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_128_GCM:128) (Exim) id 1vyQlp-009wbG-Gz; Fri, 06 Mar 2026 09:42:53 +0100 Message-ID: <9b53aa5b-19d9-4846-8c4b-2ccc80588ad5@igalia.com> Date: Fri, 6 Mar 2026 08:42:52 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH v3 0/3] Querying errors from drm_syncobj To: Yicong Hui , =?UTF-8?Q?Christian_K=C3=B6nig?= , =?UTF-8?Q?Michel_D=C3=A4nzer?= Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, skhan@linuxfoundation.org, david.hunter.linux@gmail.com, Philipp Stanner , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , matthew.brost@intel.com References: <20260225124609.968505-1-yiconghui@gmail.com> <3491d5f9-d08e-4193-a983-45340af73745@amd.com> <7300ad7c-39a5-4424-b4fd-9d3f97083f06@mailbox.org> <3167d5c6-3454-4652-86c7-e9ef0ef0a517@gmail.com> Content-Language: en-GB From: Tvrtko Ursulin In-Reply-To: <3167d5c6-3454-4652-86c7-e9ef0ef0a517@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 05/03/2026 16:23, Yicong Hui wrote: > On 2/25/26 1:57 PM, Christian König wrote: >> On 2/25/26 14:37, Michel Dänzer wrote: >>> On 2/25/26 14:25, Christian König wrote: >>>> On 2/25/26 13:46, Yicong Hui wrote: >>>>> This patch series adds 2 new flags, DRM_SYNCOBJ_QUERY_FLAGS_ERROR and >>>>> DRM_SYNCOBJ_WAIT_FLAGS_ABORT_ON_ERROR for 3 ioctl operations >>>>> DRM_IOCTL_SYNCOBJ_QUERY, DRM_IOCTL_SYNCOBJ_WAIT and >>>>> DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT to allow them to batch-request error >>>>> codes from multiple syncobjs and abort early upon error of any of >>>>> them. >>>> >>>> Patch #1 looks good enough to add my rb. >>>> >>>> Patch #2 looks good as well, but I'm not familiar enough with the >>>> code and have no time to wrap my head around it to give a review. >>>> >>>> Adding a few people on CC, maybe somebody has time to take another >>>> look. >>>> >>>>> >>>>> Based on discussions from Michel Dänzer and Christian König, and a >>>>> starter task from the DRM todo documentation. >>>>> >>>>> See https://gitlab.gnome.org/GNOME/mutter/-/issues/4624 for >>>>> discussions >>>>> on userspace implementation. >>>>> >>>>> I have looked into adding sub test cases into syncobj_wait.c and >>>>> syncobj_timeline.c, igt-tests for this and I think I understand the >>>>> process for writing tests and submitting them, however, these ioctls >>>>> only trigger in the case that there is an error, but I am not sure >>>>> what >>>>> is the best way to artifically trigger an error from userspace in >>>>> order >>>>> to test that these ioctl flags work. What's the recommended way to >>>>> approach this? >>>> >>>> When Michel agrees that this is the way to go then we either need an >>>> in-kernel selftest (see directory drivers/gpu/drm/tests/) or an >>>> userspace IGT test. >>>> >>>> Not sure what is more appropriate, maybe somebody on CC has more >>>> experience with that. >>> >>> I'd advise against landing this in the kernel before there's a >>> corresponding display server implementation making use of it, in a >>> mergeable state. >> >> Yeah we clearly have the rule that this can't be pushed into the >> kernel without userspace code as well. >> >>> Otherwise you might end up with the kernel having to support UAPI >>> which no real-world user space actually uses. Been there, done that >>> myself. >>> >>> >>> I don't have the capacity to contribute anything more than advice at >>> this point. >> >> Oh that is sad. Do you know anybody who could work on that? >> >> It is a clear improvement to error handling and I don't like to keep >> Yicong's work only on the mailing list. >> >> Thanks, >> Christian. >> > > Hello > > Is there anything else I can do? Or will we have to just leave all of > this here unmerged > > I have read the emails from Tvrtko and Matthew and I'm absolutely happy > to send a v4 to ameliorate these issues, but there might not be a need > to do so if the series won't get merged in the end I wasn't following closely the userspace angle of the discussion to be sure, nor I know enough about what are all the userspaces which may want to use it, but in general, if there is more than one potential userspace, perhaps you could try to interest some of them into the feature. Or add support for it yourself, submit to them and say this improves this or that and I have the kernel feature waiting already. One other thing, so that your effort is not lost should someone want to work on it in the future, perhaps a patch for the TODO file which links to your latest series on lore (once all review comments are addressed) and noting that the kernel implementation exists but is waiting on userspace? Not sure if we ever done something like that but maybe we should to avoid work duplication in the future. And also to preserve some credit if someone picks up the work 1-2-3 years down the road. Regards, Tvrtko > Regardless, thank you to Christian and all the maintainers for being > welcoming and all your work reviewing this patch series so far! > > Thanks > Yicong