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 DE7D0C3DA4A for ; Thu, 22 Aug 2024 09:35:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 645446B00DF; Thu, 22 Aug 2024 05:35:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5F1B08001E; Thu, 22 Aug 2024 05:35:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 46A526B0113; Thu, 22 Aug 2024 05:35:11 -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 28B5C6B00DF for ; Thu, 22 Aug 2024 05:35:11 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 96CD881420 for ; Thu, 22 Aug 2024 09:35:10 +0000 (UTC) X-FDA: 82479372780.15.CA94B28 Received: from mail-lj1-f178.google.com (mail-lj1-f178.google.com [209.85.208.178]) by imf30.hostedemail.com (Postfix) with ESMTP id 734188000D for ; Thu, 22 Aug 2024 09:35:08 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=VxAazfvl; dmarc=none; spf=pass (imf30.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.178 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724319249; a=rsa-sha256; cv=none; b=0IfDv72et9HRxs7uStCQudarsI5QTJYZHPfhPwkv0LEt+r1kD8iivccgjjXOslh42sulvm bQ8aoeO2pY8korbVNkK3lgw5V6gBPfshcLkFciOGJV5XsVYjgK2frRxiaCT7BkCc+XvXqA 6cey0QYSORkBzbBOvkwsnjWjQiPsTkU= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=VxAazfvl; dmarc=none; spf=pass (imf30.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.178 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724319249; 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=206zKTa+7G2AKzXndKK4zs3d1dKxAQyC6y/j0FklOC8=; b=vMD8OZjUIXH2op2jXuUk1hnrWdbCf9pGgK3taCRV6bdM9Nsnkq8RhiXO38Tm2rpwvMqS3a 3T0Sl6qSsCmC4oJNB8JLEYexaAkyEp4k++/+6nK1X4fdMP6TvyMqmnM+35ivcTSPO4nZpq x2gPKNmPBvveS9fRuBS9Q7uObz5Ned4= Received: by mail-lj1-f178.google.com with SMTP id 38308e7fff4ca-2ef2d96164aso5201721fa.3 for ; Thu, 22 Aug 2024 02:35:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1724319306; x=1724924106; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=206zKTa+7G2AKzXndKK4zs3d1dKxAQyC6y/j0FklOC8=; b=VxAazfvlIyQWgICslEb8LjJOKixLZH03tYWz7wuA7WJ1YlKZyxr4GOobdOCGyfk0/v cFGqZ6mu5LJXvsU3yeCKIPGUmoA56cF0ptVYWP0jUqkH7CNiaGK3UB6U1OLXL2/9sQmz Cm91Q6lxheFG+1Aeu5aBCey8uL6dVZPThfh6s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724319306; x=1724924106; h=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=206zKTa+7G2AKzXndKK4zs3d1dKxAQyC6y/j0FklOC8=; b=hJVsQT+2tsxZqJAmpqfSH+ZCzrmkZRFE0NPJ8FzSi0sPJCVFza2BpgfOesrkXqpW/w RRmlQgybU5UdpIkXv+L7gZzZzi7BKWOijti+gLkGkpxcA9QJ2ZD9BcBYnWuf6GUvGCcH Ort0HOGjBb0gDQGcZ34BXBi9F9tVce0z1Bw9jkOinW7bQfwWL/Fy/59cgKbzovrm6j1X k3Y2QaVRWLp4+xnxrcjGLNey1P7qj4wcCLy7NYzEoOhX/VNqUr5jhmiIA/Yv6tOy86QW XIBWs+edabN5m5AQS3TPzUx1CrHuYOYtVzxxOYWGRMMqgZlt7Fz/pABIuu+9kOIjQkHj Qu+A== X-Forwarded-Encrypted: i=1; AJvYcCUGzsM7IghGkW1lynfpskgwOumHqr2/UWG3fp8zjqM4TcaK6W0nVQ0vf+x6CAMxzJPy8wg9aMD8mQ==@kvack.org X-Gm-Message-State: AOJu0Yx8obMRIjXjUeeGLBmRh+b7MaltmUFZmqKYYV3BxQTxI7D/EAPw sZ1nsRYjJgIP70FWS8/C0w6wzj0hBxwbzKrVov5j4Fhx8a2XkkWOXimVaBqgVb4rXPBlBq6pZ5u ximFa0g== X-Google-Smtp-Source: AGHT+IEGo0l256YUk/Rh5Ksyg1IKFbhRW/Urw9O0h6xqjXsCxOLa7yfF3maX7taFN6WZBjly5CBI3w== X-Received: by 2002:a2e:7d0a:0:b0:2f0:1fd5:2f29 with SMTP id 38308e7fff4ca-2f405c93006mr6612891fa.19.1724319305846; Thu, 22 Aug 2024 02:35:05 -0700 (PDT) Received: from mail-lj1-f169.google.com (mail-lj1-f169.google.com. [209.85.208.169]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-2f4047c5ab6sm1570391fa.48.2024.08.22.02.35.04 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Aug 2024 02:35:05 -0700 (PDT) Received: by mail-lj1-f169.google.com with SMTP id 38308e7fff4ca-2f3ce5bc7d2so5921061fa.0 for ; Thu, 22 Aug 2024 02:35:04 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCUicEJzYvnUI2OLsqUDSb3oj/jbE0ulsC1h4A+OxQP+O+qlGYtZ3zXu8kUedAQso4ax9Qe9oad02w==@kvack.org X-Received: by 2002:a2e:a9a1:0:b0:2f3:f4d1:1132 with SMTP id 38308e7fff4ca-2f405ee15b4mr8003701fa.33.1724319304600; Thu, 22 Aug 2024 02:35:04 -0700 (PDT) MIME-Version: 1.0 References: <59e90825-4efa-4384-8286-06c0235304dc@redhat.com> In-Reply-To: <59e90825-4efa-4384-8286-06c0235304dc@redhat.com> From: Linus Torvalds Date: Thu, 22 Aug 2024 17:34:48 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 0/4] mm: clarify nofail memory allocation To: David Hildenbrand Cc: Michal Hocko , Barry Song <21cnbao@gmail.com>, Yafang Shao , akpm@linux-foundation.org, linux-mm@kvack.org, 42.hyeyoo@gmail.com, cl@linux.com, hailong.liu@oppo.com, hch@infradead.org, iamjoonsoo.kim@lge.com, penberg@kernel.org, rientjes@google.com, roman.gushchin@linux.dev, urezki@gmail.com, v-songbaohua@oppo.com, vbabka@suse.cz, virtualization@lists.linux.dev Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 734188000D X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 9atn6eqq3fgsg1is376nmfg8phikiddx X-HE-Tag: 1724319308-215610 X-HE-Meta: U2FsdGVkX1/MIbdTZfYNG0Yc3Z9XCYsAbP1EYeOLH2TIhCQtREujBDMbYXTuNeUu+xHWz5LXBJVN9H/jz7miWpyY94ynh/FrEik02+6S5BcXGXrPw/5SM01rAqeSViTQsG4voKJmT4KnZ0ihHoNA2Xyn8j/gV2BE/WYHjpppHs7NXWHnEjbZfFJL1Yu8Vujji2LJIJFg3tZYIMDUIqYvHu+7KhpNNfVAA8hm6iR52CeL1Oy8wbnZty8vKpP7it6oUDs7NMOKZLR8yrSq+vtDEzT0lPZGCp1MsDJYthoIwA6lntMr1bQY4KJPnR36iKhcm7uo3e4ylWRLGc7gPH8T0tqPvj8g7iiLblBH4aaARrf+5mGrvTN3Cq8E3VODKovOIAUzDX/HQEvprzgyh31jD9TFZ/EixHz6plhG7sKBupQxMhqTk5QQP5+fjEZGbvGvLO2en0TzJa8D6o6L7rnl00bBJ1r0mBPMR2GoWZBhD8Je4TD1lEA77PEvkbjd6GUEGtbZgx6yeF3C2Ldk85roD7eWmrjYcCUDGWrUjk/f+OBhoIBi+spOvwFhitLRphzGc/527MeM4SXCjc0Wq3UyclTdMGiziZsHk8/PutHfrH69RkVVqziR84NZXez8Kx8kxRUTeil/QGguy9pmk3XASzaGpv6o/LGeON4XvnZeVXKacvwqCcqYR1NA2mC+RKxTz5JSi3sJT1icj7btpiX6vNgTTAwqVI7Frx30U38x2QATuiHZhS+kHw5nR8NGVMNT9AX7JVLlOsOmmjtpuzUQb5SlS+RuxZQlqoOgb6JFBEoEXHMKxATjk/u/YtAFcRm9XOSaGVT4X1IGcNKxraR0jzotspjJ+/8q+E4/OyOCgxRGHtdi3UpPWk8T4kYg2HaLd1SvkZGpYeYYKgk4CR0ZprlJXiTdppToJ+IUgy+BPC2XeXp+hJkGhSzcdbq6i59jBmzLBGNsbXSlL3iCnm3 8tPQ5Py4 Pn/TRtxh9bEal4KuaQGTyf7SQlVJWJzwd24txvgVwxLRENj0itQh3vcpq8lcAH8JgKwFeX48gnJaeGek3lgmqOJScujKlDUVW8hVqsiFXGX5zRHdInyBisXLDVPh/qzV4V9t1gquZJ9dqOy4aS/hr4udp37llPxY73H1uIxvHP6Ek0LhQG3pEFMYb+jtp0B+738U/qyr2AFrTwZ0p/YEgM5fDcXfKPJBFxXn3oAduYicsaC04590aYh+V9eUa/MtGF9pcZrw4SIuRO1JCq1vmxh6JN9WdooYeSFds8rbXuv10CvApyWy0y3ws4SK6ZuRih97wKLblEk2BVuNMDG+jXw+11rLdm/m4HO6XsHdKQzLSU9bUgzJqVsr3UT5gaQsYx1c8eZJltjGfX1NXQafoBMU/hB9da6tSt7fqM1Lewee53GjhNQLBFFmJxTtzyZ41B12CW8e2nokEGqfUI7cxZS7d2J/oUsLQrUVhXBbzWZKsfDrADlwUNEgbjCrikamvme94+cPWdiR9z/1wM35mHJY7EallRVFE76YvfBNBbp52pgvptepjlnTDV8e13MHr4adKsodoLaRwnl8= 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, 22 Aug 2024 at 17:27, David Hildenbrand wrote: > > To me, that implies that if you pass in MAX_ORDER+1 the VM will "retry > infinitely". if that implies just OOPSing or actually be in a busy loop, > I don't care. It could effectively happen with MAX_ORDER as well, as > stated. But certainly not BUG_ON. No BUG_ON(), but also no endless loop. Just return NULL for bogus users. Really. Give a WARN_ON_ONCE() to make it easy to find offenders, and then let them deal with it. Don't take it upon yourself to say "we have to deal with any amount of stupidity". The MM layer is not some slave to users. The MM layer is one of the most core pieces of code in the kernel, and as such the MM layer is damn well in charge. Nobody has the right to say "I will not deal with allocation failures". The MM should not bend over backwards over something like that. Seriously. Get a spine already, people. Tell random drivers that claim that they cannot deal with errors to just f-ck off. And you don't do it by looping forever, and you don't do it by killing the kernel. You do it by ignoring their bullying tactics. Then you document the *LIMITED* cases where you actually will try forever. This discussion has gone on for too damn long. Linus