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 42019C3DA4A for ; Thu, 22 Aug 2024 07:57:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A1EFA8001C; Thu, 22 Aug 2024 03:57:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9CC4880017; Thu, 22 Aug 2024 03:57:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 870958001C; Thu, 22 Aug 2024 03:57:55 -0400 (EDT) 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 635AE80017 for ; Thu, 22 Aug 2024 03:57:55 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 089EC413F3 for ; Thu, 22 Aug 2024 07:57:55 +0000 (UTC) X-FDA: 82479127710.28.DB5EE51 Received: from mail-vs1-f48.google.com (mail-vs1-f48.google.com [209.85.217.48]) by imf28.hostedemail.com (Postfix) with ESMTP id 4B4A5C000F for ; Thu, 22 Aug 2024 07:57:53 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=WZxGUlOC; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf28.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.48 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724313456; a=rsa-sha256; cv=none; b=JeHlOqhn/Tij4OBEZdr8uYTfGvT9hiUjIOHG42qckYmBVVJ99sxKlywt8lvSdYApCv4jAg V+HOZC1D+joGq3+wMuTzrA1H+McXH8fMzFRE8o0zU/+qnBfkRZU+yTms/YhAN2+yMEvalC Xqnz+nGHvehw6hiuXM44mOkL5t73hXE= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=WZxGUlOC; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf28.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.48 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=1724313456; 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=Vx7goW6BrSZt6yvtR2KIlQz0YFwTgKAn18ohH71KEoQ=; b=3KWUwd2iJpD43xVxa40vS/TODEJEvEZ1uUFcxch9rYEBjAKM8LbjzwzkfF+F8qU9WjqeFI Vp6FvAJlSbrKqaKAHmkP4V0EuKs1patVXbPldvNw3g7QU0fUkg3G41BH0HTbNdsVZxeTkM uhC+sIuqQMLgY0jfmRMrkchnF4oTHGI= Received: by mail-vs1-f48.google.com with SMTP id ada2fe7eead31-498db1fe5ccso208033137.0 for ; Thu, 22 Aug 2024 00:57:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724313472; x=1724918272; 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=Vx7goW6BrSZt6yvtR2KIlQz0YFwTgKAn18ohH71KEoQ=; b=WZxGUlOC+rJIpsAoKLCOjUU9PgEVVj7iP3KQLBviD23/FUXoipTrtXWS9RI1zBCpRZ dHAuXgmmsbrHbf2apeMy6toAOcwrXzqv3thwo7f8+AXt4e0r4FH9xz35Wa2mblj1b594 YxqNQB06GVAW7RgsZ0SpR5WUDM0iuRrclCE/gL70HFt0X7L5sqBW12ywpN2OgHBV1xW7 H7zlBqUbKMpoO3/2/ym/kDmA1qnzxj0zR1x8RDZozbqTgM8GprWRvIDspwxX5mD3glwc TBX7bPcpFHk3UWsiPb0gXovl34etBJN7y0jU7SvdwEdAkCvJepSbNS/5Y2t2AFkG0s+y Ao7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724313472; x=1724918272; 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=Vx7goW6BrSZt6yvtR2KIlQz0YFwTgKAn18ohH71KEoQ=; b=wBM8RxC7nXyXXJZnucKLYgp7U+gon5wa+W0apSK5+ZmHAnALvZxUrycLQlEnaQk7IP TyDjXx9ZuQVajmQfa+PUQ+L3vLRVsfhmeS/0cMocNjsc2rzkCO1/mCaRPaKpJcYIpyVH w5Z4CZny/rEWzwRwhfmIKrfKhOqFzXGXwukWJ8PjOSlITg0wlWXX2ju7U5bl04+2qaSb ItN3QEoIVH2MQITnEHuk23acwwuAnqLq0BydBKAYZDHGwaAfEUDqBsHRYWTeX4YVXteq q7+n5guclnMUF7aLs1R6Lb18/xcat7ONAIaMkEbHpPYf2uSWkcK5MpaO2dH2s6Ntdieg lDsQ== X-Forwarded-Encrypted: i=1; AJvYcCXQA8vtPqkb+4hPwP2ZTrjPfsT61UZ4nMEy5TLuRdYW6Q3E0rgtta8BEZ6oP/+uoAl74HJONwbZVA==@kvack.org X-Gm-Message-State: AOJu0YxE/ensz1jmd3My2K48IDdujLILXqk9haCvM0SJ8vMORv3vbBs8 EIslc6JIYWfWUqxU7/WKptT0EXZkSo5tHI6ZqU1Mu/AuLf3gIP6cIyTnxohompqgiqRHB+uZCzq cPDpt2SvPTIJS2jGicT3WzfqsuHk= X-Google-Smtp-Source: AGHT+IG/r3gSQhEjKBouSZKmUHqM+wdKZI9hDk06nNlLc2wizZHza8wUPODMHmj9HOZQ71Koaobz4K6VSNPlcbCmWm4= X-Received: by 2002:a05:6102:3914:b0:497:5e68:887b with SMTP id ada2fe7eead31-498d3e4c254mr5477927137.16.1724313472348; Thu, 22 Aug 2024 00:57:52 -0700 (PDT) MIME-Version: 1.0 References: <20240817062449.21164-1-21cnbao@gmail.com> <7050deab-e99c-4c83-b7b9-b5dad42f4e95@redhat.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Thu, 22 Aug 2024 19:57:41 +1200 Message-ID: Subject: Re: [PATCH v3 0/4] mm: clarify nofail memory allocation To: Michal Hocko Cc: Linus Torvalds , Yafang Shao , David Hildenbrand , 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" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: 4B4A5C000F X-Rspamd-Server: rspam01 X-Stat-Signature: r58jedrw6ziduxcjajmpufm4undr8wru X-HE-Tag: 1724313473-487365 X-HE-Meta: U2FsdGVkX19MJDYcNP8zIx665W8YmMQN5VB8rRQznQyHXW2L1YYmUcPGHoBfKu4mHlen9caI5UaxfRAzavJJEmN5qLhbhUJC2iyPzgx0kXfAYq4FVhXdv0wkLxMnRJubtZ4UuPezhQVCD72YwXMy9dud+bS0nH8q7RGnr7y+vYs3nBDteX2i7gxhTVfC8d2+EWT4B6wGHG2Ai6SrrOioHeUNWE/9eLe6m5txVqXA2XFBVSABLoYg/X0Ri4ZVAjb7mpNWXIU8ZRWXD0AaGQKo4wNCOCd252nB5W34iLxmwesQazU7RrvGpnQNErwbozeElowiFzDeNCHl6ZKcIHltCo59nEBGelLvFTcruz8icVndcIWLajCg61rH44rWuQpWkifn1CrHm9qskYSRM+7YuUeKdRjkOPV5uWkNBqSDWuqOheCLewgRNYexwocJHtjjMy6F5BaS9j/eEFmJZQj8ghP7nrHp729vu3R9Y7GraHsfiITq2p8OPm/n3TINnHy4Tg1vIyjUykX4pseNzMaEV+qmz7qUQhjemYIpZFBz8agILbMb1gah42oOOXjgI2zainzo/c6K79A5bTEzpcWLlbpwcI1xQPoxdBqKITgCf/ok0GG1riGM1LlIynXXqS+++byXRi4ZAJBWMvXK9pPsWnRI0VrH0XJSsmG6EEEq1FAqy/GdfkTcHfafj3T/P8iM3gEy2sn9OKMASlSJhvXS1TfneGNFTl5GgSFGrJkiNpcvdFbGAI4DaaJ15ZIolHZDAGghkt9OxTi6d1kd8uQUWiJmedCvAvXfrIVGx3NGWVcgl99m65+mE+8pcLzMzRx9IpjJYymIbshrwWdZxizQ9D5+5DMxcIGtkltOqHDIqCiXkeyJRNIHv17+sQeoBaw8aYkJUfM9WgT/AKKcAYfr06ythp8YCavqh1goEijLgHsZ8NHvN9yYkc5CKlYgq1+XDNseMC+LR1VIHaz0CLd 38dZsecE 4lpqtAAjfo5AqDQK2jKTw5E1/Wm9NGi4gsfpPamdUUYYbu+ybi1+/uWWKlK5aCnjXA4K4J58dfP6tWgxRMTqWooYdp+CsUT7DCrfX3G9Lt+LbTQRng+P38Fuq3YGfxhzE61uyF6wi9QFIAjSe6XqavHDb80ocbDYGCLvZigrRIq7yHwGznhLvNSiiJwv3HLsgQoWFfuEm5uWZKJZcBx/UTOC1YdYvFkNhahgj0mtQpBAS9d6bDu3TTnRvAlcuorRZ+v5s5sr9q31Th95/jpO1cIVIz/nKH54JCtTMXQT5CcEQhVFlnlxR0omX7Oo/QVC8lcICuGWAnoGDY/xHRe6bLp3owW3oPbjyG3H38H81oHI925Vi+CpmHC1pYGEcCuQokIL+UOVoF73e7CmGPbZ1+v2187D+xi1QeD0OPshnOfS8wPpmCHZj46ihG5jyS2QqTTR6yyQV66Ifn3hBBk1+BjDrNFAIHwLDi9XEtkfH1ysqKZY= 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, Aug 22, 2024 at 7:47=E2=80=AFPM Michal Hocko wrot= e: > > On Thu 22-08-24 14:56:08, Linus Torvalds wrote: > > On Thu, 22 Aug 2024 at 14:40, Linus Torvalds > > wrote: > > > > > > I did find three cases of kvcalloc(NOFAIL) in the nouveau driver and > > > one in erofs. It's not clear that any of them make much sense (or tha= t > > > the erofs one is actually a large allocation). > > > > Oh, and I missed one in btrfs because it needed five lines of context > > due to being the allocation from hell. > > > > That said, yes, the vmalloc case at least has no fragmentation issues, > > but I do think even that needs to be size limited for sanity. > > > > The size limit might be larger than a couple of pages, but not > > _hugely_ larger. You can't just say "I want a megabyte, and you can't > > fail me". That kind of code is garbage, and needs to be called out for > > being garbage. > > yes, no objection here. Our current limits are too large for any > practical purpose. We still need a strategy how to communicate that > the size is not supported though. Just returning NULL is IMHO bad thing > because it adds potentially silent failure. In other subthread I was > contemplating about OOPS_ON which would simply terminate the user > context and kill it right away. What do you think about something like > that? Personally, I fully support this approach that falls between BUG_ON and returning NULL. Regarding the concern about 'leaving locks behind' you have in that subthread, I believe there's no difference when returning NULL, as it could still leave locks behind but offers a chance for the calling process to avoid an immediate crash. > -- > Michal Hocko > SUSE Labs Thanks Barry