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 23002C4167B for ; Wed, 1 Nov 2023 14:28:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 461CD8D0067; Wed, 1 Nov 2023 10:28:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4129E8D0001; Wed, 1 Nov 2023 10:28:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 300718D0067; Wed, 1 Nov 2023 10:28:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 2539B8D0001 for ; Wed, 1 Nov 2023 10:28:31 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id CC0ACB5F67 for ; Wed, 1 Nov 2023 14:28:30 +0000 (UTC) X-FDA: 81409615980.28.11D994F Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) by imf17.hostedemail.com (Postfix) with ESMTP id 10F584000D for ; Wed, 1 Nov 2023 14:28:28 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=none; spf=none (imf17.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=1698848909; 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=P0XeTaB1lcNdvTZc1THQq5JlSu3PdZg1d6IZnl/eU/c=; b=HQvGRLICm9+simRIJR47Ttort3aGFwi0mVWnnBc3zpJEkvO3OkRBxxeidt8qnc7r8Sywwv ISrEjKpcRgQpCdLA6S2icOjjWCdkzQEQMoNVX5rodZQ+TsB+ZQq5GOAB6rkJmpbBE9aDM3 xXurABwSEOtIZ6xXRbmhhjvmKtzp1UA= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=none; spf=none (imf17.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=1698848909; a=rsa-sha256; cv=none; b=duY6XrqmmVh17kgJGhHjnvAA+GaQywnaYTLlz/UTMpCqK2aNkPmRzmR4Hdbg4eTB3Ths5W GVk7ruSD7j2EXTJR6xL3QfTWJX06e7VdxjPRb0wppVDOwrgF5/bDNqOU6GrXNNxCfB7hTl eAVIWlSNpPmW3DSgO5QoS7L55UGb0j4= 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 1qyCCL-00084w-04; Wed, 01 Nov 2023 10:27:57 -0400 Message-ID: <3382634358afa9b95dc4f6db8a53a136d4b9e9cb.camel@surriel.com> Subject: Re: [PATCH] mm/hugetlb: fix null ptr defer in hugetlb_vma_lock_write From: Rik van Riel To: Edward Adam Davis , syzbot+6ada951e7c0f7bc8a71e@syzkaller.appspotmail.com Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, llvm@lists.linux.dev, mike.kravetz@oracle.com, muchun.song@linux.dev, nathan@kernel.org, ndesaulniers@google.com, syzkaller-bugs@googlegroups.com, trix@redhat.com Date: Wed, 01 Nov 2023 10:27:56 -0400 In-Reply-To: References: <00000000000078d1e00608d7878b@google.com> 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-Rspamd-Queue-Id: 10F584000D X-Rspam-User: X-Stat-Signature: sx5hfoft3f8gku8qrm6t8dnsfbwad17t X-Rspamd-Server: rspam01 X-HE-Tag: 1698848908-288793 X-HE-Meta: U2FsdGVkX18Q/NTL8mdsU0X1g/0zaG+oEpDdqq11ra42UQNM49HIeoJ1/wPRZEa4VpnBOZgINEBbBbU9VKvtoVl6uCZmSC+B045Mp7mzSUFpGU3uAc/AWJKFl/iGjvG/ZjOTmTw0b3lhpAcIR4B5ibnIc/veAxcHndh7jitPLXOVoX6EWabOyT0qgui3vuuPEv2z2WynRAcnTtdCR/FTnGpJaySBdcaL4ckLGrmNH2G+nRcZJ6pE8f/f1z3n2mlgq9qB3CHJrSuBghbluT/bccP8PyXdOKY69NIod+IX+ChbDg7uQ5IB6rF8r+keStTtiJhSv77Yf/7Lz+4PRKOwWJF42x0an7SI/6Ps09CuzTgJ8qRfCdFcW3AHIkgCAEAe7v24zvPueu3nT8/HpSJ/RLfRJ76Ss3RM1Cp7vAPdl+gch2LCI+57fHD9ax7LXfYQNq6L+lApwQjyu/5+5g8YfSuBPPUhIaUW2PDzfrAyHWZoH9DhuMXvXfM6Kw2xzbIr0uvDDxpQH62ajLp4QPnr3vGzvNMB2qdl1iZFhI1JeUJbBjIl7LmTovKPmn5QoMAEKgqEQECJnbmrQEwNRFeeKqyu9TpYXj3rBMJNqRYOK/kvDcf4/59/hYnkF0FcbsWo1RFBetlfAqypum0SW81SEkhIUVCbLBEDmfVe1iSMwcyphsFq1Lkd+2mZTkg79py4cKNFcEk2oC/Pob1VLu4WjbcDTvdpeyzygvAmzQ4Ak24nTTgYEcAim9CU59WO+QYoh8VUM0Q9xMV19KiAVrw9RIC5U8Te1HDuTajNaSIQ6KPWTtAKE1N2vxqGKFH0lhdjbZwCuPNAdC/X1MCwNgGBaXldXAHE61Y7VDf2CQHWc1p1K9F4X5XNzEFY0Oe4Z8VzXJyAGJbJo8XM0wI68pXUq2uTR83pJtx3/F7QHE7qa5kw/BZAvE3DbvYTTbM2dZZU2ejEZ9Akv2NMs5Sz+Mq qwXmSwTD 6x1QTcc0qozIPmeHXCoIWTzKdcABSHO+qPZVuDoNtsWJ7RyzVMusotLFKUT+LgvV/a3QAOzcSxDqtEChuNlDyfmZHe4Hj0tzKH6aB7HAEqwqwdxxg/NVrcZP/gCRog/kB5bSMT/rifah9KE+ZNgKmDjExT9Dg0RCavPF6tmEBIqVypQ51wm+zR7U+KE3em0ut2wZ/BdxekLmfw9B5PbEatz0ghRNpx3hxnGtqoqCQ3xhj+28maNOY8C80gyOfnZPj1RFJiRvIwPnG27Xpp2EGSxbVJ9I6TmFxWgWJHnJkMOuXKEDem5PtsP6MiKRwcEwWnDXc8+hHrRfejLchGRbi0p55PhgfmTS33e67a1OcbQ9AzFp7KhTsNKy/PQ893h4jzbOOmbQ8LWhft7AScp90PupTpYaIFIY4TEUkaaPTetoPIyOszLzyZArvOxZOCr6MLSyvNwHM+OP51GTirM+TEY/eIA== 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 Wed, 2023-11-01 at 14:36 +0800, Edward Adam Davis wrote: > When obtaining resv_map from vma, it is necessary to simultaneously > determine > the flag HPAGE_RESV_OWNER of vm_private_data. > Only when they are met simultaneously, resv_map is valid. >=20 > Reported-and-tested-by: > syzbot+6ada951e7c0f7bc8a71e@syzkaller.appspotmail.com > Fixes: bf4916922c60 ("hugetlbfs: extend hugetlb_vma_lock to private > VMAs") > Signed-off-by: Edward Adam Davis > --- > =C2=A0include/linux/hugetlb.h | 4 +++- > =C2=A01 file changed, 3 insertions(+), 1 deletion(-) >=20 > diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h > index 47d25a5e1933..1a3ec1aee1a3 100644 > --- a/include/linux/hugetlb.h > +++ b/include/linux/hugetlb.h > @@ -1265,9 +1265,11 @@ static inline bool __vma_shareable_lock(struct > vm_area_struct *vma) > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0return (vma->vm_flags & V= M_MAYSHARE) && vma->vm_private_data; > =C2=A0} > =C2=A0 > +#define HPAGE_RESV_OWNER=C2=A0=C2=A0=C2=A0 (1UL << 0) > =C2=A0static inline bool __vma_private_lock(struct vm_area_struct *vma) > =C2=A0{ > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0return (!(vma->vm_flags & VM_M= AYSHARE)) && vma- > >vm_private_data; > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0return (!(vma->vm_flags & VM_M= AYSHARE)) && vma- > >vm_private_data &&=20 > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0((unsigned long)vma->vm_private_data & > HPAGE_RESV_OWNER); > =C2=A0} This could be cleaned up a bit by moving the HPAGE_RESV_OWNER definition (and its friends) into hugetlb.h, as well as the is_vma_resv_set() helper function. Then __vma_private_lock() can just call is_vma_resv_set(), and open coding a duplicate of the same code. Not having duplicates of the code will make it much harder to "miss a spot" with future changes. I am still struggling to find a place where we might leave HPAGE_RESV_OWNER behind on a pointer that is otherwise NULL, but if your tests show this fixes the issue, I'm all for it :) --=20 All Rights Reversed.