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 97BB9C54FB3 for ; Thu, 29 May 2025 18:50:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 20A9B6B0085; Thu, 29 May 2025 14:50:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1BB376B0088; Thu, 29 May 2025 14:50:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0A97B6B0089; Thu, 29 May 2025 14:50:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id DD4286B0085 for ; Thu, 29 May 2025 14:50:45 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 5B32EC0EF5 for ; Thu, 29 May 2025 18:50:45 +0000 (UTC) X-FDA: 83496836850.29.4F3E0D7 Received: from mail-lj1-f182.google.com (mail-lj1-f182.google.com [209.85.208.182]) by imf05.hostedemail.com (Postfix) with ESMTP id 4E765100004 for ; Thu, 29 May 2025 18:50:43 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=amacapital-net.20230601.gappssmtp.com header.s=20230601 header.b=ab5LMWD1; spf=pass (imf05.hostedemail.com: domain of luto@amacapital.net designates 209.85.208.182 as permitted sender) smtp.mailfrom=luto@amacapital.net; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1748544643; 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=cZR+bV/RpEv69QT29h8o3+icO6BNVEjRkOnd0TqgTeg=; b=qMCAlnetO/VNYvfwhM9sqOv64ZwZ7S7/Sx6WNKGebTQAIwuwrMc9GhbzK+29shPAHZLslP pPHwBL5Fnaf169PfuaLrN8H/8dJyqimnsoJZWTxdzMRU+Hu3823JbL1FZZbW1qS5R0CAcB XnSWTlMfEERCUy7ANrlnLE4zrtZp5jM= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=amacapital-net.20230601.gappssmtp.com header.s=20230601 header.b=ab5LMWD1; spf=pass (imf05.hostedemail.com: domain of luto@amacapital.net designates 209.85.208.182 as permitted sender) smtp.mailfrom=luto@amacapital.net; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1748544643; a=rsa-sha256; cv=none; b=iDw4sKd+mckoSjG2S4eMtsS5MbyTicV1Nw56P3gzb061bFQiQ9+NmJdo23XfuN9+3ddDO7 F6hrg6/rwUG+o7ex8ZqUuwZ+foJPfmM4UmAm9qUz6VGcv/dbpMtQIPM0raePOQ+VrduALw HERukMlyu5DYok4+NSXw1eySP7aItvk= Received: by mail-lj1-f182.google.com with SMTP id 38308e7fff4ca-3105ef2a071so14574371fa.1 for ; Thu, 29 May 2025 11:50:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20230601.gappssmtp.com; s=20230601; t=1748544641; x=1749149441; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=cZR+bV/RpEv69QT29h8o3+icO6BNVEjRkOnd0TqgTeg=; b=ab5LMWD1Tcjwr2US/8NZePVAXxP/PJ8NoEp4+VA6u2R4szOaHoV9fSFTLAm/pGQdaK n+rUnXFbsNwDTgrszynvK/CTPIA2RWmHVmlVj1lHEAkTTa6438sbcN9CgKDWr8J1K1cI g0QV/shu5am4X5NDw0FLVimPkoVDyZIVCER10EoXwcLCdhrycX8AoUK7pfR4qdM2qjR3 j0rBLEZxk+guXW3ES+HSzZauXpqnvH8AASZgakAUUpoF/AlEColFnlVjUid8wuRPqJXz tU6H8iJl3YOksQ9OAgu/KdP3frmrffUDC5nJ5Q8fsgOjqAb4zDG6o0P73NQtgTVEvCp/ YQcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748544641; x=1749149441; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=cZR+bV/RpEv69QT29h8o3+icO6BNVEjRkOnd0TqgTeg=; b=k0b0zjTbTdlVSPD30BIp0OnILgRhRmRO78uXpFl1wNJ8s8IjcsvHxcqkH5o0l9uM7g RLNUEwf4TTgmX+NxZbalTp48Rdgm+7Gd7T7LPhGwt8OqMSD14FfZnFouVqGoidQ5cx34 idw7H69BfdgC6P3Xp6Wtdg6m7SYN9vVSCULa+P9aQ48IXHDZlL1RIoIqTgDwS6lzi/YT mjvR1kWMSEOETLqaKuNbdChOafAncisSkQxrsprss7z8oxg7DzEZXgx+3NP2gHEFntko Yg2k6C7K0E3Noq6o1A4ibYLgDErsY84S6Ph9D4sIfzDIgggncCraO2mEklm0TLQ097n6 YjrA== X-Forwarded-Encrypted: i=1; AJvYcCXCIi54l+MQJE11Nj8dF3BQ+1f78dCX/Wu0u8e6uFSrWYdfN/0y8hyIpV+4dlQ+TUTo3/3cH7veeQ==@kvack.org X-Gm-Message-State: AOJu0YxKliCIDVIapG4DcS/FQ0mB19b1glgki/sf9ke5mJlDdXHXPNhL waP8UMTl/ZHorc9r7X1JK3jzeHwLDJvMcY4cc8fvQ+QlpZ4lVit4HoTvS+FI7H4jmF9Y75exCZ6 Q24fu73n5Fk3Ec5cmOtJ3aSYlNcl8v2Hgwc8Ib7jq X-Gm-Gg: ASbGncu+eNUarBWfkTLTgQLIOfIV8Vk1NHbq2R55CEbyqNHaHoZlAdeEzhSt4PzQAut kH7sAhkwkrz5X37fT+pXAjbzDigxpsfbPpwplUYdQ6I/reUHOxzjjaT1wkT6lyME1Syg9BwLKoc 4cPeM36mh/23NXnB8ZXW2ugrtSUjJTpiO+hYNbeSRhZA== X-Google-Smtp-Source: AGHT+IHvzZNFmorgbMvPjPmVBKaNoD8JL8vbWNjA3kvxqIbWCqlAQjdL2EaLHdbNkYIonfwMKxJEVmqVJFx1wvfSHiQ= X-Received: by 2002:a05:651c:3050:b0:32a:8631:c41b with SMTP id 38308e7fff4ca-32a8ce7ff5cmr3131261fa.40.1748544641324; Thu, 29 May 2025 11:50:41 -0700 (PDT) MIME-Version: 1.0 References: <85778a76-7dc8-4ea8-8827-acb45f74ee05@lucifer.local> In-Reply-To: <85778a76-7dc8-4ea8-8827-acb45f74ee05@lucifer.local> From: Andy Lutomirski Date: Thu, 29 May 2025 11:50:29 -0700 X-Gm-Features: AX0GCFspfSh1KbGnhihvv0QMDvvSEVkz0UOx1CDZtHwOavk_KVICQNzB6RwmT6E Message-ID: Subject: Re: [DISCUSSION] proposed mctl() API To: Lorenzo Stoakes Cc: Andrew Morton , Shakeel Butt , "Liam R . Howlett" , David Hildenbrand , Vlastimil Babka , Jann Horn , Arnd Bergmann , Christian Brauner , SeongJae Park , Usama Arif , Mike Rapoport , Johannes Weiner , Barry Song <21cnbao@gmail.com>, linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, Pedro Falcato Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 4E765100004 X-Stat-Signature: 33h6khwqzt4kz9bo846jqkqps8nget7t X-Rspam-User: X-HE-Tag: 1748544643-255466 X-HE-Meta: U2FsdGVkX19c7j17LdjPaDTvGTiQ+ZcwZ/6o/auG18U6pOr7M5Srriu7FQItfol4IJmlobb9hs06zxXWvSfb3SrtCKbu2ivcokEGY64OFN1d/fk2heH0VHtmAkoMKudSmsKb6S+HqktK1Ffy/PA1XKBYto8tEnLjai5vh6I+SF649Hhe0QJ2HJ5mWVrsZs/XzeXcaHWQott457V/z7/R4SUwc9v/X4Gx/pjiGQWXO2fYUSV8XvB44XvSyK2xd/wl+yM2xucDoFq1U3UY+dKU3UKlZm1HGbDgObq51whHsrmg1fZxFs0D6kigP+e9IA3vVuW56Bv9rRY/GQWWlh1djV8Mtl1K9P9NhQbKKhNNfUsfVzm36u49j4trhhxE0TU65XdNaPP47YEYxmcby9ltzfMh1uxIpFSFNt0ztyfPIliASKOcsFVeMCHkJ4128o9fLuzeJLvd9SQxF3mMr4LawIR+qV3lZafIrvuJzMoHrNV6OJspLI7CamkmjuhRERq0K79GToMo02CnYA3gbzJE0zQNIZ6O3gEOXcD6/1YyxlcOUZ0h0Pm8TnVCSFcD7IJbN9LLwmxnn2hKgedWyNwm+INeuoHDIkDVutQbJkp6//mxvTT7PzbzvMOECtlQe49vPRXZbqoEKxDXiswAMPvrnz33f352xszFW2sOngVslhsfuRu2GSxQdtTrzy1/lQSf3oEZIdj1GCImH/8IOekptsPPZFN4LW5qUP4bYU76YSBrxEFLGK95adeVBw6j2E+rGf2jk2vfWG866TXU6wqzZPLUFY5+KfRP7mgeObW3AAQCA09OZAsW/ONppso9eHRiXnZ083ynqj/FD4XyWaTSPjUw7pPF7TxWgTnHkXnjWLXyGRcYzKtGo1+oJqGxpLIWRQhdIT04FMvXRkPugYMWX/bp28aIT5PMHa6c6oftL4/b1qL2RJBIvP/4QAcmBNhP5QcKTc8KMeC44KjUc9U cRJ8s/Ex tDvQaBA7RAgJffELjy4oZNbU7b93g1Oh/1RfAvyOhvJoVQOxXu8+/XK+c7aPFU5jv9Ef+hXXeZhPPMf9+fsEfzNRtBPHcntZGHaFwJYkD+FzSM+7aRmseDweIuADfi5wRxS+Sk4LBTUF0+Crh2IG7b7x0OApT6bDMb0LcCoMaYyOgYPDK8JEfuI2dBdrNRN5+xpYupW3UOxtc/XkYXh4GITFmKo6KyauPd1DfeELU6bHk9bkFyL/yDQTWkZLHWnGQ83/2zvt0Oe5WeWdJEeRW3YbkwA== 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: List-Subscribe: List-Unsubscribe: On Thu, May 29, 2025 at 7:44=E2=80=AFAM Lorenzo Stoakes wrote: > > The behaviour will be tailored to each action taken. > > To begin with, I propose a single flag: > > - MCTL_SET_DEFAULT_EXEC - Persists this behaviour across fork/exec. It's hard to comment without a more complete proposal (*what* behavior is persisted?), but off the top of my head, this isn't so great. First, the name means nothing to me. What's "default exec"? Even aside from that, why are fork and exec the same flag? Beyond this, persisting anything across exec is a giant can of worms. We have PR_SET_NO_NEW_PRIVS to make it less hazardous, but, in general, it's risky and potentially quite confusing to do anything that affects exec'd processes. Oh, and this whole scheme is also potentially nasty for a different reason: it's not thread safe. If one thread wants to spawn a process, it should not interfere with another thread doing something else. So making an mm flag that persists across close can interfere a bit, and persisting it across clone + exec is even gnarlier. For any of these, there should be matching query features -- CRIU, debugging, etc should not be an afterthought.