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 01EADCD5BD0 for ; Wed, 27 May 2026 17:10:29 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id A978510E292; Wed, 27 May 2026 17:10:29 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="HxuBF/ZP"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.16]) by gabe.freedesktop.org (Postfix) with ESMTPS id D597D10E292 for ; Wed, 27 May 2026 17:10:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1779901808; x=1811437808; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=BWFoCh2NsO68M3rms9cSd79FpVq+VAFlQ3GbIH2tW98=; b=HxuBF/ZPm/xKWc+NxJUUGnQDVcUqDnuquEJEUOYYALD34nAM9/oe8PP/ lTPPi9lpQ1G9A4UjFRu6D+uwVQOynVRKsY36qoNazrN6hwNuZ89L0qI7k /jCdXMAfjqTN0eTrjWPMiriRZKAjocPZ6zm/a3heTmClo5NNBMXIvs+RP L35sqKWxYRfjkAYKKt+N6/TEqx+VvVo76MW8o4PYNfVLr8yO4Vymk8884 qhngaYEm56vAnIS4xtcqFor7mBooGdHwfDoxRE7Kk9yfallFOO6HbTdU+ op/wlvrDa1dTa/TDq+Qg3V6lSjdf9sdrPccDR5nfGAgbde3riYXzetJ0w A==; X-CSE-ConnectionGUID: Ktkm5gJ0QLCeaA++Ep0rYw== X-CSE-MsgGUID: WCGfdS1CQjODojeESBT6bw== X-IronPort-AV: E=McAfee;i="6800,10657,11799"; a="80926364" X-IronPort-AV: E=Sophos;i="6.24,171,1774335600"; d="scan'208";a="80926364" Received: from orviesa003.jf.intel.com ([10.64.159.143]) by orvoesa108.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 May 2026 10:10:08 -0700 X-CSE-ConnectionGUID: wWKoXc9LSZiFKddgmxuYUQ== X-CSE-MsgGUID: ySwRpPi8R3mWAKLPaDw5sA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.24,171,1774335600"; d="scan'208";a="246325129" Received: from gauravga-mobl1.amr.corp.intel.com (HELO adixit-MOBL3.intel.com) ([10.125.67.21]) by ORVIESA003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 May 2026 10:10:08 -0700 Date: Wed, 27 May 2026 10:10:08 -0700 Message-ID: <87cxygvkwf.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: Gustavo Sousa Cc: , Subject: Re: [PATCH i-g-t] lib/intel_wa: Return false for non-root users In-Reply-To: <87fr3d6pgh.fsf@intel.com> References: <20260527034342.1952153-1-ashutosh.dixit@intel.com> <87fr3d6pgh.fsf@intel.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.2 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-BeenThere: igt-dev@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Development mailing list for IGT GPU Tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: igt-dev-bounces@lists.freedesktop.org Sender: "igt-dev" On Wed, 27 May 2026 04:50:54 -0700, Gustavo Sousa wrote: > > Ashutosh Dixit writes: > > > Under some circurmstancs debugfs reads are initiated by non-root users. In > > these cases, just return false rather than asserting that debugfs could not > > be read. > > > > Signed-off-by: Ashutosh Dixit > > --- > > lib/intel_wa.c | 4 ++++ > > 1 file changed, 4 insertions(+) > > > > diff --git a/lib/intel_wa.c b/lib/intel_wa.c > > index a16ea62a4c..2d0d664f3c 100644 > > --- a/lib/intel_wa.c > > +++ b/lib/intel_wa.c > > @@ -47,6 +47,10 @@ bool igt_has_intel_wa(int drm_fd, const char *check_wa) > > unsigned int xe; > > char name[256]; > > > > + /* If we are not root, we can't read debugfs, just return false */ > > + if (getuid() != 0) > > + return false; > > This doesn't sound right to me. The function will be lying by returning > false here and will probably make it harder to debug issues on code that > rely on having the correct result for a workaround check. > > My personal take is that we probably should start avoiding having > asserts in lib/ code and defer any assertion to real test code. OK, I've reverted the original patch: https://patchwork.freedesktop.org/series/167401/