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 C941FC25B74 for ; Thu, 9 May 2024 06:13:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3E6FB6B0083; Thu, 9 May 2024 02:13:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 371BA6B0085; Thu, 9 May 2024 02:13:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2116E6B0088; Thu, 9 May 2024 02:13:13 -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 03A396B0083 for ; Thu, 9 May 2024 02:13:12 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 8BE23121481 for ; Thu, 9 May 2024 06:13:12 +0000 (UTC) X-FDA: 82097839824.11.54F5244 Received: from mail-vk1-f173.google.com (mail-vk1-f173.google.com [209.85.221.173]) by imf09.hostedemail.com (Postfix) with ESMTP id B4C9914000A for ; Thu, 9 May 2024 06:13:10 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=mNwLIzgX; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf09.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.173 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1715235190; 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=6F6BKpRJQNg/VL1hLJe69exk1Y5QwBVu9m/6Ynps7qA=; b=H/zkc0OCiNP3k1qQr/2coHuDna5sZidRlAB1fXpAtV5mWW1rACZXvS9b6vzRO8lFoJvnEv CusvXSHxgl+ZMI7JHbu0dGaBIIRU5MIy3ALH5O8ww15+hea4KWg939UJAtJq22fQbmnedi sbFKkkNcIBZIPfEvgmrmdyu0Hx8uDcM= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=mNwLIzgX; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf09.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.173 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715235190; a=rsa-sha256; cv=none; b=GS8RciJhmti63S9cNPkUbKRHMx3s1pnCrUU0MjRe8IIAr2Vr/lzM8Mt68RGYer+zX0LL7C f0ksHlS12ymsWZdnI1xC/IJnO7DRx5QTUG2Im+8jItOKplcjy4qoNBOchFdxA5I+4NEuQL 0ATljGcmUtmZOjp6uQ+jyCFBGv572po= Received: by mail-vk1-f173.google.com with SMTP id 71dfb90a1353d-4df214fdc37so313123e0c.0 for ; Wed, 08 May 2024 23:13:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715235190; x=1715839990; 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=6F6BKpRJQNg/VL1hLJe69exk1Y5QwBVu9m/6Ynps7qA=; b=mNwLIzgXdXKuHq+1QsUsVD2H2b8TBe+8WGwsgKoRkgilS2zSFnQo/YTKvjgf5vDGKy UroRVF4Wi6YqUOkZ4m3NPEM/p+UutjSX0ECYgtaQTDDLf6FtWWR8Ljld7huwqfA7YH0O lfNtNeex72F7QnSq6uvW/6fvKDQ0t8RLv1gT7Jrm8/GUMRP13PQH+pcPImaay6dzzSW8 IOgexh+y8qGDkmRSFa+4x9gkFh4wEGD+375SfjU/I5FWYtZIvDLzLE9zn+Vk5PDXw+oO cTWa7TEoeg/dqX/znNryeokPfYFqx3Wtuhr8RGVDW/nJVgnNiGw2vAXES+dwpb/m6Mlw QUOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715235190; x=1715839990; 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=6F6BKpRJQNg/VL1hLJe69exk1Y5QwBVu9m/6Ynps7qA=; b=FlTanDH3hOJ8cw1ewcoNALgtMP36yIEHhctRBaRe3SihNLLFdYahUF5E1B+GVzFZxC es+5vQ+YRwx87D9JvSd8k+gL06xrvjiba/VRKadOCfYPgYvfNxNP+R4dLu8QhTe/i7x+ bZq2WNFKZYNApEviuRSULiU2/OgNJT723oh0oaI8smUVNgCiJb0luEebNtjqgXdNpApU NweQNUUkbZV9L9YWqlFgoFYL8SuOFppHkbAeSmw87fPb401xuBMMi5U2M2V+ctJQCQid Kg/oBSWeelq2FTkGANn4G9DeM3hPgQ8LI4KITYcB3Ssvk1HpBItz+SrPyDh6+eqx/mVe cOeg== X-Forwarded-Encrypted: i=1; AJvYcCXs1E7X+QL7DUYhPZH2eW54UwWLkpZmVgvQFBXst3+mx0l2fiFnOLrKC8dKQg2Dv7b/8I+SU80zMX76LayAY8bMJoU= X-Gm-Message-State: AOJu0Yw5sAvhDGipA9/FOFsFWk8VUC6Ci+0JSBDgiQ9d/amYpYCSWV99 0FrEUlW9rVakmOP5/x2matgkrU0r3F9XYZmnLZuDFmcivACUf+80+YvniqX8VfUYR0hsg0AlP3V qceUUJ3q0stJ1EkbBYQoiWfEpQqk= X-Google-Smtp-Source: AGHT+IGVdIq1ZWy7m4bpS8XSGo5Gde81s0E0aZg6rWvS3bVTSyhJlxf/E2s0PdrLPIq/d/NF1HRPZWnhBfATpEVIiBM= X-Received: by 2002:a05:6122:2504:b0:4b9:e8bd:3b2 with SMTP id 71dfb90a1353d-4df78edca00mr1587765e0c.2.1715235189744; Wed, 08 May 2024 23:13:09 -0700 (PDT) MIME-Version: 1.0 References: <20240508125808.28882-1-hailong.liu@oppo.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Thu, 9 May 2024 18:12:58 +1200 Message-ID: Subject: Re: [RFC PATCH] mm/vmalloc: fix vmalloc which may return null if called with __GFP_NOFAIL To: Christoph Hellwig Cc: hailong.liu@oppo.com, akpm@linux-foundation.org, urezki@gmail.com, lstoakes@gmail.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, xiang@kernel.org, chao@kernel.org, Oven Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: B4C9914000A X-Stat-Signature: cwq3kgn85xbpg5y66mx7674cjusigrd9 X-Rspam-User: X-HE-Tag: 1715235190-321705 X-HE-Meta: U2FsdGVkX1+GAtoHKAH3ALScpGSZ1wg9P1AGTMDSJ1Yk/0mv+GxOnVAJBFlnDOXDHLHbiznvKNdGq+tRFlMmptL+wMZNibp2ZpfPP9cKozFEMBxxk8pdClm44lC34NNv6YHIuwCEygKsjROmmCM7WEz1xPcaxPePCozfNqrJV9zArcrRP2uzHOdBYRidDBxVDxNCvW9CkuuXofRnL3enEF4SASrOyAxZAVaVHbUPZZIKY3CAx/lukWBrR3AMDtzpuKlwEq3BZ4rnlt/+m2wFb3IRSP/0Uuw9XKUwfX/qOgmwANG1S9wB+UowXpY4E38oOFLGj5fafCr2vLIe7jAfWoFWeOat8KaApJ+u4YIidzJbDWgh4zl5wBVqORhWWs18aa5FFJdLwtVRWIjdRJn6xBJvT8GWi24zBwT0SlA/WIhXrNCmtC3prauScvitkoWuOW5mUy96I3ldFZhHrEA1u72Mi0mJedmRsOj7/ypXa46zB6dR78M25qTwqt5M+vIwL3DLGBDSAI26LEa/tQ0PnzNYXitYcRkD7kWnfSiSvdRj87zSymyAMFeqgDXUzzmnvvJWlbHWfhf97J7TLQhVZ1sJrduIV14D7seWaGJbP7qZmoNdb8ZjjakP3Ph9ZKLgSMN22CH8jYYPuxvwgvlIISEkUjCQ2crnGZRKWk8RlhyUav5swhT4XCnNDT+He1ec3sCAC5lHXvphT4JDJqP+sDH8WntbJn2N+YLP7S6yk6q+PbEVVND+Oeq2wdgSX6ehnshwdikjigZtyZh0+CdKofY02e8uIO5dcgnhg+Bb9J+zT80WzSbUClVnu4S2+7sq7cppatV3KgMMgKwJM6wfp4ashrt6nBs16yeaa2s+K/87tHB9PRC5P0b/F+BjM6p7cO3WZSjpjmC8MStAVCLfqBTSzcfMsHOqZDwo4i0z6P/0jmcNO9sytp245rBs1b4C9rvx/w0XJ8qf6/hY+cl cgRT5XvI iy78HQKUJKyTocOk1HgDNM1rHpnFDTc3FVm14GMBBuCgcUn51CE6dM7xINxs9CBqe9OSXNjWO8BI9LTGdV8df5Xm0Axv986mQDvVM+YkLDwDn3MElLKjYVlRZR6UsYWPGr4FmXh5HSwBEcHdiVxCYmRtpsSwffCXOrVpfAl7bpjP4r5q2Q99QopD6cjFrsMCyii9CG04zYo4m2BoQxQ6YfO+N51NWVtvYnwgiy7YW5YjOD5V51syPBZCY3svnqG6oUaC9MN94lVZYULphyN/PVThaQxcEguYttvvQzt0+1YpxyWCdV3C5115CzMtx9qMUswhrCewwg16DOyBAMJ7556fS+T94yB3BV3wDs/AI+Rb6Gj2p8BgnWVZfiuAolZ6RaCI7o/wpt2EiMnFzo7RoRpayEbILoaTAVpZYQEsYfOldB+lfFmkKp9vjBDyiFPsn2OixtTcnCfmu3/I= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000027, 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, May 9, 2024 at 4:52=E2=80=AFPM Christoph Hellwig wrote: > > On Thu, May 09, 2024 at 02:20:03PM +1200, Barry Song wrote: > > reverting the fix intended to address the OOM-killer issue in commit > > dd544141b9eb. > > Should we indeed permit the NOFAIL flag for large kvmalloc allocations? > > What is large? When you don't allow actually use cases people will > just reimplement it poorly. E.g. we'd probably have to add back the > XFS kmem_ wrappers. Xiang gave his number 24KiB in erofs, but probably we still have some "naughty" users allocating much more than 24KiB with NOFAIL in other subsystems. We should never return NULL for NOFAIL. So, in any case, we require Hailong's patch in some form. However, commit dd544141b9eb ("vmalloc: back off when the current task is OOM-killed") is also tackling an issue. If we can find a way to preserve it= s benefits even in the NOFAIL scenario, it would be preferable, though it seems improbable. Thus, I'm considering if we could at least include a WARN_ON_ONCE((gfp & NOFAIL) && size > LARGE) to aid in debugging potential issues we might encounter. Furthermore, compelling a large allocation with NOFAIL also appears pointless, as it could lead to unpredictable long latency. But I don't know what the proper "LARGE" value is. Thanks Barry