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 57263C4167D for ; Fri, 3 Nov 2023 03:16:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231366AbjKCDQW convert rfc822-to-8bit (ORCPT ); Thu, 2 Nov 2023 23:16:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54008 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229459AbjKCDQU (ORCPT ); Thu, 2 Nov 2023 23:16:20 -0400 Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2ADCC1A5 for ; Thu, 2 Nov 2023 20:16:17 -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.2) (envelope-from ) id 1qykf0-0007x0-1e; Thu, 02 Nov 2023 23:15:50 -0400 Message-ID: <48ec0dd17f048541dd83f7ed7cb29dac91d8c607.camel@surriel.com> Subject: Re: [PATCH] mm/hugetlb: fix null ptr defer in hugetlb_vma_lock_write From: Rik van Riel To: Mike Kravetz Cc: Edward Adam Davis , akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, llvm@lists.linux.dev, muchun.song@linux.dev, nathan@kernel.org, ndesaulniers@google.com, syzbot+6ada951e7c0f7bc8a71e@syzkaller.appspotmail.com, syzkaller-bugs@googlegroups.com, trix@redhat.com Date: Thu, 02 Nov 2023 23:15:50 -0400 In-Reply-To: <20231103023737.GC3531@monkey> References: <3382634358afa9b95dc4f6db8a53a136d4b9e9cb.camel@surriel.com> <20231103022426.GA3531@monkey> <20231103023737.GC3531@monkey> 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 Thu, 2023-11-02 at 19:37 -0700, Mike Kravetz wrote: > On 11/02/23 19:24, Mike Kravetz wrote: > > > > In the specific case causing the null-ptr-deref, the resv_map > > pointer > > (vm_private_data) is NULL. > > Hi Rik, > > In commit bf4916922c60 hugetlbfs: extend hugetlb_vma_lock to private > VMAs, > it correctly says: > >     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. > > That qualification '(with resv_map)' caught my attention originally, > and > I thought about it again while looking into this.  We now cover the > common > cases, but there are still quite a few cases where resv_map is NULL > for > private mappings.  In such cases, the race between MADV_DONTNEED and > page > fault still exists.  Is that a concern? Honestly, I'm not sure. In hugetlb_dup_vma_private, which is called at fork time, we have this comment: * - For MAP_PRIVATE mappings, this is the reserve map which does * not apply to children. Faults generated by the children are * not guaranteed to succeed, even if read-only. That suggests we already have no guarantee of faults succeeding after fork. > > With a bit more work we 'could' make sure every hugetlb vma has a > lock > to participate in this scheme. > > Any thhoughts? We can certainly close the race between MADV_DONTNEED and page faults for MAP_PRIVATE mappings in child processes, but that does not guarantee that we actually have hugetlb pages for those processes. In short, I'm not sure :) -- All Rights Reversed.