linux-kernel - Re: linux-next: Tree for Jul 21 [drivers/gpu/drm/xe/xe.ko]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <di56uabghjhn6pst3byqplwkpy6oin6gjqjlvklolp7h6kz4vc@ygemqab4dj6t>
Date: Wed, 23 Jul 2025 12:50:01 -0300
From: Lucas De Marchi <lucas.demarchi@...el.com>
To: Randy Dunlap <rdunlap@...radead.org>
CC: Stephen Rothwell <sfr@...b.auug.org.au>, Linux Next Mailing List
	<linux-next@...r.kernel.org>, Linux Kernel Mailing List
	<linux-kernel@...r.kernel.org>, <linux-um@...ts.infradead.org>, "Richard
 Weinberger" <richard@....at>, <intel-xe@...ts.freedesktop.org>, "Linux DRI
 Development" <dri-devel@...ts.freedesktop.org>
Subject: Re: linux-next: Tree for Jul 21 [drivers/gpu/drm/xe/xe.ko]

On Tue, Jul 22, 2025 at 10:26:11AM -0300, Lucas De Marchi wrote:
>On Mon, Jul 21, 2025 at 10:50:29PM -0700, Randy Dunlap wrote:
>>Hi,
>>
>>On 7/21/25 6:38 PM, Lucas De Marchi wrote:
>>>On Mon, Jul 21, 2025 at 01:17:33PM -0700, Randy Dunlap wrote:
>>>>
>>>>
>>>>On 7/21/25 12:41 AM, Stephen Rothwell wrote:
>>>>>Hi all,
>>>>>
>>>>>Changes since 20250718:
>>>>>
>>>>
>>>>on ARCH=um SUBARCH=i386, when
>>>># CONFIG_DEBUG_FS is not set
>>>
>>>can you share your entire config? I have all of the settings above, but
>>>I can't reproduce it with gcc-13. Is this a regression from the previous
>>>-next tag? I think the diff below should fix it, but I can't confirm on
>>>my end nor I see how this would be a regression from a few days ago
>>>only.
>>
>>It's a randconfig, attached. (#1046 is for 32-bit)
>>config-um64-drmxegt is for 64-bit.
>>using gcc (SUSE Linux) 15.1.1 20250714
>
>just tried on Ubuntu with gcc 14 and still can't reproduce it. I try
>again later on arch or suse.
>
>>
>>>
>>>-----8<-------
>>>diff --git a/drivers/gpu/drm/xe/xe_gt.h b/drivers/gpu/drm/xe/xe_gt.h
>>>index e9ccab8aedbef..41880979f4ded 100644
>>>--- a/drivers/gpu/drm/xe/xe_gt.h
>>>+++ b/drivers/gpu/drm/xe/xe_gt.h
>>>@@ -24,7 +24,7 @@
>>> extern struct fault_attr gt_reset_failure;
>>> static inline bool xe_fault_inject_gt_reset(void)
>>> {
>>>-    return should_fail(&gt_reset_failure, 1);
>>>+    return IS_ENABLED(CONFIG_DEBUG_FS) && should_fail(&gt_reset_failure, 1);
>>> }
>>>
>>> struct xe_gt *xe_gt_alloc(struct xe_tile *tile);
>>>-----8<-------
>>
>>This fixes the problem for me. Thanks.
>>
>>Acked-by: Randy Dunlap <rdunlap@...radead.org>
>>Tested-by: Randy Dunlap <rdunlap@...radead.org>
>
>ok, thanks for confirming.  Initially I thought we could have a
>dependency on debugfs that commit ccbfd2df3018 ("drm/xe: clean up fault
>injection usage") broke, but it doesn't seem so.
>
>So... another approach, probably more correct, would be to move the
>attribute off _debugfs.c, since it's availability shouldn't be tied to
>debugfs.

nvm, the change is correct, it is actually a debugfs attribute.

Applied to drm-xe-next:

	4d3bbe9dd28c ("drm/xe: Fix build without debugfs")

thanks,
Lucas De Marchi