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 8D6ACE77188 for ; Fri, 3 Jan 2025 00:29:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DA5BF6B007B; Thu, 2 Jan 2025 19:29:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D56FD6B0082; Thu, 2 Jan 2025 19:29:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C1DB76B0083; Thu, 2 Jan 2025 19:29:29 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id A35496B007B for ; Thu, 2 Jan 2025 19:29:29 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 14AA51C6EF1 for ; Fri, 3 Jan 2025 00:29:29 +0000 (UTC) X-FDA: 82964255682.05.96589CF Received: from mail-yb1-f180.google.com (mail-yb1-f180.google.com [209.85.219.180]) by imf18.hostedemail.com (Postfix) with ESMTP id 156B31C0003 for ; Fri, 3 Jan 2025 00:29:03 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=LovDhB0h; spf=pass (imf18.hostedemail.com: domain of guoweikang.kernel@gmail.com designates 209.85.219.180 as permitted sender) smtp.mailfrom=guoweikang.kernel@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1735864144; 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=QfCTYXyJooU+yKvix7ZA9z1p9NJ3MNeopDSoO1GUr3k=; b=FcCcCo0wiDbPEI/wQOGq59VCA/ZeV15j8eO+ukGmgSoHdcsl10ZIc7H+/i6m5TadVk7osJ T19hJ9JfuIdJlJN7G37+6wj4HqWUUmxPfVpubZa6yufRbPOKxC1j/Llbin0US7L1h3arYc UJxYF56y5HWltr/BS4P6o+eY9jSxlIc= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=LovDhB0h; spf=pass (imf18.hostedemail.com: domain of guoweikang.kernel@gmail.com designates 209.85.219.180 as permitted sender) smtp.mailfrom=guoweikang.kernel@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1735864144; a=rsa-sha256; cv=none; b=YzVcylz//26EOIgleGlTWye5JrvMnKrwwZMkJrmvwFTPPhWzJpYNPCQ5meGwFltBCqAHhN xvM78CZ6j9IOgusPOSptJebnB+678Vdfq72vJrh17lZ8JP3/F4WMsQOoUSVrr5ZUrWWCTN pGigNh7b/W89Y3NwLAD3epgEQ5eT0aw= Received: by mail-yb1-f180.google.com with SMTP id 3f1490d57ef6-e4930eca0d4so14860439276.3 for ; Thu, 02 Jan 2025 16:29:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1735864166; x=1736468966; 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=QfCTYXyJooU+yKvix7ZA9z1p9NJ3MNeopDSoO1GUr3k=; b=LovDhB0hTZNsPzzKf6n+jMdUk3PkEyNNLk+JSUojAjDvOXZNOp2IgQyvKZcexZZSUe Zvtvn3sd1h5L5ebHPNvRa+d81GxfoKoS3HCEO2/Z81c2G1rNfEdLKvnqGdQDwrmCsS0k Bzcr9RTKXx3R70vqMGMeOd2fAMgRAKRF214YR5MpIDVzD8zybs6WPoP+h1TYLRsrxUfP fwR4NpVnx5rVyjUo7HUtlJyXYznVyrjju1Eol7FArDKv8fRIriOkMQ3ELbRYel1xhElQ krV+YMZqFjV7Lgml09t78QEQN1rPL6QQrMlvmJZz6muol7CMZOa3n4zJ/vnu3Ab9JYgw DzfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735864166; x=1736468966; 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=QfCTYXyJooU+yKvix7ZA9z1p9NJ3MNeopDSoO1GUr3k=; b=EZCTYa7k/kBQ599Y0YjzZKpZHYKvzyQ1foQPhWJTcAyqQp3qRrT2jXGA+UCgNypk+q iTSX4jZXEDr+KXWoAbWMFetJUjRMYg8+O5YMMB/DYHz3YOxdfBn/eVDY0XEWe5px8MDc 4qC2+Na3AvgU0Fjo0/NwKCubxGRiuFvAvYpej988Vnh4pou8GLPjemu7gov/IfIwhNKb VNtJCye0mDJkNl3Gy0xySUjGu7a6f6Sz+9JFNm/hrSXdtugFnSN9Oio8x7ldyHr0FN7v sMOInqA9qMsUTA5JyyeSvkOqobUX0OVTnQ5cuFsl6uKYEBvnpBNuoDcE5qktAfFyh/uP Hz8A== X-Forwarded-Encrypted: i=1; AJvYcCXlRRJDjdAjmsnAjs5W+vLf//OSfNOp9fGPDvv5LGZpUbOVix3I2XcquxR1x5k2J5bR0+onKIVrew==@kvack.org X-Gm-Message-State: AOJu0YzkXd5FZPshEyl5f9lkS4sb/2SnbBgA4/07erpvD5XY308XQY3G PrRg5MEUROB0gsTQsiMylCnTkjU2ksDx0J7PNePuw3J0fpxmrHWKdQLrtkON1aAn5tB7D5Q7qJM OXOk6ljPZz/Aq5aRlnkY1QmGy9Y0= X-Gm-Gg: ASbGnct8Zilupss7JNM7aaPuETwHC3s2Udh9iKbFsEEqa4Roc80uhEu0renbZ9AcNGk /ZheP6qxpRNoOmO2cxn47/2FfM5Cj06fxcBRCzH8= X-Google-Smtp-Source: AGHT+IEXQSWoAQ/kx1k32k7A2etOe7cv11L00dWv+yuZ/2DuWvYTRoRBoc9wuZeQLfoPM9+AC5HTr2eGxAqNqktsEpc= X-Received: by 2002:a05:690c:6289:b0:6ea:95f5:2607 with SMTP id 00721157ae682-6f3f80d16d1mr303971427b3.5.1735864166293; Thu, 02 Jan 2025 16:29:26 -0800 (PST) MIME-Version: 1.0 References: <20250102072528.650926-1-guoweikang.kernel@gmail.com> <20250102150835.776fe72f565cc3232d83e6a7@linux-foundation.org> In-Reply-To: <20250102150835.776fe72f565cc3232d83e6a7@linux-foundation.org> From: Weikang Guo Date: Fri, 3 Jan 2025 08:29:18 +0800 Message-ID: Subject: Re: [PATCH v8] mm/memblock: Add memblock_alloc_or_panic interface To: Andrew Morton Cc: Mike Rapoport , linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 156B31C0003 X-Stat-Signature: x3x9iaqw6id4bgrexqicu7d6jywbex7j X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1735864143-184817 X-HE-Meta: U2FsdGVkX1/GrKPNzO6bztuXNVLz/zlx6+zy9edauhRijc2S+gMlXqNf7XhifyekF6jkStupkOQtosu60uSKvFGqLuC7tFDc7Siru3YLwAHfFt3i707cYKDCFnKm2DUKcdPvtgQNAr+5e4KQpdsPqZyDSAK9OtdMh1tuOzhq5gQXNh/bZYqf8+4+ikjCtYfPvHfm483MUCeGJqSPD9lLJwspQZmoZjSqq3werxgwIj8QcJywmU73mUTJtiie2VRU4aIGyB6l5IvMbvCIvLtQlwhNq0kI6wjKokuYELFR2+t912TGyoZTFaNOpiL7utqnXc5RwcIvG2IFWlb32ifrq+eneivPdZZQJdHX/AKuz7w8oUUuhYMbyCI1O+NUSh8yxFWMBoIICXw7KrChVlK1EI5/4Cm28Cdx54T+VknEtLw4W8lIwqopJQyG99NdIrgXtKgBrhONAmcnG6P1Zm35kLHhpr5CgoahDKqHgISta2OwCsZCPPPPvzUpSKyGoMFh4HGK4RUt7jXKbvYe1cNyxqmGI+7YIpZf5RjdXKDnzq/A9dneeLncU/dvAqiAI/ITTc0uUC1/jaLtkJk0xYwrrd7f4ylHMLPQ8kgieDv0pwLhI9SipRFWF5LO6FAQMnv0TDH2tFyJZIj4fbLyULbCEqDro/Q4gJfRiExEtUmwKAeaAok8m+Qfj3EvqcgFeWgoQLEdRooUx8XsGDi2LJb22CsL0FbnNzXFsEPdWU805q0Ne+JAMbD6juovTSNi+gzT+t6L1YAmA8R+3O/lnZJwyjQdvbo4ZCJjVrk4GUP5IuS8yRjW3SO9eQgS+IBvHTYvld8+gWHDq2WlbgJ4P7itPwS4XrLJ97FmQJtLhwcUU6si9sdCj5fRAVg9++1Owetl8EsZB0hMr1N8gXtbLTS2vqyrcKzCS38Xzp7AIzgRiHG4n0NLCTX3j1OFwSqBOmITOfVx+JurpbL9GC52Nfz +RLN0hSd qglhCTlNC8Vt4vY4nBG4ufXU4mg5XOzL+bh03gWLo00ECor1SEG7wBOBp/9CLEmUk3V9MszLNtsTOFAWxHF/GkG0X19dZ0kkHcA8kWet7R3yRdPjv9Z96p4TX9BXXsMoc0ZGEtMBDVsV9yZrjD8ZLisQz1n6ElRHSKl2Ysw7W9WMywrM1Nbn0FYszV8W73e2A4SJHVCf9/X1yS1EgrFx+N6eMnZpleYd3HoTJSa+HWeJe7B5LnTtHN1UC3pHStzIdRO5c3tImcnnRj3ywYo/qPC7iZ9MCaZc4nlb6NtfvLpETEQZb981Q0kN5uQDgxrDO+lbpxrP8NR3WM9F2wy9yaXcafUDBNSTHoGqH4w3Ei2w3FuM0eBHGoRM7HVXLIem7rFvbRRo70/bsWcqThbZbney+A+sr2P2iCCHlqG92s7r3gJW0B/YbAEGW9FwkqO7ogcZTJG7E5nZB1sbgwlONS6I+vK2kURUfjzkf X-Bogosity: Ham, tests=bogofilter, spamicity=0.000003, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Hi, Andrew Andrew Morton wrote on Friday, 3 January 2025 07:08: > > On Thu, 2 Jan 2025 15:25:28 +0800 Guo Weikang wrote: > > > Before SLUB initialization, various subsystems used memblock_alloc to > > allocate memory. In most cases, when memory allocation fails, an immediate > > panic is required. To simplify this behavior and reduce repetitive checks, > > introduce `memblock_alloc_or_panic`. This function ensures that memory > > allocation failures result in a panic automatically, improving code > > readability and consistency across subsystems that require this behavior. > > Just to be annoying... > > We now have many more calls to memblock_alloc_or_panic() than to > memblock_alloc(). So perhaps memblock_alloc() should default to > panicing and we add a new memblock_alloc_no_panic() for the exceptional > cases. > A good point > And from looking around a bit, I think many of the remaining calls to > memblock_alloc() could be made to panic on failure anyway. If the > kernel cannot successfully execute memblock_alloc(small amount) at > __init time then the kernel is hopelessly broken and there's no point > in proceeding? I actually did the same thing as you did, tracing back to the memblock_alloc() caller, and indeed some of the remaining calls can also panic.There are also very few cases where the return value is `ENOMEM`. > > In fact I wonder if there is really any legitimate use of > memblock_alloc_no_panic()? Of course, I can try to submit a new patch for discussion, but if the default behavior is panic, then other similar interfaces like memblock_alloc_from() also need to be changed. --- Guo