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 E8959C02192 for ; Wed, 5 Feb 2025 13:05:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 78B9E280005; Wed, 5 Feb 2025 08:05:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7136B280004; Wed, 5 Feb 2025 08:05:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 53E6A6B0098; Wed, 5 Feb 2025 08:05:16 -0500 (EST) 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 2B9866B0095 for ; Wed, 5 Feb 2025 08:05:16 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id BFA19140C8B for ; Wed, 5 Feb 2025 13:05:08 +0000 (UTC) X-FDA: 83085911496.17.B27C9F4 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf15.hostedemail.com (Postfix) with ESMTP id 763C2A000C for ; Wed, 5 Feb 2025 13:05:06 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b="HdJY9t/X"; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b="/5HMX24D"; dkim=pass header.d=suse.de header.s=susede2_rsa header.b="HdJY9t/X"; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b="/5HMX24D"; spf=pass (imf15.hostedemail.com: domain of osalvador@suse.de designates 195.135.223.130 as permitted sender) smtp.mailfrom=osalvador@suse.de; dmarc=pass (policy=none) header.from=suse.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738760706; 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=T1hxKKTF2Tkd7wwVqx/X9ElblRcEFK/OJz6T2RxwZI8=; b=zE9cLDFL+k8VTOlBzdN0nlbP6/zTVzJu57iPK4LD4mIk32DQJywRfE8KbUerx8BNjuGgZK VcDWHPXmd1iHmHC+U/gqTErqpr8I66wxcQuq/xs+9pzGNuLJiSFFKhKtje47Y2eBbnrWIg yyRr4awEKAAOa76GZGN6BCAqykTRx5M= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b="HdJY9t/X"; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b="/5HMX24D"; dkim=pass header.d=suse.de header.s=susede2_rsa header.b="HdJY9t/X"; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b="/5HMX24D"; spf=pass (imf15.hostedemail.com: domain of osalvador@suse.de designates 195.135.223.130 as permitted sender) smtp.mailfrom=osalvador@suse.de; dmarc=pass (policy=none) header.from=suse.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738760706; a=rsa-sha256; cv=none; b=b6yAY4VLHmXvAYHMQ/4kWp1GozTvOPE6qwQ///pDOVLmGtEPT8Ht7ahuM/BxleAxDCSt5V kTG5aJpX6i3DdGjcE2NdEGoXJuN3RfAqFkoIjMRGbpSS+CEEkcDaEbRr9xMGQ8gt5t1KYR hOiXsYKje/leQIs4vlcoZUtslGDp0AI= Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id A79D02122A; Wed, 5 Feb 2025 13:05:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1738760704; h=from:from:reply-to: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=T1hxKKTF2Tkd7wwVqx/X9ElblRcEFK/OJz6T2RxwZI8=; b=HdJY9t/XmEGE5vxCf96Fi2/lPyzryQnWahjdjSMpka9Kvk7ZPd84qQDgkL1wOimqFC6+UX rXLz/WfePss+b3KaRIv0VEc6Zl0s/fSM/yUOULi7Ye5IGTvs+X83Bul8IOHgTA2HgpBZF4 OWKeKTehLkEr0ufbsbHFYrL/WgoWzWU= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1738760704; h=from:from:reply-to: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=T1hxKKTF2Tkd7wwVqx/X9ElblRcEFK/OJz6T2RxwZI8=; b=/5HMX24DVRsNeFjzfJfdW4VsGp99IwnIl1AqrUMbi8nfNLpv6ibRywwcB1coqZR8jkltNC VYU6Ym+CPA7FMSBQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1738760704; h=from:from:reply-to: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=T1hxKKTF2Tkd7wwVqx/X9ElblRcEFK/OJz6T2RxwZI8=; b=HdJY9t/XmEGE5vxCf96Fi2/lPyzryQnWahjdjSMpka9Kvk7ZPd84qQDgkL1wOimqFC6+UX rXLz/WfePss+b3KaRIv0VEc6Zl0s/fSM/yUOULi7Ye5IGTvs+X83Bul8IOHgTA2HgpBZF4 OWKeKTehLkEr0ufbsbHFYrL/WgoWzWU= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1738760704; h=from:from:reply-to: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=T1hxKKTF2Tkd7wwVqx/X9ElblRcEFK/OJz6T2RxwZI8=; b=/5HMX24DVRsNeFjzfJfdW4VsGp99IwnIl1AqrUMbi8nfNLpv6ibRywwcB1coqZR8jkltNC VYU6Ym+CPA7FMSBQ== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 2CD72139D8; Wed, 5 Feb 2025 13:05:04 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id cD6bBwBio2etcgAAD6G6ig (envelope-from ); Wed, 05 Feb 2025 13:05:04 +0000 Date: Wed, 5 Feb 2025 14:05:02 +0100 From: Oscar Salvador To: Ricardo =?iso-8859-1?Q?Ca=F1uelo?= Navarro Cc: akpm@linux-foundation.org, riel@surriel.com, linux-mm@kvack.org, stable@vger.kernel.org, kernel-dev@igalia.com, revest@google.com Subject: Re: [PATCH v2] mm,madvise,hugetlb: check for 0-length range after end address adjustment Message-ID: References: <20250203075206.1452208-1-rcn@igalia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20250203075206.1452208-1-rcn@igalia.com> X-Rspamd-Action: no action X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 763C2A000C X-Stat-Signature: o57rkb85fmfasnbbp4qyzhoimkriqeg5 X-HE-Tag: 1738760706-100776 X-HE-Meta: U2FsdGVkX1/iSZwlK6I0lDWQp3SOJP19rGdGgEni8O1pKClnhflF8PPZlmLZxjobWDvOZ77+i8UMn1OlG3pwQWUn6wCi1rjZczxxivGWGJ8K06ugCJT+o9+hA8oSp2X07+qKW2SigGP2TKtB+b3/ttDx0yuS35kJ4sICiQnU0XtGLQZZV/q9iFaHq3LkEXF5KmMUz4lxlSZIX+IFPuYLU21khIYfTMN3uN5lHQKOQsh+MhTdbgY+SR+t62Ld10jyJF0ohCWvz3SOg/KCmhmmT2WSPNIrqlo1ubpLDss0ZUcsaRQOtjPa7nhGYitIUlcIly22nu6Sbq4MmQ+PVmQFInuaJlsbuZZZx/wdAXKLhjAYep3bVD/47accGx42HPQgYJo9Wt8n36RlIkj7MkGJ+MfZJNPyQquZ9vcihT9Yjm/a9UXF9zGMq3DqgCCWKA/L4tYSXGD/vZareUqBkBS0bPVAoHB0aQgE3eErjlWHYHrbsmUvgFiLGQ7bQXi8X1Xu2tI4/hc6UfeqYIa8N9haG4toJuKslpx7d91GVSTZ+0OEcWX0S9PURyUYpn1OApk7zHDfGEyBWFj86VIVXdJpjzXcnPvSpgL1AD0WxeCS1jAd9XKpCdf/Wjsb+g2JYY21lh1xAb6m06JF/iCZgDg7zeGvz8yhP1euAy9dGMIKaVHZqwYRgaZJ3hD0D7e/pm5P5xxIbmrBaJnEcVhXFUkZQd+cozWK5Cx++yj3E8dmSQtAY15RFfQNXcBIcdu2d5PYbp7hjfa2v9aQDkq45uWLDOM+fuV7u1caDOBhU0qLH/TbRZk5DXUxv41ACQ9vBeUEzKR2oUPwGkPV+awXVVOcxY8TF7bICSvjeDrXwhwHWT/At5ugY2nTm3a+6/apyB7VNmbkGlVfhMjYduYyx3wJLPATw6UD6PMH8HC9i92Q7hMFg5zcu23Keh9UxGHaCnzv5I0+CTsmmk54LlQMwsH kZh3a6pY 7OnXliogka6q0SHMKlDaoS0889lomhf3a3PvGeYTdIS2s7onhZaZQ3RBM11Eyez3dim3DDTYQdTbdlUOJanOLFCd9/N5/Ny02BLdNMa0uMrXkXdx6ZEWdPKC2xb0J8sh83uS78YeC7sdnKxvQcxku4oS6u/YIx7rOGIRC8LPIGSQxFrM+pOKHE12dKo5dYssPtgNBAgAozMvopndVijVlUymqJjZq4i+mtk2f7IZaq2F6RfNwR8wz2MTwlAmjhnJtD9AfLsk0Y61XHVxme/0UvHEw7ngO7GAmqF+gZDsTg4bnx9VFP2f5z9aHgbs32HymNDIQs3eMqKpAqnpfzMMQ/rPc7UwdLt+0tXhl4v6K32/rZTG3be2QnXwlBw== 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 Mon, Feb 03, 2025 at 08:52:06AM +0100, Ricardo Cañuelo Navarro wrote: > Add a sanity check to madvise_dontneed_free() to address a corner case > in madvise where a race condition causes the current vma being processed > to be backed by a different page size. > > During a madvise(MADV_DONTNEED) call on a memory region registered with > a userfaultfd, there's a period of time where the process mm lock is > temporarily released in order to send a UFFD_EVENT_REMOVE and let > userspace handle the event. During this time, the vma covering the > current address range may change due to an explicit mmap done > concurrently by another thread. > > If, after that change, the memory region, which was originally backed by > 4KB pages, is now backed by hugepages, the end address is rounded down > to a hugepage boundary to avoid data loss (see "Fixes" below). This > rounding may cause the end address to be truncated to the same address > as the start. > > Make this corner case follow the same semantics as in other similar > cases where the requested region has zero length (ie. return 0). > > This will make madvise_walk_vmas() continue to the next vma in the > range (this time holding the process mm lock) which, due to the prev > pointer becoming stale because of the vma change, will be the same > hugepage-backed vma that was just checked before. The next time > madvise_dontneed_free() runs for this vma, if the start address isn't > aligned to a hugepage boundary, it'll return -EINVAL, which is also in > line with the madvise api. > > From userspace perspective, madvise() will return EINVAL because the > start address isn't aligned according to the new vma alignment > requirements (hugepage), even though it was correctly page-aligned when > the call was issued. > > Fixes: 8ebe0a5eaaeb ("mm,madvise,hugetlb: fix unexpected data loss with MADV_DONTNEED on hugetlbfs") > Cc: stable@vger.kernel.org > Signed-off-by: Ricardo Cañuelo Navarro Reviewed-by: Oscar Salvador > --- > Changes in v2: > - Added documentation in the code to tell the user how this situation > can happen. (Andrew) > --- > mm/madvise.c | 11 ++++++++++- > 1 file changed, 10 insertions(+), 1 deletion(-) > > diff --git a/mm/madvise.c b/mm/madvise.c > index 49f3a75046f6..08b207f8e61e 100644 > --- a/mm/madvise.c > +++ b/mm/madvise.c > @@ -933,7 +933,16 @@ static long madvise_dontneed_free(struct vm_area_struct *vma, > */ > end = vma->vm_end; > } > - VM_WARN_ON(start >= end); > + /* > + * If the memory region between start and end was > + * originally backed by 4kB pages and then remapped to > + * be backed by hugepages while mmap_lock was dropped, > + * the adjustment for hugetlb vma above may have rounded > + * end down to the start address. > + */ > + if (start == end) > + return 0; > + VM_WARN_ON(start > end); The change itself looks fine to me, although I am wondering whether it would make more sense to place the check right after the call to madvise_dontneed_free_valid_vma(). It looks kind of more logical to me, but not a big deal. -- Oscar Salvador SUSE Labs