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 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();


The folio_memcg_charged() only checks folio->memcg_data.

So something does not quite add up here?

-- 
Cheers,

David