Re: [PATCH (resend)] Input: MT - limit max slots

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

On Mon, Jul 29, 2024 at 11:41:59AM -0700, Linus Torvalds wrote:
> On Mon, 29 Jul 2024 at 11:35, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> >
> > What exactly did you do? Limit size of data userspace can request to be
> > written? What is the max allowed size then? Can I stick a warning in the
> > code to complain when it is "too big"?
> 
> Look up MAX_RW_COUNT.
> 
> 
> > So does this mean that we should disallow any and all allocations above
> > 4k because they can potentially fail, depending on the system state? Or
> > maybe we should be resilient and fail gracefully instead?
> 
> We are resilient and fail gracefully.
> 
> But there's very a limit to that.
> 
> Dmitry - none of this is at all new. The kernel has a *lot* of
> practical limits. Many of them actually come from very traditional
> sources indeed.
> 
> Things like NR_OPEN, PATH_MAX, lots of arbitrary limits because arrays
> don't get to grow too big. Things that are *so* basic that you don't
> even think about them, because you think they are obvious.
> 
> In fact, you should start from the assumption that *EVERYTHING* is limited.
> 
> So get off your idiotic high horse. The input layer is not so special
> that you should say "I can't have any limits".

OK, if you want to have limits be it. You probably want to lower from
1024 to 128 or something, because with 1024 slots the structure will be
larger than one page and like I said mt->red table will be 4Mb.

This still will not affect any real users, and will not solve syzkaller
issue as it will continue tripping on various memory allocations that we
are actually prepared to handle.

Thanks.

-- 
Dmitry