Hello,
syzbot found the following crash on:
HEAD commit: 234b69e3e089 ocfs2: fix ocfs2 read block panic
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=131f761a400000
kernel config: https://syzkaller.appspot.com/x/.config?x=5fa12be50bca08d8
dashboard link: https://syzkaller.appspot.com/bug?extid=87829a10073277282ad1
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=126ca61a400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=119d6511400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: [email protected]
input: syz0 as /devices/virtual/input/input25382
WARNING: CPU: 0 PID: 11238 at mm/slab_common.c:1031 kmalloc_slab+0x56/0x70
mm/slab_common.c:1031
Kernel panic - not syncing: panic_on_warn set ...
CPU: 0 PID: 11238 Comm: syz-executor124 Not tainted 4.19.0-rc4+ #25
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c4/0x2b4 lib/dump_stack.c:113
panic+0x238/0x4e7 kernel/panic.c:184
__warn.cold.8+0x163/0x1ba kernel/panic.c:536
report_bug+0x254/0x2d0 lib/bug.c:186
fixup_bug arch/x86/kernel/traps.c:178 [inline]
do_error_trap+0x1fc/0x4d0 arch/x86/kernel/traps.c:296
do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:316
invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:993
RIP: 0010:kmalloc_slab+0x56/0x70 mm/slab_common.c:1031
kobject: 'input25395' (00000000663cc863): kobject_cleanup, parent
(null)
Code: c5 40 2b 17 89 5d c3 48 85 ff b8 10 00 00 00 74 f4 83 ef 01 c1 ef 03
0f b6 87 60 2a 17 89 eb d8 31 c0 81 e6 00 02 00 00 75 db <0f> 0b 5d c3 48
8b 04 c5 80 2a 17 89 5d c3 66 90 66 2e 0f 1f 84 00
kobject: 'input25395' (00000000663cc863): calling ktype release
RSP: 0018:ffff8801c477f978 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 00000000fffffffd RCX: ffffffff8534b947
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000003fffffff60
RBP: ffff8801c477f978 R08: ffff8801d2eee000 R09: ffffed003731ee41
R10: ffff8801c477fa48 R11: ffff8801b98f720f R12: 0000000000000000
R13: 0000000000000000 R14: ffff8801b92ac9c0 R15: 00000000006080c0
__do_kmalloc mm/slab.c:3713 [inline]
__kmalloc+0x25/0x760 mm/slab.c:3727
kobject: 'input25395': free name
kmalloc include/linux/slab.h:518 [inline]
kzalloc include/linux/slab.h:707 [inline]
input_mt_init_slots+0xe5/0x4a0 drivers/input/input-mt.c:52
uinput_create_device drivers/input/misc/uinput.c:335 [inline]
uinput_ioctl_handler.isra.10+0x2049/0x2540 drivers/input/misc/uinput.c:876
uinput_ioctl+0x4c/0x60 drivers/input/misc/uinput.c:1047
vfs_ioctl fs/ioctl.c:46 [inline]
file_ioctl fs/ioctl.c:501 [inline]
do_vfs_ioctl+0x1de/0x1720 fs/ioctl.c:685
ksys_ioctl+0xa9/0xd0 fs/ioctl.c:702
__do_sys_ioctl fs/ioctl.c:709 [inline]
__se_sys_ioctl fs/ioctl.c:707 [inline]
__x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:707
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x446ec9
Code: e8 2c b3 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 2b 09 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007fa83f4b1da8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00000000006dbc28 RCX: 0000000000446ec9
RDX: 0000000000446ec9 RSI: 0000000000005501 RDI: 0000000000000004
RBP: 00000000006dbc20 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000006dbc2c
R13: 6e69752f7665642f R14: 00007fa83f4b29c0 R15: 00000000006dbd2c
Kernel Offset: disabled
Rebooting in 86400 seconds..
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at [email protected].
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
On Fri, Sep 21, 2018 at 10:24 AM syzbot
<[email protected]> wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 234b69e3e089 ocfs2: fix ocfs2 read block panic
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=131f761a400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=5fa12be50bca08d8
> dashboard link: https://syzkaller.appspot.com/bug?extid=87829a10073277282ad1
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=126ca61a400000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=119d6511400000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: [email protected]
>
> input: syz0 as /devices/virtual/input/input25382
> WARNING: CPU: 0 PID: 11238 at mm/slab_common.c:1031 kmalloc_slab+0x56/0x70
> mm/slab_common.c:1031
> Kernel panic - not syncing: panic_on_warn set ...
This is coming from:
commit 6286ae97d10ea2b5cd90532163797ab217bfdbdf
Author: Christoph Lameter <[email protected]>
Date: Fri May 3 15:43:18 2013 +0000
slab: Return NULL for oversized allocations
The inline path seems to have changed the SLAB behavior for very large
kmalloc allocations with commit e3366016 ("slab: Use common
kmalloc_index/kmalloc_size functions"). This patch restores the old
behavior but also adds diagnostics so that we can figure where in the
code these large allocations occur.
Reported-and-tested-by: Tetsuo Handa <[email protected]>
Signed-off-by: Christoph Lameter <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
[ [email protected]: use WARN_ON_ONCE ]
Signed-off-by: Pekka Enberg <[email protected]>
You'll have to convince Cristoph that WARN_ON_ONCE() there is evil and
has to be eradicated so that KASAN can run (but then we'd not know
easily that some allocation failed because it was too big and never
had a chance of succeeding vs. ordinary memory failure).
Can I recommend that maybe you introduce infrastructure for
panic_on_warn to ignore certain "well known" warnings?
Thanks.
--
Dmitry
On Fri, Sep 21, 2018 at 7:52 PM, Dmitry Torokhov
<[email protected]> wrote:
> On Fri, Sep 21, 2018 at 10:24 AM syzbot
> <[email protected]> wrote:
>>
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit: 234b69e3e089 ocfs2: fix ocfs2 read block panic
>> git tree: upstream
>> console output: https://syzkaller.appspot.com/x/log.txt?x=131f761a400000
>> kernel config: https://syzkaller.appspot.com/x/.config?x=5fa12be50bca08d8
>> dashboard link: https://syzkaller.appspot.com/bug?extid=87829a10073277282ad1
>> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=126ca61a400000
>> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=119d6511400000
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: [email protected]
>>
>> input: syz0 as /devices/virtual/input/input25382
>> WARNING: CPU: 0 PID: 11238 at mm/slab_common.c:1031 kmalloc_slab+0x56/0x70
>> mm/slab_common.c:1031
>> Kernel panic - not syncing: panic_on_warn set ...
>
> This is coming from:
>
> commit 6286ae97d10ea2b5cd90532163797ab217bfdbdf
> Author: Christoph Lameter <[email protected]>
> Date: Fri May 3 15:43:18 2013 +0000
>
> slab: Return NULL for oversized allocations
>
> The inline path seems to have changed the SLAB behavior for very large
> kmalloc allocations with commit e3366016 ("slab: Use common
> kmalloc_index/kmalloc_size functions"). This patch restores the old
> behavior but also adds diagnostics so that we can figure where in the
> code these large allocations occur.
>
> Reported-and-tested-by: Tetsuo Handa <[email protected]>
> Signed-off-by: Christoph Lameter <[email protected]>
> Link: http://lkml.kernel.org/r/[email protected]
> [ [email protected]: use WARN_ON_ONCE ]
> Signed-off-by: Pekka Enberg <[email protected]>
>
> You'll have to convince Cristoph that WARN_ON_ONCE() there is evil and
> has to be eradicated so that KASAN can run (but then we'd not know
> easily that some allocation failed because it was too big and never
> had a chance of succeeding vs. ordinary memory failure).
>
> Can I recommend that maybe you introduce infrastructure for
> panic_on_warn to ignore certain "well known" warnings?
Hi Christoph,
What was the motivation behind that WARNING about large allocations in
kmalloc? Why do we want to know about them? Is the general policy that
kmalloc calls with potentially large size requests need to use NOWARN?
If this WARNING still considered useful? Or we should change it to
pr_err?
On Sun, 23 Sep 2018, Dmitry Vyukov wrote:
> What was the motivation behind that WARNING about large allocations in
> kmalloc? Why do we want to know about them? Is the general policy that
> kmalloc calls with potentially large size requests need to use NOWARN?
> If this WARNING still considered useful? Or we should change it to
> pr_err?
In general large allocs should be satisfied by the page allocator. The
slab allocators are used for allocating and managing small objects. The
page allocator has mechanisms to deal with large objects (compound pages,
multiple page sized allocs etc).
On Mon, Sep 24, 2018 at 5:08 PM, Christopher Lameter <[email protected]> wrote:
> On Sun, 23 Sep 2018, Dmitry Vyukov wrote:
>
>> What was the motivation behind that WARNING about large allocations in
>> kmalloc? Why do we want to know about them? Is the general policy that
>> kmalloc calls with potentially large size requests need to use NOWARN?
>> If this WARNING still considered useful? Or we should change it to
>> pr_err?
>
> In general large allocs should be satisfied by the page allocator. The
> slab allocators are used for allocating and managing small objects. The
> page allocator has mechanisms to deal with large objects (compound pages,
> multiple page sized allocs etc).
I am asking more about the status of this warning. If it fires in
input_mt_init_slots(), does it mean that input_mt_init_slots() needs
to be fixed? If not, then we need to change this warning to something
else.
On Mon, 24 Sep 2018, Dmitry Vyukov wrote:
> On Mon, Sep 24, 2018 at 5:08 PM, Christopher Lameter <[email protected]> wrote:
> > On Sun, 23 Sep 2018, Dmitry Vyukov wrote:
> >
> >> What was the motivation behind that WARNING about large allocations in
> >> kmalloc? Why do we want to know about them? Is the general policy that
> >> kmalloc calls with potentially large size requests need to use NOWARN?
> >> If this WARNING still considered useful? Or we should change it to
> >> pr_err?
> >
> > In general large allocs should be satisfied by the page allocator. The
> > slab allocators are used for allocating and managing small objects. The
> > page allocator has mechanisms to deal with large objects (compound pages,
> > multiple page sized allocs etc).
>
> I am asking more about the status of this warning. If it fires in
> input_mt_init_slots(), does it mean that input_mt_init_slots() needs
> to be fixed? If not, then we need to change this warning to something
> else.
Hmmm.. kmalloc falls back to the page allocator already?
See
static __always_inline void *kmalloc(size_t size, gfp_t flags)
{
if (__builtin_constant_p(size)) {
if (size > KMALLOC_MAX_CACHE_SIZE)
return kmalloc_large(size, flags);
Note that this uses KMALLOC_MAX_CACHE_SIZE which should be smaller than
KMALLOC_MAX_SIZE.
How large is the allocation? AFACIT nRequests larger than KMALLOC_MAX_SIZE
are larger than the maximum allowed by the page allocator. Thus the warning
and the NULL return.
On Mon, Sep 24, 2018 at 03:55:04PM +0000, Christopher Lameter wrote:
> On Mon, 24 Sep 2018, Dmitry Vyukov wrote:
>
> > On Mon, Sep 24, 2018 at 5:08 PM, Christopher Lameter <[email protected]> wrote:
> > > On Sun, 23 Sep 2018, Dmitry Vyukov wrote:
> > >
> > >> What was the motivation behind that WARNING about large allocations in
> > >> kmalloc? Why do we want to know about them? Is the general policy that
> > >> kmalloc calls with potentially large size requests need to use NOWARN?
> > >> If this WARNING still considered useful? Or we should change it to
> > >> pr_err?
> > >
> > > In general large allocs should be satisfied by the page allocator. The
> > > slab allocators are used for allocating and managing small objects. The
> > > page allocator has mechanisms to deal with large objects (compound pages,
> > > multiple page sized allocs etc).
> >
> > I am asking more about the status of this warning. If it fires in
> > input_mt_init_slots(), does it mean that input_mt_init_slots() needs
> > to be fixed? If not, then we need to change this warning to something
> > else.
>
> Hmmm.. kmalloc falls back to the page allocator already?
>
> See
>
> static __always_inline void *kmalloc(size_t size, gfp_t flags)
> {
> if (__builtin_constant_p(size)) {
It would not be a constant here though.
> if (size > KMALLOC_MAX_CACHE_SIZE)
> return kmalloc_large(size, flags);
>
>
> Note that this uses KMALLOC_MAX_CACHE_SIZE which should be smaller than
> KMALLOC_MAX_SIZE.
>
>
> How large is the allocation? AFACIT nRequests larger than KMALLOC_MAX_SIZE
> are larger than the maximum allowed by the page allocator. Thus the warning
> and the NULL return.
The size in this particular case is being derived from a value passed
from userspace. Input core does not care about any limits on size of
memory kmalloc() can support and is perfectly happy with getting NULL
and telling userspace to go away with their silly requests by returning
-ENOMEM.
For the record: I definitely do not want to pre-sanitize size neither in
uinput nor in input core.
Thanks.
--
Dmitry
On Mon, Sep 24, 2018 at 8:41 PM, Dmitry Torokhov
<[email protected]> wrote:
> On Mon, Sep 24, 2018 at 03:55:04PM +0000, Christopher Lameter wrote:
>> On Mon, 24 Sep 2018, Dmitry Vyukov wrote:
>>
>> > On Mon, Sep 24, 2018 at 5:08 PM, Christopher Lameter <[email protected]> wrote:
>> > > On Sun, 23 Sep 2018, Dmitry Vyukov wrote:
>> > >
>> > >> What was the motivation behind that WARNING about large allocations in
>> > >> kmalloc? Why do we want to know about them? Is the general policy that
>> > >> kmalloc calls with potentially large size requests need to use NOWARN?
>> > >> If this WARNING still considered useful? Or we should change it to
>> > >> pr_err?
>> > >
>> > > In general large allocs should be satisfied by the page allocator. The
>> > > slab allocators are used for allocating and managing small objects. The
>> > > page allocator has mechanisms to deal with large objects (compound pages,
>> > > multiple page sized allocs etc).
>> >
>> > I am asking more about the status of this warning. If it fires in
>> > input_mt_init_slots(), does it mean that input_mt_init_slots() needs
>> > to be fixed? If not, then we need to change this warning to something
>> > else.
>>
>> Hmmm.. kmalloc falls back to the page allocator already?
>>
>> See
>>
>> static __always_inline void *kmalloc(size_t size, gfp_t flags)
>> {
>> if (__builtin_constant_p(size)) {
>
> It would not be a constant here though.
>
>> if (size > KMALLOC_MAX_CACHE_SIZE)
>> return kmalloc_large(size, flags);
>>
>>
>> Note that this uses KMALLOC_MAX_CACHE_SIZE which should be smaller than
>> KMALLOC_MAX_SIZE.
>>
>>
>> How large is the allocation? AFACIT nRequests larger than KMALLOC_MAX_SIZE
>> are larger than the maximum allowed by the page allocator. Thus the warning
>> and the NULL return.
>
> The size in this particular case is being derived from a value passed
> from userspace. Input core does not care about any limits on size of
> memory kmalloc() can support and is perfectly happy with getting NULL
> and telling userspace to go away with their silly requests by returning
> -ENOMEM.
>
> For the record: I definitely do not want to pre-sanitize size neither in
> uinput nor in input core.
Christopher,
Assuming that the size is large enough to fail in all allocators, is
this warning still useful? How? Should we remove it?
On Tue, 25 Sep 2018, Dmitry Vyukov wrote:
> Assuming that the size is large enough to fail in all allocators, is
> this warning still useful? How? Should we remove it?
Remove it. It does not make sense because we check earlier if possible
without the warn.
On Tue, Sep 25, 2018 at 4:04 PM, Christopher Lameter <[email protected]> wrote:
> On Tue, 25 Sep 2018, Dmitry Vyukov wrote:
>
>> Assuming that the size is large enough to fail in all allocators, is
>> this warning still useful? How? Should we remove it?
>
> Remove it. It does not make sense because we check earlier if possible
> without the warn.
Mailed "mm: don't warn about large allocations for slab" to remove the warning.
On Thu, 27 Sep 2018, Dmitry Vyukov wrote:
> On Tue, Sep 25, 2018 at 4:04 PM, Christopher Lameter <[email protected]> wrote:
> > On Tue, 25 Sep 2018, Dmitry Vyukov wrote:
> >
> >> Assuming that the size is large enough to fail in all allocators, is
> >> this warning still useful? How? Should we remove it?
> >
> > Remove it. It does not make sense because we check earlier if possible
> > without the warn.
>
> Mailed "mm: don't warn about large allocations for slab" to remove the warning.
>
Hoe it arrives here at some point.
On Thu, Sep 27, 2018 at 4:16 PM, Christopher Lameter <[email protected]> wrote:
> On Thu, 27 Sep 2018, Dmitry Vyukov wrote:
>
>> On Tue, Sep 25, 2018 at 4:04 PM, Christopher Lameter <[email protected]> wrote:
>> > On Tue, 25 Sep 2018, Dmitry Vyukov wrote:
>> >
>> >> Assuming that the size is large enough to fail in all allocators, is
>> >> this warning still useful? How? Should we remove it?
>> >
>> > Remove it. It does not make sense because we check earlier if possible
>> > without the warn.
>>
>> Mailed "mm: don't warn about large allocations for slab" to remove the warning.
>>
>
> Hoe it arrives here at some point.
It's here:
https://lore.kernel.org/patchwork/patch/992660/
On Mon, Sep 24, 2018 at 11:41:58AM -0700, Dmitry Torokhov wrote:
> > How large is the allocation? AFACIT nRequests larger than KMALLOC_MAX_SIZE
> > are larger than the maximum allowed by the page allocator. Thus the warning
> > and the NULL return.
>
> The size in this particular case is being derived from a value passed
> from userspace. Input core does not care about any limits on size of
> memory kmalloc() can support and is perfectly happy with getting NULL
> and telling userspace to go away with their silly requests by returning
> -ENOMEM.
>
> For the record: I definitely do not want to pre-sanitize size neither in
> uinput nor in input core.
Probably should be using kvzalloc then.
On Thu, 27 Sep 2018, Dmitry Vyukov wrote:
> On Thu, Sep 27, 2018 at 4:16 PM, Christopher Lameter <[email protected]> wrote:
> > On Thu, 27 Sep 2018, Dmitry Vyukov wrote:
> >
> >> On Tue, Sep 25, 2018 at 4:04 PM, Christopher Lameter <[email protected]> wrote:
> >> > On Tue, 25 Sep 2018, Dmitry Vyukov wrote:
> >> >
> >> >> Assuming that the size is large enough to fail in all allocators, is
> >> >> this warning still useful? How? Should we remove it?
> >> >
> >> > Remove it. It does not make sense because we check earlier if possible
> >> > without the warn.
> >>
> >> Mailed "mm: don't warn about large allocations for slab" to remove the warning.
> >>
> >
> > Hoe it arrives here at some point.
>
> It's here:
> https://lore.kernel.org/patchwork/patch/992660/
>
Please post on the mailing list and NAK to the patch. Testing against
KMALLOC_MAX_CACHE_SIZE is not ok.
On Thu, Sep 27, 2018 at 5:22 PM, Christopher Lameter <[email protected]> wrote:
> On Thu, 27 Sep 2018, Dmitry Vyukov wrote:
>
>> On Thu, Sep 27, 2018 at 4:16 PM, Christopher Lameter <[email protected]> wrote:
>> > On Thu, 27 Sep 2018, Dmitry Vyukov wrote:
>> >
>> >> On Tue, Sep 25, 2018 at 4:04 PM, Christopher Lameter <[email protected]> wrote:
>> >> > On Tue, 25 Sep 2018, Dmitry Vyukov wrote:
>> >> >
>> >> >> Assuming that the size is large enough to fail in all allocators, is
>> >> >> this warning still useful? How? Should we remove it?
>> >> >
>> >> > Remove it. It does not make sense because we check earlier if possible
>> >> > without the warn.
>> >>
>> >> Mailed "mm: don't warn about large allocations for slab" to remove the warning.
>> >>
>> >
>> > Hoe it arrives here at some point.
>>
>> It's here:
>> https://lore.kernel.org/patchwork/patch/992660/
>>
>
> Please post on the mailing list
It is on the mailing lists:
https://lkml.org/lkml/2018/9/27/802
> and NAK to the patch. Testing against
> KMALLOC_MAX_CACHE_SIZE is not ok.
Why?
On Thu, 27 Sep 2018, Dmitry Vyukov wrote:
> > Please post on the mailing list
>
> It is on the mailing lists:
> https://lkml.org/lkml/2018/9/27/802
Ok then lets continue the discussion there.
On Thu, Sep 27, 2018 at 07:35:37AM -0700, Matthew Wilcox wrote:
> On Mon, Sep 24, 2018 at 11:41:58AM -0700, Dmitry Torokhov wrote:
> > > How large is the allocation? AFACIT nRequests larger than KMALLOC_MAX_SIZE
> > > are larger than the maximum allowed by the page allocator. Thus the warning
> > > and the NULL return.
> >
> > The size in this particular case is being derived from a value passed
> > from userspace. Input core does not care about any limits on size of
> > memory kmalloc() can support and is perfectly happy with getting NULL
> > and telling userspace to go away with their silly requests by returning
> > -ENOMEM.
> >
> > For the record: I definitely do not want to pre-sanitize size neither in
> > uinput nor in input core.
>
> Probably should be using kvzalloc then.
No. No sane input device can track so many contacts so we need to use
kvzalloc(). Failing to allocate memory is proper response here.
Thanks.
--
Dmitry
On Tue, 16 Oct 2018, Dmitry Torokhov wrote:
> On Thu, Sep 27, 2018 at 07:35:37AM -0700, Matthew Wilcox wrote:
> > On Mon, Sep 24, 2018 at 11:41:58AM -0700, Dmitry Torokhov wrote:
> > > > How large is the allocation? AFACIT nRequests larger than KMALLOC_MAX_SIZE
> > > > are larger than the maximum allowed by the page allocator. Thus the warning
> > > > and the NULL return.
> > >
> > > The size in this particular case is being derived from a value passed
> > > from userspace. Input core does not care about any limits on size of
> > > memory kmalloc() can support and is perfectly happy with getting NULL
> > > and telling userspace to go away with their silly requests by returning
> > > -ENOMEM.
> > >
> > > For the record: I definitely do not want to pre-sanitize size neither in
> > > uinput nor in input core.
> >
> > Probably should be using kvzalloc then.
>
> No. No sane input device can track so many contacts so we need to use
> kvzalloc(). Failing to allocate memory is proper response here.
What is a "contact" here? Are we talking about SG segments?
On October 17, 2018 8:35:15 AM PDT, Christopher Lameter <[email protected]> wrote:
>On Tue, 16 Oct 2018, Dmitry Torokhov wrote:
>
>> On Thu, Sep 27, 2018 at 07:35:37AM -0700, Matthew Wilcox wrote:
>> > On Mon, Sep 24, 2018 at 11:41:58AM -0700, Dmitry Torokhov wrote:
>> > > > How large is the allocation? AFACIT nRequests larger than
>KMALLOC_MAX_SIZE
>> > > > are larger than the maximum allowed by the page allocator. Thus
>the warning
>> > > > and the NULL return.
>> > >
>> > > The size in this particular case is being derived from a value
>passed
>> > > from userspace. Input core does not care about any limits on size
>of
>> > > memory kmalloc() can support and is perfectly happy with getting
>NULL
>> > > and telling userspace to go away with their silly requests by
>returning
>> > > -ENOMEM.
>> > >
>> > > For the record: I definitely do not want to pre-sanitize size
>neither in
>> > > uinput nor in input core.
>> >
>> > Probably should be using kvzalloc then.
>>
>> No. No sane input device can track so many contacts so we need to use
>> kvzalloc(). Failing to allocate memory is proper response here.
>
>What is a "contact" here? Are we talking about SG segments?
No, we are talking about maximum number of fingers a person can have. Devices don't usually track more than 10 distinct contacts on the touch surface at a time.
Thanks.
--
Dmitry
On Wed, 17 Oct 2018, Dmitry Torokhov wrote:
> >What is a "contact" here? Are we talking about SG segments?
>
> No, we are talking about maximum number of fingers a person can have. Devices don't usually track more than 10 distinct contacts on the touch surface at a time.
Ohh... Way off my usual contexts of development. Sorry.
Ok you have my blessing.