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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 09365CDE003 for ; Thu, 26 Sep 2024 13:32:15 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id CCAA810EB45; Thu, 26 Sep 2024 13:32:14 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="MU4w5d0c"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.17]) by gabe.freedesktop.org (Postfix) with ESMTPS id D2A3C10EB45 for ; Thu, 26 Sep 2024 13:32:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1727357532; x=1758893532; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=0Y5xyn1IcEWgrjnJZ5Aje3ARLnCQi9NHbIx/Ab7tPQ4=; b=MU4w5d0c8tjfbrLGsTm9EJCSd+/gkjgFIXdzuBd58QFFueeR9Nkgg41T cS8YxnoVBFRkeW9udppBERIvOrYi14tvkg6m6fd4dJk5pHW3WZrTd3DDO VnmfIGktRxAGmH6vKErZ4/7nY6vMD4IyI8PT1qOup9bGNDOasonu2ub7I yqj5cP02Pf/oru2749ED47Kt4mx6L62vj4lcQgdCPospnMfBpiPfGGJ+a L0Ylbw2kj+gJHAe+8CEh6P8G2sFm+7JTy5Nj2msea03eAXhmsZuJ5qxxx JkTb+y/sxLYwqrvMODXg/NSK9HOTdCMR1qgMpU0vPfzfG8id1paP+A/Jz Q==; X-CSE-ConnectionGUID: 9ICDleQ3Ss6XqJYiK/J4Eg== X-CSE-MsgGUID: ZsShq/t+RtyqrqD3fcNoXg== X-IronPort-AV: E=McAfee;i="6700,10204,11207"; a="26315602" X-IronPort-AV: E=Sophos;i="6.11,155,1725346800"; d="scan'208";a="26315602" Received: from fmviesa004.fm.intel.com ([10.60.135.144]) by fmvoesa111.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Sep 2024 06:32:12 -0700 X-CSE-ConnectionGUID: wEnwsZ4eRLqywkpaRwZQPA== X-CSE-MsgGUID: jMtLXy5lQ1+CpvGoDWKJCw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,155,1725346800"; d="scan'208";a="76645162" Received: from jnikula-mobl4.fi.intel.com (HELO localhost) ([10.237.66.160]) by fmviesa004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Sep 2024 06:32:10 -0700 From: Jani Nikula To: Lucas De Marchi Cc: Francois Dugast , intel-xe@lists.freedesktop.org, Matthew Brost , Rodrigo Vivi , Michal Wajdeczko Subject: Re: [PATCH v3] drm/xe: Use fault injection infrastructure to find issues at probe time In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <20240925155546.76630-1-francois.dugast@intel.com> <87jzey21i8.fsf@intel.com> <87ed561vci.fsf@intel.com> Date: Thu, 26 Sep 2024 16:32:08 +0300 Message-ID: <87bk0a1qxz.fsf@intel.com> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: intel-xe@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel Xe graphics driver List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-xe-bounces@lists.freedesktop.org Sender: "Intel-xe" On Thu, 26 Sep 2024, Lucas De Marchi wrote: > On Thu, Sep 26, 2024 at 02:57:01PM GMT, Jani Nikula wrote: >>On Thu, 26 Sep 2024, Francois Dugast wrote: >>> On Thu, Sep 26, 2024 at 12:43:59PM +0300, Jani Nikula wrote: >>>> On Wed, 25 Sep 2024, Francois Dugast wrote: >>>> > +/* >>>> > + * The ALLOW_ERROR_INJECTION() macro is added to conditionally skip execution at >>>> > + * runtime and use a provided return value, in order to test errors paths in the >>>> > + * callers. The requirements for the error injectable functions are not strictly >>>> > + * fullfilled but this is acceptable because the caller only propagates the error >>>> > + * up the stack without cleanup of resources potentially allocated here. >>>> > + */ >>>> >>>> I'm curious on the details of "The requirements for the error injectable >>>> functions are not strictly fullfilled". It's repeated many times, but >>>> not explained. Maybe I'd like the info spoon fed to me instead of having >>>> to figure it out for myself. ;) >>> >>> Understandable! I will make it more explicit in the next revision. Any >>> suggestion to avoid the duplication? >> >>All I can think of is adding a single, more thorough explanation comment >>about the approach to error injection somewhere suitable (*), and then >>have short comments referencing that. >> >> /* See xxx for details on error injection. */ > > https://docs.kernel.org/fault-injection/fault-injection.html#requirements-for-the-error-injectable-functions > > so... like this? > > /* > * See "Requirements for the Error Injectable Functions" in > * Documentation/fault-injection/fault-injection.rst > */ All I wanted to know was what "not strictly fullfilled" means in "The requirements for the error injectable functions are not strictly fullfilled". What parts are we violating? What's the impact? BR, Jani. -- Jani Nikula, Intel