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 0CAF0C4332F for ; Thu, 2 Nov 2023 13:46:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3EA988D0055; Thu, 2 Nov 2023 09:46:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 39A728D000F; Thu, 2 Nov 2023 09:46:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 288A28D0055; Thu, 2 Nov 2023 09:46:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 17B9B8D000F for ; Thu, 2 Nov 2023 09:46:54 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id D21B0C0190 for ; Thu, 2 Nov 2023 13:46:53 +0000 (UTC) X-FDA: 81413139906.02.AA82C38 Received: from out162-62-57-137.mail.qq.com (out162-62-57-137.mail.qq.com [162.62.57.137]) by imf21.hostedemail.com (Postfix) with ESMTP id DFDF71C001F for ; Thu, 2 Nov 2023 13:46:49 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=qq.com header.s=s201512 header.b=mC0zvjQE; spf=pass (imf21.hostedemail.com: domain of nh26223@qq.com designates 162.62.57.137 as permitted sender) smtp.mailfrom=nh26223@qq.com; dmarc=pass (policy=quarantine) header.from=qq.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1698932811; h=from:from: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:dkim-signature; bh=vXlKBRHvNub2ggaMH+0mx9+DOFMDH691qFaLcYjo3U0=; b=Xuv82knJLlxXS2FJcgZKX9eDv0J/jgz/NuYYRhpUFvm6PUKDXfbHdCJ5DKk26zbLS7+oJd iqpw4K2GDwmP+s3rsu/pDHTUpvHWeN0hl614a80l7a37Y+DizhzEmYs/eb9M5CABRFJeRp UiO99effEAfsHikizAiVEfSDHZwBMd0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698932811; a=rsa-sha256; cv=none; b=m2GPBw61xqYjb6P9XXTzBNH+gRgRLnno4E51l5jvvlvjNdioHNpWUVFxeO9wAL81WkqfVA L7aArv3PLk6k8YdsERp5hB3rW4MWPHlSYSKfPxBK6qHC1usdA2ythINl+fObKxz6SBohLz liPT/gCOeKeWnPSSG5ba3UqMkUk5Wug= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=qq.com header.s=s201512 header.b=mC0zvjQE; spf=pass (imf21.hostedemail.com: domain of nh26223@qq.com designates 162.62.57.137 as permitted sender) smtp.mailfrom=nh26223@qq.com; dmarc=pass (policy=quarantine) header.from=qq.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s201512; t=1698932794; bh=vXlKBRHvNub2ggaMH+0mx9+DOFMDH691qFaLcYjo3U0=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=mC0zvjQEpqio+jNnPh/jn6t8nAdf4h+UpTIfSnQzDyMJdiNxqbHrcbFE7stKWnnnz 7+IecsC6ngxHjwhXOhPiXLJENQN7z3a1rtzJP4NF4IhNu0dI67Ki0/8JyveAH1rTqL 4LrKiPSZv33Y2EeEizMxM62iMyQomSawnr5dp3RQ= Received: from [192.168.71.17] ([114.93.60.151]) by newxmesmtplogicsvrszb1-0.qq.com (NewEsmtp) with SMTP id B9FA8EA5; Thu, 02 Nov 2023 21:46:31 +0800 X-QQ-mid: xmsmtpt1698932791t0qal6u3j Message-ID: X-QQ-XMAILINFO: NvKyM24IHTKStqgV7c37iClZzhL/cIwwLQgieaaeU/XLgSwja/hd4K53MSEufe VIFjoE5Th3QXClreifDw1wEUQiEkUIOi7O20Jyqj33tK0ezezSdCDyjmxB/1yJN6MKCvxAwH/Y6K ixN0TNLMySRlLLHd0kWrdoK8X2xcvR/Bsa939O9kp2yyjJtwTKJR728DpSJlKIUHH8DRnQ/SoZE0 R70yqQfWYLyfd3Nuv8gwXxmyj51vGGA3qXQxBbLV+yGx5YpHHWwN4gJNMjydFSW3WsnPZe2nAqBW irM4PGicEZT4lc02lUlOyJbANn7uPtOOYIihXsLcsbQ+B7wHpBAUqicNrOEr4cOzUoDvKdj8YeB1 gr2Rs7Ej925+/PQU1jOoBBNx3NWj6EK18WH9F+FPM2mJ2b0YzeABTQpjPXZvmvKPYTpT190VJjBq x5yDkpufid2moIYqGVTDRp6F/3M1ndWZBdDv27nLvLo9zdxA26FYpq6D1O7cIYAaAyKIN/olpwIH /Xyg+egLH3CuHBv7sV7eV0bpkR83b/nA7/pFBkk7ns9YgepPVlWtYJcpo+ZaxMR6uwSpgV3NkYQ1 uw2Twu4VcvIUM7af60QQQRF8DsHs21C36UM7MO2/tzD+ACnt++abLMqBlSAygoE77tG/WCvQoPTo /56a3rvPxd4BWIGu1YqBy/z/REJixYakzTp8CnjXNdSkfc7za+X+/2xGIlsCUr9mUl+y3qHLXsd6 uN+4I32DlZLIjdmNMP4rchOJvrqAcYL3XgZdkk1IbDkdjoSeIXoJBvXnBHJpUmSc6SFl9yXcp042 ELQiFuFMPtezKBrjGsX5+dDnWd15K0zZc83+IDsemXZ7LOVtwbxPpKH4aYIIk2pNQj/u8PBIYWn2 eegbBUvw6GfyLvb8iUTCk2tEn5pYeWs5ZHfYn3GPoRXUBqRKM8Rkm3J25Pys4ZmHaCZF4pshkl9P 148ClhVSE5xscviXy1jRjYWXKkcIIWiRfDmTxttSTzZw5KYcd26uF/3pc5bFjT X-QQ-XMRINFO: NyFYKkN4Ny6FSmKK/uo/jdU= X-OQ-MSGID: <47c865e2-fb34-4634-aec3-c08110cd9f0c@qq.com> Date: Thu, 2 Nov 2023 21:46:31 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm/hugetlb: fix null ptr defer in hugetlb_vma_lock_write Content-Language: en-US To: Rik van Riel , 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 References: <00000000000078d1e00608d7878b@google.com> <3382634358afa9b95dc4f6db8a53a136d4b9e9cb.camel@surriel.com> From: "Yin, Fengwei" In-Reply-To: <3382634358afa9b95dc4f6db8a53a136d4b9e9cb.camel@surriel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Stat-Signature: xriueyeeaigygd3kwu8jenkjy9q763t9 X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: DFDF71C001F X-Rspam-User: X-HE-Tag: 1698932809-930339 X-HE-Meta: U2FsdGVkX1+qivKePxNMzXGng6FsnLCgTo95sviG8s0UZLztmqm4fQ5og04qZJjyrfMjtrfI6XU6bS2jddLIs2cvkfphLqp3eF3YaiAsLGQnY8FZtGnMSNMTUohdRXzsO3AlGjP1nW1ZWnMLZrmlnTIGPoTT4iUvShn79qC7dlcGDSOc3JaIclos0pWkhRVitBB5ol/xskV4J+Yeu5caOSlG7bWtZ65ThxXzU5/zcvfDc7GV3drPMusveR+1gQv7wRbjz/K8QJigPBk88HfaIMXMHhBUDIToX2y2/pNvHk6KRL3x7ThHi4oRGs6g6N/7HlQ6Ngcf3e4rGYc1o9iiRzLU0etr3OVQOX8ZLrzGUvrCCVGa+3tbWEcvYSM1zjUGzPoJ8lsOmsAXlYNSGe52jxIfs+tAW0P/cn+tOaSJ0E96Y37dW6hv2NYZh4qPpBXzj0mjVIHENyXjbQr1UIn2oiymqkKAoaRO9QEN5ldpnOzff7NTSCxpt55E5hW1KJhjjYrnE5yGc9XvIsl9CYSHuhJWQQqzHysRxpnuxgLzbmJ8UPjgqSux6F2X4y7XwBPI++OOht4RFL0Wo5N1mYQvPkecDd3TJmwrq4CQkcCszF8WfLYEmIHQIlE6QKRbT0jJhzZ68UN3CmckBFbmHfeTqKi2iDbuHREbLzZ2IRDjQZEkPalrtYgcl4ElcwjFuaM/XN69WJSlCw3q9gTm7Cd4B44T8iPO3FzcRQvlZX8TtTESGy/7ngzrWLygIUrntpy3m6izUszWYxsWe+acqUU0c2Vh9ka9M47WM6ZiPynFAwTul3zHjc+h4VMB2enBXdPh2DbjpaSj74IU9Osv1i5DADZWwi+FGiY7ZNfjSzVBrQiugBjITE32TB58VM0diSjivp8E1SscS+knic07s9mqQCwLUu0r42aKpY498MRAeXsb/DEIuWmdQePXW6bSEAzHvb1Ns5vxKqBmJ+VawpT jYtwq1x0 20nn97Ia3JHHsKgWuy2uvRHQ8KemJhuoeqD+6+TFnoBoShzXxEh7KExHoZaRUyRE3LJaR37dfU3z+X0Egv9rW3aHxNBWJauAqcsLEfjDKVhFm23Bp52zKBi8qaexN+r6yh71xJstBhOkN33xLYw1ZVVu2UtcZRXyXkHW5OrvrM5DWoiWtzXZJe4LIMDVmLE5B18C8GfQUUT42kkE/h96QmaLTAhtxU/c2zACNgu5to3S7nK/ogmjTHFrcOIhGL/0reQSM3+oG3PAyLXwX0ad5Ha9UytgiMnfmhaJufcHc2Lit4iBiY+W2iHEH6WfjgWsiW0TV/biXdeB7k7j8101JSJG1MjQk66xw9MPsqHFvtGL60ryfWe8OBAAw+oBJpxjwohNzZlBIMYj6GMVPeXMAGNw1xJ1CoGqZUZFM7M/EmPeexj+0mZ6xyMwhJWcE0Q6Y2HgiTc51gh5/GmUu2MlOOf+c54im7EQi5+ra37qOF2234MJBO4cVh8Idxa883klo/Tpf03o4Ca7PTyY= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000004, 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 1/11/2023 22:27, Rik van Riel wrote: > 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. >> >> 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 >> --- >>  include/linux/hugetlb.h | 4 +++- >>  1 file changed, 3 insertions(+), 1 deletion(-) >> >> 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) >>         return (vma->vm_flags & VM_MAYSHARE) && vma->vm_private_data; >>  } >> >> +#define HPAGE_RESV_OWNER    (1UL << 0) >>  static inline bool __vma_private_lock(struct vm_area_struct *vma) >>  { >> -       return (!(vma->vm_flags & VM_MAYSHARE)) && vma- >>> vm_private_data; >> +       return (!(vma->vm_flags & VM_MAYSHARE)) && vma- >>> vm_private_data && >> +               ((unsigned long)vma->vm_private_data & >> HPAGE_RESV_OWNER); >>  } I am wondering whether this line should be: return (!(vma->vm_flags & VM_MAYSHARE)) && ((unsigned long)vma->vm_private_data & HPAGE_RESV_OWNER); or even: return (unsigned long)vma->vm_private_data & HPAGE_RESV_OWNER; because mm/hugetlb.c has: "We know private mapping must have HPAGE_RESV_OWNER set." > > 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 :) > Like you said, vma->vm_private_data is cleared during fork(). But I saw following possible code path in child process: hugetlb_wp() unmap_ref_private() if alloc_hugetlb_folio fails unmap_hugepage_range() __unmap_hugepage_range() set_vma_resv_flags(vma, HPAGE_RESV_UNMAPPED) vm_private_data become 0x2 which is none NULL without HPAGE_RESV_OWNER bit.