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 07112CD4845 for ; Fri, 22 Sep 2023 16:21:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 778216B02E1; Fri, 22 Sep 2023 12:21:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 728966B02E3; Fri, 22 Sep 2023 12:21:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5EF8A6B02E4; Fri, 22 Sep 2023 12:21:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 4E8C76B02E1 for ; Fri, 22 Sep 2023 12:21:45 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 1E506B3AD6 for ; Fri, 22 Sep 2023 16:21:45 +0000 (UTC) X-FDA: 81264749370.28.830B9DB Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) by imf30.hostedemail.com (Postfix) with ESMTP id BD48D80027 for ; Fri, 22 Sep 2023 16:21:42 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=devkernel.io header.s=fm3 header.b=vhHMv1cQ; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=ZMACuU8A; spf=pass (imf30.hostedemail.com: domain of shr@devkernel.io designates 64.147.123.20 as permitted sender) smtp.mailfrom=shr@devkernel.io; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695399703; 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=l0GrjrIypWNrvLrMpjxWoVWk3qVTn1PfECewz++IatQ=; b=BgzWLlzndQ1JvOydqmMUJBXG6DDvvgfM4l+xIEjD69E2cGxXg+76TN+A2UA0KvbFIFuNmQ Y2+4C4l679Y5XaKygDO44K22996P0e9jFFaEiFD9y9JemjuJnoOB1j0fhchjzEOfj887FZ YAIiKxcNvSFOcrFZQDMzCsGv9UnoUxA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695399703; a=rsa-sha256; cv=none; b=7PwCI877UgkqUJlEHs/kGtg0mW2Q1raSJjmjiAr3E8QuNT1BvLcL+4C19hmrCmtRr+KbJR AyH5B2UkNGbNRz/ejF2D74EZyKrEaBKw2uz/YPEuFAdJHIWE8gd1d4FZYRBa+o0//G5yLK SflBIhJtb2RiX3cTGLMULRevH3JlleQ= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=devkernel.io header.s=fm3 header.b=vhHMv1cQ; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=ZMACuU8A; spf=pass (imf30.hostedemail.com: domain of shr@devkernel.io designates 64.147.123.20 as permitted sender) smtp.mailfrom=shr@devkernel.io; dmarc=none Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id D7CCB320085B; Fri, 22 Sep 2023 12:21:38 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Fri, 22 Sep 2023 12:21:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=devkernel.io; h= cc:cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm3; t=1695399698; x=1695486098; bh=l0 GrjrIypWNrvLrMpjxWoVWk3qVTn1PfECewz++IatQ=; b=vhHMv1cQnO5x40/4o0 uwiDeYjTh1i4iTha5hAYO1s5L/pZDueCB0K1EqkLRCLLOn+28cEx5WmcrHT4p/4+ AQCOE+M5MieT2k/PmX0ivu7nabxOTnx9BnlDBa16N637G6D6ouxAcvZUjWGBUWTy FA5PICARqWElUaPnuPFgb+HL2JCa3V3oWrUoLNZ52e153ZA0cvL46eXC0gZWJtgJ Pp8nDHrc9mkKy3wdugQ5lioB/JyE1DCrh6Mhp1IHwxPFefG547gbhT4r2xRBwFVu WSK9g1nU4Zs1l84NLp/HwXKvljHrEQRA7+RDnnEsEbi4wz3Pqo9FSnjqjqxPGHnv 7Biw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; t=1695399698; x=1695486098; bh=l0GrjrIypWNrv LrMpjxWoVWk3qVTn1PfECewz++IatQ=; b=ZMACuU8A891NRckNQxCOedNH5smy4 RpnglAwhGqfZGPul3JRi83iOOoG/wVygaInrp6Jw9M706+6ksemWfvAloCXlP7t3 9DTssfCDY2v22irBFMSWrxVTo0wHdSahgbhN/vN4iGbxC8iTrKbkPm/is+FK0vIV aFp/DDD0WF+/FYaON92uq0n68/qpncnZH1nJSTkG7GS6Wv1/7ebEEBkqZ/FbHtlq yWnjKEJjDmyTUuKMCSxWAn2K17J1Y+mDwn68kXenU7bqfTI7vJIT5ibw6OR+7dyo 22+AyxgKm4d5NxchDwJsPjvMMH84HnkSmHf2qHAwWSUnnHcKV7sc2p/dg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudekkedgkeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpehffgfhvfevufffjgfkgggtsehttd ertddtredtnecuhfhrohhmpefuthgvfhgrnhcutfhovghstghhuceoshhhrhesuggvvhhk vghrnhgvlhdrihhoqeenucggtffrrghtthgvrhhnpeevlefggffhheduiedtheejveehtd fhtedvhfeludetvdegieekgeeggfdugeeutdenucevlhhushhtvghrufhiiigvpedtnecu rfgrrhgrmhepmhgrihhlfhhrohhmpehshhhrseguvghvkhgvrhhnvghlrdhioh X-ME-Proxy: Feedback-ID: i84614614:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 22 Sep 2023 12:21:37 -0400 (EDT) References: <20230921164709.3627565-1-shr@devkernel.io> <20230921173251.54b854fb0ec7af2bf3e3ec3b@linux-foundation.org> User-agent: mu4e 1.10.1; emacs 28.2.50 From: Stefan Roesch To: Andrew Morton Cc: kernel-team@fb.com, david@redhat.com, hannes@cmpxchg.org, riel@surriel.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v3 0/2] mm/ksm: add fork-exec support for prctl Date: Fri, 22 Sep 2023 09:08:41 -0700 In-reply-to: <20230921173251.54b854fb0ec7af2bf3e3ec3b@linux-foundation.org> Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Queue-Id: BD48D80027 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: pwex65pjrnu4fw8f995tzo9dud7dbmpm X-HE-Tag: 1695399702-910133 X-HE-Meta: U2FsdGVkX18+Tfj1Y4/bIDfh/uhf7PvkB/vC8pRuD3jCOdK/pDU0EfweTy6nYDDTUasZafAKq/EPq6ALTxbLsFqNoXPs9nXCcSgq3z997OCODIMMDz54CAf16poGc9tkyMhS6F2Jw3HueeLePmAMGJC6pzmoC/seIMBlKdw/55K4juTCZY8Z4XQn37q+LyxpZS/0aTZTf81v9r7fCD02CLFnoiUMuw+f1ZphhKRgROV4z0/pGqpFD1AL/fAbZ9V/BeFIpI8D4XX/Ki/MNhrMmXWGbgEyI/doVBtmIhcr6d1DdFour0YrCGwTcYm2sdPC8JAjI7XafGtArHGgjpXAo+BPVetkyueHTp5VdQga1dt7UlmcXzQmPiARcpacQLxshr50T7EbjjTTQ02+ZVX7VaRMcLxYG+n3ANqu3A+ClViAFn+hoTxg4TSU/aFg3vdy4ozqeGHIw2JfwVdjwP1xj2ZFepC5V3elc5HeknOQe9Jer8phVqg6bymDhWvRj+Zo9+gp0tJVqAVdUUwq2ZrWSjV+TZU943JsMp5ux1QaWO4w72uAlF2Q/pvxfebd1Dch/Xcyd3nb2vrDiQ7jWvaRUMgayiksrO1wc8gQKAGXbnd3vm3S7mi2X8cwocTCPB/hOCU/345CSQmuYcPsm1ZhcIoh5pSzsuMx4RPFsKJu0Ekauso20dp3udeqYrOB2pf52yvjJUGtbVYR/wDIZCqeUcAX+mwYLXFhbI3+MBVCel3YGedrxg3w+MFsJuR4JtoEZSzd0YCEHacYvuu5Mevc139mY0XJ6OUNNwg5QJTrP68Mu3b4M9b/4x7UU/bRiZ5fVuKQoq2Ku8uuc1Lmaj0QZfAKpjCN+JLPuKIlzqJy0+BL+q58nPv0KbMxt015RDcr7MB3I5FuwVDywcnXg45sYcfO0kOrkpSWvq0AK8chn7jhhxUVeJbZIwj6rcI1FhCUJpSkXruTZQXv3t7RQYQ 2wZweKOk kx60QQ05I+0xZCJOSRVVVC6WEpYrj2TC7z39M8ZgeavLlwD3efl0D1buQFrlS8tTAZ3/SM5M3tPAzmpH6zwQMfeTlaal9IGDKZPYxVb7g0gQ3ddiztxJFk1Of6XmB9gfQM+EkNRr0MZTo+09J6IQj1EMyjzCSa1X4Gzdf2ycfez9gIRETcQrnGMCAgGdIMZK+pOa8uocTazkDuvePe9EZVJhJnj9TEgTqr/d9 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: Andrew Morton writes: > On Thu, 21 Sep 2023 09:47:07 -0700 Stefan Roesch 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.