On Mon, Jul 29, 2024 at 04:28:38PM +0200, Greg Kroah-Hartman wrote: > On Mon, Jul 29, 2024 at 10:15:26PM +0900, Tetsuo Handa wrote: > > On 2024/07/29 22:05, Greg Kroah-Hartman wrote: > > > On Mon, Jul 29, 2024 at 09:51:30PM +0900, Tetsuo Handa wrote: > > >> syzbot is reporting too large allocation at input_mt_init_slots(), for > > >> num_slots is supplied from userspace using ioctl(UI_DEV_CREATE). > > >> > > >> Since nobody knows possible max slots, this patch chose 1024. > > >> > > >> Reported-by: syzbot <syzbot+0122fa359a69694395d5@xxxxxxxxxxxxxxxxxxxxxxxxx> > > >> Closes: https://syzkaller.appspot.com/bug?extid=0122fa359a69694395d5 > > >> Suggested-by: Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> > > >> Signed-off-by: Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx> > > >> --- > > >> This patch was tested in linux-next between next-20240611 and next-20240729 > > >> via my tree. Who can take this patch? If nobody can, I will send to Linus. > > > > > > What is wrong with the normal input maintainer and tree? Why not send > > > it there? > > > > I don't know why. I couldn't get further response from Dmitry Torokhov. > > Who can make final decision and what tree is used? > > > > e.g. > > 2022-11-23 0:28 https://lkml.kernel.org/r/03e8c3f0-bbbf-af37-6f52-67547cbd4cde@xxxxxxxxxxxxxxxxxxx > > 2023-09-03 13:55 https://lkml.kernel.org/r/07350163-de52-a2bf-58bf-88c3d9d8d85b@xxxxxxxxxxxxxxxxxxx > > 2024-05-27 10:35 https://lkml.kernel.org/r/7b7f9cf5-a1de-4e5a-8d30-bb2979309f02@xxxxxxxxxxxxxxxxxxx > > > > Again, it's up to the Input maintainer. Sorry, I meant to respond to this and it got lost in my mailbox. To be honest I really dislike all this extra patching for the sake of syzkaller. Syzkaller is a tool and ideally we should not modify random places in the kernel just because it decided to [ab]use one mechanism that is also used for other purposes. Now, to the issue at hand. I believe there are 2 classes of warnings: a true warning that is emitted for clearly unexpected situation that was caused by a bug or an invariant violation somewhere. Those we definitely want syzkaller to report so that we could identify the root cause and fix it. iThe other types of warnings, such as the warning in the memory allocation case, are warnings of convenience. We have them so that we do not need to annotate all memory allocation checks with custom messages. Instead we just rely on k*alloc() and friends to give us a spew when they can't allocate memory. These allocation failures are expected and typically are handled (and if they are not handled we'll get an oops a moment later). We really do not need syzkaller to trip on those. Can we change k*alloc() to stop triggering panic on warning when we run with syzkaller? Thanks. -- Dmitry
