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;
Content-Type: text/plain;
        charset=us-ascii
MIME-Version: 1.0
Subject: Re: [PATCH 1/6] mm: kfence: simplify kfence pool initialization
From:   Muchun Song <muchun.song@linux.dev>
In-Reply-To: <CANpmjNNXDHZGr_r6aZi1bv5itc5KvGhRNnq_CSQRrmB6Wwx+Dg@mail.gmail.com>
Date:   Tue, 28 Mar 2023 20:53:21 +0800
Cc:     Muchun Song <songmuchun@bytedance.com>, glider@google.com,
        dvyukov@google.com, Andrew Morton <akpm@linux-foundation.org>,
        jannh@google.com, sjpark@amazon.de, kasan-dev@googlegroups.com,
        Linux Memory Management List <linux-mm@kvack.org>,
        linux-kernel@vger.kernel.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <D04CBA99-3E17-4749-9144-34B6D9D3208E@linux.dev>
References: <20230328095807.7014-1-songmuchun@bytedance.com>
 <20230328095807.7014-2-songmuchun@bytedance.com>
 <CANpmjNP+nLfMKLj-4L4wXBfQpO5N0Y6q_TEkxjM+Z0WXxPvVxg@mail.gmail.com>
 <CANpmjNNXDHZGr_r6aZi1bv5itc5KvGhRNnq_CSQRrmB6Wwx+Dg@mail.gmail.com>
To:     Marco Elver <elver@google.com>
Precedence: bulk


> On Mar 28, 2023, at 20:05, Marco Elver <elver@google.com> wrote:
>=20
> On Tue, 28 Mar 2023 at 13:55, Marco Elver <elver@google.com> wrote:
>>=20
>> On Tue, 28 Mar 2023 at 11:58, Muchun Song <songmuchun@bytedance.com> =
wrote:
>>>=20
>>> There are three similar loops to initialize kfence pool, we could =
merge
>>> all of them into one loop to simplify the code and make code more
>>> efficient.
>>>=20
>>> Signed-off-by: Muchun Song <songmuchun@bytedance.com>
>>=20
>> Reviewed-by: Marco Elver <elver@google.com>
>>=20
>>> ---
>>> mm/kfence/core.c | 47 =
++++++-----------------------------------------
>>> 1 file changed, 6 insertions(+), 41 deletions(-)
>>>=20
>>> diff --git a/mm/kfence/core.c b/mm/kfence/core.c
>>> index 7d01a2c76e80..de62a84d4830 100644
>>> --- a/mm/kfence/core.c
>>> +++ b/mm/kfence/core.c
>>> @@ -539,35 +539,10 @@ static void rcu_guarded_free(struct rcu_head =
*h)
>>> static unsigned long kfence_init_pool(void)
>>> {
>>>        unsigned long addr =3D (unsigned long)__kfence_pool;
>>> -       struct page *pages;
>>>        int i;
>>>=20
>>>        if (!arch_kfence_init_pool())
>>>                return addr;
>>> -
>>> -       pages =3D virt_to_page(__kfence_pool);
>>> -
>>> -       /*
>>> -        * Set up object pages: they must have PG_slab set, to avoid =
freeing
>>> -        * these as real pages.
>>> -        *
>>> -        * We also want to avoid inserting kfence_free() in the =
kfree()
>>> -        * fast-path in SLUB, and therefore need to ensure kfree() =
correctly
>>> -        * enters __slab_free() slow-path.
>>> -        */
>=20
> Actually: can you retain this comment somewhere?

Sure, I'll move this to right place.

Thanks.