Re: resctrl mount fail on v6.13-rc1

[Reinette Chatre]

+x86 folks

On 12/2/24 7:35 PM, Ming Lei wrote:
> On Mon, Dec 02, 2024 at 06:47:38PM -0800, Luck, Tony wrote:
>> On Mon, Dec 02, 2024 at 02:26:48PM -0800, Reinette Chatre wrote:
>>> Hi Tony,
>>>
>>> On 12/2/24 1:42 PM, Luck, Tony wrote:
>>>> Anyone better a decoding lockdep dumps then me make sense of this?
>>>>
>>>> All I did was build v6.13-rc1 with (among others)
>>>>
>>>> CONFIG_PROVE_LOCKING=y
>>>> CONFIG_PROVE_RAW_LOCK_NESTING=y
>>>> CONFIG_PROVE_RCU=y
>>>>
>>>> and then mount the resctrl filesystem:
>>>>
>>>> $ sudo mount -t resctrl resctrl /sys/fs/resctrl
> 
> [linux]# make -C tools/testing/selftests TARGETS=resctrl run_tests
> make: Entering directory '/root/git/linux/tools/testing/selftests'
> make[1]: Nothing to be done for 'all'.
> TAP version 13
> 1..1
> # timeout set to 120
> # selftests: resctrl: resctrl_tests
> # TAP version 13
> # # Fail: Check kernel supports resctrl filesystem
> # 1..0 # SKIP resctrl FS does not exist. Enable X86_CPU_RESCTRL config option.
> ok 1 selftests: resctrl: resctrl_tests # SKIP
> make: Leaving directory '/root/git/linux/tools/testing/selftests'
> 
> [linux]# grep X86_CPU_RESCTRL .config
> CONFIG_X86_CPU_RESCTRL=y
> 
> Can you share how to make /sys/fs/resctrl so that I can check if the
> recent changes in block tree can avoid this warning? 

Thank you very much for taking a look.

You may not be testing on hardware supported by resctrl. A /proc/cpuinfo
flag bit that indicates hardware supported by resctrl is "rdt_a". When booting a kernel
compiled with CONFIG_X86_CPU_RESCTRL=y on such hardware dmesg will contain
information like:
	resctrl: L3 allocation detected
	resctrl: MB allocation detected
	resctrl: L3 monitoring detected                           

> 
>>>>
>>>> There are only trivial changes to the resctrl code between
>>>> v6.12 (which works) and v6.13-rc1:
>>>>
>>>> $ git log --oneline v6.13-rc1 ^v6.12 -- arch/x86/kernel/cpu/resctrl
>>>> 5a4b3fbb4849 Merge tag 'x86_cache_for_v6.13' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
>>>> 9bce6e94c4b3 x86/resctrl: Support Sub-NUMA cluster mode SNC6
>>>> 29eaa7958367 x86/resctrl: Slightly clean-up mbm_config_show()
>>>>
>>>> So something in kernfs? Or the way resctrl uses kernfs?
>>>
>>> I am not seeing this but that may be because I am not testing with
>>> selinux enabled. My test kernel has:
>>> # CONFIG_SECURITY_SELINUX is not set
>>>
>>> I am also not running with any btrfs filesystems. 
>>>
>>> Is this your usual setup in which you are seeing this the first time? Is it
>>> perhaps possible for you to bisect?
>>
>> Bisection says:
>>
>> $ git bisect bad
>> f1be1788a32e8fa63416ad4518bbd1a85a825c9d is the first bad commit
>> commit f1be1788a32e8fa63416ad4518bbd1a85a825c9d
>> Author: Ming Lei <ming.lei@xxxxxxxxxx>
>> Date:   Fri Oct 25 08:37:20 2024 +0800
>>
>>     block: model freeze & enter queue as lock for supporting lockdep
>>
>>>
>>> The subject states "resctrl mount fail" - could you please confirm if
>>> resctrl cannot be mounted in addition to the lockdep warning?
> 
> It seems one lockdep false positive, but it shouldn't cause 'resctrl
> mount fail', I will take a look at the lock chains and see if some of
> them can be cut.

Tony confirmed [1] in follow-up message that resctrl mount succeeded despite
the lockdep notice.

Reinette


[1] https://lore.kernel.org/all/Z0441XN_KoCP-fNz@agluck-desk3/