Re: [BUG] WARNING in workingset_activation triggered by KVM page fault path on Linux 7.0.0-08391-g1d51b370a0f8

["David Hildenbrand (Arm)" <david@kernel.org>]

On 4/22/26 15:01, Sean Christopherson wrote:
> On Wed, Apr 22, 2026, David Hildenbrand (Arm) wrote:
>> On 4/22/26 04:06, Zw Tang wrote:
>>> Hi David,
>>>
>>> Thanks for pointing this out.
>>>
>>> You are right. The commit id I sent was incorrect. I mistakenly used the
>>> git describe-style suffix g1d51b370a0f8, but the actual git commit is:
>>>
>>> 1d51b370a0f8f642f4fc84c795fbedac0fcdbbd2
>>>
>>> The short commit id is:
>>>
>>> 1d51b370a0f8
>>>
>>> Sorry for the confusion.
>>>
>>> I am also re-checking whether the kernel image was built from a clean tree
>>> and whether there were any local modifications when the crash was reproduced,
>>> so that the reported source line numbers match the exact build.
>>
>> Okay, on that tree include/linux/memcontrol.h:381 points at
>>
>> 	lockdep_assert_once(rcu_read_lock_held() ||
>> 	lockdep_is_held(&cgroup_mutex));
>>
>> lockdep_is_held() would not trigger a warning like that IIRC, but
>>
>> lockdep_assert_once() does
>>
>> 	do { WARN_ON_ONCE(debug_locks && !(cond)); } while (0)
>>
>>
>> So likely we are calling obj_cgroup_memcg() without the RCU read lock held?
>>
>>
>> kvm_release_page_clean()->kvm_set_page_accessed()->mark_page_accessed()->folio_mark_accessed()->workingset_activation()
>>
>> ... grabs the RCU lock, though, before calling
>>
>> 	rcu_read_lock();
>> 	workingset_age_nonresident(folio_lruvec(folio), folio_nr_pages(folio));
>> 	rcu_read_unlock();
> 
> No?  Since commit 906c38ff52e9 ("memcg: workingset: remove folio_memcg_rcu usage"),
> I see:

Yeah, I used git show show
1d51b370a0f8f642f4fc84c795fbedac0fcdbbd2:include/linux/memcontrol.h to look at
the file but then explored the other code without a checkout, ugh.

> 
> void workingset_activation(struct folio *folio)
> {
> 	/*
> 	 * Filter non-memcg pages here, e.g. unmap can call
> 	 * mark_page_accessed() on VDSO pages.
> 	 */
> 	if (mem_cgroup_disabled() || folio_memcg_charged(folio))
> 		workingset_age_nonresident(folio_lruvec(folio), folio_nr_pages(folio));
> }
> 
> But for the life of me, I can't figure out how obj_cgroup_memcg() is being reached,
> and I haven't been able to reproduce the splat to add instrumentation (though I
> haven't tried very hard).

folio_lruvec() does a folio_memcg(folio) that does a obj_cgroup_memcg() for
folio_memcg_kmem().

So the page was charged through __memcg_kmem_charge_page() by passing
__GFP_ACCOUNT to the kernel.

So this is likely not some ordinary folio?

-- 
Cheers,

David