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 7E2B5C83F1A for ; Mon, 14 Jul 2025 15:37:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EC2648D000E; Mon, 14 Jul 2025 11:37:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E71E68D0001; Mon, 14 Jul 2025 11:37:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D3A0C8D000E; Mon, 14 Jul 2025 11:37:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id C3FEF8D0001 for ; Mon, 14 Jul 2025 11:37:48 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 8F34510CF71 for ; Mon, 14 Jul 2025 15:37:48 +0000 (UTC) X-FDA: 83663275416.17.36CDA2D Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf19.hostedemail.com (Postfix) with ESMTP id 375F61A0006 for ; Mon, 14 Jul 2025 15:37:46 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=KS4y+IUS; spf=pass (imf19.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=1752507466; 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=amM9FSOvpJvmGAYB5+wYTX2dkMFWF/xAHWtESWwGefc=; b=3frPeE44pu2IND5t8KORaro5jNPt+AL73FrYTvuAd/hwrcORx5J1+f5Rt6F5qSV4bhpfSF r8XJlIE3Bil5tJJGkgUFnbghErepCpJzrITlI+cbCmgN+XboHAGwUr1ek40j/thR+XwxQV a+gcFHUm2WUjsyO0hgqQK3/mwedaQMk= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=KS4y+IUS; spf=pass (imf19.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=1752507466; a=rsa-sha256; cv=none; b=mzq/7AQIZ+8Err1TEcwtggKPhSEnMsQHSdZVWSk5HHPmgvbkJq3UsZQpNDlfg2Rc4z+68w mdETuKG3DiyJpVCgJDpmXVubdphQvWOSllspOxFI+p1xAzCRW/taHMO6+EPqjWQQ3qnxFY JRBAVw3KvmKlmfskYXIrsq5yTc7kWpo= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1752507465; 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=amM9FSOvpJvmGAYB5+wYTX2dkMFWF/xAHWtESWwGefc=; b=KS4y+IUS/VuzXLEI/uV1zlGqxJQ69fkUoePFWyHGtIwamgAsPPGNqgB6BVzq1KuAPi84// D1uPYeXSOr7NfuzFYuP0i1paRm/MHoJtZXBC4VBum45KCIbv0gVi9BaeFmwlWykJAomIwd 6ZjrGEQNmEwtjkkMEmQrpVbJcvAQ7Xk= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-370-9EaqD4WKPt-pSA6BnSsHCw-1; Mon, 14 Jul 2025 11:37:42 -0400 X-MC-Unique: 9EaqD4WKPt-pSA6BnSsHCw-1 X-Mimecast-MFC-AGG-ID: 9EaqD4WKPt-pSA6BnSsHCw_1752507461 Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-3a6d1394b07so3190730f8f.3 for ; Mon, 14 Jul 2025 08:37:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752507461; x=1753112261; 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=amM9FSOvpJvmGAYB5+wYTX2dkMFWF/xAHWtESWwGefc=; b=GwRtWiD3l9DzLnPLC5iPIPLIgXYNgIVaaRQYc6QmIr2MCtaN1ymNR3k7MYXRI/KtPk AlPaqyGlRL+WrmgzESTAodj7mzBIDvaPy1a/32uIzImI8DFreAb7jwtvOE+MwESzMVUN nwnS/aaH1TaKLDVTTV/Ciu9b6/ghVm/C5PTurXTjSLMJy8Dz6demIq9JTbt7vZb0iiqW EMl/Zz/ahmm20KQtygbLbmg71NrgNuDz8GTcnNXqcRDT6kvaCE82D7iwl81Coep51K7C TA6dts8EK8EoeNMoFWjj/E2hCDkiKyejO2hO+N/1Y9GfNXLqfXK44qx3v/JlLhv4dt61 n5Rw== X-Forwarded-Encrypted: i=1; AJvYcCV0Bm0qSUW33nNOiGKQRX0TDtRoVk0fK3fu3w5wHp7wrspnE9ymxM2F93ml0xFQwBgGEaKcVBGgiA==@kvack.org X-Gm-Message-State: AOJu0YxCKMbdI6LdpbCLHCxT11fUSn769M6juwHcE9wjnJpI4XvaeMKh p9fsSZbqt5j56i6EDV27Yj48zfNGC4flVAwNXHj11yfvzBt+816oqZDrHk5bPtEv+kSWzg6Os9t SKiRv3rXQJTxnFI1fbJtejrMK2nt1cWibjKhxIjgQ4UnKXBN8uCq2 X-Gm-Gg: ASbGncs239VLxqDX5BlLxwPb5Z6A0eZvNn8zSofXcIgHlNVZnAEufmup+zCOpPpEJre a6voqd+8OqtZu4UUs8gcts4diQk1gOZfBHYlrkl2lJnqOqOyaUn9uD2BxvW5pO6pNuCJqn/6wsq EewI03CDEGiFyaxGOBvPyl1WNqJ+oaKlUQzqEiY7tbgmOscmz8Eo1KaasqZlfN+RLsO0lrURZ4K 62hbtQMjXACULOzUMqLrA2JDKw9AayUDdeAO06o5VAsRuasee0gF2CJQYH2g19naLCjEPU2SVgU +nJhYvJT2bf0O18T4jqf9/7CqMyLYsuELfgWBub3O0XpWSImx9ZcU2FHj7tLklnBh+pVa5aHxTg Hz2HKGM+qz/s5BOYrZ6NQ0E6voYPm/khIN+77TlnFHuEf89i/wt06M7N+HKzBTnHQ X-Received: by 2002:a05:6000:2181:b0:3a5:52cc:5e29 with SMTP id ffacd0b85a97d-3b5f18565a3mr10465568f8f.7.1752507461086; Mon, 14 Jul 2025 08:37:41 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGPukMrCzOvCLUT8Y3kmqUzqBTSWnEJUhx8wiPtEwlzku2il6SHlKwJQ5ZMalbTMucKfe2C9Q== X-Received: by 2002:a05:6000:2181:b0:3a5:52cc:5e29 with SMTP id ffacd0b85a97d-3b5f18565a3mr10465550f8f.7.1752507460652; Mon, 14 Jul 2025 08:37:40 -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-3b5e8bd1741sm12914882f8f.18.2025.07.14.08.37.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Jul 2025 08:37:40 -0700 (PDT) Message-ID: <1163e5f4-2ce9-49ee-bf2f-9a52e948edb8@redhat.com> Date: Mon, 14 Jul 2025 17:37:39 +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> <0c78bc9b-8aae-47ba-9679-423d862591df@redhat.com> <00bb2d76-4d52-40ec-ac75-546311b8ddcb@lucifer.local> From: David Hildenbrand Organization: Red Hat In-Reply-To: <00bb2d76-4d52-40ec-ac75-546311b8ddcb@lucifer.local> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: fny5-Vyh9qQ-pe1ouvMp9RwpxQaPPx8eBRE8gSGOSzA_1752507461 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Queue-Id: 375F61A0006 X-Rspamd-Server: rspam06 X-Stat-Signature: 1d3mm37zapa5xqrxphqqj5najhu8cyg3 X-HE-Tag: 1752507466-531162 X-HE-Meta: U2FsdGVkX19zqH7meoJH/oKb16fBo3/rZ4OWKEnPNeRrRtXtela8/z1iSbECOT0b00ibtUlOw9LT7UC9TqVwX4X41w3GBNLt+bigaanyi3v4k2gmYaoGqUBML/OB7duKnIusQZqB9O7jZp64lzFdfH2ZRBkF6mzZjQST8lmYZAaxSItb9C4cIoaI106kMg/J0LsiP+wHxtEA70CzmIUbowsZ7bXnc0c1SuMru55yxKgq23yXQyM2zTR2N/zFo2hXyuM9o1f30vVDAgU4lswDzLZzMtFXZnu11K5kr5ux/kgOA3lwRv8IGLt2U3JCJP2JZE2vTw6tqQXTV8AugSXdv9kq1I0rjjibSKHM/0ES83Xeqc3v8mvRzlnsj+jMXsn+R0mXoeBcyNPKvcsYiaod9/oJOaWRwWy5zsrN7p5/OxP7LWEZGpJxSxC5qCPoG2VAJd31IEmoAM3Ew8643H4WXxPTvZ0o6jYVvehzc7dtMm6pRrXeqVPf6F9RiEQlUuFjQ487SkrIaFwWBM+RDjYgM2Ry5h6q86xSJrwlul9adv8Qiq6QzmjFTz46tEN7y/qCtR4fdS4UV6/myzP5wiMVFPNDw2daMe+MYaTM6bpv+7OIfNjvcqu6X5C+ssLestn3eRs0+OlIbTej0nklfBG5spJ4aaesmKE6QsOiOGfVaMCaB3vGopp9G4BatO7kHl52gApYsynMmgqnoS95fxdby5RxXDIo+IQJChyeYcUyJyofCV0J34ktBV6YVWSLbN35gNFOIfBU8Rkb/y0fKtgF1m9xA+PlvJkIXtkc9F20CrbLC5gZABFbiQ1/91vVHg/sCb/ggzoDsDoytx4gqqd6cmK9Gxfw31CIFogolvVUJp4SdT3ZzAqoJ8sZOqyrQD0LVrFywOz2nP12LDTzFwyOWBy8d5BOC0aKcOxy5D4PRVP3ebY/lnuCc3FCwK+1QntHOMSY0t8yoLjtEJs3mWn K9nANJ15 O6W2Y2MV27ehXji9e8jZ+gGBndbrBRMGmGXA+KLf7L3a8F7nKsvrnsYh5OVKlC8WXwjTgGXAz+uHQoFF0Z58ViN5fMvNIw+opGlcVW4cYPSh4zmFCiA/20Pp6qk4DWXUJAcwSHZKHznEmXu6nwz+KlunwKs6cmshZlv46VFFXZTqqXgS9HDNJFxBUokQwY0Bz/bSvTQyGP10UouAORR3ZGJ5SZz5iDv+QipgEV9hP8duhwMllSS9KzZxh8fdugJ86ZWVsNa04JwzWRzYtnPscPp8nWdT6PY2fN024G+IkXMLAruaV+jC6OqcZoBLv/E+/u1kKBxLZnVNY8/RS9s53tKdKRmd95IafYJSI8qacXIGDF9CyLtbnIs3bI3bcheulJ2p2B8yAXXkQp8s/I3sJRWpDWc6v5DBgO8lvdPn94ffZVoJ0swsEnA2H7rsGi4Vq+ph1PDkhtG9DH72bV9AbtlZWGQ== 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:27, Lorenzo Stoakes wrote: > On Mon, Jul 14, 2025 at 05:24:14PM +0200, David Hildenbrand wrote: >> 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. > > Once this lands in mm-new I can send a fix (like litearlly tomorrow if it lands > :P). I just don't think a functional change belongs as part of a refactoring. > > I worry that we'll get catch-22 caught on the (numerous) problems with the mseal > implementation and thus not provide a foundation upon which to fix them... Not sure what's right or wrong at this point. The cover letter only talked about anonymous memory: " Some destructive madvice() behaviors (e.g. MADV_DONTNEED) for anonymous memory, when users don't have write permission to the memory. Those behaviors can alter region contents by discarding pages, effectively a memset(0) for anonymous memory. " We're similarly in the domain of altering memory content that was there (resetting it back to whatever the file provided). It does like something that is not desired, but no idea how security relevant it would be. Probably a corner case we can indeed fixup separately. -- Cheers, David / dhildenb