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=-11.4 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable 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 7A224C55179 for ; Fri, 23 Oct 2020 11:29:21 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B33E0221F9 for ; Fri, 23 Oct 2020 11:29:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B33E0221F9 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id F0E176B0068; Fri, 23 Oct 2020 07:29:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EBDBC6B006C; Fri, 23 Oct 2020 07:29:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DACA36B006E; Fri, 23 Oct 2020 07:29:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0126.hostedemail.com [216.40.44.126]) by kanga.kvack.org (Postfix) with ESMTP id ADFA76B0068 for ; Fri, 23 Oct 2020 07:29:19 -0400 (EDT) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 42F038BB9DAA for ; Fri, 23 Oct 2020 11:29:19 +0000 (UTC) X-FDA: 77402969238.29.town11_601179f27259 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin29.hostedemail.com (Postfix) with ESMTP id 16CE5180868EE for ; Fri, 23 Oct 2020 11:29:19 +0000 (UTC) X-HE-Tag: town11_601179f27259 X-Filterd-Recvd-Size: 3497 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf07.hostedemail.com (Postfix) with ESMTP for ; Fri, 23 Oct 2020 11:29:18 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 21138B1B6; Fri, 23 Oct 2020 11:29:17 +0000 (UTC) Subject: Re: [PATCH] mm/cma.c: remove redundant cma_mutex lock To: David Hildenbrand , Lecopzer Chen , linux-kernel@vger.kernel.org, linux-mm@kvack.org Cc: matthias.bgg@gmail.com, akpm@linux-foundation.org, yj.chiang@mediatek.com References: <20201020102241.3729-1-lecopzer.chen@mediatek.com> <458cdc24-f637-ef4b-19de-513ceab14f23@redhat.com> From: Vlastimil Babka Message-ID: Date: Fri, 23 Oct 2020 13:29:16 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.3 MIME-Version: 1.0 In-Reply-To: <458cdc24-f637-ef4b-19de-513ceab14f23@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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 10/20/20 1:27 PM, David Hildenbrand wrote: > On 20.10.20 12:22, Lecopzer Chen wrote: >> The cma_mutex which protects alloc_contig_range() was first appeared in >> commit 7ee793a62fa8c ("cma: Remove potential deadlock situation"), >> at that time, there is no guarantee the behavior of concurrency inside >> alloc_contig_range(). >> >> After the commit 2c7452a075d4db2dc >> ("mm/page_isolation.c: make start_isolate_page_range() fail if already isolated") >> > However, two subsystems (CMA and gigantic >> > huge pages for example) could attempt operations on the same range. If >> > this happens, one thread may 'undo' the work another thread is doing. >> > This can result in pageblocks being incorrectly left marked as >> > MIGRATE_ISOLATE and therefore not available for page allocation. >> The concurrency inside alloc_contig_range() was clarified. >> >> Now we can find that hugepage and virtio call alloc_contig_range() without >> any lock, thus cma_mutex is "redundant" in cma_alloc() now. >> >> Signed-off-by: Lecopzer Chen >> --- >> mm/cma.c | 4 +--- >> 1 file changed, 1 insertion(+), 3 deletions(-) >> >> diff --git a/mm/cma.c b/mm/cma.c >> index 7f415d7cda9f..3692a34e2353 100644 >> --- a/mm/cma.c >> +++ b/mm/cma.c >> @@ -38,7 +38,6 @@ >> >> struct cma cma_areas[MAX_CMA_AREAS]; >> unsigned cma_area_count; >> -static DEFINE_MUTEX(cma_mutex); >> >> phys_addr_t cma_get_base(const struct cma *cma) >> { >> @@ -454,10 +453,9 @@ struct page *cma_alloc(struct cma *cma, size_t count, unsigned int align, >> mutex_unlock(&cma->lock); >> >> pfn = cma->base_pfn + (bitmap_no << cma->order_per_bit); >> - mutex_lock(&cma_mutex); >> ret = alloc_contig_range(pfn, pfn + count, MIGRATE_CMA, >> GFP_KERNEL | (no_warn ? __GFP_NOWARN : 0)); >> - mutex_unlock(&cma_mutex); >> + >> if (ret == 0) { >> page = pfn_to_page(pfn); >> break; >> > > I guess this is fine. In case there is a race we return with -EBUSY - > which is suboptimal (as it could just be a temporary issue if the other > user backs off), but should be good enough for now. Agreed. > Acked-by: David Hildenbrand Acked-by: Vlastimil Babka