Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp1000579iob; Fri, 13 May 2022 19:10:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzh4qifNnl30AinIjx33Lxfe19px+a7n6pd6bVz0Vs4YyunyUi5CltygFSuZQj9KC9bQt9J X-Received: by 2002:a5d:64ab:0:b0:20c:64d4:d565 with SMTP id m11-20020a5d64ab000000b0020c64d4d565mr6127341wrp.683.1652494246061; Fri, 13 May 2022 19:10:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652494246; cv=none; d=google.com; s=arc-20160816; b=cNYb5rvB/F2ZDWTBq9KUBOrkCnHbm/H1jhaaAixxsyCxC16LlH5aZin0SO9nbGXTel BLkcC16xH5HCfI94cH6YOHygNmq3AP2VQiFGPBWH8MH/COq6LYS1B6viPAjebmj+s1zL YLyu2qKbYF6Db+aeFCOlDtHIzcd7c88L32219/COCwYBz5E9wg8imRLVnJ4Iii95lAvq B4FvvRJB0FF+63jMEiIc5NQE+JsChu7DtH7g/yegknibQCVrY5b/YN8ZBaT1kaUp81qm 26Cw9R3ru0h//t8QGbk2bGndZdcSac/r+sVm4qVgRZx0PS4M9mNvrPsq9tCdUilpesgn 8DLA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=z9qO5NMGKQYL2WOTFj5dbrfEpsnI+nYjcnnXFuhApBQ=; b=cYdfzk9WCLlFRBeKGxOfEkn9aOg4q0tV1kgN3FR+2ZML+PATH9ug///1P/LXwK5U+L 7u6sb8i/Qlv4h9wYZ0Nq3zmU/Fy++5mzvh9PpybLC3TUHSwbHYlMGZR36icvcUImU0gr Q5mw18J3jG9a2ALOm8k5y7t0bk4nUsDdWobmHpum+T2ihOQ8AwTepwtilPEml+c0fhPC wnJNJEOSO6dotZYXF8hlG/fAAY4PQ8Mlev9h3CWudu057VFTNyDtve/aEw26uuClArPa es575W/is3t5HEqTWdrM8TXQ3HlPt/9j+DdTYZ/JaUJN/zZRuQ1MgMf5LkuWib0ezTUS Um3g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=NQu3DKyB; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id n10-20020a05600c3b8a00b00394690b76f3si6607584wms.19.2022.05.13.19.10.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 May 2022 19:10:46 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=NQu3DKyB; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 004E449801A; Fri, 13 May 2022 17:29:44 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349460AbiEKXpk (ORCPT + 99 others); Wed, 11 May 2022 19:45:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53466 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349452AbiEKXpj (ORCPT ); Wed, 11 May 2022 19:45:39 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C1FC36211F for ; Wed, 11 May 2022 16:45:37 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 81066B82642 for ; Wed, 11 May 2022 23:45:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 266A4C340EE; Wed, 11 May 2022 23:45:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1652312735; bh=b6mgKJpVJA/b7+VDSLPzDbu9hDNiACAHNnivpAnLRXQ=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=NQu3DKyBmK8FcoCK67b8nygpYZHdzwkv8l49/7YNJqI22QYKFW0YKFLz6fh2Gdq/6 lK3q+K1EwN5AW1fTyV+603TNksBJI5aOD4KVFaI5dfkrZIVyt5NT01tyNhaaZIe0sW yiUchbbd2TNRSP5ZG0vEMhwj3svStRjxS3MS7uyzG1dPbyw7z6aHBOZs04GGEZZpry Bvh0r3gnZQ32rAUsXBn4hPVPmdeJoFAcXJ4acEkAICBfqU7TTaSFjzirHp2GuFq1lh wFytBIQfJim9nuY9bq/wx1UNNDgNzDRR/WL+LAjvbCirBnA9VLdpmKCHkythUmn7dD OJKYM0sxY6jMg== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id BAFD55C05FC; Wed, 11 May 2022 16:45:34 -0700 (PDT) Date: Wed, 11 May 2022 16:45:34 -0700 From: "Paul E. McKenney" To: John Hubbard Cc: Minchan Kim , Andrew Morton , linux-mm , LKML , John Dias , David Hildenbrand Subject: Re: [PATCH v4] mm: fix is_pinnable_page against on cma page Message-ID: <20220511234534.GG1790663@paulmck-ThinkPad-P17-Gen-1> Reply-To: paulmck@kernel.org References: <2ffa7670-04ea-bb28-28f8-93a9b9eea7e8@nvidia.com> <54b5d177-f2f4-cef2-3a68-cd3b0b276f86@nvidia.com> <8f083802-7ab0-15ec-b37d-bc9471eea0b1@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8f083802-7ab0-15ec-b37d-bc9471eea0b1@nvidia.com> X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RDNS_NONE,SPF_HELO_NONE,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 Wed, May 11, 2022 at 04:13:10PM -0700, John Hubbard wrote: > On 5/11/22 16:08, Minchan Kim wrote: > > > OK, so the code checks the wrong item each time. But the code really > > > only needs to know "is either _CMA or _ISOLATE set?". And so you > > > > Yes. > > > > > can just sidestep the entire question by writing it like this: > > > > > > int mt = get_pageblock_migratetype(page); > > > > > > if (mt & (MIGRATE_ISOLATE | MIGRATE_CMA)) > > > return false; > > > > I am confused. Isn't it same question? > > > > set_pageblock_migratetype(MIGRATE_ISOLATE) > > if (get_pageblock_migrate(page) & MIGRATE_CMA) > > > > set_pageblock_migratetype(MIGRATE_CMA) > > > > if (get_pageblock_migrate(page) & MIGRATE_ISOLATE) > > Well no, because the "&" operation is a single operation on the CPU, and > isn't going to get split up like that. Chiming in a bit late... The usual way that this sort of thing causes trouble is if there is a single store instruction that changes the value from MIGRATE_ISOLATE to MIGRATE_CMA, and if the compiler decides to fetch twice, AND twice, and then combine the results. This could give a zero outcome where the underlying variable never had the value zero. Is this sort of thing low probability? Definitely. Isn't this sort of thing prohibited? Definitely not. So what you have will likely work for at least a while longer, but it is not guaranteed and it forces you to think a lot harder about what the current implementations of the compiler can and cannot do to you. The following LWN article goes through some of the possible optimizations (vandalisms?) in this area: https://lwn.net/Articles/793253/ In the end, it is your code, so you get to decide how much you would like to keep track of what compilers get up to over time. ;-) Thanx, Paul