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=-15.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham 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 E5DBCC11F66 for ; Thu, 1 Jul 2021 02:43:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BDA576140F for ; Thu, 1 Jul 2021 02:43:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238635AbhGACqS (ORCPT ); Wed, 30 Jun 2021 22:46:18 -0400 Received: from szxga02-in.huawei.com ([45.249.212.188]:5948 "EHLO szxga02-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238056AbhGACqR (ORCPT ); Wed, 30 Jun 2021 22:46:17 -0400 Received: from dggeme703-chm.china.huawei.com (unknown [172.30.72.57]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4GFj9z5cS6z76Rp; Thu, 1 Jul 2021 10:40:23 +0800 (CST) Received: from [10.174.178.36] (10.174.178.36) by dggeme703-chm.china.huawei.com (10.1.199.99) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Thu, 1 Jul 2021 10:43:45 +0800 Subject: Re: [Phishing Risk] [External] [PATCH 2/3] mm/zsmalloc.c: combine two atomic ops in zs_pool_dec_isolated() To: Muchun Song CC: Andrew Morton , Minchan Kim , , , LKML , Linux Memory Management List References: <20210624123930.1769093-1-linmiaohe@huawei.com> <20210624123930.1769093-3-linmiaohe@huawei.com> <1b38b33f-316e-1816-216f-9923f612ceb6@huawei.com> <01117bc0-53b1-d81a-a4d8-2a1dbe5dcd94@huawei.com> <97fdc2f3-6757-7ca1-6323-02b618b85894@huawei.com> From: Miaohe Lin Message-ID: <1b85c741-59ea-e3a0-5b58-08ea6e8bfbbc@huawei.com> Date: Thu, 1 Jul 2021 10:43:45 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.178.36] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To dggeme703-chm.china.huawei.com (10.1.199.99) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021/6/25 18:40, Muchun Song wrote: > On Fri, Jun 25, 2021 at 5:32 PM Miaohe Lin wrote: >> >> On 2021/6/25 16:46, Miaohe Lin wrote: >>> On 2021/6/25 15:29, Muchun Song wrote: >>>> On Fri, Jun 25, 2021 at 2:32 PM Miaohe Lin wrote: >>>>> >>>>> On 2021/6/25 13:01, Muchun Song wrote: >>>>>> On Thu, Jun 24, 2021 at 8:40 PM Miaohe Lin wrote: >>>>>>> >>>>>>> atomic_long_dec_and_test() is equivalent to atomic_long_dec() and >>>>>>> atomic_long_read() == 0. Use it to make code more succinct. >>>>>> >>>>>> Actually, they are not equal. atomic_long_dec_and_test implies a >>>>>> full memory barrier around it but atomic_long_dec and atomic_long_read >>>>>> don't. >>>>>> >>>>> >>>>> Many thanks for comment. They are indeed not completely equal as you said. >>>>> What I mean is they can do the same things we want in this specified context. >>>>> Thanks again. >>>> >>>> I don't think so. Using individual operations can eliminate memory barriers. >>>> We will pay for the barrier if we use atomic_long_dec_and_test here. >>> >>> The combination of atomic_long_dec and atomic_long_read usecase is rare and looks somehow >>> weird. I think it's worth to do this with the cost of barrier. >>> >> >> It seems there is race between zs_pool_dec_isolated and zs_unregister_migration if pool->destroying >> is reordered before the atomic_long_dec and atomic_long_read ops. So this memory barrier is necessary: >> >> zs_pool_dec_isolated zs_unregister_migration >> pool->destroying != true >> pool->destroying = true; >> smp_mb(); >> wait_for_isolated_drain >> wait_event with atomic_long_read(&pool->isolated_pages) != 0 >> atomic_long_dec(&pool->isolated_pages); >> atomic_long_read(&pool->isolated_pages) == 0 > > I am not familiar with zsmalloc. So I do not know whether the race > that you mentioned above exists. But If it exists, the fix also does > not make sense to me. If there should be inserted a smp_mb between > atomic_long_dec and atomic_long_read, you should insert > smp_mb__after_atomic instead of using atomic_long_dec_and_test. > Because smp_mb__after_atomic can be optimized on certain architecture > (e.g. x86_64). > Sorry for the delay. I think there is two options: atomic_long_dec(&pool->isolated_pages); smp_mb__after_atomic atomic_long_read(&pool->isolated_pages) == 0 We have two atomic ops with one smp_mb. vs atomic_long_dec_and_test while implies __smp_mb__before_atomic + atomic_long_ops + smp_mb__after_atomic. We have one atomic ops with two smp_mb. I think either one works but prefer later one. What do you think? Thanks. > Thanks. > >> >> Thus wake_up_all is missed. >> And the comment in zs_pool_dec_isolated() said: >> /* >> * There's no possibility of racing, since wait_for_isolated_drain() >> * checks the isolated count under &class->lock after enqueuing >> * on migration_wait. >> */ >> >> But I found &class->lock is indeed not acquired for wait_for_isolated_drain(). So I think the above race >> is possible. Does this make senses for you ? >> Thanks. >> >>>> >>>>> >>>>>> That RMW operations that have a return value is equal to the following. >>>>>> >>>>>> smp_mb__before_atomic() >>>>>> non-RMW operations or RMW operations that have no return value >>>>>> smp_mb__after_atomic() >>>>>> >>>>>> Thanks. >>>>>> >>>>>>> >>>>>>> Signed-off-by: Miaohe Lin >>>>>>> --- >>>>>>> mm/zsmalloc.c | 3 +-- >>>>>>> 1 file changed, 1 insertion(+), 2 deletions(-) >>>>>>> >>>>>>> diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c >>>>>>> index 1476289b619f..0b4b23740d78 100644 >>>>>>> --- a/mm/zsmalloc.c >>>>>>> +++ b/mm/zsmalloc.c >>>>>>> @@ -1828,13 +1828,12 @@ static void putback_zspage_deferred(struct zs_pool *pool, >>>>>>> static inline void zs_pool_dec_isolated(struct zs_pool *pool) >>>>>>> { >>>>>>> VM_BUG_ON(atomic_long_read(&pool->isolated_pages) <= 0); >>>>>>> - atomic_long_dec(&pool->isolated_pages); >>>>>>> /* >>>>>>> * There's no possibility of racing, since wait_for_isolated_drain() >>>>>>> * checks the isolated count under &class->lock after enqueuing >>>>>>> * on migration_wait. >>>>>>> */ >>>>>>> - if (atomic_long_read(&pool->isolated_pages) == 0 && pool->destroying) >>>>>>> + if (atomic_long_dec_and_test(&pool->isolated_pages) && pool->destroying) >>>>>>> wake_up_all(&pool->migration_wait); >>>>>>> } >>>>>>> >>>>>>> -- >>>>>>> 2.23.0 >>>>>>> >>>>>> . >>>>>> >>>>> >>>> . >>>> >>> >> > . >