Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp4498640imw; Tue, 12 Jul 2022 09:00:29 -0700 (PDT) X-Google-Smtp-Source: AGRyM1tyE+AjKCyXm+mIh9QuuaEEcbnm/TxS0LjoBuyeKukfaW5EiXhoUFY57W0JS1sJ+exKK8Me X-Received: by 2002:a17:90b:1b03:b0:1f0:298e:b0bf with SMTP id nu3-20020a17090b1b0300b001f0298eb0bfmr5095252pjb.59.1657641629289; Tue, 12 Jul 2022 09:00:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1657641629; cv=none; d=google.com; s=arc-20160816; b=JuMNFsuzGEvfxx/jkVjy9xC/v2XdYUzJXgA5IGGuUHwBUPXZMsehn+G0ht6tzBMcff xIHIFbDzwrySLJ3ZqNPZN2TRt/hz37L/3c0RQt1IQ8kOWjGQumwMqFRnHyRnigtRJYU1 ZYsaMaV89Jy9wJxOlGf2ns8nZ7xg7ksSpx2v74A278CNFERzhf0w5OjJ1wwu9RDqapqx Fz9XwfU7uzSmAfN62aP3GUvb9m9LJ+3t0lD34NNWSO5xc7yQPeK+y2puFtySmXDrLX7x pvVgcKVxiYZhGDiZlfMm6DOp2IoEFXSaZnmdHRZnIsVzeqwQNIZW/iVDZs8pWvW0XFxS Zw6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=2nlWovdml3x38ikBsijP4iu2GVcLVtEJCFEUL/KVw7o=; b=CK+EE8G6ltBUNw3MLF0bRST5fULFcNFaC4uvnb5lqTWMx64AIC6AtquLrVA7FkgeWv 8iVuWzSj4dbjzYHH47bzOE9sL1OkhSXEt30buaPB2MSAe6RIZxuZPvmmmkpuazLJqnBI fcIXAwaObdY3i2b3Jfzna2+Fe9KkhySP5xC6rcU+32KTuRZcKx6ZM/t5a9P2LQo0JTeN 5BmKdClczavhDRQk4arb79VK0sj/s2y9STowBB6DmYXshSLGX7NoylSppU9F1HgZg3bl 7o4swtS7DFQ/vUgD1EJ0e5MK3ueOFbkj7mxGh8NK+HIQJvzBsmLPGF+/sdI3V2obMoox WL8g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=l7epumwr; 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=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id t63-20020a635f42000000b00415c97318c6si14835291pgb.289.2022.07.12.09.00.14; Tue, 12 Jul 2022 09:00:29 -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=@google.com header.s=20210112 header.b=l7epumwr; 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=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233630AbiGLPs0 (ORCPT + 99 others); Tue, 12 Jul 2022 11:48:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57650 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229657AbiGLPsZ (ORCPT ); Tue, 12 Jul 2022 11:48:25 -0400 Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0E982C54BD for ; Tue, 12 Jul 2022 08:48:21 -0700 (PDT) Received: by mail-wm1-x32a.google.com with SMTP id p27-20020a05600c1d9b00b003a2f36054d0so52442wms.4 for ; Tue, 12 Jul 2022 08:48:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=2nlWovdml3x38ikBsijP4iu2GVcLVtEJCFEUL/KVw7o=; b=l7epumwrTzHY/T/kgehRLD4WmQF+WOR5a1v/PiZIlCt0xOL8TbVuf2dOsADboZauYg yoHGQR9uyhRHNy5Z+nD+Yr/Q4cjuuoa9717gHmCsEmXCZ/rp5QqzsjCTFNVry0nBuUQs oNuoDRJgCp4nizfkUcp4m7npXsvxkMY4EcPEbXdtKtMaGrRwD85mdhlPbmIF6zfSi++s MNocdcQZIE4dJTnTes/KPHJRgRQ+FMrgxNsAtRDCoZVdJvj0T1yzqWZ/cFRMRp4d3UfS mwVBT0upNQxQC+KQnXKvDcnVv44yLYa7rwH++mX8p7TUCXdA7Gowr+9glk8fn+Chx/hG Nn9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=2nlWovdml3x38ikBsijP4iu2GVcLVtEJCFEUL/KVw7o=; b=bN8dzG5FiUtSFgFaq25VrbBMJBjneph4GXTI9z6cp6FUl0fxOlalmm/Sgrad4+xKc1 Ny8XsJpRto4w9QjOzty9trm7QNX+8qzYMvQba9/4bfoPWzhVvILCYFZNgOrD1St2YFzl 3LqVMPM0zzIzbHu07iIvsVZ35PNicsQtLmos6ZXwRmC25DR8OFMWQXM4IZiQXtDrex9Q dzbM9n3WpPqzyV1V4j1iAc6J7ARXDw0qMUIbCd5Oz+NmyaT6excK0Md/syt1Kn53Q7Wb wGAHDCDOlyNOt1D6UEoDAESAPVo0tTSnMffJZIcVP9Dkiq4SWEGd6+kny4f9PVuqVqIZ 9IOA== X-Gm-Message-State: AJIora+alQLwMoXTEj2GWNWd4QYCY3ZYdLGlSK0l6ZbJRHvO1vY3sT8T v1DDbQCQcyS41eFvVqSwcZSEZLE0ZZh8kNad4J+HBnQESg== X-Received: by 2002:a7b:cd0c:0:b0:3a2:e864:98b8 with SMTP id f12-20020a7bcd0c000000b003a2e86498b8mr4562927wmj.200.1657640899216; Tue, 12 Jul 2022 08:48:19 -0700 (PDT) MIME-Version: 1.0 References: <20220712042258.293010-1-jstultz@google.com> <13c5ca05-a366-2751-4f26-d978d074f748@amd.com> In-Reply-To: <13c5ca05-a366-2751-4f26-d978d074f748@amd.com> From: John Stultz Date: Tue, 12 Jul 2022 08:48:07 -0700 Message-ID: Subject: Re: [RFC][PATCH 1/3] drm: drm_syncobj: Add note in DOC about absolute timeout values To: =?UTF-8?Q?Christian_K=C3=B6nig?= Cc: LKML , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , Jason Ekstrand , Lionel Landwerlin , Chunming Zhou , David Airlie , Daniel Vetter , dri-devel@lists.freedesktop.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL 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 Tue, Jul 12, 2022 at 12:40 AM Christian K=C3=B6nig wrote: > Am 12.07.22 um 06:22 schrieb John Stultz: > > After having to debug down through the kernel to figure out > > why my _WAIT calls were always timing out, I realized its > > an absolute timeout value instead of the more common relative > > timeouts. > > > > This detail should be called out in the documentation, as while > > the absolute value makes sense here, its not as common for timeout > > values. > > Well absolute timeout values are mandatory for making -ERESTARTSYS work > without any additional handling. Yes! I'm not saying it's wrong to use absolute values, just that relative values are common enough to create some confusion here. > So using them is recommended for ~20 years now and IIRC even documented > somewhere. So in addition to "somewhere", why not in the interface documentation as we= ll? > See here as well https://lwn.net/Articles/17744/ how much trouble system > calls with relative timeouts are. Yep. Well aware. :) thanks -john