On Thu, Aug 22, 2024 at 7:47 PM Michal Hocko <mhocko@xxxxxxxx> wrote: > > On Thu 22-08-24 14:56:08, Linus Torvalds wrote: > > On Thu, 22 Aug 2024 at 14:40, Linus Torvalds > > <torvalds@xxxxxxxxxxxxxxxxxxxx> 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? 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
