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 35B1CC4828E for ; Fri, 2 Feb 2024 19:13:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8E8006B0074; Fri, 2 Feb 2024 14:13:32 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 870E96B0075; Fri, 2 Feb 2024 14:13:32 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6EB116B007B; Fri, 2 Feb 2024 14:13:32 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 5BE816B0074 for ; Fri, 2 Feb 2024 14:13:32 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 12AF440F9B for ; Fri, 2 Feb 2024 19:13:31 +0000 (UTC) X-FDA: 81747812622.29.7197BB0 Received: from mail-ed1-f50.google.com (mail-ed1-f50.google.com [209.85.208.50]) by imf24.hostedemail.com (Postfix) with ESMTP id 0451B18001B for ; Fri, 2 Feb 2024 19:13:28 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=DeWf+9x+; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf24.hostedemail.com: domain of dianders@chromium.org designates 209.85.208.50 as permitted sender) smtp.mailfrom=dianders@chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706901209; 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=AzRl/p/zBM55V3qi6ZzeQftf/q51vbL6S+/zvQ3KD1E=; b=KIs7PCSnfftgxXxRaIz18Arx/3+v82MAzklHYhREuII6W74kOhF5xt6hTyAZv82r72X9mb F2+kqjFOitOZrM8ATWkfmmfMAcyxngT+o6ET2mPx4xv4zqusolsCZ3RESrk4h3lGkq8Z8e vbW/lrf1zY4xrJArBlCkHlbuoNWfhqM= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=DeWf+9x+; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf24.hostedemail.com: domain of dianders@chromium.org designates 209.85.208.50 as permitted sender) smtp.mailfrom=dianders@chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706901209; a=rsa-sha256; cv=none; b=3eC6c/AAVx/3TJPmnySO+TQ1CsqM74a9ybXhmnnLo2gNOzCg33o+HZsk/r68riwIpeoAdT iqQsnCx42qUekI1WeosVg21dyyxwowdFXF9Z3UkJTq+dNp1bKeOM7zHQQDZaW4upU3zfEn 6qEW67ljnFkLonTgElv75kFeT7sGNgA= Received: by mail-ed1-f50.google.com with SMTP id 4fb4d7f45d1cf-55a035669d5so3581018a12.2 for ; Fri, 02 Feb 2024 11:13:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1706901206; x=1707506006; 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=AzRl/p/zBM55V3qi6ZzeQftf/q51vbL6S+/zvQ3KD1E=; b=DeWf+9x+VwuwTMldg+VARy/+TdA59zB5773k3V7uPS8AnehSISG5CziWhE2JRqxrf+ 0hWlvXSAVIm57DBuNqfWnIfqq5E7/Aiop8jQzduRogTBwX9a2voFUsDKgL7yXsTmtUv2 V2RQrbfE4xraQaz/q1wz+w+EDpOa4M9EhkU4Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706901206; x=1707506006; 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=AzRl/p/zBM55V3qi6ZzeQftf/q51vbL6S+/zvQ3KD1E=; b=onat+Ev0gjxADxBxXG3XBpeQ4b2FfaV3+aEzNAUDhxoMVjlXFNr9dDpFqgWVQKcmna ViywR9NPwsaU2IVhasjbg5I7Hzjb+pSSnsjL52FUe5p9+0oPIwjlmI01jYJl9nqT0ykf 5amI+eD8ya6l1HiQh2Mw+bRDtvbvLZQ/cv9u1Klsfn/igaz1yv4hkVQy6eZ8uOxYLwk3 ylQLR3Wyab9uYTXpJTOQBcRCxwXGfz3MI8rvDxmwQuImRakMmAIhLhNpXcBVPXWVcaMu a7a42/tnwYIv0FWPlznm8HYPz7mly9JoNTlEfQkEmuk7UJ8iJXNN1vR+Pba54DErqPJN Rlcg== X-Gm-Message-State: AOJu0YyGPGqbuDBUdGr5jOrQCEMC7y56+NehHTJI4GdGGC4V959lzz4Y OAiKdny8/nl+NdpzxtD8d8e+HNTmwYh/JP73khcDrO07zHjF0T3QjAQs/i14eI96g2Sf7fiuAYT rC9BO X-Google-Smtp-Source: AGHT+IHu7Y2KNcm3AZhDe9fC16Mm+BSrTMo2sdmhITDpcIw4N0XMj6A/3WENR4Gedklm2k86Sg9j+A== X-Received: by 2002:a17:906:185:b0:a35:7685:1731 with SMTP id 5-20020a170906018500b00a3576851731mr2093013ejb.12.1706901206020; Fri, 02 Feb 2024 11:13:26 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCVPSsHApXOfKDsb2il0cMsSOCsxzA8cOUkPtHNTE6X6cQ6cX9EBZrRdvDX/N+yJzZobgLcazskmKWCU2WEeOWtRRyQ= Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com. [209.85.128.45]) by smtp.gmail.com with ESMTPSA id a20-20020a170906671400b00a34d0a865ecsm1153333ejp.163.2024.02.02.11.13.24 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 02 Feb 2024 11:13:25 -0800 (PST) Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-40f00adacfeso6565e9.1 for ; Fri, 02 Feb 2024 11:13:24 -0800 (PST) X-Received: by 2002:a05:600c:6016:b0:40f:cb0d:4dd1 with SMTP id az22-20020a05600c601600b0040fcb0d4dd1mr54895wmb.6.1706901204019; Fri, 02 Feb 2024 11:13:24 -0800 (PST) MIME-Version: 1.0 References: <20240201171159.1.Id9ad163b60d21c9e56c2d686b0cc9083a8ba7924@changeid> <20240202012249.GU2087318@ZenIV> <20240202030438.GV2087318@ZenIV> <20240202034925.GW2087318@ZenIV> <20240202040503.GX2087318@ZenIV> <20240202164947.GC2087318@ZenIV> <20240202165524.GD2087318@ZenIV> In-Reply-To: From: Doug Anderson Date: Fri, 2 Feb 2024 11:13:08 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] regset: use vmalloc() for regset_get_alloc() To: Dave Martin Cc: Al Viro , Christian Brauner , Eric Biederman , Jan Kara , Kees Cook , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Oleg Nesterov , Catalin Marinas , Will Deacon , Mark Brown , Linux ARM Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: 9ypx5a3433rowtbssfsoxt9jbn7ffb6m X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 0451B18001B X-HE-Tag: 1706901208-71922 X-HE-Meta: U2FsdGVkX1+cM0mLozyyM3VUan31Zo+ZtmGyGVGM1OyopRdc1i0pKQOhv/tIgmClZw6ujez33BGVYaSjSTnSbwNOQOB+ev5IwU3swCiwa7qx6uc/3tKumBnQ2M90jQHT6FKA4GjhgaYtNurnJS1vDbNh4d2D/QhHEtYoTffNegWQ6E35CTO3LAwUm2vxNu9j/94WIfN+ZhXg+rxPkKDecR28dqOdYrxSfLS+0niMFSoz+HMkpdtw+YZFEpEIWKivLURODgvS+wgYZpLyXv2yx8zhf8YR3N7xk+w1jxQ/Pa0HdaaXEGItUIHP3PHazukUWhBKooYOErYyEDOir3B19sxNUe+yFvm0ewueNhQPIH+8s/HJysMYDErtIIga1msxGIuOyzB4TMf5UDpstOy1eC1GkD/5aPUbS6sD20PuZnxaAz3uP3R6Pqz2Ce8lSxTih3E7ySU7OMid9oNhAAzYCJ2199q2ySW0pFn0ZGSb50ALCLjcoP+uD55NARBZdfTyp4K1rkSbaDESK8DlORC3iD87wCJRtCEv7i1KndnmBUeTWp7Z1IOYu7qOZqn0xlRnidwe1WbswJJn8KeUXzVa6SmBeKUaE0VrLxI8S7q0pOA2U0CU+qU7ELM8EUKRSoy3ni63DO2jsa9I9hkmKuCWXIPTDBoqrbdjMCkg4yf/YspFAeIn5JXgoHVXLbsagy1bL7NujCAq4FjjJrLeCjSWdY2dvQuPd5RXk4/o5bSsfUTFl8zLCc096OA7RaLF2dbSdv8VvZ2FntlLB6QEzErx/kyuEAGeonk9Rk8UQ8FTwaCMjVc/QY7DkRrCBmv8aMweSmbsBPkbTuz2kREsI2y9MSOK2uWZmw5J4uRkarrXs84LTbSPWNnvLFjyQ8GGDGAX6rN30pmcFqkeLmgspIbqhCJMJa5x7UKzy2yH4HapsDQdD1tKGMIIgOwyZ6y9nDUr4DCHwrNdsuY4OzLcR7w UA7YxOgv nvDYB55wff5Lr1Xy/tYML/5vOa9QHcsGukmTWul4mHFIXFKxE3f3bKyNbsugvTkmgOstr/xcUSnBI1jTHFOlSInArN07Ni2ZmVwYfLRbtPuPq/vgIzHpvXoMzEiGjhkk8UvmJPuVh5McY1BHT/VsS1/vdTKeStdjnzpI0D9hzU2ch1Yz4ajBperbBZgI0cK93Eu5kE7x2/aeW1sEKnzOAs5Jl1y9FNFTJs9qkpqHO+4BbPHTvBJZnBu3CFXq0h1ervzuQD0YkPJUB84lshNG/DisRYbp5Z5XGQ7apsqyYh6bE7vqQbcwQ2YE+IzAo0/PsL0ST/RNMWz6K5aj37rTscum7/KeBR3/hQFV0Rlp84oQoamDNhK1bECHquaNGqKWwRCBTnDjPmART6SdIOa8s9eLLM2VvOFFNuzYW 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: Hi, On Fri, Feb 2, 2024 at 10:08=E2=80=AFAM Dave Martin w= rote: > > So, if the only reason for trying to migrate to vmalloc() is to cope > with an insanely sized regset on arm64, I think somehow or other we can > avoid that. Right. The only reason for the patch to switch to vmalloc() was in reaction to seeing the order 7 memory allocation. If we can decrease that to something sensible then I'm happy enough keeping the allocation as kmalloc(). > Options: > > a) bring back ->get_size() so that we can allocate the correct size > before generating the regset data; > > b) make aarch64_regsets[] __ro_after_init and set > aarch64_regsets[REGSET_SVE].n based on the boot-time probed maximum size > (which will be sane); or > > c) allow membufs to grow if needed (sounds fragile though, and may be > hard to justify just for one arch?). > > > Thoughts? > > If people don't want to bring back get_size(), then (b) doesn't look > too bad. Either a) or b) sounds fine to me, but I'm just a visitor to this code so maybe I'll let the adults in the room chime in with their opinions. ;-) Also: if you think it's fruitful for me to try to write a patch to do either of those then I can, but I also wouldn't object at all to someone else writing a patch to fix this and I can just provide a Tested-by and/or Reviewed-by. Let me know. -Doug