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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9BC98C0015E for ; Wed, 19 Jul 2023 14:26:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231628AbjGSO0e (ORCPT ); Wed, 19 Jul 2023 10:26:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57722 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231620AbjGSO0W (ORCPT ); Wed, 19 Jul 2023 10:26:22 -0400 Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 42DDC10F5 for ; Wed, 19 Jul 2023 07:26:20 -0700 (PDT) Received: by mail-yb1-xb36.google.com with SMTP id 3f1490d57ef6-c2cf4e61bc6so7247704276.3 for ; Wed, 19 Jul 2023 07:26:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1689776779; x=1692368779; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=2VK55DG3Fs7PTghAKQd0jM8nvqZIPZ4glcR3HhFBT7c=; b=7jfU311slUUW0UFqd1xP+4htLveZmM27w7SWA5P0Ofot830W2PGNGcLy4HrhdEoxQm az+ILN50Jzlo4maRmOZlUhdjCrGtxh073DOAMOQlyZCSdcDvxCsrVoHtWECGQCV6CMYP dtkRMmL1WsTSmqNv2tW3j4A1S23poCaDbO2S1YBY1oW1aMQtTEPf6UsRY+WbA+OtKrIC Ua7LPGLJzdckrb/5yRJ7bC/gRfLRRWFwi+VUOyu29ro5uT5rEQHlXpAaCoqRhr+mHIqE pK8dmPZI3dsvbXSSHF64DsP7G2TTHotWz5S+oM6rCmanQUB6ET0h94ELWpdpUDirIPGy yX7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689776779; x=1692368779; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=2VK55DG3Fs7PTghAKQd0jM8nvqZIPZ4glcR3HhFBT7c=; b=UVZpgABYpkklUc6x/21HUJhBzQa4vnwhNz0Q0xjyTz5hu2xpSFh11bWWQHXjXwyLpE S8N3/7NKBnFD0JNMq93dosrPvk+rVEEoQkYj5LB7ZJKsWTvUqdkCqdcCf5RooH5pbaWI TFTHJTXlL6HIK7NkUztx+mvu6xv2Eab7cm5kcqoxSSHgYWJaJiZywwBUQ3KS9yrHjKuO Gkrtvg451vd7LFcPq3umPWKD4yw8NWkKw4yQS+ismp6KXXcLhqnv9GwHZLi7gB5fum+A 1KsOf/jzl5ZzQqwesK4+ngfiVEPHGB9ET9QXGcZh2juCP7ze0RMB6DgPUlkVBMbYSRQp hh2Q== X-Gm-Message-State: ABy/qLaipCoeh1N4Q+UOxxk2dFGUwnhZdW2A66kxjW+eAaS6Ks+6HBtO Nx5aLzioao0K/CyfTJ4q/YvCfGUaV5b8IVCrG8qooA== X-Google-Smtp-Source: APBJJlFkic+Ri/Zc9kWO4O0LpFmkfS6fsW6kTdiRwmfAxsS9VkTkZur4wtoBXB7B9HvqhJ1+BGi7/g== X-Received: by 2002:a25:5342:0:b0:c85:d8b7:1b96 with SMTP id h63-20020a255342000000b00c85d8b71b96mr2356398ybb.52.1689776778840; Wed, 19 Jul 2023 07:26:18 -0700 (PDT) Received: from ripple.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id 133-20020a250b8b000000b00cecd504e708sm651446ybl.35.2023.07.19.07.26.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Jul 2023 07:26:18 -0700 (PDT) Date: Wed, 19 Jul 2023 07:26:08 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@ripple.attlocal.net To: Yin Fengwei cc: Yosry Ahmed , Yu Zhao , linux-mm@kvack.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, willy@infradead.org, david@redhat.com, ryan.roberts@arm.com, shy828301@gmail.com, Hugh Dickins Subject: Re: [RFC PATCH v2 3/3] mm: mlock: update mlock_pte_range to handle large folio In-Reply-To: Message-ID: <79f6822-f2f8-aba4-b517-b661d07e2d@google.com> References: <20230712060144.3006358-1-fengwei.yin@intel.com> <20230712060144.3006358-4-fengwei.yin@intel.com> <40cbc39e-5179-c2f4-3cea-0a98395aaff1@intel.com> <16844254-7248-f557-b1eb-b8b102c877a2@intel.com> <208aff10-8a32-6ab8-f03a-7f3c9d3ca0f7@intel.com> <438d6f6d-2571-69d9-844e-9af9e6b4f820@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 19 Jul 2023, Yin Fengwei wrote: > >>>>>>>>> Could this also happen against normal 4K page? I mean when user try to munlock > >>>>>>>>> a normal 4K page and this 4K page is isolated. So it become unevictable page? > >>>>>>>> Looks like it can be possible. If cpu 1 is in __munlock_folio() and > >>>>>>>> cpu 2 is isolating the folio for any purpose: > >>>>>>>> > >>>>>>>> cpu1 cpu2 > >>>>>>>> isolate folio > >>>>>>>> folio_test_clear_lru() // 0 > >>>>>>>> putback folio // add to unevictable list > >>>>>>>> folio_test_clear_mlocked() > >>>>> folio_set_lru() > Let's wait the response from Huge and Yu. :). I haven't been able to give it enough thought, but I suspect you are right: that the current __munlock_folio() is deficient when folio_test_clear_lru() fails. (Though it has not been reported as a problem in practice: perhaps because so few places try to isolate from the unevictable "list".) I forget what my order of development was, but it's likely that I first wrote the version for our own internal kernel - which used our original lruvec locking, which did not depend on getting PG_lru first (having got lru_lock, it checked memcg, then tried again if that had changed). I was uneasy with the PG_lru aspect of upstream lru_lock implementation, but it turned out to work okay - elsewhere; but it looks as if I missed its implication when adapting __munlock_page() for upstream. If I were trying to fix this __munlock_folio() race myself (sorry, I'm not), I would first look at that aspect: instead of folio_test_clear_lru() behaving always like a trylock, could "folio_wait_clear_lru()" or whatever spin waiting for PG_lru here? Hugh