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 BA638CE79AE for ; Wed, 20 Sep 2023 04:10:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232569AbjITEKI convert rfc822-to-8bit (ORCPT ); Wed, 20 Sep 2023 00:10:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54040 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229534AbjITEKF (ORCPT ); Wed, 20 Sep 2023 00:10:05 -0400 Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E9B63B0 for ; Tue, 19 Sep 2023 21:09:59 -0700 (PDT) Received: from imladris.home.surriel.com ([10.0.13.28] helo=imladris.surriel.com) by shelob.surriel.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1qioWz-0007rh-32; Wed, 20 Sep 2023 00:09:41 -0400 Message-ID: <7ddc6ba18b3fef3ed637dcd9a85e90cf4ca6ca7d.camel@surriel.com> Subject: Re: [PATCH 1/2] hugetlbfs: extend hugetlb_vma_lock to private VMAs From: Rik van Riel To: Matthew Wilcox Cc: linux-kernel@vger.kernel.org, kernel-team@meta.com, linux-mm@kvack.org, akpm@linux-foundation.org, muchun.song@linux.dev, mike.kravetz@oracle.com, leit@meta.com Date: Wed, 20 Sep 2023 00:09:41 -0400 In-Reply-To: References: <20230920021811.3095089-1-riel@surriel.com> <20230920021811.3095089-2-riel@surriel.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT User-Agent: Evolution 3.46.4 (3.46.4-1.fc37) MIME-Version: 1.0 Sender: riel@surriel.com Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2023-09-20 at 04:57 +0100, Matthew Wilcox wrote: > On Tue, Sep 19, 2023 at 10:16:09PM -0400, riel@surriel.com wrote: > > From: Rik van Riel > > > > Extend the locking scheme used to protect shared hugetlb mappings > > from truncate vs page fault races, in order to protect private > > hugetlb mappings (with resv_map) against MADV_DONTNEED. > > > > Add a read-write semaphore to the resv_map data structure, and > > use that from the hugetlb_vma_(un)lock_* functions, in preparation > > for closing the race between MADV_DONTNEED and page faults. > > This feels an awful lot like the invalidate_lock in struct > address_space > which was recently added by Jan Kara. > Indeed it does. It might be even nicer if we could replace the hugetlb_vma_lock special logic with the invalidate_lock for hugetlbfs. Mike, can you think of any reason why the hugetlb_vma_lock logic should not be replaced with the invalidate_lock? If not, I'd be happy to implement that. -- All Rights Reversed.