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 BB323C433EF for ; Fri, 1 Jul 2022 12:02:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 551E66B0073; Fri, 1 Jul 2022 08:02:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5032C6B0074; Fri, 1 Jul 2022 08:02:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3CA4D6B0075; Fri, 1 Jul 2022 08:02:27 -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 2D5D36B0073 for ; Fri, 1 Jul 2022 08:02:27 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay13.hostedemail.com (Postfix) with ESMTP id DA7D36114E for ; Fri, 1 Jul 2022 12:02:26 +0000 (UTC) X-FDA: 79638393492.11.D1932C6 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf19.hostedemail.com (Postfix) with ESMTP id EAEF51A004C for ; Fri, 1 Jul 2022 12:02:25 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 7B4FF1FF75; Fri, 1 Jul 2022 12:02:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1656676944; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=sVpgnE/8BZxRSzmz9vKSkY1hVDHLAHVE+9dfE4p0HjM=; b=lfWLx3UvlBhalAxtzaDJq9fSfggEWtE87v+Jj7FtQbw11mUiQB3caS0ix41x6nPu2yKMwW 3Y/qICf8kktb8V+0p6nuxnONDF7WHW4m8e50YR8XjOSOtd/ziSguTGfe0vXXwy1Lb2nvmn NozaM7XNWL55gGlr2o5cxPfaZz94eRk= Received: from suse.cz (unknown [10.100.201.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 4403D2C141; Fri, 1 Jul 2022 12:02:24 +0000 (UTC) Date: Fri, 1 Jul 2022 14:02:23 +0200 From: Michal Hocko To: David Hildenbrand Cc: cgel.zte@gmail.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, vbabka@suse.cz, minchan@kernel.org, oleksandr@redhat.com, xu xin , Jann Horn , Andrew Morton Subject: Re: [PATCH linux-next] mm/madvise: allow KSM hints for process_madvise Message-ID: References: <20220701084323.1261361-1-xu.xin16@zte.com.cn> <93e1e19a-deff-2dad-0b3c-ef411309ec58@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656676946; a=rsa-sha256; cv=none; b=AxwX3W09mKDXtq2Z43UBo4HZ5xzMtxIYRHW15nWiEvBa+YwGyNOoyAkm+SNPy8dxri+o0A ZUfimayPJgKsjSZsVwqYpxbhcLpuh5jB0aV4DWXqXEfLIXu+wgutcau4RiJNCgnjDcqOP0 2+0PO5EhtHG7cLTI7FkcR15N1rk9f+s= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=lfWLx3Uv; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf19.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656676946; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=sVpgnE/8BZxRSzmz9vKSkY1hVDHLAHVE+9dfE4p0HjM=; b=gWyX3M3WsBjnU9acehi3MJP1xrE7i3xaCwV4FLPGiXOKREOnMiwNlpJqFe2Fn6i3Qn426x 9g9NydWPeTUoDxhfo1dz+mBX26JlHWLkIUZUPxaZDGsGlV4lo1Kt4qGXVHmn1R+wzpXmFj itQYMeq9C/6D3lXBBE0p5ZuIGOQRjGY= Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=lfWLx3Uv; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf19.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: EAEF51A004C X-Stat-Signature: wptdrrkic38ftmbqgqi1uubr14dt7954 X-Rspam-User: X-HE-Tag: 1656676945-175330 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 Fri 01-07-22 12:50:59, David Hildenbrand wrote: > On 01.07.22 12:32, David Hildenbrand wrote: > > On 01.07.22 11:11, Michal Hocko wrote: > >> [Cc Jann] > >> > >> On Fri 01-07-22 08:43:23, cgel.zte@gmail.com wrote: > >>> From: xu xin > >>> > >>> The benefits of doing this are obvious because using madvise in user code > >>> is the only current way to enable KSM, which is inconvenient for those > >>> compiled app without marking MERGEABLE wanting to enable KSM. > >> > >> I would rephrase: > >> " > >> KSM functionality is currently available only to processes which are > >> using MADV_MERGEABLE directly. This is limiting because there are > >> usecases which will benefit from enabling KSM on a remote process. One > >> example would be an application which cannot be modified (e.g. because > >> it is only distributed as a binary). MORE EXAMPLES WOULD BE REALLY > >> BENEFICIAL. > >> " > >> > >>> Since we already have the syscall of process_madvise(), then reusing the > >>> interface to allow external KSM hints is more acceptable [1]. > >>> > >>> Although this patch was released by Oleksandr Natalenko, but it was > >>> unfortunately terminated without any conclusions because there was debate > >>> on whether it should use signal_pending() to check the target task besides > >>> the task of current() when calling unmerge_ksm_pages of other task [2]. > >> > >> I am not sure this is particularly interesting. I do not remember > >> details of that discussion but checking signal_pending on a different > >> task is rarely the right thing to do. In this case the check is meant to > >> allow bailing out from the operation so that the caller could be > >> terminated for example. > >> > >>> I think it's unneeded to check the target task. For example, when we set > >>> the klob /sys/kernel/mm/ksm/run from 1 to 2, > >>> unmerge_and_remove_all_rmap_items() doesn't use signal_pending() to check > >>> all other target tasks either. > >>> > >>> I hope this patch can get attention again. > >> > >> One thing that the changelog is missing and it is quite important IMHO > >> is the permission model. As we have discussed in previous incarnations > >> of the remote KSM functionality that KSM has some security implications. > >> It would be really great to refer to that in the changelog for the > >> future reference (http://lkml.kernel.org/r/CAG48ez0riS60zcA9CC9rUDV=kLS0326Rr23OKv1_RHaTkOOj7A@mail.gmail.com) > >> > >> So this implementation requires PTRACE_MODE_READ_FSCREDS and > >> CAP_SYS_NICE so the remote process would need to be allowed to > >> introspect the address space. This is the same constrain applied to the > >> remote momory reclaim. Is this sufficient? > >> > >> I would say yes because to some degree KSM mergning can have very > >> similar effect to memory reclaim from the side channel POV. But it > >> should be really documented in the changelog so that it is clear that > >> this has been a deliberate decision and thought through. > >> > >> Other than that this looks like the most reasonable approach to me. > >> > >>> [1] https://lore.kernel.org/lkml/YoOrdh85+AqJH8w1@dhcp22.suse.cz/ > >>> [2] https://lore.kernel.org/lkml/2a66abd8-4103-f11b-06d1-07762667eee6@suse.cz/ > >>> > > > > I have various concerns, but the biggest concern is that this modifies > > VMA flags and can possibly break applications. > > > > process_madvise must not modify remote process state. > > > > That's why we only allow a very limited selection that are merely hints. > > > > So nack from my side. > > > > [I'm quit ebusy, but I think some more explanation might be of value] > > One COW example where I think force-enabling KSM for processes is > *currently* not a good idea (besides the side channel discussions, which > is also why Windows stopped to enable KSM system wide a while ago): > > App: > > a) memset(page, 0); > b) trigger R/O long-term pin on page (e.g., vfio) > > If between a) and b) KSM replaces the page by the shared zeropage you'll > get an unreliable pin because we don't break yet COW when taking a R/O > pin on the shared zeropage. And in the traditional sense, the app did > everything right to guarantee that the pin will stay reliable. Isn't this a bug in the existing implementation of the CoW? > Further, if an app explicitly decides to disable KSM one some region, we > should not overwrite that. Well, the interface is rather spartan. You cannot really tell "disable KSM on some reqion". You can only tell "KSM can be applied to this region" and later change your mind. Maybe this is what you had in mind though. -- Michal Hocko SUSE Labs