Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) client-ip=2620:137:e000::3:1;
Date:   Thu, 5 Oct 2023 15:59:39 -0700
From:   Mike Kravetz <mike.kravetz@oracle.com>
To:     Rik van Riel <riel@surriel.com>
Cc:     linux-kernel@vger.kernel.org, kernel-team@meta.com,
        linux-mm@kvack.org, akpm@linux-foundation.org,
        muchun.song@linux.dev, leit@meta.com, willy@infradead.org,
        stable@kernel.org
Subject: Re: [PATCH 2/3] hugetlbfs: close race between MADV_DONTNEED and page
 fault
Message-ID: <20231005225939.GA86415@monkey>
References: <20231004032814.3108383-1-riel@surriel.com>
 <20231004032814.3108383-3-riel@surriel.com>
 <20231005031959.GA13437@monkey>
 <99b67e2408c260f53958e98226449fd2bb6a58d8.camel@surriel.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <99b67e2408c260f53958e98226449fd2bb6a58d8.camel@surriel.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?iso-8859-1?Q?q3pfzmb/eVTcsmOWKdJxmvsIy/xlh8hFaySTJ7DxEFssa2XHSdRpGtacF8?=
 =?iso-8859-1?Q?YXl5ZIAgUJy2Hj0+ZMaKuEpOPAEcEHAtkzRS69HTig4wkP4awx011B6zQj?=
 =?iso-8859-1?Q?ItvBKaVePl0ODwRMwk0otsDbifl08TcQvH5WJPd97DWSH09GfynEFCLdeQ?=
 =?iso-8859-1?Q?atvRATuAcu2KTNhBlsDh8s5aK54Fr4uWxUqzpv2csXT/mgirOoW9Q/qpeU?=
 =?iso-8859-1?Q?kWKRG5hw3nxnqjUrn9U4/UgieR5F9J8WtnZwtgyb7609m2wB+5DqAwZrjG?=
 =?iso-8859-1?Q?vEAtBm+RopbcO0HiapvS30xEExwlonz/WIvxjG1EK9sGZCBK2t6HLb4of0?=
 =?iso-8859-1?Q?iH3QZXKqLMpmV8UBbVEZoxYasL9u3SGP0geG8xJnrIqMdRe1+plOFfMZZ5?=
 =?iso-8859-1?Q?+6OvzRANUF8d4siFLjGhbeJLgP2aUiS9fsMjPpJxk+wuc4MXhCVVwP9HiI?=
 =?iso-8859-1?Q?9lc617+ipRkYM0h7uyUtqPF6+SChSPpqlYnXFYPOj22fHFiTyYu+f1ykS4?=
 =?iso-8859-1?Q?h/HXPN+s9KAJ5z7nHGxRe5lOH9ZHsEVmEuMhN/3+OuOlslqTS/XiT5/YRA?=
 =?iso-8859-1?Q?m8PzIrLQk6I+SNBtSrJFkhTbcs/UoqkkgWkHvNLlOMYOC62IXgH7aKRgI9?=
 =?iso-8859-1?Q?lfAX9WtxV808nI7+0xo+my+dijkYgQIHXOUsAPcsA6ggNGyINkeXve93ID?=
 =?iso-8859-1?Q?setvs07WbaRvCSgkIgPok21LeKN4HzLW8xppYz2bQp7GqsWs0XEnvXU2JZ?=
 =?iso-8859-1?Q?eSNALCoL3K6Yf3rMK4W4ptz7XTessoTRe5WGHkRVVXH8XtXyR3WeFuIQBo?=
 =?iso-8859-1?Q?1mo7R3bPNe1r7JC0akH3l+eKGP6VJ6VfT7zi26wuQsiKDc3jR937ekl2bY?=
 =?iso-8859-1?Q?EJ6ZMc1Oxjv1N+9tJ8t6iPvpg6il7L4dHrQxGK2x7YkVd8jevcsaV8+gKr?=
 =?iso-8859-1?Q?CLmBtBrLqQf6iN4ohDOzIt7GrVi1M44d4e8VfPzDZcCB47HM8KC0wJd2BF?=
 =?iso-8859-1?Q?oWg0+zHDdROCe2uJ21NsCNxo2k3bMR4clkhuR0nsARvNsoIptN0RmYtWE1?=
 =?iso-8859-1?Q?/YDwC3uHYUSK2tlvk1xtiNXSdT9ArBVywHyIO0paQiof9AC0WipM7DXmiq?=
 =?iso-8859-1?Q?Wvha2Qw/khA2uLQSAWFectcdlNVsraNN4VsuJN3Iix9lcDLyTSZV4Jbfe6?=
 =?iso-8859-1?Q?fkLAi7etol+nTlAU59sds4MuWb2T2SeSSrDSl8bkdobaXS7VIjHyD4yPGp?=
 =?iso-8859-1?Q?Z1YMbePM7ms2+bGRwCFAST3o7hls+OJFpBP+kg2oiWne/1FcU9/tYJikfa?=
 =?iso-8859-1?Q?fYCz+ge9C+jI9nGJ6saatGh+4BhGJ3d8dJ+Nwr+OkijPRMVY0nTDOicdWL?=
 =?iso-8859-1?Q?SQPejPuk40WHs+kGB64ndqXP67f3mSUHR/hfZ6hJfS3IBpg5EfjDuJ0bJT?=
 =?iso-8859-1?Q?l/OZfdyFcFQB6/YSi2tKWHkTvP0fSLqsh5Ci29fQgpDHEQAMSFUzWX03ue?=
 =?iso-8859-1?Q?4m0HX3Vm/nG+ZAz5m4ruCTR78DR8SUVw9/cseBTrz/qlbYQoZ/2q9sxQkU?=
 =?iso-8859-1?Q?PDI1GteiFM3Vilt5V9QGrT8o17pQqCUdbzKn/fqhj0IcSq3+mO+b9BqMFb?=
 =?iso-8859-1?Q?zK00MNMnpYOsngjah91vV2TZ+3bloMDmuG?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: =?iso-8859-1?Q?Q0rcD33V30H/sX006EO0j5LhNxygGYX0SLo9OtcqPxCqsXX7m8z/V8XMAJ?=
 =?iso-8859-1?Q?ryZU/VIrRq/8T07UcXGwlCGr5n6B9gTQEK2TqQrCjmpVF816NXZohA1vCg?=
 =?iso-8859-1?Q?ZheN/tIljHniJRtO+Kfd4SAPFcBDR/Te/hiMM8mC7oNNEPN4QEv4/khe3p?=
 =?iso-8859-1?Q?cTeEw50L4eQ5zz0yN8ysfwgMWMJ9XCpuWn9+f4cWDZyHC3KYZuk47ljOOZ?=
 =?iso-8859-1?Q?w7rVrkP8GroUSoKVj0CvPHM3/hKY3XxCEVKLjF9Po3pv96c4mvuNKRlVDK?=
 =?iso-8859-1?Q?3SID5DIQvG5b9Sik6fGeSCowxO1RR7uGmZvZwJdUzTvrccaRDQD+/eaANN?=
 =?iso-8859-1?Q?GKa5NjE7R7VDKY0VXHHFb9C2WyfRYIPIAKCTp8mglrMSATEDKnz0zVy3Qp?=
 =?iso-8859-1?Q?vbAUnRwsIKiBCV4GE3z4MSwv8UQ2BZ6wGiKdNuZP5nUClcAMy0BcrTVu5U?=
 =?iso-8859-1?Q?MfqGU2Yl/l0x/CdWF6VcVflZwVe62oR5EzxwCVD+xiqc+5BcWL6rMvtbba?=
 =?iso-8859-1?Q?dfBpHQYvWhXPSBNgQiGpxaH2NvEyi6QAyjnG5HAT0tya9rJ8ZJzTRML7G3?=
 =?iso-8859-1?Q?rmc0xK/WtwFaH/QjFcGpYqpPKV3ObSM9TuVu+wcZZVs1m+Y4xv8uLRvNIT?=
 =?iso-8859-1?Q?JKFDnGlfFPFU0yUUKy/Aa6rSZSROknNh7YAaeeH515x2H1MqNv+nZrAWDk?=
 =?iso-8859-1?Q?rZ1x5cb9Jy4iO8cEmsi2Ge3xXeZ37LZa/tnOPUiQco4sLvg1agHxEJc0DY?=
 =?iso-8859-1?Q?NyIV6AJObIhyfqKRlhPwDmUbAqeNX62SjkjVzhOcLqowz08wqdRS0NttmC?=
 =?iso-8859-1?Q?h/vfF6YGs55bz/Hl6fTmJCYtqe0OUKaBrtx3/4Iyiua31wfe6mGtk6ajdL?=
 =?iso-8859-1?Q?JAtW7AXvzZqLNrsI+5OpPjTwtf8bMmmJHiaMe/Pt2WWRECbBTegtIshvLH?=
 =?iso-8859-1?Q?4kxFxPyJyNNtzoD+6ioLbZzTF3X23F4OwXqVSmpmwkWn5I/2H38sKCypxY?=
 =?iso-8859-1?Q?N4ht/gBi8Y6nQhEqRPJdeUwYuTPhPe+fhoDl6/?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 377900a7-1cec-4090-da92-08dbc5f6c321
X-MS-Exchange-CrossTenant-AuthSource: BY5PR10MB4196.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Oct 2023 22:59:43.4373
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: ffBd06VssYnk5wk3ngfF4gv9iPpU8dGbOKum4KrkLwnnFswxKduBbns5bs6d/aMkLUWGLPnKbkia2E7jZDCFkg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR10MB5089
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.267,Aquarius:18.0.980,Hydra:6.0.619,FMLib:17.11.176.26
 definitions=2023-10-05_18,2023-10-05_01,2023-05-22_02
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 malwarescore=0
 adultscore=0 suspectscore=0 mlxlogscore=561 bulkscore=0 mlxscore=0
 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2309180000 definitions=main-2310050175
X-Proofpoint-GUID: Gvvf2yWSoW-OQbXmf2XzXbPORZJreCjS
X-Proofpoint-ORIG-GUID: Gvvf2yWSoW-OQbXmf2XzXbPORZJreCjS
X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable
	autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on morse.vger.email
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (morse.vger.email [0.0.0.0]); Thu, 05 Oct 2023 16:09:20 -0700 (PDT)

On 10/05/23 09:23, Rik van Riel wrote:
> On Wed, 2023-10-04 at 20:19 -0700, Mike Kravetz wrote:
> > On 10/03/23 23:25, riel@surriel.com?wrote:
> > > 
> > > @@ -5457,11 +5460,12 @@ void __unmap_hugepage_range_final(struct
> > > mmu_gather *tlb,
> > > ???????????????? * someone else.
> > > ???????????????? */
> > > ????????????????__hugetlb_vma_unlock_write_free(vma);
> > > -???????????????i_mmap_unlock_write(vma->vm_file->f_mapping);
> > > ????????} else {
> > > -???????????????i_mmap_unlock_write(vma->vm_file->f_mapping);
> > > ????????????????hugetlb_vma_unlock_write(vma);
> > > ????????}
> > > +
> > > +???????if (vma->vm_file)
> > > +???????????????i_mmap_unlock_write(vma->vm_file->f_mapping);
> > > ?}
> > 
> > In the case of a mmap(hugetlbfs_file_mmap) error, the per-vma hugetlb
> > lock will not be setup.? The hugetlb_vma_lock/unlock routines do not
> > check for this as they were previously always called after the lock
> > was
> > set up.? So, we can now get:
> 
> Wait, the hugetlb_vma_(un)lock_{read,write} functions do
> have checks for the presence of the lock:
> 
> void hugetlb_vma_lock_read(struct vm_area_struct *vma)
> {
>         if (__vma_shareable_lock(vma)) {
>                 struct hugetlb_vma_lock *vma_lock = vma-
> >vm_private_data;
> 
>                 down_read(&vma_lock->rw_sema);
>         } else if (__vma_private_lock(vma)) {
>                 struct resv_map *resv_map = vma_resv_map(vma);
> 
>                 down_read(&resv_map->rw_sema);
>         }
> }
> 
> Both __vma_shareable_lock and __vma_private_lock check that
> vma->vm_private_data points at something.
> 
> Exactly what corner case am I missing here?
> 
> What leaves vma->vm_private_data pointing at something
> invalid?

You are correct.  The checks in hugetlb_vma_(un)lock_{read,write} functions
should be sufficient.

Here is the corner case that needs to be addressed:

mmap
	hugetlbfs_file_mmap
		hugetlb_reserve_pages {
			!VM_MAYSHARE so
			resv_map = resv_map_alloc();
			set_vma_resv_map(vma, resv_map);
			set_vma_resv_flags(vma, HPAGE_RESV_OWNER);
			...
			some error in hugetlb_reserve_pages,
			goto out_err
			out_error:
			if (vma && is_vma_resv_set(vma, HPAGE_RESV_OWNER))
				kref_put(&resv_map->refs, resv_map_release);
			return false;

Note that we free resv_map but do not clear vm_private_data.  So, at
unmap time we try to use the lock in the freed resv_map.

Leaving the dangling pointer to a freed structure is BAD.  However, no
code accessed the freed structure until this patch.

I would suggest incorporating this into this patch, or even as a stand
alone patch before this series.

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index d25db18c9526..a3ae13d0f8fe 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1171,8 +1171,7 @@ static void set_vma_resv_map(struct vm_area_struct *vma, struct resv_map *map)
 	VM_BUG_ON_VMA(!is_vm_hugetlb_page(vma), vma);
 	VM_BUG_ON_VMA(vma->vm_flags & VM_MAYSHARE, vma);
 
-	set_vma_private_data(vma, (get_vma_private_data(vma) &
-				HPAGE_RESV_MASK) | (unsigned long)map);
+	set_vma_private_data(vma, (unsigned long)map);
 }
 
 static void set_vma_resv_flags(struct vm_area_struct *vma, unsigned long flags)
@@ -6910,8 +6909,10 @@ bool hugetlb_reserve_pages(struct inode *inode,
 		 */
 		if (chg >= 0 && add < 0)
 			region_abort(resv_map, from, to, regions_needed);
-	if (vma && is_vma_resv_set(vma, HPAGE_RESV_OWNER))
+	if (vma && is_vma_resv_set(vma, HPAGE_RESV_OWNER)) {
 		kref_put(&resv_map->refs, resv_map_release);
+		set_vma_resv_map(vma, NULL);
+	}
 	return false;
 }

At one time set_vma_resv_map must have wanted to preserve flags.
However, that is no longer the case so we can remove that code.

Of course, feel free to address some other way if you would like.
 

> > +++ b/mm/hugetlb.c
> > @@ -5503,10 +5503,12 @@ void __unmap_hugepage_range(struct mmu_gather
> > *tlb, struct vm_area_struct *vma,
> > ?void __hugetlb_zap_begin(struct vm_area_struct *vma,
> > ???????????????????????? unsigned long *start, unsigned long *end)
> > ?{
> > +???????if (!vma->vm_file)??????/* hugetlbfs_file_mmap error */
> > +???????????????return;
> > +
> 
> This does not seem quite correct, because the locking is needed to
> avoid the race between MADV_DONTNEED and the page fault path.
> 
> 

Note that vma->vm_file is always set for hugetlb vmas except in the mmap
error case.  The first line of code in hugetlb_fault is:

	mapping = vma->vm_file->f_mapping;

So, bailing out early like this should not be an issue.


> > Another way to resolve would be to fix up the hugetlb_vma_lock/unlock
> > routines
> > to check for and handle a null lock.
> 
> I thought I had that already. 
> 

You did.  My bad!  I saw the NULL deref and jumped to conclusions.

> Does __vma_shareable_lock need to check for !vma->vm_file ?

I do not think there is a need.  It has the check for vma->vm_private_data
which should be sufficient.  We only got in trouble in the !VM_MAYSHARE
case because of the stale/invalid pointer.

However, I do still think we could have that early return in the case of
!vma->vm_file I suggested earlier.  There is no need to take the locks
in this case we will not be calling the hugetlb unmap code.
-- 
Mike Kravetz