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: <vpdxxpbbirslnp5m2sdaz74ehdwc5tp54fp6rp2kxtt7vmr23e@lnp5lp7vzryy>
Date: Tue, 22 Jul 2025 10:26:11 -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 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.

Lucas De Marchi

>
>>
>> thanks,
>> Lucas De Marchi
>>
>>>
>>> ERROR: modpost: "gt_reset_failure" [drivers/gpu/drm/xe/xe.ko] undefined!
>
>
>-- 
>~Randy