Received: by 2002:a05:6358:e9c4:b0:b2:91dc:71ab with SMTP id hc4csp6430211rwb; Tue, 9 Aug 2022 15:27:27 -0700 (PDT) X-Google-Smtp-Source: AA6agR7XpYsDDVokiw2W4sfOMxrlQPQu17/S/iz9tiDqfZZNZ/8N+3q2rLeoYgGfT9NAz0Ps+dvU X-Received: by 2002:a17:906:9b14:b0:730:984e:a51c with SMTP id eo20-20020a1709069b1400b00730984ea51cmr18185976ejc.435.1660084046813; Tue, 09 Aug 2022 15:27:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1660084046; cv=none; d=google.com; s=arc-20160816; b=Uy/t/qqIZfYDwKLDGdyIkUEfF7R9rp8ZHTF2cuCDPI3SwMVCZRFNWh11IFVQBIyua/ ZsJH+z3qB2fIsi/twtzBx5MhcykZ707wUvce5CGePOtz3P28RHs52Ra8On37J+A/SEjh UDF7qn+4+WH2rsqRw7zDThz6h5bEaTmFgQGoq3h2enkLQts7hAky7rRnI91lVEQGsbWs MBFL7rmEiw6jAHx54AJpXmYm9cRJUd/OChdO4uMbRAGXGYmmjEBrOGNLeCZmrqHG2D00 4RAApkFs/AouY2k9PdKA+1mR8yFOSI016tfwiQ9vO8a2G/iv6Lf/0RObkyaGLMnIzcEs 7v1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version:dkim-signature; bh=3EJhff9VTHzfniLlXSqHGtz5Fl+rtZw2O6BTVWrxTb4=; b=FluNXjlhGGSKa9td6ZMkDcTw+UwKQyEd3pXoFhB2xlJa2mfNqz7+i12Jl6IVpXSJYR 8mAeXOSBTpXOpIWr8u753EwpykE1lmGMWo0l6gwrlVF87UvfjtEhUJ5GwWu/BFpwYnhi eJ9rtx0Z7S7Ec9hyRHHNqMeMFqV3MkQ8G3+pVy3wsYwKHEfUHdREtCZ4idnT4Hi5ycNI u0XJKsrTHLTQ+obMdA9/UEm7ruo3fBHQBJPJ32kXEkMOYhFTeOSFeNiiPCg9TKHB+KPW camubn/wI1RGAXFdqthcwm8aQubyeDOZZfJFFDfKtVDv2PGC4D2M/2H/VLSeK9V1uTfx gjGA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@dubeyko-com.20210112.gappssmtp.com header.s=20210112 header.b=zf6oNIpF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ek6-20020a056402370600b0043bb6a22af3si8794523edb.387.2022.08.09.15.26.59; Tue, 09 Aug 2022 15:27:26 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@dubeyko-com.20210112.gappssmtp.com header.s=20210112 header.b=zf6oNIpF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229950AbiHIWS1 (ORCPT + 99 others); Tue, 9 Aug 2022 18:18:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40542 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230072AbiHIWSM (ORCPT ); Tue, 9 Aug 2022 18:18:12 -0400 Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 726F227168 for ; Tue, 9 Aug 2022 15:18:11 -0700 (PDT) Received: by mail-qk1-x72f.google.com with SMTP id w6so9867722qkf.3 for ; Tue, 09 Aug 2022 15:18:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dubeyko-com.20210112.gappssmtp.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3EJhff9VTHzfniLlXSqHGtz5Fl+rtZw2O6BTVWrxTb4=; b=zf6oNIpFSPmpq23CMj0vnxs5CoxbVdH/us/fHBcH9Z+sldQ7NGfDn2DVCyFSwt6s52 KmixXpV5nktrJT1izeCozuOuz9hVQZDp9R9MC3DQfAnfScvJwkiudoV/EzbDnXHSqDzb NCY58gdfn8xxupB6qq/qAhXblETgUZNia7dGwaa37//GCoUsbnl0gU9KcvkShmwVYM6M A1gt5B+MXaiHSmwYRNR2IDS2eabMDptwUPfxVHQLqnkXDx3I4DiKA4K7ULt8o4NVwEPC oCeCjoxZdjGTzyqMwMqXzjYe9Y5P2/GVocLRERh5KuGKaH/vpcxsNoztps4LE1OtuIsO AP8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3EJhff9VTHzfniLlXSqHGtz5Fl+rtZw2O6BTVWrxTb4=; b=ucr//V1R/HjJPeujhnz3AQ2wML4gUNhBYeuQl0+Xce3TzDNpD5mDfx+qsukrNSNcPH X69bVZX2AJvFaPzO1fDM1aPALVJ4zk3m2cIbtSJTxaMLsdqDg/tQR8kNrYpyuAAC1BX/ 2SOC5u4gWKrM7pzCBJCbu6GmSyGHv7SExNfGLmMtXypEM4U76UZIcb7ttstvmB8jJ+QS eExh1RcgA9IHRIJciotqUb83p7tooQz1pgDWmIrvo0HJ6XMLsMrxnd2VUgFyfLlwhPgG FrGm6xW6vPjr39r6dUbN7hkR8/gq7AgyOp8JXwLmIlA4Pr6ioXNH7X1vLI5UXvbsnn/1 Dbmg== X-Gm-Message-State: ACgBeo316Io4fdMNoehpHGGWhc+HimIZ/jdhMvwoFBdOBy2FneI9muex xxWkBEY+b7R8+NWhdjDbTk7cig== X-Received: by 2002:a05:620a:74e:b0:6b5:f0ec:edbe with SMTP id i14-20020a05620a074e00b006b5f0ecedbemr19241026qki.436.1660083490530; Tue, 09 Aug 2022 15:18:10 -0700 (PDT) Received: from smtpclient.apple ([2600:1700:42f0:6600:b19b:cbb5:a678:767c]) by smtp.gmail.com with ESMTPSA id o4-20020ac841c4000000b00342fd6d6dd3sm3791677qtm.42.2022.08.09.15.18.07 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Aug 2022 15:18:09 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: [PATCH 3/4] hfsplus: Convert kmap() to kmap_local_page() in bitmap.c From: Viacheslav Dubeyko In-Reply-To: <20220809203105.26183-4-fmdefrancesco@gmail.com> Date: Tue, 9 Aug 2022 15:18:05 -0700 Cc: "Matthew Wilcox (Oracle)" , Ira Weiny , Jens Axboe , Andrew Morton , Bart Van Assche , Kees Cook , Muchun Song , Linux FS Devel , LKML Content-Transfer-Encoding: quoted-printable Message-Id: <55002DA9-757F-47C0-B1C7-F808002E6B34@dubeyko.com> References: <20220809203105.26183-1-fmdefrancesco@gmail.com> <20220809203105.26183-4-fmdefrancesco@gmail.com> To: "Fabio M. De Francesco" X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On Aug 9, 2022, at 1:31 PM, Fabio M. De Francesco = wrote: >=20 > kmap() is being deprecated in favor of kmap_local_page(). >=20 > There are two main problems with kmap(): (1) It comes with an overhead = as > mapping space is restricted and protected by a global lock for > synchronization and (2) it also requires global TLB invalidation when = the > kmap=E2=80=99s pool wraps and it might block when the mapping space is = fully > utilized until a slot becomes available. >=20 > With kmap_local_page() the mappings are per thread, CPU local, can = take > page faults, and can be called from any context (including = interrupts). > It is faster than kmap() in kernels with HIGHMEM enabled. Furthermore, > the tasks can be preempted and, when they are scheduled to run again, = the > kernel virtual addresses are restored and are still valid. >=20 > Since its use in bitmap.c is safe everywhere, it should be preferred. >=20 > Therefore, replace kmap() with kmap_local_page() in bitmap.c. >=20 > Tested in a QEMU/KVM x86_32 VM, 6GB RAM, booting a kernel with > HIGHMEM64GB enabled. >=20 > Cc: Viacheslav Dubeyko > Suggested-by: Ira Weiny > Reviewed-by: Ira Weiny > Signed-off-by: Fabio M. De Francesco > --- Looks good. Reviewed-by: Viacheslav Dubeyko Thanks, Slava. > fs/hfsplus/bitmap.c | 20 ++++++++++---------- > 1 file changed, 10 insertions(+), 10 deletions(-) >=20 > diff --git a/fs/hfsplus/bitmap.c b/fs/hfsplus/bitmap.c > index cebce0cfe340..bd8dcea85588 100644 > --- a/fs/hfsplus/bitmap.c > +++ b/fs/hfsplus/bitmap.c > @@ -39,7 +39,7 @@ int hfsplus_block_allocate(struct super_block *sb, = u32 size, > start =3D size; > goto out; > } > - pptr =3D kmap(page); > + pptr =3D kmap_local_page(page); > curr =3D pptr + (offset & (PAGE_CACHE_BITS - 1)) / 32; > i =3D offset % 32; > offset &=3D ~(PAGE_CACHE_BITS - 1); > @@ -74,7 +74,7 @@ int hfsplus_block_allocate(struct super_block *sb, = u32 size, > } > curr++; > } > - kunmap(page); > + kunmap_local(pptr); > offset +=3D PAGE_CACHE_BITS; > if (offset >=3D size) > break; > @@ -84,7 +84,7 @@ int hfsplus_block_allocate(struct super_block *sb, = u32 size, > start =3D size; > goto out; > } > - curr =3D pptr =3D kmap(page); > + curr =3D pptr =3D kmap_local_page(page); > if ((size ^ offset) / PAGE_CACHE_BITS) > end =3D pptr + PAGE_CACHE_BITS / 32; > else > @@ -127,7 +127,7 @@ int hfsplus_block_allocate(struct super_block *sb, = u32 size, > len -=3D 32; > } > set_page_dirty(page); > - kunmap(page); > + kunmap_local(pptr); > offset +=3D PAGE_CACHE_BITS; > page =3D read_mapping_page(mapping, offset / = PAGE_CACHE_BITS, > NULL); > @@ -135,7 +135,7 @@ int hfsplus_block_allocate(struct super_block *sb, = u32 size, > start =3D size; > goto out; > } > - pptr =3D kmap(page); > + pptr =3D kmap_local_page(page); > curr =3D pptr; > end =3D pptr + PAGE_CACHE_BITS / 32; > } > @@ -151,7 +151,7 @@ int hfsplus_block_allocate(struct super_block *sb, = u32 size, > done: > *curr =3D cpu_to_be32(n); > set_page_dirty(page); > - kunmap(page); > + kunmap_local(pptr); > *max =3D offset + (curr - pptr) * 32 + i - start; > sbi->free_blocks -=3D *max; > hfsplus_mark_mdb_dirty(sb); > @@ -185,7 +185,7 @@ int hfsplus_block_free(struct super_block *sb, u32 = offset, u32 count) > page =3D read_mapping_page(mapping, pnr, NULL); > if (IS_ERR(page)) > goto kaboom; > - pptr =3D kmap(page); > + pptr =3D kmap_local_page(page); > curr =3D pptr + (offset & (PAGE_CACHE_BITS - 1)) / 32; > end =3D pptr + PAGE_CACHE_BITS / 32; > len =3D count; > @@ -215,11 +215,11 @@ int hfsplus_block_free(struct super_block *sb, = u32 offset, u32 count) > if (!count) > break; > set_page_dirty(page); > - kunmap(page); > + kunmap_local(pptr); > page =3D read_mapping_page(mapping, ++pnr, NULL); > if (IS_ERR(page)) > goto kaboom; > - pptr =3D kmap(page); > + pptr =3D kmap_local_page(page); > curr =3D pptr; > end =3D pptr + PAGE_CACHE_BITS / 32; > } > @@ -231,7 +231,7 @@ int hfsplus_block_free(struct super_block *sb, u32 = offset, u32 count) > } > out: > set_page_dirty(page); > - kunmap(page); > + kunmap_local(pptr); > sbi->free_blocks +=3D len; > hfsplus_mark_mdb_dirty(sb); > mutex_unlock(&sbi->alloc_mutex); > --=20 > 2.37.1 >=20