All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Yafang Shao <laoar.shao@gmail.com>,
	David Hildenbrand <david@redhat.com>,
	Barry Song <21cnbao@gmail.com>,
	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
Subject: Re: [PATCH v3 0/4] mm: clarify nofail memory allocation
Date: Thu, 22 Aug 2024 09:47:36 +0200	[thread overview]
Message-ID: <ZsbtGClLMtaeakdo@tiehlicka> (raw)
In-Reply-To: <CAHk-=wiNCkgsrdNii7EwEXjt_47wF7YBJYWMhdsZJS8yVFDR=Q@mail.gmail.com>

On Thu 22-08-24 14:56:08, Linus Torvalds wrote:
> On Thu, 22 Aug 2024 at 14:40, Linus Torvalds
> <torvalds@linux-foundation.org> 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 that
> > 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?
-- 
Michal Hocko
SUSE Labs

  reply	other threads:[~2024-08-22  7:47 UTC|newest]

Thread overview: 101+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-17  6:24 [PATCH v3 0/4] mm: clarify nofail memory allocation Barry Song
2024-08-17  6:24 ` [PATCH v3 1/4] vduse: avoid using __GFP_NOFAIL Barry Song
2024-08-17  6:24 ` [PATCH v3 2/4] mm: document __GFP_NOFAIL must be blockable Barry Song
2024-08-17  6:24 ` [PATCH v3 3/4] mm: BUG_ON to avoid NULL deference while __GFP_NOFAIL fails Barry Song
2024-08-19  9:43   ` David Hildenbrand
2024-08-19  9:47     ` Barry Song
2024-08-19  9:55       ` David Hildenbrand
2024-08-19 10:02         ` Barry Song
2024-08-19 12:33           ` David Hildenbrand
2024-08-19 12:48             ` Barry Song
2024-08-19 12:49               ` David Hildenbrand
2024-08-19 17:12                 ` Michal Hocko
2024-08-19 17:17                   ` Linus Torvalds
2024-08-19 20:24                   ` David Hildenbrand
2024-08-19 20:35                     ` Linus Torvalds
2024-08-19 21:57                       ` David Hildenbrand
2024-08-19 22:13                         ` Linus Torvalds
2024-08-20  6:17                         ` Michal Hocko
2024-08-19 12:49             ` Christoph Hellwig
2024-08-19 12:51               ` David Hildenbrand
2024-08-19 12:53                 ` Christoph Hellwig
2024-08-19 13:14                   ` David Hildenbrand
2024-08-19 13:05                 ` Barry Song
2024-08-19 13:10                   ` David Hildenbrand
2024-08-19 13:19                     ` Barry Song
2024-08-19 13:22                       ` David Hildenbrand
2024-08-17  6:24 ` [PATCH v3 4/4] mm: prohibit NULL deference exposed for unsupported non-blockable __GFP_NOFAIL Barry Song
2024-08-18  2:55   ` Yafang Shao
2024-08-18  3:48     ` Barry Song
2024-08-18  5:51       ` Yafang Shao
2024-08-18  6:27         ` Barry Song
2024-08-18  6:45           ` Barry Song
2024-08-18  7:07             ` Yafang Shao
2024-08-18  7:25               ` Barry Song
2024-08-19  7:51               ` Michal Hocko
2024-08-19  7:50     ` Michal Hocko
2024-08-19  9:25       ` Yafang Shao
2024-08-19  9:39         ` Barry Song
2024-08-19  9:45           ` Yafang Shao
2024-08-19 10:10             ` Barry Song
2024-08-19 11:56               ` Yafang Shao
2024-08-19 12:09                 ` Michal Hocko
2024-08-19 12:17                   ` Yafang Shao
2024-08-19 14:01                     ` Michal Hocko
2024-08-19 10:17         ` Michal Hocko
2024-08-19 11:56           ` Yafang Shao
2024-08-19 12:04             ` Michal Hocko
2024-08-19  9:44   ` David Hildenbrand
2024-08-19 10:19     ` Michal Hocko
2024-08-19 12:48       ` David Hildenbrand
2024-08-19 13:02 ` [PATCH v3 0/4] mm: clarify nofail memory allocation David Hildenbrand
2024-08-19 16:05   ` Linus Torvalds
2024-08-19 19:23     ` Barry Song
2024-08-19 19:33       ` Linus Torvalds
2024-08-19 21:48         ` Barry Song
2024-08-20  6:24         ` Michal Hocko
2024-08-21 12:40     ` Yafang Shao
2024-08-21 22:59       ` Linus Torvalds
2024-08-22  6:21         ` Michal Hocko
2024-08-22  6:40           ` Linus Torvalds
2024-08-22  6:56             ` Linus Torvalds
2024-08-22  7:47               ` Michal Hocko [this message]
2024-08-22  7:57                 ` Barry Song
2024-08-22  8:24                   ` Michal Hocko
2024-08-22  8:39                     ` David Hildenbrand
2024-08-22  9:08                       ` Linus Torvalds
2024-08-22  9:16                         ` Michal Hocko
2024-08-22  9:24                           ` Linus Torvalds
2024-08-22  9:11                       ` Michal Hocko
2024-08-22  9:18                         ` Linus Torvalds
2024-08-22  9:33                           ` Michal Hocko
2024-08-22  9:44                             ` Linus Torvalds
2024-08-22  9:59                               ` Michal Hocko
2024-08-22 10:30                                 ` Linus Torvalds
2024-08-22 10:46                                   ` Michal Hocko
2024-08-22  9:27                         ` David Hildenbrand
2024-08-22  9:34                           ` Linus Torvalds
2024-08-22  9:43                             ` David Hildenbrand
2024-08-22  9:53                               ` Linus Torvalds
2024-08-22 11:58                                 ` Johannes Weiner
2024-08-26 12:10                             ` Vlastimil Babka
2024-08-27  6:57                               ` Linus Torvalds
2024-08-27  7:15                               ` Barry Song
2024-08-27  7:38                                 ` Vlastimil Babka
2024-08-27  7:50                                   ` Barry Song
2024-08-29 10:24                                     ` Vlastimil Babka
2024-08-29 11:53                                       ` Barry Song
2024-08-29 13:20                                         ` Michal Hocko
2024-08-29 21:27                                           ` Barry Song
2024-08-29 22:31                                             ` Barry Song
2024-08-30  7:24                                               ` Michal Hocko
2024-08-30  7:37                                                 ` Vlastimil Babka
2024-08-22  9:41                           ` Michal Hocko
2024-08-22  9:42                             ` David Hildenbrand
2024-08-22  7:01             ` Gao Xiang
2024-08-22  7:54               ` Michal Hocko
2024-08-22  8:04                 ` Gao Xiang
2024-08-22 14:35                   ` Yafang Shao
2024-08-22 15:02                     ` Gao Xiang
2024-08-22  6:37       ` Barry Song
2024-08-22 14:22         ` Yafang Shao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZsbtGClLMtaeakdo@tiehlicka \
    --to=mhocko@suse.com \
    --cc=21cnbao@gmail.com \
    --cc=42.hyeyoo@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=david@redhat.com \
    --cc=hailong.liu@oppo.com \
    --cc=hch@infradead.org \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=laoar.shao@gmail.com \
    --cc=linux-mm@kvack.org \
    --cc=penberg@kernel.org \
    --cc=rientjes@google.com \
    --cc=roman.gushchin@linux.dev \
    --cc=torvalds@linux-foundation.org \
    --cc=urezki@gmail.com \
    --cc=v-songbaohua@oppo.com \
    --cc=vbabka@suse.cz \
    --cc=virtualization@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.