Message ID | 20230921164709.3627565-1-shr@devkernel.io |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:172:b0:3f2:4152:657d with SMTP id h50csp5182165vqi; Thu, 21 Sep 2023 15:36:28 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHC/LtFs7z8gc7Vw2QOJG7BH7txZbsQlcV4z6Vjmi+Dm6jb4yUCAcNupIuftExt5TFJtLk7 X-Received: by 2002:a05:6a00:815:b0:690:3a0f:4164 with SMTP id m21-20020a056a00081500b006903a0f4164mr7823237pfk.19.1695335788206; Thu, 21 Sep 2023 15:36:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1695335788; cv=none; d=google.com; s=arc-20160816; b=IzEZToZOWeffKYUqLElVDQ8s6bG9LnG/aYCAHD1QAuh+iBQOEc+fzK+20Zq+ORU8+d BLlJcdqzUgkCWwa7ructfQhqkqea6R2U3kYwULJk82PBZa6U+s3GDkYs5dRtC0sKZvZm ol2FZiKef+Ip2/4KDdSowmJVMg1l48viFUgir26h8RpPjCm1vnoaqMh52NBBGnib06ZM v1RvPDHNr09oTNLVuT5yROec+25hXn1tUS99fj8poZc4czwKOC8jGBmHS/of4GYYzOVD 1vhTUQ/Ryjp8Qf7f/33A8u4YD1ODDXNDH7Q/5bwv6T6Oc8pl/evNHJ1ydMak5ziGUY8w nyKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=Q5eXsN6o+cp0dRU6wJOSguQAuugpqR6at+DPeLAQPVg=; fh=sS+J4OyOC0EcVLWJpS3mBHGeO+0+dYZJ+ImCUfzsrH4=; b=FRLG/oyHyaNjKUfQdUWovntrJ43Vft50V4TCiecQGyRQb7H/WKoW2EpsJLVaClgQwJ l5Y45ZEPDtXjEJ9/B2lLEaPc/BHnZ1VKv0ogmxMUz/+hwFnQGX8f9uCWYZsSqbHQcH2Q iELGUJZs7jbFn7+bG6LL1FxKE5coAZ8lAtx68P9iR3k4jCyErMXEmmZKUwsQtyU8Tp89 bPXUebXmLyDll/q+hqNgLclRJCRhHhOOYfv6ewiGZlyT/T581x0BhRG8lY8arFl+9/Ru 73H5bRugkqfaMc3DWewtV1R86xqcVoOqwB0SyEOBx1A5New8f+kYsgyiMotX9cC7Wdqy c7jw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.31 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from morse.vger.email (morse.vger.email. [23.128.96.31]) by mx.google.com with ESMTPS id x24-20020a056a000bd800b00690d42e3347si2205604pfu.157.2023.09.21.15.36.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Sep 2023 15:36:28 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.31 as permitted sender) client-ip=23.128.96.31; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.31 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by morse.vger.email (Postfix) with ESMTP id 2BDE682B1E47; Thu, 21 Sep 2023 15:21:14 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at morse.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233231AbjIUWVI (ORCPT <rfc822;pwkd43@gmail.com> + 29 others); Thu, 21 Sep 2023 18:21:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36122 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232373AbjIUWUp (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 21 Sep 2023 18:20:45 -0400 Received: from 66-220-144-178.mail-mxout.facebook.com (66-220-144-178.mail-mxout.facebook.com [66.220.144.178]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7A3E97A8F for <linux-kernel@vger.kernel.org>; Thu, 21 Sep 2023 10:10:24 -0700 (PDT) Received: by devbig1114.prn1.facebook.com (Postfix, from userid 425415) id 6C37DC502486; Thu, 21 Sep 2023 09:47:11 -0700 (PDT) From: Stefan Roesch <shr@devkernel.io> To: kernel-team@fb.com Cc: shr@devkernel.io, akpm@linux-foundation.org, david@redhat.com, hannes@cmpxchg.org, riel@surriel.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH v3 0/2] mm/ksm: add fork-exec support for prctl Date: Thu, 21 Sep 2023 09:47:07 -0700 Message-Id: <20230921164709.3627565-1-shr@devkernel.io> X-Mailer: git-send-email 2.39.3 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on morse.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (morse.vger.email [0.0.0.0]); Thu, 21 Sep 2023 15:21:14 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1777688419617803644 X-GMAIL-MSGID: 1777688419617803644 |
Series |
mm/ksm: add fork-exec support for prctl
|
|
Message
Stefan Roesch
Sept. 21, 2023, 4:47 p.m. UTC
A process can enable KSM with the prctl system call. When the process is forked the KSM flag is inherited by the child process. However if the process is executing an exec system call directly after the fork, the KSM setting is cleared. This patch series addresses this problem. 1) Change the mask in coredump.h for execing a new process 2) Add a new test case in ksm_functional_tests Changes: - V3: - Combined two lines in function ksm_fork_exec_child() - V2: - Removed the child program from the patch series - Child program is implemented by the program itself - Added a new command line parameter for the child program - Removed new section from Makefile - Removed duplicate ; charaters - Added return in if clause - Used PR_GET_MEMORY_MERGE instead of magic numbers - Resetting PR_SET_MEMROY_MERGE at the end. Stefan Roesch (2): mm/ksm: support fork/exec for prctl mm/ksm: Test case for prctl fork/exec workflow include/linux/sched/coredump.h | 7 +- .../selftests/mm/ksm_functional_tests.c | 66 ++++++++++++++++++- 2 files changed, 70 insertions(+), 3 deletions(-) base-commit: 15bcc9730fcd7526a3b92eff105d6701767a53bb
Comments
On Thu, 21 Sep 2023 09:47:07 -0700 Stefan Roesch <shr@devkernel.io> wrote: > A process can enable KSM with the prctl system call. When the process is > forked the KSM flag is inherited by the child process. I guess that's logical, as it's still the same program. > However if the > process is executing an exec system call directly after the fork, the > KSM setting is cleared. This patch series addresses this problem. Well... who said it's a problem? There's nothing in our documentation about this(?). Why is the current behavior wrong? If the new program wants KSM, it can turn on KSM. This significant change in user-visible behavior deserves much more explanation and justification, please. Including an explanation of why it's OK to change kernel behavior under existing users' feet like this,
Andrew Morton <akpm@linux-foundation.org> writes: > On Thu, 21 Sep 2023 09:47:07 -0700 Stefan Roesch <shr@devkernel.io> wrote: > >> A process can enable KSM with the prctl system call. When the process is >> forked the KSM flag is inherited by the child process. > > I guess that's logical, as it's still the same program. > >> However if the >> process is executing an exec system call directly after the fork, the >> KSM setting is cleared. This patch series addresses this problem. > > Well... who said it's a problem? There's nothing in our documentation > about this(?). Why is the current behavior wrong? If the new program > wants KSM, it can turn on KSM. > > This significant change in user-visible behavior deserves much more > explanation and justification, please. Including an explanation of why > it's OK to change kernel behavior under existing users' feet like this, Today we have two ways to enable KSM: 1) madvise system call This allows to enable KSM for a memory region for a long time. 2) prctl system call This is a recent addition to enable KSM for the complete process. In addition when a process is forked, the KSM setting is inherited. This change only affects the second case. One of the use cases for (2) was to support the ability to enable KSM for cgroups. This allows systemd to enable KSM for the seed process. By enabling it in the seed process all child processes inherit the setting. This works correctly when the process is forked. However it doesn't support fork/exec workflow. From the previous cover letter: .... Use case 3: With the madvise call sharing opportunities are only enabled for the current process: it is a workload-local decision. A considerable number of sharing opportunities may exist across multiple workloads or jobs (if they are part of the same security domain). Only a higler level entity like a job scheduler or container can know for certain if its running one or more instances of a job. That job scheduler however doesn't have the necessary internal workload knowledge to make targeted madvise calls. ... In addition it can also be a bit surprising that fork keeps the KSM setting and fork/exec does not.