Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Message-ID: <8080cb2f-09e3-30d2-0f60-160bfe5f9803@oracle.com>
Date:   Fri, 4 Mar 2022 10:45:44 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.5.0
Subject: Re: [PATCH] mm: madvise: MADV_DONTNEED_LOCKED
Content-Language: en-US
To:     Johannes Weiner <hannes@cmpxchg.org>,
        Andrew Morton <akpm@linux-foundation.org>
Cc:     Michal Hocko <mhocko@suse.com>, Vlastimil Babka <vbabka@suse.cz>,
        Nadav Amit <nadav.amit@gmail.com>,
        David Hildenbrand <david@redhat.com>, dgilbert@redhat.com,
        linux-mm@kvack.org, linux-api@vger.kernel.org,
        linux-kernel@vger.kernel.org
References: <20220304171912.305060-1-hannes@cmpxchg.org>
From:   Mike Kravetz <mike.kravetz@oracle.com>
In-Reply-To: <20220304171912.305060-1-hannes@cmpxchg.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NkVhSUxoZlF2K05TeGVHeTFDay8yc2NvaGF6V3Jvb29rWEQ2SjhOUEh1RGJL?=
 =?utf-8?B?dE9JWGMyREt5Ym16L1B2NTBETTdYNjZ4MjhtRVZNNlFzcXdGek1tZ041eDVs?=
 =?utf-8?B?MVE4M1FDbS9zbnlTU0U3ZVdEbjJ1TURhN2ZQb3M4a3NnUVAvSno2alZNbUto?=
 =?utf-8?B?MUxybEpoMjQ0MFVPbFhGUXpZaC8vQ0RsWW5nM3FZK2c2cFJvSlgwVUszdklR?=
 =?utf-8?B?M2V2bHdVU1FjTWg2dWpoUCs3RmdGVzMwYU5HeXlXQUdHRG9QYU1ZTFVQY04v?=
 =?utf-8?B?QzRvRUZoQVUzZnViREJ4OTNhNVZrKzZ1S1FlYVhDeG9LS3dVa0hkYTRFemxj?=
 =?utf-8?B?ZldiSHhsVUg4UkU0MWdHbXdTRXdlampma1hXbURMOUcwUDZIdlJVVUpvMWJH?=
 =?utf-8?B?VUxQVjJGbVBNSUpocjlQdUlqcDNmeEJUVHJjRkplRWQ2YzF2N1Bzem80UDFr?=
 =?utf-8?B?V2ZBYTlYdlFFTmlvY2NyMWovQU9aZWsrYXRZTFE4dXgvSlh1ZktidE1rVllw?=
 =?utf-8?B?VU12ZXdOVzVHNWtUaldWUUZqTUNmUFd2aURuai9ZTzVJQXFFZ1pyWFNuRjJR?=
 =?utf-8?B?YjJzUVRldVhSYzVjaXhBcENHQW8zZU9lVVhrZU5vQUh3MGcwT2hnS3VuVWJI?=
 =?utf-8?B?Qnp5TjFNRCsyc28yUUZjWWFsd0NaSi9XNE9UcjA2MXhjTnBqdHNTWStrOWRW?=
 =?utf-8?B?ZDlvTC9xU0VaVUZyZmQ2YVJRSGh2eGVGSThTUmlUNjJnQ2h1V2x5dUZiVWdp?=
 =?utf-8?B?T3ZYWGQrbC90aEc4SEs0ZDJieXFheDhhcUpjL0hibXhuR0lWc1F6UHVNV0Fr?=
 =?utf-8?B?dHhDY3UxMGNmOHRNNzlwMXU1Qit0RzFMOFpIWCswcmJXeXhkYTBOUGNhSnh4?=
 =?utf-8?B?S2pFbm5malRFT2hzTVBSVHl4SXdyZ0I4QmxXWVNPdlk4ZGdBVzFvL0xvdldm?=
 =?utf-8?B?ZGVzMHVmR1RGdE5Lek5pbml1aXhlMEh5eDRqQmR0bTRhL2VyZnFWQmdnbHdU?=
 =?utf-8?B?ZkNSQVBocE9KTjc5N0dMWEhlejJTa1FwVkRUc05odDZIT1dxeWJwQUIxeDZl?=
 =?utf-8?B?RGVNMlF4UWRGMTVyTE1LYU5PWnhUWWJvU2pTaVArQWl2ajdObjAzOUc2K1Fw?=
 =?utf-8?B?eFA1elpHWGxJc1R1QTIydytOVjFtZHZjeEkrQWd6VVNZU0lqSENaUUd5STJM?=
 =?utf-8?B?OFEwQ3VqU3p2V3NxVVpwaEhUZmU0VEhtU2VuSjNTMnVVYVYra1RPZ1NwSDJU?=
 =?utf-8?B?NmN5WUFjZGd0dGF1dHJuVnBXTU9STUtSZ09ENFZibkExUUxwb1pYV1dqWE9I?=
 =?utf-8?B?cTZQMGRSUTdzMHpIZnBCL2luUVVWWG1PTlExT3N2WFl0MmxVV2M3S1pmajkw?=
 =?utf-8?B?eWxsemI1WlpjK2lua1hzSzB3N1Z1eERMV0tlQzE0Y1F2b2V3L0FuOENkWnZh?=
 =?utf-8?B?R2ZoMW1VOUx5R0M3eTJGZjFGRlhSdk1LdEdiUy9Wb28vWWI4VjdXRmg5U1hJ?=
 =?utf-8?B?ajgzd0Z1WHhEVWpYcDJUb1hOZStrRHhVZGZvWkkvd0wzbWJsbVdvS1BmWXht?=
 =?utf-8?B?T0xDODZWSFBpNE9weGNzUDF5TzFrUEFSZ1RlUThvRy80NFlrWmQwZWdmOVlP?=
 =?utf-8?B?a2NDWUZ1NDAvSklPWmJ1REF1cWhsRXdPV1grUXYvQjNuU2RJMnNKT1p2ZEpn?=
 =?utf-8?B?OGJIeEgrelhwTlNLalVKSTBzeW44RkNXTjRsWVBLU2tZUitpOGVCQXhsSDB1?=
 =?utf-8?B?TGcyYnBRenZWTHVFbDlNWjNwZ1puNEdBWjZpTEkvaUdCUXhiN2pWZDNRTndj?=
 =?utf-8?B?bmZxZWJ0Z3RUdUJqTWNzc21jS1lJQ01TMFU0U0oxaTFVOFZ0Qi9mZjJYVGt2?=
 =?utf-8?B?WnBoV2NpcGt0bUd3eWZXd2JaNlp4OXVhSVYraFpFWkhkb082R2lxSUFBQzJB?=
 =?utf-8?B?VXhyS2dhUFJpaHNqdHVhNlFWVzIrRDZKajZqYTFTOVRFcE14VmtmSWhSSkRi?=
 =?utf-8?B?OTN4L0RnVGxsdlh4Q0FKM0swYTdrSTA4ajl2ZzV5VUFXR0c5OC9SaDRqNFhr?=
 =?utf-8?B?RmhydjNLbk5ETUR1T20yUlBFdDU5Z01aS05TbWJWeEx3cGtRWTFUTWZ3OFJR?=
 =?utf-8?B?WGpSSXBIRVpQcWdCaHRWNUxCN081MG90TXV2eTg3UXdmSDRUdFh6VWlvb2Rm?=
 =?utf-8?Q?eaX8wydXZHQCwCjcupv90ps=3D?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f4613edd-4df9-4fb7-6d12-08d9fe0f3218
X-MS-Exchange-CrossTenant-AuthSource: BY5PR10MB4196.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Mar 2022 18:45:47.1186
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: QnJco1qS2WndsyJviI7RBAjUU68v9C0/oOhXbkaItPSlo0esF+OZv/ULM8XLbRX4Me6nfzXXHu42A6S9i0Qb4w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR10MB5785
X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10276 signatures=690470
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 adultscore=0 mlxscore=0
 malwarescore=0 bulkscore=0 suspectscore=0 mlxlogscore=999 spamscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000
 definitions=main-2203040093
X-Proofpoint-ORIG-GUID: K3KuPFvz26Zw9Mqm8TuzSADS57HSW0aM
X-Proofpoint-GUID: K3KuPFvz26Zw9Mqm8TuzSADS57HSW0aM
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_NONE,SPF_HELO_NONE,
	T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
	lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 3/4/22 09:19, Johannes Weiner wrote:
> MADV_DONTNEED historically rejects mlocked ranges, but with
> MLOCK_ONFAULT and MCL_ONFAULT allowing to mlock without populating,
> there are valid use cases for depopulating locked ranges as well.
> 
> Users mlock memory to protect secrets. There are allocators for secure
> buffers that want in-use memory generally mlocked, but cleared and
> invalidated memory to give up the physical pages. This could be done
> with explicit munlock -> mlock calls on free -> alloc of course, but
> that adds two unnecessary syscalls, heavy mmap_sem write locks, vma
> splits and re-merges - only to get rid of the backing pages.
> 
> Users also mlockall(MCL_ONFAULT) to suppress sustained paging, but are
> okay with on-demand initial population. It seems valid to selectively
> free some memory during the lifetime of such a process, without having
> to mess with its overall policy.
> 
> Why add a separate flag? Isn't this a pretty niche usecase?
> 
> - MADV_DONTNEED has been bailing on locked vmas forever. It's at least
>   conceivable that someone, somewhere is relying on mlock to protect
>   data from perhaps broader invalidation calls. Changing this behavior
>   now could lead to quiet data corruption.
> 
> - It also clarifies expectations around MADV_FREE and maybe
>   MADV_REMOVE. It avoids the situation where one quietly behaves
>   different than the others. MADV_FREE_LOCKED can be added later.
> 
> - The combination of mlock() and madvise() in the first place is
>   probably niche. But where it happens, I'd say that dropping pages
>   from a locked region once they don't contain secrets or won't page
>   anymore is much saner than relying on mlock to protect memory from
>   speculative or errant invalidation calls. It's just that we can't
>   change the default behavior because of the two previous points.
> 
> Given that, an explicit new flag seems to make the most sense.
> 
> Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
> Acked-by: Michal Hocko <mhocko@suse.com>
> ---
>  include/uapi/asm-generic/mman-common.h |  2 ++
>  mm/madvise.c                           | 24 ++++++++++++++----------
>  2 files changed, 16 insertions(+), 10 deletions(-)
> 
> v2:
> - mmap_sem for read is enough for DONTNEED_LOCKED, thanks Nadav
> - rebased on top of Mike's hugetlb DONTNEED patch in -mm

Thanks for rebasing on top of recent changes.

Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>

Looks like we both will be making madvise man page changes soon.
-- 
Mike Kravetz