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 9B215C83F1B for ; Mon, 14 Jul 2025 15:24:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3ABBC8D000F; Mon, 14 Jul 2025 11:24:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 35C948D0001; Mon, 14 Jul 2025 11:24:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 24BEF8D000F; Mon, 14 Jul 2025 11:24:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 13E008D0001 for ; Mon, 14 Jul 2025 11:24:24 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id E09CF5701D for ; Mon, 14 Jul 2025 15:24:23 +0000 (UTC) X-FDA: 83663241606.20.A5487C7 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf10.hostedemail.com (Postfix) with ESMTP id 7F5DFC0003 for ; Mon, 14 Jul 2025 15:24:21 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="VgoIzQ/R"; dmarc=pass (policy=quarantine) header.from=redhat.com; spf=pass (imf10.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752506661; 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=7hER77dU2efEPR5AO+ai2n3WJMard2PzwSK87xeF4+M=; b=njUrguVOm4sbJQRQ6WC6bzJQLoHdl+oWw/kGy0yuDXy6shN9uX8OuPzu6f7I0JJ+6K/SDK afq9Qey9L4OEv530lAkeMnTm1fj/QC2boGdyF/zdeXpQ07as7cp+Z0zeH9qOxTVhVrySjT D1hUiaMF97tW3PMRRYxP2h20b82NTuo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752506661; a=rsa-sha256; cv=none; b=3XXP1NfqLVmL+z+UcKK12oBOrxyETxzjWP9+KwzB4ehLSvmToghGxHKvNi0gUy0eHapxc3 3e/m8oNWqdCuwoirSPgVB3z9NbLcmy/fCfYC2i9JMWABHmM1jlbd1QiUz1OwyYVOOnv2f/ +dp0ac97Qw5WApy0zKc9BVAslRSu5b8= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="VgoIzQ/R"; dmarc=pass (policy=quarantine) header.from=redhat.com; spf=pass (imf10.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1752506660; 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=7hER77dU2efEPR5AO+ai2n3WJMard2PzwSK87xeF4+M=; b=VgoIzQ/RScaI/UyTdNy/VkDO2Yynly09FmKSthVf6ylb2GidWo/+n7JzwOuoB6xaT3uZjl 6zgTlBkR8fNVsnGk6Wp0sP3ZHMNM93B5G6UGe6MZX4qIRzx53wLMKxigZGhmEVifsjhC+X +3E1aavMYHsmD5up917e9VJNIrmTANA= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-451-MpVxnUIYMrqd269Sfjkb9w-1; Mon, 14 Jul 2025 11:24:19 -0400 X-MC-Unique: MpVxnUIYMrqd269Sfjkb9w-1 X-Mimecast-MFC-AGG-ID: MpVxnUIYMrqd269Sfjkb9w_1752506658 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-3a4ff581df3so1810968f8f.1 for ; Mon, 14 Jul 2025 08:24:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752506658; x=1753111458; 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=7hER77dU2efEPR5AO+ai2n3WJMard2PzwSK87xeF4+M=; b=PE1o0ieyUReSJLT93/6ctfGyXvjx2YYUqryf7GaVRrd1sbAifdNbJa2ny1p+W/zxNK H8DDtxjSLKNxzFC1zQRnO9YfkBaCjSPwKbIuN27Z/Zv0QjAHDZ7cfmw7yX5Fb/U8xIFA H10hAJNe000AO+lfS9iFDKd7oLednf1xcKLaUC5fXqdDJ7Ml+Rq3zZp+WnPnYzNVwGOD DGuyvv59Elgmsq6Zu7ar7xka5aDYi9kPbR9aTH+qDijXPOdGEtb5a0FZ0GsIn76dn9kA jl+Ss2WOwZhF4qEPom/Vh+X31eA3Al42UYkgACluJo6I1ImUQ/Y+EBJQvNiPwik9uUNa X7Uw== X-Forwarded-Encrypted: i=1; AJvYcCVaJH+MADAvZWssTY2OQPqzbTwjvAs5eLE0yhH6Idvuia8GCeqnGY86/45rofoO7qVgR3ekP0vvcQ==@kvack.org X-Gm-Message-State: AOJu0Yy2dLniCS5anfLBs/xOCOMGbdkmBmjk0fylYFyTUXc+PqPBeWbl SrawOD27oluvEaqsugCgWAje9hgUkCVHeEHWzZ1hhTvFgySskH0WmSXW+BL/hf64FlfcB8en59W iD/+u9R9MwK6WLYErMDRCN2SP87P+Npqix4AJ+DKMvURLF5qi5Sa9 X-Gm-Gg: ASbGncvQ39W/6iOsGpjtGVo77Ixk68zk2X16BXG+CbFestWnXAY57UlybAP4plHAiAS 35LpGAjI/tmX+b9fNiDpdWJ3CSfiZXMZue3xIBRKlOIUfwZDf9ED1faJZWEVxJlwpioRRjzrtgZ Xg4cfxitC+8whUQq6rtOicQSeL4FBwzqI8UoH2vE+jOURjELWRRbZYYYJIbJ2dzFAIpLkpsjKvd Ltahj1RGpkcrKcYCFzkprRRirNiwlrXVUNgKaBl5EPDMxBoQpHgkp/43dBuCvKOvHOOXRJn0Yfi x9b12fnVPEircflbppJOIW3ZPpVpunP25SvqWvQYcxeDNykWPsULGVGb2WgW9UhjQT9bGiAvv00 evK+tf6t/R+X5zQBDfI2cH2O/u42Fmsgf1exUql2bY8zQ6uMI+136nSMV4I8Rhf8t X-Received: by 2002:a05:6000:250c:b0:3a4:cec5:b59c with SMTP id ffacd0b85a97d-3b5e7f3b047mr16777131f8f.25.1752506657838; Mon, 14 Jul 2025 08:24:17 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEgw0twrOXJl14XHoT9KdirKpxc0GUYVGI+Vrz9PtEtgVkL77KS9gg06YqYOwBZtiRhE7VT7g== X-Received: by 2002:a05:6000:250c:b0:3a4:cec5:b59c with SMTP id ffacd0b85a97d-3b5e7f3b047mr16777107f8f.25.1752506657390; Mon, 14 Jul 2025 08:24:17 -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 ffacd0b85a97d-3b5e8e0dc3esm12579651f8f.47.2025.07.14.08.24.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Jul 2025 08:24:16 -0700 (PDT) Message-ID: <0c78bc9b-8aae-47ba-9679-423d862591df@redhat.com> Date: Mon, 14 Jul 2025 17:24:14 +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 Cc: Andrew Morton , "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> <5e21df9f-7f75-412b-a173-fe6da49952e5@redhat.com> <0925c64b-c721-4dc5-913a-c43a94dc64a3@redhat.com> From: David Hildenbrand Organization: Red Hat In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 5ncHvXOnm8XIKw4BKmlvAS8RGD2ITH3sIR8uVGuA5bY_1752506658 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: qrijq5sphm468u3wwgtc585apfe43e4h X-Rspamd-Queue-Id: 7F5DFC0003 X-Rspamd-Server: rspam10 X-Rspam-User: X-HE-Tag: 1752506661-221007 X-HE-Meta: U2FsdGVkX19IP/YblRXbgLjv5HY4NQvVrRBGikXbLvowqmIk5stSMaq30Se13lOZUVplexVQNsjeQkqbwgzcy5YEu8eX8YuL+P7mXPHHuHQmamK0Uq9aHIq5xPjSTl5/EtGuNm1n7cdnA4PTYY5k/FFHX4Nx8UHiGouoc4GwcFjYjXtuAvAdZCPgj2XJd12XvyZcT5Et/Vbo9HVeKkeOE8oTdZFGe9OgecDaNXN6vl1zk6WJEia4Y1rDHR+1yXcE2CHrIOvqB6Vny7WL4KDixYvTq2bLo92G7uCEgWyicz2PFln0w56fIkqWVi3cUywfRzUdiLKuAwXeF+5K8JKo/ih/16qL19hxckBTDjbdl+0wi0JHd5BwcH9obj4fOBdbcjTsWkQbNFztaBRrgLwfPsT7aEYD/j8eaw63NtVrhnwZU6dWInuqraaee+QZkWXcKgTfGETnnoBugUE3fKohbQwvsdjkmmXRKW1WC1DeLfmTKGD1HDeJoVVpC8IFMCbrueGhWSc78DbKM4tu7/luYd2R8rBetKE+hDXVcBcU3J9Gq3lWhFX8OSLKh4AVPe9aBgjALe6TahdMnBRrEVZ4ECfF5h1tn8Ew+Ahi7/JVUKx6apd2MvehDe4xag20j4nf09iCvA95irTdi5BLBusNQoo/+3ajq6ExYgU+teZ4G9RMAYe++I1dgyLahCVZHQoIVQyxGpPQE6ODPtDN7UjbCOnn6Ml9tnC1Qns8lRtsPlt1hpeSL/ZbxiNpiM1i9fZpUL42tRRgmKgph5gNm/Vp/qa7PaH4VEUE/S2yH1RPsJnYTQeCwChsrxcSrNQywks1YPT4nzPYyKdtynnQVV/tQyZv4F30QIgWXnS/ednMw5WTfgSLfJDUywp1fPLfgW76Ns8zWDsspPZ4IU0xR6C2KbhQ4+CUsU/NRAQ1LgFwMPB0qqReFu2s7mWL1Lfqim16dlSovOE7bo39yN6vqI/ 6NrPVS2m lvPDExHS6yJNl0XWzAsLmLoCRWdjVjbGhz6B+QYogfaG+NgcbWkdhkx3TGO2izXW6AruVSAvkGvfjCuoLeM13i7n+mNcBo4eKmK1WZWNB9KhfWAhMZnttt8mH/TMYWuJBzzcH8Wz6KDr60iG6v4ZslEUchRUsKPyjhagwj2NxewciKVJcdOY0MdtkGpq1/QKTVRuFqPXgFYJDQHcOjYxHliwzrQR/pZCoV1bz3TCcHLtahRXiaEH+v6zDiCJypbA6t3bVtUm1WFquoVhzRxJMjZztJFqXowhCKG89LOmpYgG9dbTV8uxtZw9R0Y5YLScAnX7HKYlVOfbuE9RBz4OwNmRicxOvRlfaP/6q+7Gv1HxM9KeRPkQxzf1yjHurzb74mj08XQIejlEftm5PblwZyjIOjUqGFqmJxPEXXO1MjqXE/KCrfzdwdEisznr412cbsc4Gmy/uT1b8/znf5p4xG1nkDw== 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 17:18, Lorenzo Stoakes wrote: > On Mon, Jul 14, 2025 at 05:03:03PM +0200, David Hildenbrand wrote: >>>> or sth like that would surely clean that up further. >>> >>> Well, I plan to make this not a thing soon so I'd rather not. >>> >>> The intent is to make _all_ VMA flags work on 32-bit kernels. I have done some >>> preparatory work and next cycle intend to do more on this. >>> >>> So I'd rather avoid any config changes on this until I've given this a shot. >> >> Sure, if that is in sight. > > Yes :) > >>>>> + * 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. >>> >>> Hm I'm confused :P we do do this first? I think the idea with this is we can >>> very cheaply ignore any MADV_ that isn't applicable. >>> >>> Did you mean to put this comment under line below? >>> >>> I mean it's not exactly a perf hotspot so don't mind moving them around. >> >> I was thinking of this (start with sealed, then go into details about >> discards): >> >> /* If the VMA isn't sealed, we're all good. */ >> if (can_modify_vma(vma)) >> return true; >> >> /* In a sealed VMA, we only care about discard operations. */ >> if (!is_discard(madv_behavior->behavior)) >> return true; >> >> /* But discards of file-backed mappings are fine. */ >> if (!vma_is_anonymous(vma)) >> return true; > > Right yeah. > >> >> ... >> >> >> But now I wonder, why is it okay to discard anon pages in a MAP_PRIVATE file >> mapping? > > I'm duplicating existing logic here (well updating from the vma->vm_file check > and a seemingly pointless !vma->vm_file && vma->vm_flags & VM_SHARED check), but > this is a good point... Yeah, not blaming you, just scratching my head :) > > For the purposes of the refactoring I guess best to keep the logic ostensibly > the same given the 'no functional change intended', but we do need to fix this > yes. Likely a fix should be pulled in early? Not sure ... but it sure sounds broken. -- Cheers, David / dhildenb