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 7E64EC3A59D for ; Fri, 21 Oct 2022 20:48:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 072C08E0003; Fri, 21 Oct 2022 16:48:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F3DCB8E0001; Fri, 21 Oct 2022 16:48:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DDEF28E0003; Fri, 21 Oct 2022 16:48:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id D00A48E0001 for ; Fri, 21 Oct 2022 16:48:41 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 173EB140352 for ; Fri, 21 Oct 2022 20:48:41 +0000 (UTC) X-FDA: 80046145242.26.8AD3D8E Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf02.hostedemail.com (Postfix) with ESMTP id 8488480003 for ; Fri, 21 Oct 2022 20:48:40 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id B6250B82A2F; Fri, 21 Oct 2022 20:48:38 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 326A3C433C1; Fri, 21 Oct 2022 20:48:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1666385317; bh=BmGPpt6ZZmS6tEKeRWOGR6TymKZu3px6XDlXoOZvO54=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=NLkzSlyPq+qlpzvyyt31uOBvLLNUIb7e79iWRR07Td0MCWazlH4tj+gL9ryGgMhnR QD+VJXjR9P7dhlnDE3uch/jDCamvlp+sosNWsc3v6sdfS8ciwz87zSqWyGGAH0JvBq i2VvfVrBK5AxyroSqECfQRmMXkBblqz8a04EtdJE= Date: Fri, 21 Oct 2022 13:48:36 -0700 From: Andrew Morton To: Rik van Riel Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, kernel-team@meta.com, Mike Kravetz , David Hildenbrand Subject: Re: [PATCH] mm,madvise,hugetlb: fix unexpected data loss with MADV_DONTNEED on hugetlbfs Message-Id: <20221021134836.1fe0e8c8310eb247ce7acafb@linux-foundation.org> In-Reply-To: <20221021154546.57df96db@imladris.surriel.com> References: <20221021154546.57df96db@imladris.surriel.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1666385320; 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=vSUYSsVVs69MXg4Zail5fN9LKVMtwxPEFEZAyniXFvw=; b=6JNYns0gIs3eMi+7Yg62PsKvM4UIdFvzxTjuQva1Ds5PjH/5X/0KZ3Pyqf6+1bIvTB9XD0 FFz+CPCjkIlOpCSXHmU30gicDdYRPvyGVlXN1BcyTsTEMaxOzXyO0yNvY8Qc++TU0vAefg qeRCyvcweRBm2a/og4apViBStCRkyrY= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=NLkzSlyP; spf=pass (imf02.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1666385320; a=rsa-sha256; cv=none; b=W1cKsJ2qMefjlOCvN/yXkh74YWW9TdaBi+xiLCPusp2rNoIbVskLUcOqiJfb0odzkFaLxB dnGwSbVNWR3kr8SU+/aXUhIUozVhtOiLTBABHtLgowITGFXMWG3d4Kb8lgDA3aVwaW4grM oXa/mRXEEt68LFuLiV7bSvQWpu1sa0s= X-Stat-Signature: 8gi6ztabiw14kujox6dzeyfte1efb48f X-Rspam-User: Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=NLkzSlyP; spf=pass (imf02.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 8488480003 X-HE-Tag: 1666385320-749139 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: On Fri, 21 Oct 2022 15:45:46 -0400 Rik van Riel wrote: > A common use case for hugetlbfs is for the application to create > memory pools backed by huge pages, which then get handed over to > some malloc library (eg. jemalloc) for further management. > > That malloc library may be doing MADV_DONTNEED calls on memory > that is no longer needed, expecting those calls to happen on > PAGE_SIZE boundaries. > > However, currently the MADV_DONTNEED code rounds up any such > requests to HPAGE_PMD_SIZE boundaries. Well that's obnoxious. > This leads to undesired > outcomes when jemalloc expects a 4kB MADV_DONTNEED, but 2MB of > memory get zeroed out, instead. > > Use of pre-built shared libraries means that user code does not > always know the page size of every memory arena in use. > > Avoid unexpected data loss with MADV_DONTNEED by rounding up > only to PAGE_SIZE (in do_madvise), and rounding down to huge > page granularity. > > That way programs will only get as much memory zeroed out as > they requested. If we merge this, we're inviting people to develop and test code on the 6.2 kernel only to ship it and then find that it misbehaves on 6.1 and earlier. So I think we should backport this. > While we're here, refactor madvise_dontneed_free_valid_vma > a little so mlocked hugetlb VMAs need MADV_DONTNEED_LOCKED. And if we do backport it, "while we're here" changes are unwelcome!