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 3D2BDC433EF for ; Tue, 3 May 2022 18:36:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 80AE26B00BF; Tue, 3 May 2022 14:36:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7BAC06B00C1; Tue, 3 May 2022 14:36:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 65B3B6B00C2; Tue, 3 May 2022 14:36:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.26]) by kanga.kvack.org (Postfix) with ESMTP id 58F636B00BF for ; Tue, 3 May 2022 14:36:22 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id 36569120A37 for ; Tue, 3 May 2022 18:36:22 +0000 (UTC) X-FDA: 79425287004.14.3EA5C2D Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf25.hostedemail.com (Postfix) with ESMTP id 39A21A0081 for ; Tue, 3 May 2022 18:36:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1651602981; 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=fJCjU8JdJDMoZ6JiGS8DoI4ltHKw0EEf1II2eYjKnuM=; b=CjHsPo2rUeaX+OSH+lHmd06FbvOwp1RZB9nCQDyMpTCfvDb2biUf59aUgTiswK0Eb4ksiv eybqp+fdvEb2/vIBweVgXY8cBqyzjITBSLeuK2LCHcSI2EVnAqoP7nBc4ebL9E9KacJb3O 6CQMtaWaKolrc84Bc53ga8SCxsLI/DU= Received: from mail-pl1-f197.google.com (mail-pl1-f197.google.com [209.85.214.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-433-nBBbi4hdPZ2rAsIkDuT_KQ-1; Tue, 03 May 2022 14:36:08 -0400 X-MC-Unique: nBBbi4hdPZ2rAsIkDuT_KQ-1 Received: by mail-pl1-f197.google.com with SMTP id x23-20020a170902b41700b0015ea144789fso2913786plr.13 for ; Tue, 03 May 2022 11:36:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:organization:in-reply-to :content-transfer-encoding; bh=fJCjU8JdJDMoZ6JiGS8DoI4ltHKw0EEf1II2eYjKnuM=; b=Pos2du1N2nVZXL1zN1ScB3wRAMe/ru+njbflLK0NsaXFjSd2ccTbF7gEbFM3Pw8yi0 iOKxdaniDrq7L4PVLYNjOslI8w1UxFiNJgeBspT9VPxdiI9SjF02J32zZPU5kfRy59Us HbbU7Rgs8zy/4Ae8JkPd6kbcKu3QqF1KKrxNW7axIBfLTqMdUMgyHPauVS7PEFbSMHDZ a0lZ3GPsVmsj5pDUZ6nUv4+mQDTwS2WDK27698xh1A0zMHB3TgZZOzCxPezU2y2U77UN QvcAmFzK6nNCI5jp4xxo1iy+c7HUCcW7shtJeT/PPYtfX4ReKQrDIgaK3sn0Dib3rolM 3ehg== X-Gm-Message-State: AOAM5318RSZN88RnXszHYjCZl1zww5KjM8VzX3NIMg9mlHlEsCj+NksT LxBHRV9UNSi4RAy9Ot+awkUGKB1SLHjSZCu00OSa3oj0X/Hbywn5JDMMmTAMenCbZdoaZGFp0z4 l3ci5TtWH86Y= X-Received: by 2002:a17:902:e78e:b0:15d:29ba:77fe with SMTP id cp14-20020a170902e78e00b0015d29ba77femr17951901plb.119.1651602967848; Tue, 03 May 2022 11:36:07 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy4nv0IKW7HMA4MKhMR91C6X0V3KPHdcvIk0GGNMCBLpb+uvHfY05+UexIai2OiC1Zhd4hVfg== X-Received: by 2002:a17:902:e78e:b0:15d:29ba:77fe with SMTP id cp14-20020a170902e78e00b0015d29ba77femr17951880plb.119.1651602967566; Tue, 03 May 2022 11:36:07 -0700 (PDT) Received: from [10.10.69.234] ([8.34.116.185]) by smtp.gmail.com with ESMTPSA id k15-20020aa790cf000000b0050dc7628174sm6623027pfk.78.2022.05.03.11.36.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 May 2022 11:36:06 -0700 (PDT) Message-ID: <0fa49d1f-a05d-bdb1-df60-800ff5999d8e@redhat.com> Date: Tue, 3 May 2022 20:35:59 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: [PATCH] mm/mprotect: reduce Committed_AS if memory protection is changed to PROT_NONE To: Andrew Morton , liusongtang Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, nixiaoming@huawei.com, young.liuyang@huawei.com, wangkefeng@huawei.com References: <20220426112705.3323-1-liusongtang@huawei.com> <20220426133401.9404190c5a5c6ff58b694c59@linux-foundation.org> From: David Hildenbrand Organization: Red Hat In-Reply-To: <20220426133401.9404190c5a5c6ff58b694c59@linux-foundation.org> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 39A21A0081 X-Stat-Signature: 76mk1dom7ikhk4rpjkwxw9kckqgd5dup X-Rspam-User: Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=CjHsPo2r; spf=none (imf25.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-HE-Tag: 1651602969-20358 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 26.04.22 22:34, Andrew Morton wrote: > On Tue, 26 Apr 2022 19:27:05 +0800 liusongtang wrote: > >> If PROT_WRITE is set, the size of vm area will be added to Committed_AS. >> However, if memory protection is changed to PROT_NONE, >> the corresponding physical memory will not be used, but Committed_AS still >> count the size of the PROT_NONE memory. >> >> This patch reduce Committed_AS and free the corresponding memory if >> memory protection is changed to PROT_NONE. >> >> ... >> >> --- a/mm/mprotect.c >> +++ b/mm/mprotect.c >> @@ -497,6 +497,12 @@ mprotect_fixup(struct vm_area_struct *vma, struct vm_area_struct **pprev, >> } >> >> success: >> + if ((newflags & (VM_READ | VM_WRITE | VM_EXEC | VM_LOCKED | VM_ACCOUNT)) == VM_ACCOUNT) { >> + zap_page_range(vma, start, end - start); >> + newflags &= ~VM_ACCOUNT; >> + vm_unacct_memory((end - start) >> PAGE_SHIFT); >> + } >> + >> /* >> * vm_flags and vm_page_prot are protected by the mmap_lock >> * held in write mode. > > Surprised. If userspace does mprotect(addr, len. PROT_NONE) then > mprotect(addr, len. PROT_READ), what is now at *addr? Zeroes? > I don't think so. I don't see any pages getting zapped at my quick test (unless it's wrong) shows that data is maintained. Further, it could violate POSIX semantics. So this patch is wrong, there might have been anonymous pages populated. -- Thanks, David / dhildenb