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 Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id BC479C54E94 for ; Thu, 26 Jan 2023 15:48:23 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4P2lVF6h2cz3fJ7 for ; Fri, 27 Jan 2023 02:48:21 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=techsingularity.net (client-ip=46.22.136.236; helo=outbound-smtp52.blacknight.com; envelope-from=mgorman@techsingularity.net; receiver=) Received: from outbound-smtp52.blacknight.com (outbound-smtp52.blacknight.com [46.22.136.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4P2lTf6CgLz3cgs for ; Fri, 27 Jan 2023 02:47:50 +1100 (AEDT) Received: from mail.blacknight.com (pemlinmail04.blacknight.ie [81.17.254.17]) by outbound-smtp52.blacknight.com (Postfix) with ESMTPS id A4D51FAC7E for ; Thu, 26 Jan 2023 15:47:44 +0000 (GMT) Received: (qmail 28996 invoked from network); 26 Jan 2023 15:47:44 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[84.203.198.246]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 26 Jan 2023 15:47:44 -0000 Date: Thu, 26 Jan 2023 15:47:40 +0000 From: Mel Gorman To: Suren Baghdasaryan Subject: Re: [PATCH v3 6/7] mm: introduce mod_vm_flags_nolock and use it in untrack_pfn Message-ID: <20230126154740.j3a3lu4x557c56yi@techsingularity.net> References: <20230125233554.153109-1-surenb@google.com> <20230125233554.153109-7-surenb@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20230125233554.153109-7-surenb@google.com> X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: michel@lespinasse.org, joelaf@google.com, songliubraving@fb.com, mhocko@suse.com, leewalsh@google.com, david@redhat.com, peterz@infradead.org, bigeasy@linutronix.de, peterx@redhat.com, dhowells@redhat.com, linux-mm@kvack.org, edumazet@google.com, jglisse@google.com, punit.agrawal@bytedance.com, will@kernel.org, arjunroy@google.com, dave@stgolabs.net, minchan@google.com, x86@kernel.org, hughd@google.com, willy@infradead.org, gurua@google.com, mingo@redhat.com, linux-arm-kernel@lists.infradead.org, rientjes@google.com, axelrasmussen@google.com, kernel-team@android.com, soheil@google.com, paulmck@kernel.org, jannh@google.com, liam.howlett@oracle.com, shakeelb@google.com, luto@kernel.org, gthelen@google.com, ldufour@linux.ibm.com, vbabka@suse.cz, posk@google.com, lstoakes@gmail.com, peterjung1337@gmail.com, kent.overstreet@linux.dev, hughlynch@google.com, linux-kernel@vger.kernel.org, hannes@cmpxchg.org, akpm@linux-foundation.org, tatashin@google.com, linuxppc-dev@lists.ozlabs.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Wed, Jan 25, 2023 at 03:35:53PM -0800, Suren Baghdasaryan wrote: > In cases when VMA flags are modified after VMA was isolated and mmap_lock > was downgraded, flags modifications would result in an assertion because > mmap write lock is not held. Add note that it's also used during exit when the locking of the VMAs becomes irrelevant (mm users is 0, should be no VMA modifications taking place other than zap). The typical naming pattern when a caller either knows it holds the necessary lock or knows it does not matter is __mod_vm_flags() > Introduce mod_vm_flags_nolock to be used in such situation, when VMA is > not part of VMA tree and locking it is not required. Instead of such situations, describe in as "used when the caller takes responsibility for the required locking". > Pass a hint to untrack_pfn to conditionally use mod_vm_flags_nolock for > flags modification and to avoid assertion. > > Signed-off-by: Suren Baghdasaryan Patch itself looks ok. It strays close to being "conditional locking" though which might attract some complaints. -- Mel Gorman SUSE Labs 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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id EB639C54E94 for ; Thu, 26 Jan 2023 15:48:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=fUP4hOlJRnz5qzLMEXFxe7pBS4vZczQqhxse95OC1cg=; b=sG80RgJ70WrxWK xT0lS5MJTVqDMCrzAwsBGN6vpQPlkdGeQEebtF9zW1rjYcytCmobmk86YGvo91VqV/Y0Cl3qSeg83 gKc5rOc/x9yMJ1Pug0Z0XOq8+7V+xX7V/fyx3g4ZgMxTwTutzI9Q7pINS4cOgWyrQAH9y78/Qu4gv cNG7YD1Fl99ocCTPTk9M2uqJ1Obgg4RpqOgGNPTzNKYnuQKqha8g2HiV9drbxR0sFwSV3PXHUxyp5 dAFO+xv9d9NviQhTc0hW21XMQuQ1pIUyDkjzuStTTrWMSR+JbB2u+Md0ZrvK3VV40hT9MCD/PhawQ pnKk82NcUeeFHz4tZXow==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pL4Tg-00BbFN-Md; Thu, 26 Jan 2023 15:47:52 +0000 Received: from outbound-smtp51.blacknight.com ([46.22.136.235]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pL4Tc-00BbDT-2l for linux-arm-kernel@lists.infradead.org; Thu, 26 Jan 2023 15:47:49 +0000 Received: from mail.blacknight.com (pemlinmail04.blacknight.ie [81.17.254.17]) by outbound-smtp51.blacknight.com (Postfix) with ESMTPS id ABA30FAC82 for ; Thu, 26 Jan 2023 15:47:44 +0000 (GMT) Received: (qmail 28996 invoked from network); 26 Jan 2023 15:47:44 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[84.203.198.246]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 26 Jan 2023 15:47:44 -0000 Date: Thu, 26 Jan 2023 15:47:40 +0000 From: Mel Gorman To: Suren Baghdasaryan Cc: akpm@linux-foundation.org, michel@lespinasse.org, jglisse@google.com, mhocko@suse.com, vbabka@suse.cz, hannes@cmpxchg.org, dave@stgolabs.net, willy@infradead.org, liam.howlett@oracle.com, peterz@infradead.org, ldufour@linux.ibm.com, paulmck@kernel.org, mingo@redhat.com, will@kernel.org, luto@kernel.org, songliubraving@fb.com, peterx@redhat.com, david@redhat.com, dhowells@redhat.com, hughd@google.com, bigeasy@linutronix.de, kent.overstreet@linux.dev, punit.agrawal@bytedance.com, lstoakes@gmail.com, peterjung1337@gmail.com, rientjes@google.com, axelrasmussen@google.com, joelaf@google.com, minchan@google.com, jannh@google.com, shakeelb@google.com, tatashin@google.com, edumazet@google.com, gthelen@google.com, gurua@google.com, arjunroy@google.com, soheil@google.com, hughlynch@google.com, leewalsh@google.com, posk@google.com, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, x86@kernel.org, linux-kernel@vger.kernel.org, kernel-team@android.com Subject: Re: [PATCH v3 6/7] mm: introduce mod_vm_flags_nolock and use it in untrack_pfn Message-ID: <20230126154740.j3a3lu4x557c56yi@techsingularity.net> References: <20230125233554.153109-1-surenb@google.com> <20230125233554.153109-7-surenb@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20230125233554.153109-7-surenb@google.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230126_074748_290174_0224649E X-CRM114-Status: GOOD ( 11.11 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Jan 25, 2023 at 03:35:53PM -0800, Suren Baghdasaryan wrote: > In cases when VMA flags are modified after VMA was isolated and mmap_lock > was downgraded, flags modifications would result in an assertion because > mmap write lock is not held. Add note that it's also used during exit when the locking of the VMAs becomes irrelevant (mm users is 0, should be no VMA modifications taking place other than zap). The typical naming pattern when a caller either knows it holds the necessary lock or knows it does not matter is __mod_vm_flags() > Introduce mod_vm_flags_nolock to be used in such situation, when VMA is > not part of VMA tree and locking it is not required. Instead of such situations, describe in as "used when the caller takes responsibility for the required locking". > Pass a hint to untrack_pfn to conditionally use mod_vm_flags_nolock for > flags modification and to avoid assertion. > > Signed-off-by: Suren Baghdasaryan Patch itself looks ok. It strays close to being "conditional locking" though which might attract some complaints. -- Mel Gorman SUSE Labs _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D9EB7C54E94 for ; Thu, 26 Jan 2023 15:47:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 54E398E0001; Thu, 26 Jan 2023 10:47:49 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5000B6B0073; Thu, 26 Jan 2023 10:47:49 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3C5ED8E0001; Thu, 26 Jan 2023 10:47:49 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 2E9416B0072 for ; Thu, 26 Jan 2023 10:47:49 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 091E21205B3 for ; Thu, 26 Jan 2023 15:47:49 +0000 (UTC) X-FDA: 80397380658.23.0A29B4E Received: from outbound-smtp63.blacknight.com (outbound-smtp63.blacknight.com [46.22.136.252]) by imf03.hostedemail.com (Postfix) with ESMTP id 416C720005 for ; Thu, 26 Jan 2023 15:47:45 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf03.hostedemail.com: domain of mgorman@techsingularity.net designates 46.22.136.252 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1674748066; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=T5VepjU5ywtLJ/PE22ygSqN/FavdT00O8jJ1wJy0pmI=; b=hZBE6IsDGitIJCUrNiNztujAi6Yde6F+jBt7STT2PhuK56a2NxwWcw/QyiyWryomi8uW7j 4oKYRmWRZ7DZIaZ5crA9UfLFdZO05tA5An6Itd2XkplnNKWBHa4Q7yzt3Q/MWVKxgQY5+a y6ywswuP9Nr0KEy+3lu0W7EefhMU70k= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf03.hostedemail.com: domain of mgorman@techsingularity.net designates 46.22.136.252 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1674748066; a=rsa-sha256; cv=none; b=a3HbjMtLYmhU9Iu91Oovtjs8OvRIVNGsfg7ovyHEgJI+8Arzaodi+1YHaI2LIH+izTafhN 0q9qtGG4if7Oj9SDTakHDcSP4/FiIrEzyBQ23lCRhTIjMyO1ROzurTRtZyyHJurbVmnDC0 OPwN7N7o2h5ckjiCFF4khU4k++OIhyE= Received: from mail.blacknight.com (pemlinmail04.blacknight.ie [81.17.254.17]) by outbound-smtp63.blacknight.com (Postfix) with ESMTPS id A5073FAC7F for ; Thu, 26 Jan 2023 15:47:44 +0000 (GMT) Received: (qmail 28996 invoked from network); 26 Jan 2023 15:47:44 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[84.203.198.246]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 26 Jan 2023 15:47:44 -0000 Date: Thu, 26 Jan 2023 15:47:40 +0000 From: Mel Gorman To: Suren Baghdasaryan Cc: akpm@linux-foundation.org, michel@lespinasse.org, jglisse@google.com, mhocko@suse.com, vbabka@suse.cz, hannes@cmpxchg.org, dave@stgolabs.net, willy@infradead.org, liam.howlett@oracle.com, peterz@infradead.org, ldufour@linux.ibm.com, paulmck@kernel.org, mingo@redhat.com, will@kernel.org, luto@kernel.org, songliubraving@fb.com, peterx@redhat.com, david@redhat.com, dhowells@redhat.com, hughd@google.com, bigeasy@linutronix.de, kent.overstreet@linux.dev, punit.agrawal@bytedance.com, lstoakes@gmail.com, peterjung1337@gmail.com, rientjes@google.com, axelrasmussen@google.com, joelaf@google.com, minchan@google.com, jannh@google.com, shakeelb@google.com, tatashin@google.com, edumazet@google.com, gthelen@google.com, gurua@google.com, arjunroy@google.com, soheil@google.com, hughlynch@google.com, leewalsh@google.com, posk@google.com, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, x86@kernel.org, linux-kernel@vger.kernel.org, kernel-team@android.com Subject: Re: [PATCH v3 6/7] mm: introduce mod_vm_flags_nolock and use it in untrack_pfn Message-ID: <20230126154740.j3a3lu4x557c56yi@techsingularity.net> References: <20230125233554.153109-1-surenb@google.com> <20230125233554.153109-7-surenb@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20230125233554.153109-7-surenb@google.com> X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 416C720005 X-Stat-Signature: pi1u66finartnmojpyuwjigkpfkrebeq X-Rspam-User: X-HE-Tag: 1674748065-172158 X-HE-Meta: U2FsdGVkX1/mv+kvMVre2VeERpBuIpzzFDo54wBUsgCYrscBrzGC7R83ByCM08jhwXzsjFq+wlwOwukxcH3ZiHRPlWyWKEDi+dtE+h/Iz213swwV2slmMtyfbUq6Nce0zR1ZIDAASGsRE3T0G9GPeBgygNulJYrivlXUhFs1lrAqLLE/8vuuxo7hRQO2aV/scqhTWNAhAP2YmVyw2DkdxVq1aCKANNF+gMQ/CrYXr70YfPg07D8Ug34is3sXnt6geD/UaoUBNsrW8JMduDtOw3rfNeq2LEZdwpq99DraGDhFQyu/VbNRe8yqrzoobCZuNEWVcfGY/TQsut3TC0hA70ZsDuM6chP6aPma13cS1gLh+rMjgitjUIiaE6VrHuUOCmvfixOAdMOALSGXakDK8mu2fmg6R4PyWF7lsft7lzdxDwmh+AJdy+Y6K3TTk60aMUnL3LLhAhYqH9K+ySJ/HXMTPDfO5H4S+itdfM97rhxPrz+uOxpedcn/FxSvEwl/JpqNgxVQAwHPX/yMlp6+w8VUw4VckdtDSSIwiaZH0fbMlR5Z4rXCdQc2UeBJm8Aa7yaPR7eujJ2PuNPSiuvXh7fSdXiyIK20imXc0TmPaVlXnJwC5JUjH6eiGpWIziVE7XgiTsDUHPVH8R8sr04su5nD/famlGX7f6hmx+iLnAIr/R0HF4sNfLjvg5STkGIf6jzvfZxvOydsizCjOlamVUw/aYEuigBDvsc5CD4f7x9ZKlRbp0g26CQey73SBqPxHcVMs60wwu/MoBAWm4RmrMdug66/QVTt7AxtQ+jMiRk4L+QKedRt2FrMSqGZI3IxRiPcKSoENDrkD+EL3DSCmSdnPPQxTxlgwKvnbYtGbZcfN59f5hpe5RVON0Q/f4HPppEtLxf5ziD5KeEgxLqjSVeMcS9jD5DX01PtH5C4bmE2yRLcAMXG7Jy4Q38W5tQipjCPbZwLF5Nbc7jzpoS 0T1uttDO gTSfpSLXDFPzEraHZOnIvQUHoAQRX6ZnYCkgVvCKJ1n46ZzPpwrL6ZYOaHaJzDImx4rMHKaCRcKvJozJVFeoXKP5P2CmngtZCkY7DGij5rABT5Vw7SrZuRGhBhRXRFHA17EwsD7T1rJitihqmuF9f5EGftcunIY0iH6iFToQ0KaHC6Wo/Ta2cvL1mPuRYrVc4N6ZApnJlTsQ4h+weDKuSLQDNy4aZwj254GvgrViBfEfoXQeXC2HA+uYGisNoh3CXs9UX X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Jan 25, 2023 at 03:35:53PM -0800, Suren Baghdasaryan wrote: > In cases when VMA flags are modified after VMA was isolated and mmap_lock > was downgraded, flags modifications would result in an assertion because > mmap write lock is not held. Add note that it's also used during exit when the locking of the VMAs becomes irrelevant (mm users is 0, should be no VMA modifications taking place other than zap). The typical naming pattern when a caller either knows it holds the necessary lock or knows it does not matter is __mod_vm_flags() > Introduce mod_vm_flags_nolock to be used in such situation, when VMA is > not part of VMA tree and locking it is not required. Instead of such situations, describe in as "used when the caller takes responsibility for the required locking". > Pass a hint to untrack_pfn to conditionally use mod_vm_flags_nolock for > flags modification and to avoid assertion. > > Signed-off-by: Suren Baghdasaryan Patch itself looks ok. It strays close to being "conditional locking" though which might attract some complaints. -- Mel Gorman SUSE Labs