I apologize sincerely for my irresponsible and hasty email.
I reverted the unnecessary backport of 2799e77529c2 and 2efa33fc7f6e,
tested on the same qemu box as before with the same C program, there
is no warning about RCU this time. dmesg only shows the backtrace of
OOM kill.

As for memory OOMs caused by grace period's undue ends, I found each
deletion of a inode will cause a leak.
1035    void security_inode_free(struct inode *inode)
1036    {
1037        integrity_inode_free(inode);
1038        call_void_hook(inode_free_security, inode);
1039        /*
1040         * The inode may still be referenced in a path walk and
1041         * a call to security_inode_permission() can be made
1042         * after inode_free_security() is called. Ideally, the VFS
1043         * wouldn't do this, but fixing that is a much harder
1044         * job. For now, simply free the i_security via RCU, and
1045         * leave the current inode->i_security pointer intact.
1046         * The inode will be freed after the RCU grace period too.
1047         */
1048        if (inode->i_security)
1049            call_rcu((struct rcu_head *)inode->i_security,
1050                    inode_free_by_rcu);
1051    }

I am willing to do any experiment if there is a need.

Sorry again
Best Wishes
Zhouyi

On Thu, Jul 22, 2021 at 8:36 PM Matthew Wilcox [off-list ref] wrote:

On Thu, Jul 22, 2021 at 04:57:57PM +0800, Zhouyi Zhou wrote:

quoted

Thanks for reviewing,

What I have deduced from the dmesg  is:
In function do_swap_page,
after invoking
3385        si = get_swap_device(entry); /* rcu_read_lock */
and before
3561    out:
3562        if (si)
3563            put_swap_device(si);
The thread got scheduled out in
3454        locked = lock_page_or_retry(page, vma->vm_mm, vmf->flags);

I am only familiar with Linux RCU subsystem, hope mm people can solve our
confusions.

I don't understamd why you're still talking.  The problem is understood.
You need to revert the unnecessary backport of 2799e77529c2 and
2efa33fc7f6e