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 DFCB8C83F1B for ; Mon, 14 Jul 2025 14:37:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7EA7B8D000B; Mon, 14 Jul 2025 10:37:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 79AB48D0001; Mon, 14 Jul 2025 10:37:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 689D48D000B; Mon, 14 Jul 2025 10:37:38 -0400 (EDT) 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 565398D0001 for ; Mon, 14 Jul 2025 10:37:38 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 28A92B6D9F for ; Mon, 14 Jul 2025 14:37:38 +0000 (UTC) X-FDA: 83663123796.14.B4B4CBA Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf27.hostedemail.com (Postfix) with ESMTP id B80D540012 for ; Mon, 14 Jul 2025 14:37:35 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=C7SeytB4; spf=pass (imf27.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=quarantine) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752503855; 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=5g+pcFOcxgDZoR5yPrN9tuAezacA6xxzq/+I6doDGUU=; b=vkaTZZoaxn3ecB7F72LVjHyRo24s94/jXqPG3ZnYHtK6GZfucvsVUuu+d2hj29A9gfIvKZ G/D9oUYcI34Q5g7/16KFA6dvUN1Ow56XvM4mKcgISGDMJhnH+LTpzkitJwlII+dQdy6tTL D+sZKOMzusch9eXDA9mWiOUCNFefEMA= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=C7SeytB4; spf=pass (imf27.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=quarantine) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752503855; a=rsa-sha256; cv=none; b=hYRFsI/WX4tFh3xVgpvajtnkeJp/eJWZmUrhCzVMSsik6rlwx5B19+OWVamtbcanwNdecB Rm0qXnd03TwdBoDXiZoVdSbLzVkYrmwNSPkpmsH0CJtys4ALVAXNMfSs8ARJMSNdAAsdaB uyLARigxWtaIp3J4LYnWGIceM7fiXoY= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1752503855; h=from:from: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; bh=5g+pcFOcxgDZoR5yPrN9tuAezacA6xxzq/+I6doDGUU=; b=C7SeytB489MR4vF+Dwf2LWWThSYqBB94uG/S4l3eGznlp41r7Zff1u4EjdVgtBT6mSaMpD yQA3I45fOJIGRgYTEIl14qS6fef0xmh/0p0mYGseb5NVrPmPRPLQe/JDDuTiS1uI9WH+EB k+ZBhbjZcN3GB8onijT7YK6XMRoP/gE= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-490-530MB7cjMvSceVAbcImAEw-1; Mon, 14 Jul 2025 10:37:34 -0400 X-MC-Unique: 530MB7cjMvSceVAbcImAEw-1 X-Mimecast-MFC-AGG-ID: 530MB7cjMvSceVAbcImAEw_1752503853 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-451d3f03b74so25246575e9.3 for ; Mon, 14 Jul 2025 07:37:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752503853; x=1753108653; h=content-transfer-encoding:in-reply-to:organization:content-language :from:references:cc:to:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=5g+pcFOcxgDZoR5yPrN9tuAezacA6xxzq/+I6doDGUU=; b=gVxbGVj1mZQxA5Lf+pDbbqXzaS2kpJt8SKWg/5ZKRQU1J2SCCSxL1eMilkadK6wqj8 9OX08QUO0PUldzMTSkScMrvS4ixbCwIh+srP0WSfqfyrLoGp5WxUQATDEYOZMdU+jVhl LYTIlXS29Te0YENC5eorZETZ+oaKYoWMt9Kv2ZUgSeeoKY1/YDze6lhUGRZx4eapHB08 oyAYWWl/9n5buQOqXUquZM9KW26caCG41oBebDH7oYRsX1nDbj6z7b1bisbs8K/+2cSM O/IwEpcyXSRxr1tCgaxYY4s+eJGcvXdDGX2enz1toWq4zXh/J9i8q5fQYnKCMyIx3EdQ GM/Q== X-Forwarded-Encrypted: i=1; AJvYcCWN31L1n6f9cbcrUwOOmhu3eavRu+/8UbR2N0MhR6slpG9UmaDnRz8lXxc/zPHzf9dtmfzyRZuAaQ==@kvack.org X-Gm-Message-State: AOJu0YzVc8f+872nclyRVSNwU9w5BdrCA5BwGJYye/UsrDiZQeIEjioq vGm+3X/LFeRWXqOO47jhwiTYR9BL5p+DCniyaHTNC0AmU1dfnF9cBKoiiAa0im/1nSenREkXNAL yltr1oONCp/iGm8JCKMP1hSXZsdzoqMwq/H7Jhp3ahPtPRm+w5pXr X-Gm-Gg: ASbGncudsqm22cRNQUAR7G8yNL2B6KAsLx/vm+F+QUbSuyisInggl1BAevM+W9QcpQv GfzbgiWu+f67UNfpI+fwuNIdZCAo3m1gVApYvr/Aqbe1LTUnknnDCUTrik3n0ybw6pAMuAyfmrP VGj9RaMjqEsZ0tCW4hq5BIu8UUBUTO/3mLxJAAv3UxEvmlkI58bZGvYTP/+azf+cjW9SRodEWFF fwHj5I3TRM7SBXkYVF890HQoSXGpOSzsAE7hqjRzKAuRG6tIIPB8Cv+EGz2iR8c1OVwJQW78UE1 uV0w8VyTT6FjBLfUNW/77KZNXSX2QqnFBQGuSPXaiRVzDcJfm9+fyRz/CsMT292z27163WpA9vo 71q5gT4PRqDnkYLx19SmAh0Q5liiDu09CUpmlGh/EqrE6/6RB56j56CrffXE6JjKO X-Received: by 2002:a05:600c:1c9a:b0:456:1608:c807 with SMTP id 5b1f17b1804b1-4561608ca40mr47116465e9.26.1752503852582; Mon, 14 Jul 2025 07:37:32 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFTvnEcDMapbCXWP3qDegKpdCdyuaTjkUqgqccpswwEq+6DQh1O4IMK7Ozrf7oErXapdbaEbg== X-Received: by 2002:a05:600c:1c9a:b0:456:1608:c807 with SMTP id 5b1f17b1804b1-4561608ca40mr47116125e9.26.1752503852095; Mon, 14 Jul 2025 07:37:32 -0700 (PDT) Received: from ?IPV6:2003:d8:2f38:ca00:ca3a:83da:653e:234? (p200300d82f38ca00ca3a83da653e0234.dip0.t-ipconnect.de. [2003:d8:2f38:ca00:ca3a:83da:653e:234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-454d5103c2asm171298475e9.33.2025.07.14.07.37.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Jul 2025 07:37:31 -0700 (PDT) Message-ID: <5e21df9f-7f75-412b-a173-fe6da49952e5@redhat.com> Date: Mon, 14 Jul 2025 16:37:30 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/5] mm/mseal: move madvise() logic to mm/madvise.c To: Lorenzo Stoakes , Andrew Morton Cc: "Liam R . Howlett" , Vlastimil Babka , Jann Horn , Pedro Falcato , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Jeff Xu References: <5d932ec1f9d0ea115aac65067e4cb8241a06e791.1752497324.git.lorenzo.stoakes@oracle.com> From: David Hildenbrand Organization: Red Hat In-Reply-To: <5d932ec1f9d0ea115aac65067e4cb8241a06e791.1752497324.git.lorenzo.stoakes@oracle.com> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: s3QXyKzFPKuYrFmohlPTBS2YHQo53zk7IsDbUPoh-T0_1752503853 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Stat-Signature: kxdty8m4gsj9kyspm6ce6myyy7pwgzg1 X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: B80D540012 X-Rspam-User: X-HE-Tag: 1752503855-918928 X-HE-Meta: U2FsdGVkX18upBj4OLTb8nJyn31Qp/PUcsve11wAFRKhBtC7J5ucW05UwcfbJEiZwbngWHqeFES+Q8XC8guSRxxU8/0L66g+fB0kkwtKKBRZY1UMc3cm3vdERA6cZ2gqqDD6PbOofOrUNqOrxshB5ZRf6loLrnLBCa8oVYuYbdh42mZpwuQPRyoV8QqYExQr13orovDHAeoUgUGaKp4xL8jg85HQACACeBbZ7yqEG9X+CH4n5OGlYK0qPqhrx+vr+SqL7G0uUkcEqhDDEOEc/g1IupbLPOXeyUcI0juJBT35x5WiPzx0CYVa/ISuu6XnUQkXRFt4DokbKavSkx3N4DmMrvm+9YhthQbAehSPU8xzb4mvckswhQ1zMOPck3ZWNXcyCmgs5QbTzrN9HaikwEgaMWU2hBJEHH2Q6qXG4jjV5Y9SYGRv8K6XlxHrfaegMe1yat8Q7LmcWoNItD/Dw7cXrQf6FL48MTLyx6hGHLus6TZQIGURteU5VUzmzENgrAAye7djrxcMfBfSjZHNzjhuef6m7XMalnf+Ea9EmZHbwndxMkvb06tv4GCelNW5+IyK+bqqrEcBilg9oxPK3p9+IlXZuOJcc8wk2qhMpkOUrUqsTKKqJncGI+DyXnnGAWrXWpx5Hb5nl6zdUJy00yAVkadLNHaFkfUByW/DwLMheT2pW2G8kihXfnzg4y35qrq0ZWok/qNt8RCTQtJZWwKxKKpf9ZDqyof36YnanQ3RIYBA8t9xmKT5C2nm87biTSWbS+rrD3MHm7Gf5NkPbcMeVhjsN1eBHpINxhkjbFDneXUnxZbqlrOjTefcmeRsh4Ty/TEe1XDYygxArAhD9MMYB1vIHoScTK9Y33gnq6g8a9bHOYmVUoyiZdt0fVROAtKnx83Q8PbfiHTbv06xtUHrmn2FG7tU35ftNjXSH5WAgfzQR35w/ky12qxuK8nYPu1zWZdTd6nwzF2LICU FjIlX1Ak e2AK2mSrKD6cOlYijobzJPO39BGBt2ilruvlDjPsA3M9PCxTAsHeowghVINWdmlc63Rq3lERJAeQtDhMvSeRN5/mJnpLS/W0u/MsDYr6LC2wEohCRz55PFZxXWbqmi3f+094sDkKPQfrNvq5ClSd+Hy3LeWiao4Q8lxdfbAmKhfa72gj8FOCsUN4DKheh0cQX0SW7F7c0c3SnE2BebmzNJBwc58fttnv8u+hG1Ba3rt5aUyowo6xFqPOH530p+vhSPi07uIEdKnOw/dREiiMUEcz6EznNDT2ax5c9K5oR7pRcHHOHCyCXqdjXoGKMqkIsxswk167UNtm/lauWLPcsWUC/eo8hsGKbEGcNibaovHgYEEF6VYmyqLV71LrqNwWOsqm+TX/WIpF8PQ7TE9ZMCSi2TA7W91bTWJQY2wzF/+9R+d3/Wk9AXsuwEy9HfsE5SkimwS+z2+3RPbtBetSSnpIycxIlgaQGviziYUQkYonLi6HgKrwyTQaUemC17OnZxgusncdB/G9uqpA= 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 14.07.25 15:00, Lorenzo Stoakes wrote: > The madvise() logic is inexplicably performed in mm/mseal.c - this ought to > be located in mm/madvise.c. > > Additionally can_modify_vma_madv() is inconsistently named and, in > combination with is_ro_anon(), is very confusing logic. > > Put a static function in mm/madvise.c instead - can_madvise_modify() - that > spells out exactly what's happening. Also explicitly check for an anon VMA. > > Additionally add commentary to explain what's going on. > > No functional change intended. > > Signed-off-by: Lorenzo Stoakes > --- > mm/madvise.c | 62 +++++++++++++++++++++++++++++++++++++++++++++++++++- > mm/mseal.c | 49 ----------------------------------------- > mm/vma.h | 7 ------ > 3 files changed, 61 insertions(+), 57 deletions(-) > > diff --git a/mm/madvise.c b/mm/madvise.c > index 9de9b7c797c6..75757ba418a8 100644 > --- a/mm/madvise.c > +++ b/mm/madvise.c > @@ -19,6 +19,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -1256,6 +1257,65 @@ static long madvise_guard_remove(struct madvise_behavior *madv_behavior) > &guard_remove_walk_ops, NULL); > } > > +#ifdef CONFIG_64BIT It's consistent with mm/Makefile etc. but having a simple config MSEAL def_bool y if 64BIT or sth like that would surely clean that up further. > +/* Does the madvise operation result in discarding of mapped data? */ > +static bool is_discard(int behavior) > +{ > + switch (behavior) { > + case MADV_FREE: > + case MADV_DONTNEED: > + case MADV_DONTNEED_LOCKED: > + case MADV_REMOVE: > + case MADV_DONTFORK: > + case MADV_WIPEONFORK: > + case MADV_GUARD_INSTALL: > + return true; > + } > + > + return false; > +} > + > +/* > + * We are restricted from madvise()'ing mseal()'d VMAs only in very particular > + * circumstances - discarding of data from read-only anonymous SEALED mappings. > + * > + * This is because users cannot trivally discard data from these VMAs, and may s/trivally/trivially/ > + * only do so via an appropriate madvise() call. > + */ > +static bool can_madvise_modify(struct madvise_behavior *madv_behavior) > +{ > + struct vm_area_struct *vma = madv_behavior->vma; > + > + /* If the operation won't discard, we're good. */ > + if (!is_discard(madv_behavior->behavior)) > + return true; Conceptually, I would do this first and then handle all the discard cases / exceptions. > + > + /* If the VMA isn't sealed we're also good. */ > + if (can_modify_vma(vma)) > + return true; > +> + /* File-backed mappings don't lose data on discard. */ > + if (!vma_is_anonymous(vma)) > + return true; > + > + /* > + * If the VMA is writable and the architecture permits write access, > + * then discarding is fine. > + */ > + if ((vma->vm_flags & VM_WRITE) && > + arch_vma_access_permitted(vma, /* write= */ true, > + /* execute= */ false, /* foreign= */ false)) > + return true; > + > + return false; > +} > +#else > +static bool can_madvise_modify(struct madvise_behavior *madv_behavior) > +{ > + return true; > +} > +#endif > + > /* LGTM -- Cheers, David / dhildenb