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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1D8F0C4332F for ; Fri, 3 Nov 2023 03:16:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9A34E8D00B6; Thu, 2 Nov 2023 23:16:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 951358D000F; Thu, 2 Nov 2023 23:16:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7F2BB8D00B6; Thu, 2 Nov 2023 23:16:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 6E0E18D000F for ; Thu, 2 Nov 2023 23:16:20 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 488B7A085F for ; Fri, 3 Nov 2023 03:16:20 +0000 (UTC) X-FDA: 81415179720.18.3A5400D Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) by imf27.hostedemail.com (Postfix) with ESMTP id 230C24000B for ; Fri, 3 Nov 2023 03:16:16 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=none; spf=none (imf27.hostedemail.com: domain of riel@shelob.surriel.com has no SPF policy when checking 96.67.55.147) smtp.mailfrom=riel@shelob.surriel.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698981378; a=rsa-sha256; cv=none; b=p5sfMWJIuhzzyRzu6Mkgi+XCKF61/f+J4R/sZ3YOYb0VU70P+aIxGr3L1sRwsjhoK5BrE7 w/9z4iItu2szj5FT7M2eDSF40QHD+qlEoatSiHPkaoDXA3F5ibWzO/rieaJ/Hh0vxribxW Lfo9A1vNkp/nUTFb2pZr5utNYhFzei4= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=none; spf=none (imf27.hostedemail.com: domain of riel@shelob.surriel.com has no SPF policy when checking 96.67.55.147) smtp.mailfrom=riel@shelob.surriel.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1698981378; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=emkP1ffMFVxkTDl0c9YuWNULkU7SziqLbacJFdDA0EI=; b=yA+VckY0KFmrapd3JUtRw0c4l7t0pJNX+at5697NdWG7lntDvdBFahwRxBxnDdvN8cb4Rh 6OUEJfiq7HJTld9g3qo10F+eOLCDzXfMKAFITes5z9nAimHSmazZwAqk3jHFpvt54Qg15H KOp5dW/paaRgYoKMhIPtyAwzTyn0u4U= 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: quoted-printable User-Agent: Evolution 3.46.4 (3.46.4-1.fc37) MIME-Version: 1.0 X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 230C24000B X-Stat-Signature: xfeuab3e49raurorud5f6p6ze3zotems X-HE-Tag: 1698981376-241852 X-HE-Meta: U2FsdGVkX19kX8NBgdqNb9LrNAtXT7x06B7JvCZWydTl8kWDsuGUhox59tNMRqu78MrwbXse1kTK5PnRC/d1puL6cvM/Z9kumQgteJf6/EeGqSwVFUFhjU6BlNGdm79LLZE+F60kytKjxWVmg3r+NU+/tWeOxQw+L3HEeyarlUROQbXMJ41vEM3BP+Y8A6E7hFAnfXnZGyun78kiTRw/2lCG5gYR0LSkdbGyiDVxvTlvj7ClvuL7Hq9QBMGHxE8kAOKoiFVFBasW4kQfej6/WOucV/+fXJgQclu2gxoQQW053BeSWTDjRYQ0LGRl4x2hh7a362Yges5agrPiN9QzIzGvuOk49q7SpTz4/Dnt92K0GiEX3B0zS9/RgGNyOi6rO0OdhEykSnEFbU2fBgYxq2ANhYNo42Mr4fSLL4s+2XsSvRf4SDP8zTqdjsW8vwWfpx9H7Iuzap/v3ohsth735hByIHqWwWoZRiLHlT/ndHJZt6DsbU6kyznbM06drtCXwqZDPKR5dznPe5xHW4uKZOxtxADb9qZuSOsw+ctjWAwemVmf/JDlJOrqvq3zHeedV/yZgA/nffQTT0wroVHMXkWLwa9OQgOa8raDVEkoJRKnlANNkXeH0dbWTbFBlCXhd0xnGSY/iNUkbscwdzZGmztK2ZW6v32CLulm8x0jOPPwbg1ZVFySCz8NsA7V0ekLaukMkq/dTooJsdY2qZlx/8cEElz01L/A+eccqdAUpQl7S9v/TylKPKVzmyPhp6GZ4S/fqZ8WDNyIxB/C26Rp8Tf12UzHO9VtAo4Bv86R1kN/QvYqO3PeJ6JD2wYSuQ8YP6Ax3E9u2Lgc8yG7a7R8Pe5lnkLREGLu6i7+7TiLeJ4Jq9PQbprvXpuCiEJ9TkIcRKsfLVsk80CxGi3UXDieBeQj6x6uJV03de/Z0MCLpoPQk19i15/ReCeDDJCycSP4lEjFz0OTTYT1MTcY8Xm CaHVA8gu q3kQkDsZZ/s9e/tg1UwJaJtXO6yQAS/9Yt3K+2NjsJ+Gw+CAbGDg5gW6cLhUiROa/kNgLJSIsYt1M789dSbhTNNP4wVxEh5Pmig4oP8qBnR05DZq+WEnEE95molpP3+9tmiJWZmtmscKTY2YI+ZUBNoUccyaib/YbNItSK1kYubvAyjDNy9KOFL3V0P9jkxJpTm7V54fJq/QDlemURs1SdlHQtzjUk3It+04FFWDpO20WZe6VXxwhEVGlrtBGyo8MpTpgz0Wv/LCP4hLdPk+GXEpDb2wFNskTAtle/wkfHHVJfOTRF6CNT3nyWd92Lv5HUFgGrkDOgSdCqXM/9jzTEyD4GyCGYfbRSUHIhCc8ek8Y4LlUnDTramG8dpK1DW/OeOrQTm4iDricmnQ= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, 2023-11-02 at 19:37 -0700, Mike Kravetz wrote: > On 11/02/23 19:24, Mike Kravetz wrote: > >=20 > > In the specific case causing the null-ptr-deref, the resv_map > > pointer > > (vm_private_data) is NULL. >=20 > Hi Rik, >=20 > In commit bf4916922c60 hugetlbfs: extend hugetlb_vma_lock to private > VMAs, > it correctly says: >=20 > =C2=A0=C2=A0=C2=A0 Extend the locking scheme used to protect shared huget= lb mappings > from > =C2=A0=C2=A0=C2=A0 truncate vs page fault races, in order to protect priv= ate hugetlb > mappings > =C2=A0=C2=A0=C2=A0 (with resv_map) against MADV_DONTNEED. >=20 > That qualification '(with resv_map)' caught my attention originally, > and > I thought about it again while looking into this.=C2=A0 We now cover the > common > cases, but there are still quite a few cases where resv_map is NULL > for > private mappings.=C2=A0 In such cases, the race between MADV_DONTNEED and > page > fault still exists.=C2=A0 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. >=20 > With a bit more work we 'could' make sure every hugetlb vma has a > lock > to participate in this scheme. >=20 > 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 :) --=20 All Rights Reversed.