From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 83AEE3EBF3E for ; Thu, 19 Feb 2026 00:15:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771460146; cv=none; b=Vjzoka8nBiquoNhONfuwOOfvI+p5r7eECbj5P/rHLe6Wdaaj0MQuT9SL8IMcdOufB3SaBbK6vJcr6PlguQG90/FhhQkULD5FDM1ZZ/RWIYEzDcT75glYn/nst8VIX7DS6lt4gq+ITanlgoqFEhfiU1+FeqYym8cDR1sEOBS4qRg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771460146; c=relaxed/simple; bh=Br9J6OV6wysCb0CV1hd/mEXSbs2oFijg7ivomshQgqg=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=hQlhvl1bgQSMHRIHAk9zd60DyCiYXbdseecWnlGH2isQyyUXIrJ5UH7J5IFdvqJQEgpiNOdxcftMhFr1XjsywuwE/4Le5xh6lX4JA+VHfDv+wJ1FnKz+vP9D0U5olxhLmtFmO7Vk5EwRcc3k0s7vhsdQoUvs+ed6hmDW9f8V81E= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=PoUjw5wR; arc=none smtp.client-ip=209.85.128.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="PoUjw5wR" Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-483770e0b25so4256295e9.0 for ; Wed, 18 Feb 2026 16:15:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771460144; x=1772064944; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=zNieJSbrQ0dDCtKYRq0xz3ZibHVrsIB5qtqcWz6+XsM=; b=PoUjw5wR1JFP1yCgXt0ANy702vEheO4hYtf5w6BZ0iOxMei2JzfiVoJrpYhxUqCg6T cIV5Rw3Jro0P6Yyg93+OzvQmTEa6Mr9/gs2qb1vAUlKiQm7/l9UY62NSA+GXmh86l+Mp RbD0u108NGHlYt+mvVdtj5UW2/Gcyvp3bz2qjb6yLCk5FFD6P6Galbu7GSNETP15/6kE dVLBs21JEwAJ99x+cnE8I+nKOByE6TDFYG+j9NP2trKsYX+KcXXvlXgbiY6Gm57LbvTy ip/LftoVZ67gQGhazRXaNTPWJk+vMRMWWYVc0ek+PPuojbBdDciYwZhcjF4VpW0wsKrG OtzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771460144; x=1772064944; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=zNieJSbrQ0dDCtKYRq0xz3ZibHVrsIB5qtqcWz6+XsM=; b=Lj72oxqBakUmigyIukyecIqabVMHX0KzYuA2q61kp1zzaJYuZyIn/5BvTryQ1+QT9o UT3RznOn3cs/YPBcExAkcSVFaZjQa4k0AzstPbRi5/3Zb+fimk+82rxNqJTurgwyV8cZ 0JPAmxhUGifwJf/Foe5y17bVcd/FPZY3vMrJ3j8qKYtfEEAho4nPe2CPyBxrsVH3OfHj rSyLb8mrUEC6CBClhUdxM5a/3w+n/8Dqn4WQ72rsZRhgdQNb84NlyBtmTnn4/j/bng+o k9l4nvKdL/8Calxy5MZsFlCpxZV7s8qB4dWl5sfQlZRj1lOkOPU6E5w1CvqdMmTGWXWH Az+w== X-Forwarded-Encrypted: i=1; AJvYcCXYrxxHLbBN6UYQMJK+EfkrTwK7h/LYF5dxTgtKOr+BoYTOkh5k45GHPDhXhimS9rTxHdfQZ+lsyEAfi3k=@vger.kernel.org X-Gm-Message-State: AOJu0YxOu2nqGvcXGSNGG7Z4S0yRmvJN8wBQMmDkmDrm02uYoOoCNUzz m7WKwBdX9dtAFCVZEtTTqSGNOZXZCRbCxOxQnL0bk8wemdP21D5+dj5x X-Gm-Gg: AZuq6aJewaHC2AKOlyWpxcJxRuwJBgLDOQr3p2jaSEM13RTttp7daBPYNikwce/Rrab u5tqmRxBkGbBc7QU9yK3EZBN4EwIhVmsg9yidGCTJU6z4TRhDXt3j8bME26XX91Ump2GErZTFEK ixM7hgFv4kJHGBaYndsuN20vilXcG/3nVW4YQ5uI5Um461iNxQSl8kubUUc96Vn9OUjHoWjBmIp 7jJO0MmXZZbFZeXc1TfCxwY3zgJOCNBoc/PER3rBw6kT8Ss1dmSn3vV2nvJjTmjwJ27dRjgWexp Rz+9R3OnmtUlriiJl8cW/zxnFmgmgX2NM/DjQhyC25anFVFEqN0nqG2i+OvpqVgPkZEaSI7XQK9 aZ1Wgx6Y7Kzff+BtFWQvBxpnsSmZaENOjkf1IgrcJdn7+wFQrFkluTgUMNSVTGsm9RevA/9b2md E/vVopD7Irx9vpsnPGGM6n/FzRdrge/mVJKaz3dVENvMGfveWsKzUg6WmQJ5g= X-Received: by 2002:a05:600c:1da1:b0:480:25ae:9993 with SMTP id 5b1f17b1804b1-48371085c9dmr323883855e9.20.1771460143632; Wed, 18 Feb 2026 16:15:43 -0800 (PST) Received: from [10.247.12.125] ([129.234.0.168]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4839ea2b0fesm4515335e9.4.2026.02.18.16.15.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 18 Feb 2026 16:15:43 -0800 (PST) Message-ID: <96e42cb2-c5eb-4f2b-bb52-faea1c91c6c9@gmail.com> Date: Thu, 19 Feb 2026 00:15:42 +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 v1 1/2] drm/syncobj: Add DRM_IOCTL_SYNCOBJ_QUERY_ERROR to query fence error status To: =?UTF-8?Q?Michel_D=C3=A4nzer?= , =?UTF-8?Q?Christian_K=C3=B6nig?= Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, skhan@linuxfoundation.org, david.hunter.linux@gmail.com, wayland-devel@lists.freedesktop.org, mesa-dev@lists.freedesktop.org References: <20260213120836.81283-1-yiconghui@gmail.com> <20260213120836.81283-2-yiconghui@gmail.com> <0e7c3ee9-54b1-4ecc-b960-6e2fda6ab3ae@amd.com> Content-Language: en-US From: Yicong Hui In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit > Instead add some additional flag to DRM_SYNCOBJ_WAIT_FLAGS_* so that the IOCTL aborts the wait and returns an error as soon as it sees any fence with an error. > Another DRM_SYNCOBJ_QUERY_FLAGS_* is potentially also useful to query the error on a number of drm_syncobjs at the same time. > Using a new DRM_SYNCOBJ_QUERY_FLAGS_ERROR on all signaled syncobj as separate way to query if there was an error should work for you in the meantime? > @Yicong any more questions or do you got the idea? So to confirm, I should implement a flag DRM_SYNCOBJ_WAIT_FLAGS_ERROR which would make the DRM_IOCTL_SYNCOBJ_WAIT ioctl just wait until any fence returns an error, then return the error code of that syncobj/fence's first error, and then return 0 if everything completes without any errors? and add flag DRM_SYNCOBJ_QUERY_FLAGS_ERROR which would make the DRM_IOCTL_SYNCOBJ_QUERY ioctl fill out the points array with the error codes of each syncobj instead of the latest timeline point? Should it leave the entry as 0 for syncobjs with no error or leave it as it would be without the flag? And if it has multiple fences with errors it should just return the latest error right? > Good point, poll() has a POLLERR flag for that but I have no idea if eventfd supports that in any way. So potentially doable as well but a bit more work. Okay, that sounds like somewhere I could potentially implement similar functionality for poll() in a follow-up patch later in the future Thank you! - Yicong