Date:   Wed, 8 Mar 2023 11:19:27 -0500
From:   "Liam R. Howlett" <Liam.Howlett@Oracle.com>
To:     David Hildenbrand <david@redhat.com>
Cc:     maple-tree@lists.infradead.org, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org,
        Andrew Morton <akpm@linux-foundation.org>,
        Pengfei Xu <pengfei.xu@intel.com>,
        syzbot+2ee18845e89ae76342c5@syzkaller.appspotmail.com,
        Matthew Wilcox <willy@infradead.org>, heng.su@intel.com,
        lkp@intel.com, Stable@vger.kernel.org,
        Hugh Dickins <hughd@google.com>
Subject: Re: [PATCH] mm/ksm: Fix race with ksm_exit() in VMA iteration
Message-ID: <20230308161927.lb4npblk2q4vkxmg@revolver>
Mail-Followup-To: "Liam R. Howlett" <Liam.Howlett@Oracle.com>,
        David Hildenbrand <david@redhat.com>,
        maple-tree@lists.infradead.org, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org,
        Andrew Morton <akpm@linux-foundation.org>,
        Pengfei Xu <pengfei.xu@intel.com>,
        syzbot+2ee18845e89ae76342c5@syzkaller.appspotmail.com,
        Matthew Wilcox <willy@infradead.org>, heng.su@intel.com,
        lkp@intel.com, Stable@vger.kernel.org,
        Hugh Dickins <hughd@google.com>
References: <20230307205951.2465275-1-Liam.Howlett@oracle.com>
 <d6670aa7-37ee-85aa-1053-96284a2f6720@redhat.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <d6670aa7-37ee-85aa-1053-96284a2f6720@redhat.com>
User-Agent: NeoMutt/20220429
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?N/4T87khbcsSGTTIrtbcvzOTZ8po6OVaJlCpQqEIo/HJknxRL3wdLXWrrO+Z?=
 =?us-ascii?Q?f1d5H3qNwlV1dC4nX+J3ud8UUl5DGhhcq5DKaXYmlYYgGsow0holsRbIr1Sh?=
 =?us-ascii?Q?ghpUKR17ePhsVPfjoxRSVWSzhlDXgJrJCIbU/F/LmwKgP7YhDNuVphMYEFhe?=
 =?us-ascii?Q?wG9rrAoW9QIcTC6mGoDjyYSSeGcJ5sSQRsfMfP50CKCelM6AKxqYA9XodAd0?=
 =?us-ascii?Q?d7nmOrqc5AJb1j99/Wgpq/GvFMf34jv7xQyY5IV3b7EZi9LR4ry6TtOHausF?=
 =?us-ascii?Q?reiVyergVOvqRQtc7QbyN/f8SZUWAjvEgeShBzMpgmF1FbpNQ6DVkhfpHuh6?=
 =?us-ascii?Q?PJzV/YfOQWYDWj5bfwRWwjCNJDDHwioyPl1wEARJ8bqqrTP1sHLgOlsVF9zH?=
 =?us-ascii?Q?XjOGCUNeHOFNqOxip1C0I/Kx/KV8LcAhDmhWdihANI4Tbyi4E0Me/Q6IOb8m?=
 =?us-ascii?Q?V4zJfyJrCcGJ3lPNgzFhdMpg4rcHVu+0ouBWSIg/TLD/iaN3y44gp2Epw5fE?=
 =?us-ascii?Q?fBBoBzwik74nifEKmJeq76viFQVuBVNCjPArmvDrE03zjey/C8hyigcBrNzo?=
 =?us-ascii?Q?4MFJqkStx0uh3pAFB/ZMSE63ADVL8hiE4Km75DoUthONsquTZICpw5Q500py?=
 =?us-ascii?Q?wFbq3O7ZRVYCtUsf8FcyiPVcduDAO5EXrNMUIVht89Kg2/4mzAitDlxDI3YT?=
 =?us-ascii?Q?NOLLxB95YJFtdvgs6olSNS6zAfPpKa643xFsTXQ9n8Oe+V71GjcrRZ4WFyvM?=
 =?us-ascii?Q?MlMRxIHeGg1pyHL7hQRJ6Ma+aPySOBM6/rwiNSpCjZQRbw4K/ZRJoJLtUh1b?=
 =?us-ascii?Q?YJt5xFyYWVidfKmvWpMAYYltACQqBfOhg4Y5PsvToPVz4h9AdyPlOWIR/MNw?=
 =?us-ascii?Q?J/ftJ+y+wh7l0M49URmDddOU2Td3AlPUeIJ/jS+hP9zNttbmwBUR/ASoTzBD?=
 =?us-ascii?Q?OKpvj3AVGg+utVPbOfKJfJ4pxcXiJJx1Ao7Dh7D4o/QSv8gOF03Y/o8cRE7q?=
 =?us-ascii?Q?iTmxPXJccMXjNWGR259svN23sDukGAixRrcXYupsNyUuXw81Wd5AVm+1FOdO?=
 =?us-ascii?Q?oWH8FL9Cv0JEeBzewY39Xt9Mbvthcw/vySEgkufu0U8a7cMm4Aws8Xr3PW6G?=
 =?us-ascii?Q?TPg0OMiGyPO4oGvrEuGehf057aTCwWwVkg5Zj3c46U1m1NRqyYdFuhsNd9+p?=
 =?us-ascii?Q?2hEmsd/vuzQXXhjks44KFe5uWHDdc9irtDEHSQS+92J9fdakYFZ53Atc+NIZ?=
 =?us-ascii?Q?q+s94jMrWj+gUOp5Lj8F3Ln3fh9PtqZTbIQPOi1MfUwODMxBn5epXr6S1baw?=
 =?us-ascii?Q?hHWfYgwkKACU7ojwPuIQNGA9krmpYwjq1z4NQnI7RFN1cOJDfsCakbOuVq2B?=
 =?us-ascii?Q?D7fiwsSuWdjWk7ppinz1q502Y3vx0nLyHDpghPah8yZWAgJpOPHfYgnBWcxs?=
 =?us-ascii?Q?ImqJU8c4RvgZkOAnbzUohnk2um6hm+PYPGkcUDT1HU4Aqz0C/HqLNf/wL4W5?=
 =?us-ascii?Q?4GSI+yvpvNa9t8IrIqFI3N6foCEqLzF5sE4bgzHGnU8SkXQMae6hcK3Bnn97?=
 =?us-ascii?Q?LfzpduTcpttMvTUpXTj0Qcar+fxWAMn/4wkUO1HrjP0Y1dQvTFGpYEByoqlw?=
 =?us-ascii?Q?fg=3D=3D?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: =?us-ascii?Q?n67nCsdg27YiGowCyg5DzSGbtCfcYVG4FgflnRvcBZdppI+LnA+/yAjrQdPT?=
 =?us-ascii?Q?VoZJpuv1vOUpeMHzLZazWNGB6zWiXHddIL/08J7AXu5s9iLmp1l3J3FJ5n5y?=
 =?us-ascii?Q?OJ95SiDss/2mB/be4JME2X2N5hhpd4GBqedqqUBH6exRk3g5ayBZZAvPF4+h?=
 =?us-ascii?Q?Qn2+0qeLKoL5/0vTqOUNUox2YDYp9FyEu1K/S2nA9qXslA8t7cF0AL6NLxLD?=
 =?us-ascii?Q?GytnwBloN/9V43a4W4OEqAttb8ozwaveXDCsyUE958t/dxgtgtvo8mCdFS/D?=
 =?us-ascii?Q?jelvfJoo1RBAyzLeKd9Gkmq5CVTWmqdMMg/iolV53wlgHgVfo/U/+IsDCAFp?=
 =?us-ascii?Q?ExXI7E43SR2ABqhHUHTQ5q4OKYMDag28ML3NMGhkxsuaqCq3uIhEElZNmR/0?=
 =?us-ascii?Q?zkZd8R6LFBwkGunkNRA+6Z8w0hQd2ws7Er0MyyWYwJeP0cQtXpwzlm55VRPH?=
 =?us-ascii?Q?vtph3COcTqKOr5hR3zoM+WBOoNd5d8sAkmQGR1wcyr9UiPWq3CHxI4sz/AuJ?=
 =?us-ascii?Q?SS/kBpctNhrC8f6HpfxGyWbYH/gUaO29G5ZDeWFgARfB8q/HegpnbTfSwx6V?=
 =?us-ascii?Q?vVesRFqrNuPwb2l30QcnjbYqncG6C1vYcf0pEEm+lWaddup+EiZ4xBgQ9ewh?=
 =?us-ascii?Q?0jrwvg6hAxler7psJUU1q+EruwV9jAWLNFrp3W0V4JN/wpwIMROUMaoWsgs1?=
 =?us-ascii?Q?gUE1yizKe+i5Gc5z7P1FRa9tRe9nQ+XlF8nszvVk0EB1FrLeKI4EgKpBUG4X?=
 =?us-ascii?Q?j94BcY2Du4UTcUA4oCOvRaCeVhrquetkJkzd8KBjc68BASxw68mQPabwUQ8/?=
 =?us-ascii?Q?kpvsJnoBmVquKu+TktcQG/sWeYKMo5IdJpx1bQe9NNOXud7RsF0wZjjglP7+?=
 =?us-ascii?Q?JSy2e6xTbQHIOwB69Q8lRle5R40dCPh2jTlmjK2hXo4oVDpYGeC4GtB6FYeS?=
 =?us-ascii?Q?8g91w+aMNC7L/UtT0K8QlTIqldWb3aqOBj8DfK+8ALqVSQK221fT764IT9WB?=
 =?us-ascii?Q?rrDUK6j3DU2aM/v58SkdphDjtKb7kwf3XE8qxDmhUMp02FRZKWIgpykXZhIB?=
 =?us-ascii?Q?iESt6yspHos62F8dkw3cYXRDeih02Q=3D=3D?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: fb01bd8f-8759-4ecc-ee11-08db1ff0e93f
X-MS-Exchange-CrossTenant-AuthSource: SN6PR10MB3022.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Mar 2023 16:19:37.2387
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: gBvQk8GXQG+DRMFaHsA1vUP/du8rbiekdmogOMQnWndlHUq3+nlL127EHaUasvqzkf4nt2wUZ4Wah93wg1VWHA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR10MB4555
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.254,Aquarius:18.0.942,Hydra:6.0.573,FMLib:17.11.170.22
 definitions=2023-03-08_10,2023-03-08_03,2023-02-09_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 adultscore=0
 phishscore=0 suspectscore=0 malwarescore=0 spamscore=0 bulkscore=0
 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2212070000 definitions=main-2303080139
X-Proofpoint-ORIG-GUID: h1t3D3-4-a09GsJoObDYY0dQV9T7HDgq
X-Proofpoint-GUID: h1t3D3-4-a09GsJoObDYY0dQV9T7HDgq
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

* David Hildenbrand <david@redhat.com> [230308 04:41]:
> On 07.03.23 21:59, Liam R. Howlett wrote:
> > ksm_exit() may remove the mm from the ksm_scan between the unlocking of
> > the ksm_mmlist and the start of the VMA iteration.  This results in the
> > mmap_read_lock() not being taken and a report from lockdep that the mm
> > isn't locked in the maple tree code.
> 
> I'm confused.

Thanks for looking at this.  My explanation is incorrect.

>The code does
> 
> mmap_read_lock(mm);
> ...
> for_each_vma(vmi, vma) {
> mmap_read_unlock(mm);
> 
> How can we not take the mmap_read_lock() ? Or am I staring at the wrong
> mmap_read_lock() ?

That's the right one.  The mmap lock is taken, but the one we are
checking is not the correct one.  Let me try again.

Checking the mm struct against the one in the vmi confirms they are the
same, so lockdep is telling us the lock we took doesn't match what it
expected.  I verified that the lock is the same before the
'for_each_vma()' call by inserting a BUG_ON() which is never triggered
with the reproducer.

ksm_test_exit() uses the mm->mm_users atomic to detect an mm exit.  This
is usually done in mmget(), mmput(), and friends.

__ksm_exit() and unmerge_and_remove_all_rmap_items() handle freeing by
use of the mm->mm_count atomic. This is usually via mmgrab() and mmdrop().

mmput() will call __mmput() if mm_users is decremented to zero.
__mmput() calls mmdrop() after the ksm_exit() and then continue with
teardown.

So, I believe what is happening is that the external lock flag is being
cleared from the maple tree (the one lockdep checks) before we call the
iterator.

task 1					task 2
unmerge_and_remove_all_rmap_items()
 spin_lock(&ksm_mmlist_lock);
 ksm_scan.mm_slot is set
 spin_unlock(&ksm_mmlist_lock);

=======================================================================
	At this point mm->mm_users is 0, but mm_count is not as it will
	be decremented at the end of __mmput().
=======================================================================

					__mmput()
 					 ksm_exit()
					  __ksm_exit()
					   spin_lock(&ksm_mmlist_lock); 
					   mm_slot is set
					   spin_unlock(&ksm_mmlist_lock)
					   mm_slot == ksm_scan.mm_slot
					   mmap_write_lock();
					   mmap_write_unlock();
					   return
					 exit_mmap()
					   ...
					   mmap_write_lock();
					   __mt_destory()
					     Free all maple tree nodes
					     mt->flags = 0;
					   mmap_write_unlock();
					   ...

 mmap_read_lock()
 for_each_vma()
   lockdep checks *internal* spinlock


This was fine before the change as the previous for loop would not have
checked the locking and would have hit the ksm_test_exit() test before
any problem arose.

Now we are getting a lockdep warning because the maple tree flag for the
external lock is cleared.

How about this as the start to the commit message:

The VMA iterator may trigger a lockdep warning if the mm is in the
process of being cleaned up before obtaining the mmap_read_lock().

> 
> > 
> > Fix the race by checking if this mm has been removed before iterating
> > the VMAs. __ksm_exit() uses the mmap lock to synchronize the freeing of
> > an mm, so it is safe to keep iterating over the VMAs when it is going to
> > be freed.
> > 
> > This change will slow down the mm exit during the race condition, but
> > will speed up the non-race scenarios iteration over the VMA list, which
> > should be much more common.
> 
> Would leaving the existing check in help to just stop scanning faster in
> that case?

Yes.  But why?  We would stop the scanning faster in the race condition
case, but slow the normal case down.

This check was here to ensure that the mm isn't being torn down while
it's iterating over the loop.  Hugh (Cc'ed) added this in 2009, but the
fundamental problem he specifies in his commit message in 9ba692948008
("ksm: fix oom deadlock") is that exit_mmap() does not take the
mmap_lock() - which is no longer the case.  We are safe to iterate the
VMAs with the mmap_read_lock() as the mmap_write_lock() is taken during
tear down of the VMA tree today.

> 
> > 
> > Reported-by: Pengfei Xu <pengfei.xu@intel.com>
> > Link: https://lore.kernel.org/lkml/ZAdUUhSbaa6fHS36@xpf.sh.intel.com/
> > Reported-by: syzbot+2ee18845e89ae76342c5@syzkaller.appspotmail.com
> > Link: https://syzkaller.appspot.com/bug?id=64a3e95957cd3deab99df7cd7b5a9475af92c93e
> > Cc: linux-mm@kvack.org
> > Cc: linux-kernel@vger.kernel.org
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
> > Cc: heng.su@intel.com
> > Cc: lkp@intel.com
> > Cc: <Stable@vger.kernel.org>
> > Fixes: a5f18ba07276 ("mm/ksm: use vma iterators instead of vma linked list")
> > Signed-off-by: Liam R. Howlett <Liam.Howlett@oracle.com>
> > ---
> >   mm/ksm.c | 6 ++++--
> >   1 file changed, 4 insertions(+), 2 deletions(-)
> > 
> > diff --git a/mm/ksm.c b/mm/ksm.c
> > index 525c3306e78b..723ddbe6ea97 100644
> > --- a/mm/ksm.c
> > +++ b/mm/ksm.c
> > @@ -1044,9 +1044,10 @@ static int unmerge_and_remove_all_rmap_items(void)
> >   		mm = mm_slot->slot.mm;
> >   		mmap_read_lock(mm);
> 
> Better add a comment:
> 
> /*
>  * Don't iterate any VMAs if we might be racing against ksm_exit(),
>  * just exit early.
>  */
> 
> > +		if (ksm_test_exit(mm))
> > +			goto mm_exiting;
> > +
> >   		for_each_vma(vmi, vma) {
> > -			if (ksm_test_exit(mm))
> > -				break;
> >   			if (!(vma->vm_flags & VM_MERGEABLE) || !vma->anon_vma)
> >   				continue;
> >   			err = unmerge_ksm_pages(vma,
> > @@ -1055,6 +1056,7 @@ static int unmerge_and_remove_all_rmap_items(void)
> >   				goto error;
> >   		}
> > +mm_exiting:
> >   		remove_trailing_rmap_items(&mm_slot->rmap_list);
> >   		mmap_read_unlock(mm);
> 
> 
> 
> -- 
> Thanks,
> 
> David / dhildenb
>