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 willy@infradead.org wrote:
On Thu, Jul 22, 2021 at 04:57:57PM +0800, Zhouyi Zhou wrote:
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