[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wij=z-C6puGv+E5gGKgFMam-ucCjyji0-vP1wd=aUpFvQ@mail.gmail.com>
Date: Fri, 24 Mar 2023 12:11:07 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Luis Chamberlain <mcgrof@...nel.org>
Cc: David Hildenbrand <david@...hat.com>,
Kees Cook <keescook@...omium.org>,
linux-modules@...r.kernel.org, linux-kernel@...r.kernel.org,
pmladek@...e.com, petr.pavlu@...e.com, prarit@...hat.com,
christophe.leroy@...roup.eu, song@...nel.org, dave@...olabs.net,
fan.ni@...sung.com, vincent.fu@...sung.com,
a.manzanares@...sung.com, colin.i.king@...il.com
Subject: Re: [RFC 00/12] module: avoid userspace pressure on unwanted allocations
On Fri, Mar 24, 2023 at 10:54 AM Luis Chamberlain <mcgrof@...nel.org> wrote:
>
> +/*
> + * This clutch ensures we only allow a certain number concurrent threads at a
kludge, not clutch.
And it's much worse than a kludge. It's just wrong and disgusting.
> + pr_warn_ratelimited("kread_concurrent_max (%u) close to 0 (max_loads: %u), throttling...",
> + atomic_read(&kread_concurrent_max),
> + MAX_KREAD_CONCURRENT);
This is also wrong, since it's not kernel_read_file() that is the
problem, but whatever broken caller.
Yeah, yeah, in practice it's presumably always just finit_module()
doing kernel_read_file_from_fd(), but it's still *completely* wrong to
just say "function X is throttling" when "X" isn't the problem, and
doesn't tell what the _real_ problem is.
I really think this all needs some core fixing at the module layer,
not these kinds of horrific hacks.
Linus
Powered by blists - more mailing lists