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 60A9FC5475B for ; Fri, 1 Mar 2024 04:18:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DEF346B008C; Thu, 29 Feb 2024 23:18:34 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D9EB26B0093; Thu, 29 Feb 2024 23:18:34 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C3F5B6B0095; Thu, 29 Feb 2024 23:18:34 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id AD6836B008C for ; Thu, 29 Feb 2024 23:18:34 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 763591C0BBD for ; Fri, 1 Mar 2024 04:18:34 +0000 (UTC) X-FDA: 81847163748.25.D338DBF Received: from bedivere.hansenpartnership.com (bedivere.hansenpartnership.com [96.44.175.130]) by imf02.hostedemail.com (Postfix) with ESMTP id 92C7380005 for ; Fri, 1 Mar 2024 04:18:32 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=hansenpartnership.com header.s=20151216 header.b=i8ileHlr; dkim=pass header.d=hansenpartnership.com header.s=20151216 header.b=i8ileHlr; dmarc=pass (policy=none) header.from=hansenpartnership.com; spf=pass (imf02.hostedemail.com: domain of James.Bottomley@HansenPartnership.com designates 96.44.175.130 as permitted sender) smtp.mailfrom=James.Bottomley@HansenPartnership.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709266712; 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=JG4HE5UGSQa2tCJPcaW7PMgBhTwjZHcFr5bK0vH06uQ=; b=ZRozEBt1QwFt1tQ/cMiNksiCwO7mm5s/Z36Ljj0hefjw5zDOl/xqGe35YXF3aq5PDuK87r Nzv6lAHTxaGYIMlmpcccxa0uEoJAXFKxzfudIguGOjThnXxplnNLUnlhEryTp9eWMDJdPr sI7asFEQKFhQuaGtoP/m33+q28B24pg= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=hansenpartnership.com header.s=20151216 header.b=i8ileHlr; dkim=pass header.d=hansenpartnership.com header.s=20151216 header.b=i8ileHlr; dmarc=pass (policy=none) header.from=hansenpartnership.com; spf=pass (imf02.hostedemail.com: domain of James.Bottomley@HansenPartnership.com designates 96.44.175.130 as permitted sender) smtp.mailfrom=James.Bottomley@HansenPartnership.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709266712; a=rsa-sha256; cv=none; b=NEfo+VQXiiqCu7DeGpj+S94h17/Kav2o+oycCCWTs0hm5tXfHSsA/5avKEcRhKwO/3gtuo znju2Uh2YENwKKwn0UqTYUoq1hq6IrWujTK1cfbIKtvUdAd1dEGcX3Pl7EzIEZoOEIiwQE mDgEQ7M7fXepKuHPM0eVkUGYB6D52/8= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hansenpartnership.com; s=20151216; t=1709266711; bh=5p/LW4JS1Y5FbVnk8Z/1edS2WpghYxTfo3KlO7AiO7k=; h=Message-ID:Subject:From:To:Date:In-Reply-To:References:From; b=i8ileHlr/9PTgAR+6dXTkliDD7dAEIpNSyaR3PktmShzcNHU9C2WmaxfNLY9LlKEz 8rM2XEum+tvdfUiOvt2myW7UZM7yKaN29A5JmlBramaO5yNCz3PcLsFYJhNkIr9G0a x+sNIP495OcURUtqdsa1qU8CqwrPzexqddU1AbxA= Received: from localhost (localhost [127.0.0.1]) by bedivere.hansenpartnership.com (Postfix) with ESMTP id 3771B128136F; Thu, 29 Feb 2024 23:18:31 -0500 (EST) Received: from bedivere.hansenpartnership.com ([127.0.0.1]) by localhost (bedivere.hansenpartnership.com [127.0.0.1]) (amavis, port 10024) with ESMTP id n_X0Bkzttn22; Thu, 29 Feb 2024 23:18:31 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hansenpartnership.com; s=20151216; t=1709266711; bh=5p/LW4JS1Y5FbVnk8Z/1edS2WpghYxTfo3KlO7AiO7k=; h=Message-ID:Subject:From:To:Date:In-Reply-To:References:From; b=i8ileHlr/9PTgAR+6dXTkliDD7dAEIpNSyaR3PktmShzcNHU9C2WmaxfNLY9LlKEz 8rM2XEum+tvdfUiOvt2myW7UZM7yKaN29A5JmlBramaO5yNCz3PcLsFYJhNkIr9G0a x+sNIP495OcURUtqdsa1qU8CqwrPzexqddU1AbxA= Received: from [10.0.15.72] (unknown [49.231.15.39]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (2048 bits)) (Client did not present a certificate) by bedivere.hansenpartnership.com (Postfix) with ESMTPSA id DE6D01281209; Thu, 29 Feb 2024 23:18:27 -0500 (EST) Message-ID: Subject: Re: [Lsf-pc] [LSF/MM/BPF TOPIC] Reclamation interactions with RCU From: James Bottomley To: Kent Overstreet Cc: Matthew Wilcox , NeilBrown , Amir Goldstein , paulmck@kernel.org, lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, linux-fsdevel , Jan Kara Date: Fri, 01 Mar 2024 11:18:24 +0700 In-Reply-To: References: <170925937840.24797.2167230750547152404@noble.neil.brown.name> <3bykct7dzcduugy6kvp7n32sao4yavgbj2oui2rpidinst2zmn@e5qti5lkq25t> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.4 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 92C7380005 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: 3gurbqxkyjx146x5eiog9zf58kez4enz X-HE-Tag: 1709266712-102631 X-HE-Meta: U2FsdGVkX1/+Q/kGH5d7l8jikdzIgMHU+/dByIJpxm3/Gg6+a4E/JMoyQTq4uCe8DfnHOvNxYijqbVtHavjzghVfdupblP+I0fZnLXQBMcF9y3xi8xIAqTlsOSFKVTg6ztf99LCe9w9+7K2DKtLnjT8cacVtNIQ7UOpp28LvFdE0QbPYuGwYNiFkb6XC6lyuO118QFI8eztKm8FJWE3xhwxp2vzSIljaKpF1gsNK4qMI+WdoAudHb+G+E7u6S97Bro8vp3nX0dllTjAIoWquNaX10RRpOQiPERQXvsQewGNStpKR712yzCGtpF97gY8f4r65mtTg5WJ0CDXJAp9ad87/Iyg/L5q7JVWBl1NhCuK0U/8MqRXCdev9+BwCjjhnmovEKaV9f8MpZ2wQgGzYGE6AVzreeRjPuIpXbn16gcfnEDaoW0eX3yceevwEduzSh5EVmdvw0Kh5hGCgIOKAQH9h4JCcUZRyPwX0K2NphJj5RCNupnMK8K9eoyVg+NtuUfh3N6QNWkESI6Nr2UROxOdW3OZ9OtSH/b+oF+wwsBRWzItrp5SM08Jz6AlecOEOjt8PACfXVEyMKwZzrs83oyqCHmklaFOgkuZK8BPOs3wp3x1LFRm3BOpA8CcibucJPKlifQ3ThNYmomO6PDrpO8EZhCmPqtXoq8TB0XybF8JautW8/LtoQHz0oe3dNQXhv3m8L0I5LqRyJcf0lrjDDK5vamasXUTYeP2FkIWdJnXYVlx5cQ7MZLE8X0eA0Au4xnDtLd49uDd5XJf3MHZx0/QP9BUYBeYOr7wIrSTRPCMmMQN226qHvzWuRHOecjjLFVyBnLxptIp3Ru2cGR0vq3ztMdfMukYxxhomf3+7ErTdB47WVReUGlycripxsQ2rs3rNkMT1fnl84MXXvFlhm6EMjVhVJb9ANih4Xq+JWIQzcIO61gbFXHItzi3vxS/dc3Yqtt9RbvMWJcZklCJ /4zTCZAT GskpRzms4wPJFyEc6sH742bz/NFzR+M2kn9x+GwqwFus2Bxc96vQ7z0cuyZ9f7LkhRIzVs/GDav8vFBI1KtFxdv+jIxVCRHL+xJreTdnXo0UAMgu1RA6BL2cFEEQZGMgMpQG2LT7PerAykX7lAKafrUeYYaxOyfGHoEoY2RNnfLOlcH55BjRr90Fqjerd2BKm/GuawhvXxtouyG2I0dni0e0NawGHnsDDrhdQINH9VhyO2+ekwpdzeD9HUma5zHVa8gNM/0ztRcpQmIzKNy+QOYujKPy2A0vBZwPvBukLo9srJQBPCw2StZKQI5/Ql4i2V8Zf X-Bogosity: Ham, tests=bogofilter, spamicity=0.000100, 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, 2024-02-29 at 23:01 -0500, Kent Overstreet wrote: > On Thu, Feb 29, 2024 at 10:52:06PM -0500, Kent Overstreet wrote: > > On Fri, Mar 01, 2024 at 10:33:59AM +0700, James Bottomley wrote: > > > On Thu, 2024-02-29 at 22:09 -0500, Kent Overstreet wrote: [...] > > > > Let's _not_ go that route in the kernel. I have pointy sticks > > > > to brandish at people who don't want to deal with properly > > > > handling errors. > > > > > > Error legs are the least exercised and most bug, and therefore > > > exploit, prone pieces of code in C.  If we can get rid of them, > > > we should. > > > > Fuck no. > > > > Having working error paths is _basic_, and learning how to test > > your code is also basic. If you can't be bothered to do that you > > shouldn't be writing kernel code. Heh, that's as glib as saying people should test their C code for overcommit errors. If everyone did that there'd be no need for languages like rust. > > We are giving far too much by going down the route of "oh, just > > kill stuff if we screwed the pooch and overcommitted". > > > > I don't fucking care if it's what the big cloud providers want > > because it's convenient for them, some of us actually do care about > > reliability. Reliability has many definitions. The kernel tries to leave policy like this to the user, which is why the overcommit type is exposed to userspace. Arguing about whose workload is more important isn't really going to be helpful. > > By just saying "oh, the OO killer will save us" what you're doing > > is making it nearly impossible to fully utilize a machine without > > having stuff randomly killed. > > > > Fuck. That. > > And besides all that, as a practical matter you can't just "not have > erro paths" because, like you said, you'd still have to have a max > size where you WARN() - and _fail the allocation_ - and you've still > got to unwind. So? the point would be we can eliminate some potentially buggy error legs on small allocations. Since we have to add MAY_FAIL and error handling (which should already exist) to the larger ones. It would have no impact at all on scaling. The question of where the limit should be in the general case should probably be compile time configurable. We can probably even get the compiler to eliminate the if (err) leg with some judicious return value priming, meaning we achieve some meaningful bug density reduction for no or very few code changes. James