From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 62A30C4338F for ; Thu, 19 Aug 2021 02:01:23 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A982F60EB5 for ; Thu, 19 Aug 2021 02:01:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org A982F60EB5 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=sina.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 2B16A6B006C; Wed, 18 Aug 2021 22:01:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 260FF6B0071; Wed, 18 Aug 2021 22:01:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 14FE98D0001; Wed, 18 Aug 2021 22:01:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0194.hostedemail.com [216.40.44.194]) by kanga.kvack.org (Postfix) with ESMTP id ED8C86B006C for ; Wed, 18 Aug 2021 22:01:21 -0400 (EDT) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 8997218339481 for ; Thu, 19 Aug 2021 02:01:21 +0000 (UTC) X-FDA: 78490177962.25.CA49B9D Received: from mail3-167.sinamail.sina.com.cn (mail3-167.sinamail.sina.com.cn [202.108.3.167]) by imf05.hostedemail.com (Postfix) with SMTP id 6CFE0506A0BC for ; Thu, 19 Aug 2021 02:01:19 +0000 (UTC) Received: from unknown (HELO localhost.localdomain)([222.130.245.194]) by sina.com (172.16.97.32) with ESMTP id 611DBB6A0001484E; Thu, 19 Aug 2021 10:01:16 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com X-SMAIL-MID: 971977628887 From: Hillf Danton To: Liam Howlett Cc: "maple-tree@lists.infradead.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Peter Zijlstra , Michel Lespinasse , Andrew Morton Subject: Re: [PATCH v2 10/61] kernel/fork: Use maple tree for dup_mmap() during forking Date: Thu, 19 Aug 2021 10:01:05 +0800 Message-Id: <20210819020105.3756-1-hdanton@sina.com> In-Reply-To: <20210818145420.hoieffhzxnxc64qr@revolver> References: <20210817154651.1570984-1-Liam.Howlett@oracle.com> <20210818083610.3698-1-hdanton@sina.com> MIME-Version: 1.0 Authentication-Results: imf05.hostedemail.com; dkim=none; spf=pass (imf05.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.167 as permitted sender) smtp.mailfrom=hdanton@sina.com; dmarc=none X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 6CFE0506A0BC X-Stat-Signature: pnz74qgiasxt3knc64qemaupuk79fi4e X-HE-Tag: 1629338479-191300 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000019, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, 18 Aug 2021 14:54:29 +0000 Liam R. Howlett wrote: >* Hillf Danton [210818 04:36]: >> On Tue, 17 Aug 2021 15:47:11 +0000 Liam R. Howlett wrote: >> > >> > static inline void mmget(struct mm_struct *mm) >> > { >> > + mt_set_in_rcu(&mm->mm_mt); >> > atomic_inc(&mm->mm_users); >> > } >> > >> > static inline bool mmget_not_zero(struct mm_struct *mm) >> > { >> > + /* >> > + * There is a race below during task tear down that can cause the = maple >> > + * tree to enter rcu mode with only a single user. If this race >> > + * happens, the result would be that the maple tree nodes would re= main >> > + * active for an extra RCU read cycle. >> > + */ >> > + mt_set_in_rcu(&mm->mm_mt); >> > return atomic_inc_not_zero(&mm->mm_users); >> > } >> >> Nit, leave the mm with zero refcount intact. >> >> if (atomic_inc_not_zero(&mm->mm_users)) { >> mt_set_in_rcu(&mm->mm_mt); >> return true; >> } >> return false; > >Thanks for looking at this. > >I thought about that, but came up with the following scenario: > >thread 1 thread 2 >mmget(mm) > mmget_not_zero() enter.. > atomic_inc_not_zero(&mm->mm_users) >mmput(mm) > mt_set_in_rcu(&mm->mm_mt); > return true; > At first glance, given the above mmget, mmput will not hurt anyone. > >So I think the above does not remove the race, but does add instructions If the mm refcount drops to one after mmput then it is one before atomic_inc_not_zero() which only ensures the mm is stable afterwards until mmput again. >to each call to mmget_not_zero(). I thought the race of having nodes >sitting around for an rcu read cycle was worth the trade off. Is one ounce of the mm stability worth two pounds? Or three? From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=3.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 82E1CC4338F for ; Fri, 20 Aug 2021 04:05:12 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A1B29610E6 for ; Fri, 20 Aug 2021 04:05:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org A1B29610E6 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=sina.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 0DC846B0071; Fri, 20 Aug 2021 00:05:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 08C0F8D0001; Fri, 20 Aug 2021 00:05:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EE3CE6B0073; Fri, 20 Aug 2021 00:05:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0081.hostedemail.com [216.40.44.81]) by kanga.kvack.org (Postfix) with ESMTP id D27126B0071 for ; Fri, 20 Aug 2021 00:05:10 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 5C4D0181CE29A for ; Fri, 20 Aug 2021 04:05:10 +0000 (UTC) X-FDA: 78494118780.18.C381713 Received: from mail3-162.sinamail.sina.com.cn (mail3-162.sinamail.sina.com.cn [202.108.3.162]) by imf07.hostedemail.com (Postfix) with SMTP id B4CC51000099 for ; Fri, 20 Aug 2021 04:05:08 +0000 (UTC) Received: from unknown (HELO localhost.localdomain)([222.130.245.194]) by sina.com (172.16.97.27) with ESMTP id 611F29EF0002EA6E; Fri, 20 Aug 2021 12:05:06 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com X-SMAIL-MID: 8140849283205 From: Hillf Danton To: Liam Howlett Cc: "maple-tree@lists.infradead.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Peter Zijlstra , Michel Lespinasse , Andrew Morton Subject: Re: [PATCH v2 10/61] kernel/fork: Use maple tree for dup_mmap() during forking Date: Fri, 20 Aug 2021 12:04:55 +0800 Message-ID: <20210819020105.3756-1-hdanton@sina.com> MIME-Version: 1.0 X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: B4CC51000099 X-Stat-Signature: f7tbaefrpinaywxht3h1nyz7i5af9fet Authentication-Results: imf07.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf07.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.162 as permitted sender) smtp.mailfrom=hdanton@sina.com X-HE-Tag: 1629432308-440357 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000070, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Message-ID: <20210820040455.IbdxzebONQFn78zC2laYiGypGDbupzjrjgaMNoEGRs4@z> On Thu, 19 Aug 2021 13:32:58 +0000 Liam R. Howlett wrote: >* Hillf Danton [210818 22:01]: >> On Wed, 18 Aug 2021 14:54:29 +0000 Liam R. Howlett wrote: >> >* Hillf Danton [210818 04:36]: >> >> On Tue, 17 Aug 2021 15:47:11 +0000 Liam R. Howlett wrote: >> >> > >> >> > static inline void mmget(struct mm_struct *mm) >> >> > { >> >> > + mt_set_in_rcu(&mm->mm_mt); >> >> > atomic_inc(&mm->mm_users); >> >> > } >> >> > >> >> > static inline bool mmget_not_zero(struct mm_struct *mm) >> >> > { >> >> > + /* >> >> > + * There is a race below during task tear down that can cause t= he =3D >maple >> >> > + * tree to enter rcu mode with only a single user. If this rac= e >> >> > + * happens, the result would be that the maple tree nodes would= re=3D >main >> >> > + * active for an extra RCU read cycle. >> >> > + */ >> >> > + mt_set_in_rcu(&mm->mm_mt); >> >> > return atomic_inc_not_zero(&mm->mm_users); >> >> > } >> >> >> >> Nit, leave the mm with zero refcount intact. >> >> >> >> if (atomic_inc_not_zero(&mm->mm_users)) { >> >> mt_set_in_rcu(&mm->mm_mt); >> >> return true; >> >> } >> >> return false; >> > >> >Thanks for looking at this. >> > >> >I thought about that, but came up with the following scenario: >> > >> >thread 1 thread 2 >> >mmget(mm) >> > mmget_not_zero() enter.. >> > atomic_inc_not_zero(&mm->mm_users) >> >mmput(mm) >> > mt_set_in_rcu(&mm->mm_mt); >> > return true; >> > >>=3D20 >> At first glance, given the above mmget, mmput will not hurt anyone. > >In the case above, the maple tree enters RCU mode with a single user. >This will have the result of nodes being freed in RCU mode which is the >same result as what happens as it is written, except the racing thread >wins (in this case). I thought this was what you were trying to fix? > >>=3D20 >> > >> >So I think the above does not remove the race, but does add instructi= ons >>=3D20 >> If the mm refcount drops to one after mmput then it is one before >> atomic_inc_not_zero() which only ensures the mm is stable afterwards >> until mmput again. > >Right. The race we are worried about is the zero referenced mm. If >mm->mm_users is safe, then mm->mm_mt is also safe. > >>=3D20 >> >to each call to mmget_not_zero(). I thought the race of having nodes >> >sitting around for an rcu read cycle was worth the trade off. >>=3D20 >> Is one ounce of the mm stability worth two pounds? Or three? > >I don't see a stability problem with the way it is written. On the maple tree side, I see in [PATCH v2 05/61] Maple Tree: Add new data structure + * MAPLE_USE_RCU Operate in read/copy/update mode for multi-readers <...> +/** + * mt_set_in_rcu() - Switch the tree to RCU safe mode. + */ +static inline void mt_set_in_rcu(struct maple_tree *mt) +{ + if (mt_in_rcu(mt)) + return; + + mtree_lock(mt); + mt->ma_flags |=3D MAPLE_USE_RCU; + mtree_unlock(mt); +} and on the mm side, however, if atomic_inc_not_zero(&mm->mm_users) fails then who can be the "RCU multi-readers"? >Your change does not remove the race. If atomic_inc_not_zero() fails then there is no pre-condition in any form for race; if it succeeds then the race window is slammed. >Can you explain how the stability is affected negatively by the way it >is written? Hard to find the correct answer without knowing why you prefer to update the flags for mm->mm_mt with mm->mm_users dropping down to ground.