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

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

[Zw Tang]

Hi,

I am reporting a WARNING in workingset_activation() triggered by a
syzkaller C reproducer on Linux 7.0.0-08391-g1d51b370a0f8.

The warning is hit from the KVM page fault path:
kvm_set_page_accessed() -> folio_mark_accessed() -> workingset_activation().

At first glance this looks more like an MM/workingset issue than a
KVM-specific bug, although KVM/SVM is the trigger path.

Reproducer:
C reproducer: pastebin.com/raw/zzNSd9HK
console output: pastebin.com/raw/TuipfpyA
kernel config: pastebin.com/raw/aq1V3cLk

Kernel:
HEAD commit: 1d51b370a0f8
git tree: torvalds/linux
kernel version: 7.0.0-08391-g1d51b370a0f8 #1 PREEMPT(lazy) (QEMU
Standard PC, Q35)

The warning is:

WARNING in workingset_activation

Log excerpt:

WARNING: include/linux/memcontrol.h:381 at
workingset_activation+0x466/0x540, CPU#1: repro/238

Call Trace:
folio_mark_accessed+0x1d3/0x650
kvm_set_page_accessed+0x5a/0x70
kvm_release_page_clean+0x26/0x180
direct_page_fault+0x553/0x11a0
kvm_mmu_page_fault+0x35b/0x2020
kvm_handle_page_fault+0x1aa/0x380
svm_invoke_exit_handler+0x7a/0xe0
svm_handle_exit+0x416/0x7f0
vcpu_enter_guest+0x26ad/0x49c0
kvm_arch_vcpu_ioctl_run+0x697/0x25e0
kvm_vcpu_ioctl+0x737/0x1610
__x64_sys_ioctl+0x192/0x220
do_syscall_64+0x117/0xfc0
entry_SYSCALL_64_after_hwframe+0x4b/0x53

The reproducer appears to drive KVM into a guest page fault flow that
marks a folio as accessed, and the warning is then emitted inside
workingset_activation().

Because the RIP is in workingset_activation() itself, this may
indicate a problem in workingset/LRU or memcg/lruvec handling, with
KVM only serving as the trigger path.

Please let me know if I should also send this to additional KVM x86
maintainers, but mm/workingset.c seems to be the primary fault
location.

Thanks.

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

[David Hildenbrand (Arm)]

On 4/21/26 13:17, Zw Tang wrote:
> Hi,
> 
> I am reporting a WARNING in workingset_activation() triggered by a
> syzkaller C reproducer on Linux 7.0.0-08391-g1d51b370a0f8.

g1d51b370a0f8 is not a known git commit id.

Do you have an upstream git commit where the line number
include/linux/memcontrol.h:381 makes sense?


-- 
Cheers,

David

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

[Zw Tang]

[-- Attachment #1: Type: text/plain, Size: 2160 bytes --]

------------------------------
*发件人:* Tang Zw <shicenci@gmail.com>
*发送时间:* 2026年4月22日 10:03
*收件人:* David Hildenbrand (Arm) <david@kernel.org>; linux-mm@kvack.org <
linux-mm@kvack.org>; akpm@linux-foundation.org <akpm@linux-foundation.org>;
hannes@cmpxchg.org <hannes@cmpxchg.org>
*抄送:* kvm@vger.kernel.org <kvm@vger.kernel.org>;
linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>;
pbonzini@redhat.com <pbonzini@redhat.com>; seanjc@google.com <
seanjc@google.com>
*主题:* 回复: [BUG] WARNING in workingset_activation triggered by KVM page
fault path on Linux 7.0.0-08391-g1d51b370a0f8

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.
Thanks.

------------------------------
*发件人:* David Hildenbrand (Arm) <david@kernel.org>
*发送时间:* 2026年4月21日 22:06
*收件人:* Zw Tang <shicenci@gmail.com>; linux-mm@kvack.org <linux-mm@kvack.org>;
akpm@linux-foundation.org <akpm@linux-foundation.org>; hannes@cmpxchg.org <
hannes@cmpxchg.org>
*抄送:* kvm@vger.kernel.org <kvm@vger.kernel.org>;
linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>;
pbonzini@redhat.com <pbonzini@redhat.com>; seanjc@google.com <
seanjc@google.com>
*主题:* Re: [BUG] WARNING in workingset_activation triggered by KVM page
fault path on Linux 7.0.0-08391-g1d51b370a0f8

On 4/21/26 13:17, Zw Tang wrote:
> Hi,
>
> I am reporting a WARNING in workingset_activation() triggered by a
> syzkaller C reproducer on Linux 7.0.0-08391-g1d51b370a0f8.

g1d51b370a0f8 is not a known git commit id.

Do you have an upstream git commit where the line number
include/linux/memcontrol.h:381 makes sense?


-- 
Cheers,

David

[-- Attachment #2: Type: text/html, Size: 6701 bytes --]

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

[Zw Tang]

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.

Thanks.

Zw Tang <shicenci@gmail.com> 于2026年4月22日周三 10:06写道：
>
>
> ________________________________
> 发件人: Tang Zw <shicenci@gmail.com>
> 发送时间: 2026年4月22日 10:03
> 收件人: David Hildenbrand (Arm) <david@kernel.org>; linux-mm@kvack.org <linux-mm@kvack.org>; akpm@linux-foundation.org <akpm@linux-foundation.org>; hannes@cmpxchg.org <hannes@cmpxchg.org>
> 抄送: kvm@vger.kernel.org <kvm@vger.kernel.org>; linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>; pbonzini@redhat.com <pbonzini@redhat.com>; seanjc@google.com <seanjc@google.com>
> 主题: 回复: [BUG] WARNING in workingset_activation triggered by KVM page fault path on Linux 7.0.0-08391-g1d51b370a0f8
>
> 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.
> Thanks.
>
> ________________________________
> 发件人: David Hildenbrand (Arm) <david@kernel.org>
> 发送时间: 2026年4月21日 22:06
> 收件人: Zw Tang <shicenci@gmail.com>; linux-mm@kvack.org <linux-mm@kvack.org>; akpm@linux-foundation.org <akpm@linux-foundation.org>; hannes@cmpxchg.org <hannes@cmpxchg.org>
> 抄送: kvm@vger.kernel.org <kvm@vger.kernel.org>; linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>; pbonzini@redhat.com <pbonzini@redhat.com>; seanjc@google.com <seanjc@google.com>
> 主题: Re: [BUG] WARNING in workingset_activation triggered by KVM page fault path on Linux 7.0.0-08391-g1d51b370a0f8
>
> On 4/21/26 13:17, Zw Tang wrote:
> > Hi,
> >
> > I am reporting a WARNING in workingset_activation() triggered by a
> > syzkaller C reproducer on Linux 7.0.0-08391-g1d51b370a0f8.
>
> g1d51b370a0f8 is not a known git commit id.
>
> Do you have an upstream git commit where the line number
> include/linux/memcontrol.h:381 makes sense?
>
>
> --
> Cheers,
>
> David

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

[David Hildenbrand (Arm)]

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

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

[Sean Christopherson]

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:

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).

> The folio_memcg_charged() only checks folio->memcg_data.
> 
> So something does not quite add up here?
> 
> -- 
> Cheers,
> 
> David

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

[David Hildenbrand (Arm)]

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

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

[Shakeel Butt]

On Wed, Apr 22, 2026 at 06:01:44AM -0700, 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:
> 
> 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() -> folio_memcg() -> obj_cgroup_memcg() if folio_memcg_kmem()

How is the given folio (page) is allocated?