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 C4197C4828E for ; Fri, 2 Feb 2024 20:57:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C9A086B0078; Fri, 2 Feb 2024 15:57:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C21966B007B; Fri, 2 Feb 2024 15:57:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A9AE86B007D; Fri, 2 Feb 2024 15:57:16 -0500 (EST) 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 95C366B0078 for ; Fri, 2 Feb 2024 15:57:16 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 696651A1044 for ; Fri, 2 Feb 2024 20:57:16 +0000 (UTC) X-FDA: 81748074072.06.BC94CDB Received: from mail-ot1-f47.google.com (mail-ot1-f47.google.com [209.85.210.47]) by imf21.hostedemail.com (Postfix) with ESMTP id 9CEB11C0016 for ; Fri, 2 Feb 2024 20:57:13 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b="dEuthNx/"; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf21.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.210.47 as permitted sender) smtp.mailfrom=jeffxu@chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706907433; 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=jd5iB2GW7u96qhDXLTaDLBHJW+CgTFsPG8xtoncLIv8=; b=F9NmgMb3LBd47Gv1Aq0kISiymewMwCP9IQzm511yqJ5EATzsYCVINzdHmQmWxLqA6mDC0s 9rWCWV13/49BLwknUw+ykzloX74cZh6onRElGg2WwC/isxAOc6wsq2fZGLCWhF9ebzJENV QI+ESSHmlXRF7UhuYKnANiwMXGqH4Ps= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b="dEuthNx/"; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf21.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.210.47 as permitted sender) smtp.mailfrom=jeffxu@chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706907433; a=rsa-sha256; cv=none; b=C9BkRLTfeP95h7TC5u8q3HmVUc71L7DXwy1hoQ/mDIMPfntblWFH3LoH6Lf24L//0W9WqV 4K8AhjQ+mrPHbScF197CZUI206SiUK54YMQAlZ6cS8/sJi0yV3xlRwKIfCfkGchzTfFb3T qRu9BiEVVIoIEO981tYxOTsTbRr7lYI= Received: by mail-ot1-f47.google.com with SMTP id 46e09a7af769-6e12f8506ccso1392705a34.2 for ; Fri, 02 Feb 2024 12:57:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1706907432; x=1707512232; 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=jd5iB2GW7u96qhDXLTaDLBHJW+CgTFsPG8xtoncLIv8=; b=dEuthNx/S/s0UJMhNNx0dVpVVYLmbzSpleIRpEY8UeAETKzSDiEYEKnDjodRDkTzKg M39gJ7dpGwFNdQIP/gNAgttA7d4GdOwN0/7UcUHtOIVdpym8c4+qCVDFc6cnKqLfjDs3 00FN85D3tLP4V62cNcR5TJlXuGoO3Y6pXAPZQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706907432; x=1707512232; 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=jd5iB2GW7u96qhDXLTaDLBHJW+CgTFsPG8xtoncLIv8=; b=YFWtc3ilMdmi8aks5MGUJ5noFT8MA4e7qJFe4mJu4ulO2JxU7mZWc+gASb/OHBLNB7 xNO1g1wn54PWPkZcXF+Zn9bPGGU7XoWuz48XxI/GlEJR6ISEkgoKEiNmgvYIFBYcYvSe s+gmxer5Ddn/NQuXOIWxjSYnPiAGapQzAHMAS0znNi7hLiYbKsM37qKCO7hOFDWuI2Ih l6PRbZlehH8RR/Wn2TBImYlCjxiIuWIaFLFv7pNoIq7L6/TH30TQJWWuuw5gvVBGY13+ BO8Z/FI/NK0Bb4RpwdRK460AyjgX8G6IT5V2VECozTW7vBA4Zk5vuX7wcLEBZ2O8KDyB IKfw== X-Gm-Message-State: AOJu0YxG3lYXwuMsQYf/HroFuj+XWrRu7P9EX/IGCBqLStXxSV+5QiCq diZHaOJmqlt5QFygDI0sMY0mT1EZ5S5uXsIAqjkPvhbzyfhxaFIq1avPxezVQcMqX2alH+1gkbo 9Vvd9u4QsqBfLkld5QT/IbAzJOqNallWj8yex X-Google-Smtp-Source: AGHT+IHD+GETF8yRafyaSp/X/xP7FsjAotm5fR7M2Zw0jtBAVo9XvmOEOv+rES1WAYdj2NtLbAOCDZfOEWCOvlbcyl4= X-Received: by 2002:a05:6870:96a1:b0:218:d1d4:78a9 with SMTP id o33-20020a05687096a100b00218d1d478a9mr871537oaq.24.1706907432643; Fri, 02 Feb 2024 12:57:12 -0800 (PST) MIME-Version: 1.0 References: <20240131175027.3287009-1-jeffxu@chromium.org> <20240131193411.opisg5yoyxkwoyil@revolver> <20240201204512.ht3e33yj77kkxi4q@revolver> <20240202151345.kj4nhb5uog4aknsp@revolver> <20240202192137.6lupguvhtdt72rbr@revolver> <85714.1706902336@cvs.openbsd.org> In-Reply-To: From: Jeff Xu Date: Fri, 2 Feb 2024 12:57:00 -0800 Message-ID: Subject: Re: [PATCH v8 0/4] Introduce mseal To: Linus Torvalds Cc: "Liam R. Howlett" , Jeff Xu , Jonathan Corbet , akpm@linux-foundation.org, keescook@chromium.org, jannh@google.com, sroettger@google.com, willy@infradead.org, gregkh@linuxfoundation.org, usama.anjum@collabora.com, rdunlap@infradead.org, jorgelo@chromium.org, groeck@chromium.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, pedro.falcato@gmail.com, dave.hansen@intel.com, linux-hardening@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 9CEB11C0016 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: zcmr1jsm6kuduq8as11j3x1qh4ffxyyh X-HE-Tag: 1706907433-129381 X-HE-Meta: U2FsdGVkX1+qHAEBvM73IIP7YF4LbPireJyCcnAGxeoDUW7BHm1FTPJ5TEDeHOzg7ogDLzC/lJ/QMojRTmNMDIAToyODItynVC7MvbxD8sGHZ61BIDbylCWPUZUBjUqr09sKnECDmz8BqYr6hD0vwKinzdzkbfyFYqt0cgnGoMFYmoBjH6T0GjQ4D/e88Xn6AH0XZk2FMt4pOfL7aLYDwagBXnuuVixphEWvm5MXW4lAjX9LDkYtsyBtt34g6/Q1IN9mMt4tkq4DOK3/v51mbfzHxDL+JWzoV1onEE2BWRhvJJb8PXCB862rFG99TvyuCAnbYghLH4GhF8uf7QT5jW7SWXwdYMChUNODj9UtKU2s6bH2CpIRnltq3LD6VyxKPuSxZFcBhFUS8mqPjub+DAedYzKRjsXzY8YrOUyS6V1r5OltJmI5nCH5F2gaVjkcv6LtHse7DQIjNHZ2lsaWPDOzCPRGfzIOPISK/hFecpKB6y5rsFwgP3UHCrw41qzic3qTzQPNAkMtUU6VxblWlG5km2TJB1y0ZNucVEoUIdrToV61nOBFS686gTNX0m0stLFsun4++POo+DHhwnJFPQ/7av0b991wTvs30TvW7tqYJOrQ+Vr9U0tqvBMgwwbQfCrQ4U5P5wOxL+QxKD2ogm/03ac17N+7nKo07ubMWRShthle5QZBVrJs/ucLNkGufmM+ZaJuJS2pWORECWQ6FCeG9+rCPFYZPAn324n1naj5P42x+02XhFWcC7Dl9DYl6s+It+1vEZXQWsYC52bknyJAQ6hU6lhLV3/pfXXGgmEnkG3S38LeO3kHcOstaOlRP5uGja0vRdGZRyAa2ZND3nCsetPf2B8U4XaJoBqS7IOXpV3uhAY92iGJ9Kg7B3a9mlaqUQt5AW0AeNljmZB7m+YRj5mVzZaQX5o1/6KU2LLROTf5I9tCSesE/PNjQryHG2ZtF4t+j4V1jVgMOcH 4L550cPU 3oFzCw+JJ5AMuzanRklxlzjUNsAX58jh64fghx95Tjzf33wqmFpK6m3G2VHqk6mtBXFpTkDuWT5ONuN2o23XlTtHERtncaNIt6oRnBMX1Pw0C7YipNLsG5l2fRjyzDA858lwp09nRQU+wQ7u6EDhJ1J/gQFd+zzopyCyNKIzugNZL4aps5Xq2AXjpamf75SOFlxLrzzDujBrSnqt5TFGGiSnxz1z/T3KdZw6Vp48UjNBniawqRMCqmjdfuE/48mtor5CWUuAR0AZG6japts1jLEGGfuIThb12wUQYeA5InlRCxMuMM4NPImG1/Mh66JzPv/eT8IALIzTv6c/56jGVteDDotqUmC+k8qYY2TwpG4aSrzzn5F9k06gE/PojHbneG0L3dB6U/bXd4JRjiKlBny4jjoxU9wQBnY2H X-Bogosity: Ham, tests=bogofilter, spamicity=0.000897, 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 Fri, Feb 2, 2024 at 12:37=E2=80=AFPM Linus Torvalds wrote: > > On Fri, 2 Feb 2024 at 11:32, Theo de Raadt wrote: > > > > Unix system calls must be atomic. > > > > They either return an error, and that is a promise they made no changes= . > > That's actually not true, and never has been. > > It's a good thing to aim for, but several errors means "some or all > may have been done". > > EFAULT (for various system calls), ENOMEM and other errors are all > things that can happen after some of the system call has already been > done, and the rest failed. > > There are lots of examples, but to pick one obvious VM example, > something like mlock() may well return an error after the area has > been successfully locked, but then the population of said pages failed > for some reason. > > Of course, implementations can differ, and POSIX sometimes has insane > language that is actively incorrect. > > Furthermore, the definition of "atomic" is unclear. For example, POSIX > claims that a "write()" system call is one atomic thing for regular > files, and some people think that means that you see all or nothing. > That's simply not true, and you'll see the write progress in various > indirect ways (look at intermediate file size with 'stat', look at > intermediate contents with 'mmap' etc etc). > > So I agree that atomicity is something that people should always > *strive* for, but it's not some kind of final truth or absolute > requirement. > > In the specific case of mseal(), I suspect there are very few reasons > ever *not* to be atomic, so in this particular context atomicity is > likely always something that should be guaranteed. But I just wanted > to point out that it's most definitely not a black-and-white issue in > the general case. > Thanks. At least I got this part done right for mseal() :-) -Jeff > Linus >