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 54A58C43334 for ; Fri, 1 Jul 2022 10:51:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BA1EC6B0071; Fri, 1 Jul 2022 06:51:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B2AEE6B0073; Fri, 1 Jul 2022 06:51:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9A47F6B0074; Fri, 1 Jul 2022 06:51:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 89D1B6B0071 for ; Fri, 1 Jul 2022 06:51:06 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 4B99720DFD for ; Fri, 1 Jul 2022 10:51:06 +0000 (UTC) X-FDA: 79638213732.23.F0283C4 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf17.hostedemail.com (Postfix) with ESMTP id ABAF840039 for ; Fri, 1 Jul 2022 10:51:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1656672663; 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=p904tAF9K07KDnBScamIzcjJHAu8q9svh+jJU8ShoFA=; b=TL/jmnxEo5qY44lhSRCOJRVjqrdxRYoFhzPoSslTkVVTlmX+FlXr3SDi16PBZw9z/Wn/SB U/OFcJGVworrBwENlc8azXjU4bXSBEUBXVJYK4hMUfbCTFVpxg1d0FfGKr78myw6wP1J7L pNHNhYudJIlnMKQJfbYQfSYQ0fTWkSY= 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.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-630-YOS__b5MPJCIUbCaTeaOaQ-1; Fri, 01 Jul 2022 06:51:02 -0400 X-MC-Unique: YOS__b5MPJCIUbCaTeaOaQ-1 Received: by mail-wr1-f69.google.com with SMTP id q6-20020adfea06000000b0021bad47edaeso302457wrm.20 for ; Fri, 01 Jul 2022 03:51:02 -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 :content-language:from:to:cc:references:organization:subject :in-reply-to:content-transfer-encoding; bh=p904tAF9K07KDnBScamIzcjJHAu8q9svh+jJU8ShoFA=; b=YKnTFzIHOLbEGhqfTxYi6RBq3pMs5s0Bwvd2YeFVYYyt9+xhKp1hF2kQRCeOa0xwun WjF7FcIZR1I2KSlm/mLo42G9GOUdouMKeysbuYQiZ2Yq7cRlYFDhXX8/GZa4M0KBrEa1 Q4t7dhFxqrkk1uqju7aegJ+2/6REmFRvkDRIxhhra5NKeLahjlASW4yuxMBceOqJib26 oxzo0TYNBvKQ7marMj3mViUwgL/dl4skzdf/5kYAMt2hYYXEeUH1v51leWdREQqdr5Eg uV8X3A1gGdaxXbhi4Wt5RETLkMonzOmn/Spjh1TOjFtnpSsJzv5zI+69fuISg6LA9J8I kF0w== X-Gm-Message-State: AJIora9SZmKH7OEzv+9lL0WXFa90sWonm11dys7Syl661PxeqaERGNz6 gpLvAUPlXniToyDPzD9KJZgCXiRBhL7y75DuEbTCsU4ml4JEzCsPp526KG2ptw1RS0McpmOboFq HLtDLIRh6nYw= X-Received: by 2002:adf:ce8f:0:b0:21b:b56a:fa24 with SMTP id r15-20020adfce8f000000b0021bb56afa24mr12806907wrn.173.1656672661438; Fri, 01 Jul 2022 03:51:01 -0700 (PDT) X-Google-Smtp-Source: AGRyM1uXGAZr8bv/H+/RffeNr9hvP5W4YiErS9Acr664i6euyTxz/QPSWJhY4kOvWisocUAt00R1SA== X-Received: by 2002:adf:ce8f:0:b0:21b:b56a:fa24 with SMTP id r15-20020adfce8f000000b0021bb56afa24mr12806876wrn.173.1656672661049; Fri, 01 Jul 2022 03:51:01 -0700 (PDT) Received: from ?IPV6:2003:cb:c709:e300:d7a0:7fc3:8428:43e5? (p200300cbc709e300d7a07fc3842843e5.dip0.t-ipconnect.de. [2003:cb:c709:e300:d7a0:7fc3:8428:43e5]) by smtp.gmail.com with ESMTPSA id a2-20020adfbc42000000b0021ba1b6186csm24658958wrh.40.2022.07.01.03.51.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 01 Jul 2022 03:51:00 -0700 (PDT) Message-ID: Date: Fri, 1 Jul 2022 12:50:59 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 From: David Hildenbrand To: Michal Hocko , cgel.zte@gmail.com Cc: akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, vbabka@suse.cz, minchan@kernel.org, oleksandr@redhat.com, xu xin , Jann Horn References: <20220701084323.1261361-1-xu.xin16@zte.com.cn> <93e1e19a-deff-2dad-0b3c-ef411309ec58@redhat.com> Organization: Red Hat Subject: Re: [PATCH linux-next] mm/madvise: allow KSM hints for process_madvise In-Reply-To: <93e1e19a-deff-2dad-0b3c-ef411309ec58@redhat.com> 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 ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="TL/jmnxE"; spf=none (imf17.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656672665; 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=p904tAF9K07KDnBScamIzcjJHAu8q9svh+jJU8ShoFA=; b=Ct2P3edkdfvpsOf0IPl/LxH7nVEIwvJ4mPQn1s3xQva/phpguATY80k2VBce9LrYP74K91 G8+XcdKj2FrkiFOvP0CbusoofMdJoCs4mk9K9Hh9+7S0cny+NWefOvMD5JEV7u8t5SW8Hb eSSSqSzUlFdxF61o6RmBTiGL1xxfsII= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656672665; a=rsa-sha256; cv=none; b=6u+grbtn32lDOQ6e3rgi9Thm/Kc3gaLp7KoEsq3oYUDWSCw606KwByPXAzrxqZKnDwzlkm 8DqWm8nEOKZS6kL2Y1oACVnY8L1Nmj1uTnkBDlvsYngILBZz5oHaxLK0FU3+ozwfq2EMHD I2X5gqT2mpadsi/1HrzeepKXLC2LE0o= X-Stat-Signature: 4n8u1rn38i5thmgu1j5bzich1uqxuu1a X-Rspamd-Queue-Id: ABAF840039 Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="TL/jmnxE"; spf=none (imf17.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspamd-Server: rspam12 X-Rspam-User: X-HE-Tag: 1656672665-499850 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 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. Further, if an app explicitly decides to disable KSM one some region, we should not overwrite that. I can see that we might want such a (VMA-wide? process-wide? system-wide?) overwrite, but IMHO we would have to make sure that a) Any eventual side effects (see above) are handled correctly. b) The app has an explicit mechanism to certainly disable KSM for a region (e.g., storing secrets) -- similarly to MADV_NOHUGEPAGE that ensures that there will *not* be huge pages. IOW, fixes for a) [I'm planning on doing that] and two sets of flags for b) to distinguish what the app wants and what somebody else might want. -- Thanks, David / dhildenb