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 9AE61E77173 for ; Mon, 9 Dec 2024 02:29:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 004D68D0024; Sun, 8 Dec 2024 21:29:24 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EF4A58D0015; Sun, 8 Dec 2024 21:29:23 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D950A8D0024; Sun, 8 Dec 2024 21:29:23 -0500 (EST) 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 B9F948D0015 for ; Sun, 8 Dec 2024 21:29:23 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 1DD44140987 for ; Mon, 9 Dec 2024 02:29:23 +0000 (UTC) X-FDA: 82873838334.21.D728912 Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176]) by imf19.hostedemail.com (Postfix) with ESMTP id D17B51A0004 for ; Mon, 9 Dec 2024 02:28:59 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=pynv3n4U; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf19.hostedemail.com: domain of bgeffon@google.com designates 209.85.214.176 as permitted sender) smtp.mailfrom=bgeffon@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1733711342; a=rsa-sha256; cv=none; b=MSu+LDOBerEDrVTh0K7fidMrBx8hc/EYfokbmfX2tt/HN4/OZdogGnfKD8HLFAjpKYuIJI kAvk2vAJhXuPKOMXaiFsAe176Dv+7bWgxiTsMt9BvTqGH0l14D5pXvlWDKwoADo35ukbGB TMznxLiXy69U79KpgBWuKecgxzgyIOw= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=pynv3n4U; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf19.hostedemail.com: domain of bgeffon@google.com designates 209.85.214.176 as permitted sender) smtp.mailfrom=bgeffon@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1733711342; 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=ka9+j8P1UyfdFOngKJs0khOivaTg1zLeITHqI6Ru1tI=; b=S6xgTbWY2S8EmURQHIHaeiGXM0MTM6QNFrZK7K7MOJGbrm4mS2gLYgKPyGrUxigKtiY/Y8 k9hv4JnSCw2BCCX8vDjnXSnZpsUCr6QNi0FvwvD69m65j2BcGs2td/LXcwJrOWxY3cMe8p dndjL+s1JGj4730d4ofvNIAnzr33UPY= Received: by mail-pl1-f176.google.com with SMTP id d9443c01a7336-215740b7fb8so127275ad.0 for ; Sun, 08 Dec 2024 18:29:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1733711360; x=1734316160; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ka9+j8P1UyfdFOngKJs0khOivaTg1zLeITHqI6Ru1tI=; b=pynv3n4UvvQmIDdxK/+PdhfKWKOAWRoXRc3dyOwCGxECy3w9o93d/KlCPhU3OrldKa Ip3bcQ0jaKCD+pxL7d5joxRUKYuqXuLRqOImo44drQjPLQ2WKaNDwXotBG+5ehJRcLrq g0QK+YkamufEvmwbT671Lzt2WauVd0NhZ8ZqEtAyKFMCc33jcsfFaEJbuBPdSL46WnGP G0gKOiDJzd9C9kTliDJO0/4rXHtAmOdTsgq8Rwf+0+8tkp0YDZMT9UwzkDang8HFmeGB vfBzZHtK8+lRCqVdOKL+27ZXUSlduZWCNjAjnC4GUWYgsF40psdJMBdtKJ81lTQkqkG0 9gnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733711360; x=1734316160; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ka9+j8P1UyfdFOngKJs0khOivaTg1zLeITHqI6Ru1tI=; b=APFS1wTNHqBYmue99UhClhHpV38OXXcBdbbubkD0grUNrrN09/VTnaM49M5Gi28CtQ /eHgKysN6dOazTz8pNWnsxwOIt3tpN3nMy6neV/WNx+oEtdFxQy720JPSVt2cYgiP70w uk4AqRoF9X563PH4dHMFVT6jjdpYSENAC+vlHUp+1EIpTTOJWGGDX/UP0R43qF0Xf6lV JCSgTzB7ig0fWDen6RjWQ+ZfkUmyQaeaXJc3I0E2HL6zDJgHH+IZU4wwoXeuaoXF3uHU w5+osjdqPh9TPxeOy+z2pbAPTUtRCl/V/tkhjFYd5IN3Zk1aa+TAiR/51CklJblje7VP C3cg== X-Forwarded-Encrypted: i=1; AJvYcCXzMBidM3q+2xKv/+Qn9y+iDsqT47TY5YWihjTV/k7UAIrVaqxNXDaqfv41Ar9Jc/g2iY5Z2RTQrA==@kvack.org X-Gm-Message-State: AOJu0Yxu+SuNfPXuMX4ttR2N0lZPkQKzsrgG9VqKF1y9mLnLZd1WbDYf kW2kJjdRON/iBFqxzp+k6NGMdzcGS6An1WVFZvAwOzveD1MymHuneRlv/MaMLt0FnyykV2r7yli SJdEQ4ky7OroniXHYsjxQToi74O510WVcfs1s X-Gm-Gg: ASbGncutFNMH6CClew6dju+7w1UE00LEhb6aWdVNfUvAVVFox6A/CxNfWqJRzZR/Fnv fy8Q5khXNagHNzzq3/4e3UXiIeINX6XI= X-Google-Smtp-Source: AGHT+IH1tl+NeR9OKA53arvCmHwV/ON+NaNlZw58Bl3GW7p5kZDh1MVGbMUuFDtmVn12tDIvOHNo3XiUvQQrZxbb9pc= X-Received: by 2002:a17:902:f611:b0:215:9327:5aed with SMTP id d9443c01a7336-2162a9d6029mr2697315ad.20.1733711359668; Sun, 08 Dec 2024 18:29:19 -0800 (PST) MIME-Version: 1.0 References: <20241206152032.1222067-1-bgeffon@google.com> <04b1f6c2-32be-4bc0-af0a-919c9c1ee33f@lucifer.local> In-Reply-To: <04b1f6c2-32be-4bc0-af0a-919c9c1ee33f@lucifer.local> From: Brian Geffon Date: Sun, 8 Dec 2024 18:28:40 -0800 Message-ID: Subject: Re: [PATCH 0/2] mremap: Fix newaddr hint with MREMAP_DONTUNMAP To: Lorenzo Stoakes Cc: Jann Horn , "Liam R. Howlett" , Vlastimil Babka , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Marco Vanotti Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: 64p4wnaybrxcosh4rhmpnzd11s8ogjw8 X-Rspam-User: X-Rspamd-Queue-Id: D17B51A0004 X-Rspamd-Server: rspam08 X-HE-Tag: 1733711339-666178 X-HE-Meta: U2FsdGVkX19fS3xwfzXbhsfehntm5kVLHdgfncBypYO1Py4JxQt7a6a2i4N0EP6X9t6hAoGYTTvyXXGieAeXU1iitYCE963URH3kg7Fr8l9cWrJgWvk18pjyeEHKwRogdc8IaRgnOl2qE2Avaezp3yYnpNuLtOLL3G6flegGKgtKlZQ3TK/+XWxTHPXiUhx//eiIH3en3R4z4UZpqvUhE49rE3RFq+32gsK7kY5ku0FCnVCeA2g2NtV/sxoVIdNB7dStoiNmwc1hIiirsaH4PrUY2346TTuE2PNTu5Grc/irH/4m92+kfcPgD1mQ1dMTQryda6fzr0V968FThU9woS7jISpQUXkZLIua5/OzN8QydSYGSt+D1exf0+su12kD6edXZtVNuj2vv45v4bj9CkBF7SNSidk7WM2pSsdG0tKWCh2g9jDg/V0CsKRSwcdJQRDeonjo0jJeLtKuyeX8eBFtMebls/qOyXBSLjBt7XsAd2mOTnF6B2hIzkEIE6/2T3jkah777CuICdZEsKi+UKmusd98Aj6fUlOrKRGcw97JPo8E2DvhXonq+XczzEdNbqeXS9v32hgPzkJnbapxk2uK1BguFEsBvsZY2pc9AWkT14gAFfMn8muuoSBAy1yBYh9h2KvCUJl0BwtiKpYQ6zEjxDq6y/qVI+bN38BFZTU+u7lG74W+TFAlTmsVe6WLzU4v2Rq6jxT50n8+WtQ3YpJD0yjWiqQ/xS200iC6CV3yaOuPEV1SQ/Uh6DejFJTZ0OfFsg6CABDRGhTwTwq91+86D+gfpjoRTwtcQeiR/TKeIIr946jf832a+zEbpbNV/45kdQa9hratsMwy8mfRijDlzgNlv9ENX+NCCJv8njY64iMqvHRbX8V2rrondl4Doxv4VxqrVUl6zfTdLuvqmWNG+z6FsUB60ge49sfEX94vDwf50yeWUV5jdtIZbk/uUFhrP+Z9HxGs+ys8Nvw FDQuo6cp h/L5WnZ3p+vwi7+M6GjqKqomdBWmXkZcAS3K8ejebvpz4niisKf+IbFVgOYHn6dyYQKQZa6EXftLEpybv9CYmoLWA8U/AIfbo2RCtIv1HPVnwW+on/kB/EO8271+m32g30oVpvpl5Oirt89jUHwYYWRD1jog2AAj2GNatz3YVgeIcKK+JkqHd35rPw+M2aDn1ZyvPJT+t8fcSqhCNXfDLH6Ws9RfD8z2CPjzy8rztbPLa+3f27NxoVAkHUoLYF4vIIU1N1XJTT7f16Mtfsr24Cd9U3QfKj7KU4npFmHofFuMQooWsnKcFqrIBWIx78hjRRa4wqnXpKhK4z4AI/c+Zb/I5gjgflZjqP8BcaLre3LmV/2TGAlG5D23rMg== X-Bogosity: Unsure, tests=bogofilter, spamicity=0.458955, 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 Fri, Dec 6, 2024 at 10:52=E2=80=AFAM Lorenzo Stoakes wrote: > > On Fri, Dec 06, 2024 at 07:42:51PM +0100, Jann Horn wrote: > > +mmap maintainers (maybe mm/mremap.c should be added to the file > > pattern for "MEMORY MAPPING" in "MAINTAINERS"? I'm not sure) > > Yeah I think it's actually right to group together _all_ VMA-related oper= ations > under the VMA entry, because we have interaction between them all mprotec= t, > mlock, etc. etc. etc. > > I will send a patch in a second for this, because we do keep getting bitt= en by > this. > > > > > On Fri, Dec 6, 2024 at 4:20=E2=80=AFPM Brian Geffon wrote: > > > mmap(2) allows for a destination address to be specified without > > > MAP_FIXED and in this situation it's a hint to get_unmapped_area(). > > > This address need not be page aligned because get_unmapped_area() wil= l > > > align the hint. > > > > > > In the case of mremap(2) with MREMAP_DONTUNMAP it shares a code path > > > with MREMAP_FIXED in mremap_to(), which means this function can be > > > called in 3 different scenarios: MREMAP_FIXED only, MREMAP_DONTUNMAP > > > only, or MREMAP_FIXED | MREMAP_DONTUNMAP. In the second case when onl= y > > > MREMAP_DONTUNMAP is specified we don't need to do alignment or size > > > checks on newaddr because they will be passed to get_unmapped_area() = and > > > dealt with appropriately. > > > > > > This patch corrects that behavior to match what non-MREMAP_DONTUNMAP > > > mremap(2) and mmap(2) do. This odd behavioral difference was reported= by > > > Marco Vanotti. Additionally, I've included a self test to validate th= is > > > behavior. > > Yeah if this is user-facing - I don't think we can change this. Can we do= any v2 > as an RFC for now until we can get a chance to look at this? And please c= c- the > VMA/mmap maintainers on future revisions (sorry this wasn't at all clear,= we > need to update MAINTAINERS here). Sure, I'll mail the next series as an RFC in the next few days. This behavior was not introduced intentionally. > > Thanks! > > > > > Marco pointed me to this; I had no idea mremap() had this undocumented > > behavior where it takes a hint address. The mremap() manpage is > > currently wrong about this, it sort of implies that the new_address > > argument is only used if MREMAP_FIXED is set. > > > > Marco also noticed that upstream glibc now assumes this behavior: > > https://sourceware.org/git/?p=3Dglibc.git;a=3Dcommit;h=3D6c40cb0e9f893d= 49dc7caee580a055de53562206 > > > > Debian also has a test that explicitly checks for this behavior: > > https://sources.debian.org/src/glibc/2.40-4/debian/patches/git-updates.= diff/?hl=3D22820#L22818 > > > > I guess it's too late to remove that behavior at this point, and the > > right thing to do is to update the manpage? > > Yeah, if user-facing we can't fundamentally change behaviour even if it's > strange I'd say. Definitely, no matter what happens we'll need a man page update. I think to make things consistent we'll probably want to consider allowing all variants of mremap(2) (without MREMAP_FIXED) to use newaddr as a hint, like mmap(2). But I'll mail the RFC with much more detail in the cover letter about the history and impact. Brian