Re: Re: WARNING in input_alloc_absinfo
On Tue, Aug 7, 2018 at 4:28 PM, syzbot wrote: >> On Thu, Jul 26, 2018 at 11:40 AM, Dmitry Vyukov >> wrote: >>> >>> On Mon, Jul 2, 2018 at 11:30 AM, Dmitry Vyukov >>> wrote: >>>> >>>> On Fri, Jun 29, 2018 at 11:59 PM, wrote: >>>>> >>>>> On Monday, June 25, 2018 at 5:43:02 AM UTC-7, Dmitry Vyukov wrote: > > >>>>>> On Tue, Jun 19, 2018 at 8:51 PM, Dmitry Torokhov >>>>>> wrote: >>>>>> > On Thu, Jun 14, 2018 at 05:47:03AM -0700, syzbot wrote: >>>>>> >> Hello, >>>>>> >> >>>>>> >> syzbot found the following crash on: >>>>>> >> >>>>>> >> HEAD commit:d2d741e5d189 kmsan: add initialization for shmem >>>>>> >> pages >>>>>> >> git tree: https://github.com/google/kmsan.git/master >>>>>> >> console output: >>>>>> >> https://syzkaller.appspot.com/x/log.txt?x=1775bae780 >>>>>> >> kernel config: >>>>>> >> https://syzkaller.appspot.com/x/.config?x=48f9de3384bcd0f >>>>>> >> dashboard link: >>>>>> >> https://syzkaller.appspot.com/bug?extid=c382812c78d98ecd9fb8 >>>>>> >> compiler: clang version 7.0.0 (trunk 329391) >>>>>> >> syzkaller >>>>>> >> repro:https://syzkaller.appspot.com/x/repro.syz?x=13b31ae780 >>>>>> >> C reproducer: >>>>>> >> https://syzkaller.appspot.com/x/repro.c?x=1733255b80 >>>>>> >> >>>>>> >> IMPORTANT: if you fix the bug, please add the following tag to the >>>>>> >> commit: >>>>>> >> Reported-by: syzbot+c38281...@syzkaller.appspotmail.com >>>>>> >> >>>>>> >> RBP: 006cb018 R08: 0001 R09: 7ffe93080031 >>>>>> >> R10: R11: 0246 R12: 0004 >>>>>> >> R13: R14: R15: >>>>>> >> [ cut here ] >>>>>> >> input_alloc_absinfo(): kcalloc() failed? >>>>>> >> WARNING: CPU: 1 PID: 4498 at drivers/input/input.c:487 >>>>>> >> input_alloc_absinfo+0x183/0x190 drivers/input/input.c:487 >>>>>> >> Kernel panic - not syncing: panic_on_warn set ... >>>>>> > >>>>>> > Hmm, so there is not really a problem as far as I am concerned. We >>>>>> > do >>>>>> > generate a warning if we can't allocate memory for absinfo, as this >>>>>> > is >>>>>> > really unexpected, but the case is handled properly by the callers >>>>>> > so >>>>>> > there is no reason for us to go belly up here. > > >>>>>> Note to myself: ping this bug when "include/asm-generic/bug.h: clarify >>>>>> valid uses of WARN()" is fully merged. > > > >>>>> No, this warning will still be there even after the "clarifying" patch >>>>> is >>>>> merged. It does not check user inputs, it warns that the system is so >>>>> low on >>>>> memory that we could not allocate measly amount needed for absinfo. >>>>> Treat it >>>>> as you treat OOM warnings from kmalloc() itself. > > >>>> Hi Dmitry, > > >>>> kmalloc does not produce WARNING on OOM. The rule is not only about >>>> invalid inputs, it's also about any transient conditions and "WARNING >>>> only for kernel bugs". > > >>>> To put this in larger context, being able to distinguish kernel bugs >>>> from non-bugs is a very important and practically useful capability, >>>> which in particular enables systematic testing, but also makes things >>>> simpler for all kernel users. There must be a very significant reason >>>> to abandon this capability. What is that reason in this case? > > >>>> I also don't understand what is so special about this case. If we want >>>> user message for kmalloc failures, kmalloc is the right place for such >>>> warning, rather than a random call site out of thousands. Consider, >>>> the allocation failure can happen on the very next or previous kmalloc >>>> call, and user won't be warned. The rest of the kernel (including the >>>> rest of input sybsystem) does not warn on allocation failures, so that >>>> looks like what we need to do here as well. Or, if there is something >>>> very special about this particular kmalloc call site, something that >>>> makes it different from thousands of other call sites, why don't you >>>> want to replace it with pr_err which would both give the diagnostics >>>> but also not block systematic testing? Which looks like a win-win to >>>> me. > > >>>> Thanks > > > >>> So, Dmitry, do you mind fixing this in the name of unblocking kernel >>> testing? > > > >> Let's tell syzbot about the pending fix: > > >> #syz fix: Input: do not use WARN() in input_alloc_absinfo() > > > Can't find the corresponding bug. Now with syzbot email in CC: #syz fix: Input: do not use WARN() in input_alloc_absinfo()
Re: Re: WARNING in input_alloc_absinfo
On Tue, Aug 7, 2018 at 4:28 PM, syzbot wrote: >> On Thu, Jul 26, 2018 at 11:40 AM, Dmitry Vyukov >> wrote: >>> >>> On Mon, Jul 2, 2018 at 11:30 AM, Dmitry Vyukov >>> wrote: >>>> >>>> On Fri, Jun 29, 2018 at 11:59 PM, wrote: >>>>> >>>>> On Monday, June 25, 2018 at 5:43:02 AM UTC-7, Dmitry Vyukov wrote: > > >>>>>> On Tue, Jun 19, 2018 at 8:51 PM, Dmitry Torokhov >>>>>> wrote: >>>>>> > On Thu, Jun 14, 2018 at 05:47:03AM -0700, syzbot wrote: >>>>>> >> Hello, >>>>>> >> >>>>>> >> syzbot found the following crash on: >>>>>> >> >>>>>> >> HEAD commit:d2d741e5d189 kmsan: add initialization for shmem >>>>>> >> pages >>>>>> >> git tree: https://github.com/google/kmsan.git/master >>>>>> >> console output: >>>>>> >> https://syzkaller.appspot.com/x/log.txt?x=1775bae780 >>>>>> >> kernel config: >>>>>> >> https://syzkaller.appspot.com/x/.config?x=48f9de3384bcd0f >>>>>> >> dashboard link: >>>>>> >> https://syzkaller.appspot.com/bug?extid=c382812c78d98ecd9fb8 >>>>>> >> compiler: clang version 7.0.0 (trunk 329391) >>>>>> >> syzkaller >>>>>> >> repro:https://syzkaller.appspot.com/x/repro.syz?x=13b31ae780 >>>>>> >> C reproducer: >>>>>> >> https://syzkaller.appspot.com/x/repro.c?x=1733255b80 >>>>>> >> >>>>>> >> IMPORTANT: if you fix the bug, please add the following tag to the >>>>>> >> commit: >>>>>> >> Reported-by: syzbot+c38281...@syzkaller.appspotmail.com >>>>>> >> >>>>>> >> RBP: 006cb018 R08: 0001 R09: 7ffe93080031 >>>>>> >> R10: R11: 0246 R12: 0004 >>>>>> >> R13: R14: R15: >>>>>> >> [ cut here ] >>>>>> >> input_alloc_absinfo(): kcalloc() failed? >>>>>> >> WARNING: CPU: 1 PID: 4498 at drivers/input/input.c:487 >>>>>> >> input_alloc_absinfo+0x183/0x190 drivers/input/input.c:487 >>>>>> >> Kernel panic - not syncing: panic_on_warn set ... >>>>>> > >>>>>> > Hmm, so there is not really a problem as far as I am concerned. We >>>>>> > do >>>>>> > generate a warning if we can't allocate memory for absinfo, as this >>>>>> > is >>>>>> > really unexpected, but the case is handled properly by the callers >>>>>> > so >>>>>> > there is no reason for us to go belly up here. > > >>>>>> Note to myself: ping this bug when "include/asm-generic/bug.h: clarify >>>>>> valid uses of WARN()" is fully merged. > > > >>>>> No, this warning will still be there even after the "clarifying" patch >>>>> is >>>>> merged. It does not check user inputs, it warns that the system is so >>>>> low on >>>>> memory that we could not allocate measly amount needed for absinfo. >>>>> Treat it >>>>> as you treat OOM warnings from kmalloc() itself. > > >>>> Hi Dmitry, > > >>>> kmalloc does not produce WARNING on OOM. The rule is not only about >>>> invalid inputs, it's also about any transient conditions and "WARNING >>>> only for kernel bugs". > > >>>> To put this in larger context, being able to distinguish kernel bugs >>>> from non-bugs is a very important and practically useful capability, >>>> which in particular enables systematic testing, but also makes things >>>> simpler for all kernel users. There must be a very significant reason >>>> to abandon this capability. What is that reason in this case? > > >>>> I also don't understand what is so special about this case. If we want >>>> user message for kmalloc failures, kmalloc is the right place for such >>>> warning, rather than a random call site out of thousands. Consider, >>>> the allocation failure can happen on the very next or previous kmalloc >>>> call, and user won't be warned. The rest of the kernel (including the >>>> rest of input sybsystem) does not warn on allocation failures, so that >>>> looks like what we need to do here as well. Or, if there is something >>>> very special about this particular kmalloc call site, something that >>>> makes it different from thousands of other call sites, why don't you >>>> want to replace it with pr_err which would both give the diagnostics >>>> but also not block systematic testing? Which looks like a win-win to >>>> me. > > >>>> Thanks > > > >>> So, Dmitry, do you mind fixing this in the name of unblocking kernel >>> testing? > > > >> Let's tell syzbot about the pending fix: > > >> #syz fix: Input: do not use WARN() in input_alloc_absinfo() > > > Can't find the corresponding bug. Now with syzbot email in CC: #syz fix: Input: do not use WARN() in input_alloc_absinfo()
Re: Re: WARNING in input_alloc_absinfo
On Thu, Jul 26, 2018 at 11:40 AM, Dmitry Vyukov wrote: On Mon, Jul 2, 2018 at 11:30 AM, Dmitry Vyukov wrote: On Fri, Jun 29, 2018 at 11:59 PM, wrote: On Monday, June 25, 2018 at 5:43:02 AM UTC-7, Dmitry Vyukov wrote: On Tue, Jun 19, 2018 at 8:51 PM, Dmitry Torokhov wrote: > On Thu, Jun 14, 2018 at 05:47:03AM -0700, syzbot wrote: >> Hello, >> >> syzbot found the following crash on: >> >> HEAD commit:d2d741e5d189 kmsan: add initialization for shmem pages >> git tree: https://github.com/google/kmsan.git/master >> console output: >> https://syzkaller.appspot.com/x/log.txt?x=1775bae780 >> kernel config: >> https://syzkaller.appspot.com/x/.config?x=48f9de3384bcd0f >> dashboard link: >> https://syzkaller.appspot.com/bug?extid=c382812c78d98ecd9fb8 >> compiler: clang version 7.0.0 (trunk 329391) >> syzkaller >> repro:https://syzkaller.appspot.com/x/repro.syz?x=13b31ae780 >> C reproducer: >> https://syzkaller.appspot.com/x/repro.c?x=1733255b80 >> >> IMPORTANT: if you fix the bug, please add the following tag to the >> commit: >> Reported-by: syzbot+c38281...@syzkaller.appspotmail.com >> >> RBP: 006cb018 R08: 0001 R09: 7ffe93080031 >> R10: R11: 0246 R12: 0004 >> R13: ffff R14: R15: >> [ cut here ] >> input_alloc_absinfo(): kcalloc() failed? >> WARNING: CPU: 1 PID: 4498 at drivers/input/input.c:487 >> input_alloc_absinfo+0x183/0x190 drivers/input/input.c:487 >> Kernel panic - not syncing: panic_on_warn set ... > > Hmm, so there is not really a problem as far as I am concerned. We do > generate a warning if we can't allocate memory for absinfo, as this is > really unexpected, but the case is handled properly by the callers so > there is no reason for us to go belly up here. Note to myself: ping this bug when "include/asm-generic/bug.h: clarify valid uses of WARN()" is fully merged. No, this warning will still be there even after the "clarifying" patch is merged. It does not check user inputs, it warns that the system is so low on memory that we could not allocate measly amount needed for absinfo. Treat it as you treat OOM warnings from kmalloc() itself. Hi Dmitry, kmalloc does not produce WARNING on OOM. The rule is not only about invalid inputs, it's also about any transient conditions and "WARNING only for kernel bugs". To put this in larger context, being able to distinguish kernel bugs from non-bugs is a very important and practically useful capability, which in particular enables systematic testing, but also makes things simpler for all kernel users. There must be a very significant reason to abandon this capability. What is that reason in this case? I also don't understand what is so special about this case. If we want user message for kmalloc failures, kmalloc is the right place for such warning, rather than a random call site out of thousands. Consider, the allocation failure can happen on the very next or previous kmalloc call, and user won't be warned. The rest of the kernel (including the rest of input sybsystem) does not warn on allocation failures, so that looks like what we need to do here as well. Or, if there is something very special about this particular kmalloc call site, something that makes it different from thousands of other call sites, why don't you want to replace it with pr_err which would both give the diagnostics but also not block systematic testing? Which looks like a win-win to me. Thanks So, Dmitry, do you mind fixing this in the name of unblocking kernel testing? Let's tell syzbot about the pending fix: #syz fix: Input: do not use WARN() in input_alloc_absinfo() Can't find the corresponding bug. -- You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/CACT4Y%2Ba%2Bc6skSwS8WfY9GUs9mnjmf_aa7C5crW-m2Jb54ZbyuA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Re: WARNING in input_alloc_absinfo
On Thu, Jul 26, 2018 at 11:40 AM, Dmitry Vyukov wrote: On Mon, Jul 2, 2018 at 11:30 AM, Dmitry Vyukov wrote: On Fri, Jun 29, 2018 at 11:59 PM, wrote: On Monday, June 25, 2018 at 5:43:02 AM UTC-7, Dmitry Vyukov wrote: On Tue, Jun 19, 2018 at 8:51 PM, Dmitry Torokhov wrote: > On Thu, Jun 14, 2018 at 05:47:03AM -0700, syzbot wrote: >> Hello, >> >> syzbot found the following crash on: >> >> HEAD commit:d2d741e5d189 kmsan: add initialization for shmem pages >> git tree: https://github.com/google/kmsan.git/master >> console output: >> https://syzkaller.appspot.com/x/log.txt?x=1775bae780 >> kernel config: >> https://syzkaller.appspot.com/x/.config?x=48f9de3384bcd0f >> dashboard link: >> https://syzkaller.appspot.com/bug?extid=c382812c78d98ecd9fb8 >> compiler: clang version 7.0.0 (trunk 329391) >> syzkaller >> repro:https://syzkaller.appspot.com/x/repro.syz?x=13b31ae780 >> C reproducer: >> https://syzkaller.appspot.com/x/repro.c?x=1733255b80 >> >> IMPORTANT: if you fix the bug, please add the following tag to the >> commit: >> Reported-by: syzbot+c38281...@syzkaller.appspotmail.com >> >> RBP: 006cb018 R08: 0001 R09: 7ffe93080031 >> R10: R11: 0246 R12: 0004 >> R13: ffff R14: R15: >> [ cut here ] >> input_alloc_absinfo(): kcalloc() failed? >> WARNING: CPU: 1 PID: 4498 at drivers/input/input.c:487 >> input_alloc_absinfo+0x183/0x190 drivers/input/input.c:487 >> Kernel panic - not syncing: panic_on_warn set ... > > Hmm, so there is not really a problem as far as I am concerned. We do > generate a warning if we can't allocate memory for absinfo, as this is > really unexpected, but the case is handled properly by the callers so > there is no reason for us to go belly up here. Note to myself: ping this bug when "include/asm-generic/bug.h: clarify valid uses of WARN()" is fully merged. No, this warning will still be there even after the "clarifying" patch is merged. It does not check user inputs, it warns that the system is so low on memory that we could not allocate measly amount needed for absinfo. Treat it as you treat OOM warnings from kmalloc() itself. Hi Dmitry, kmalloc does not produce WARNING on OOM. The rule is not only about invalid inputs, it's also about any transient conditions and "WARNING only for kernel bugs". To put this in larger context, being able to distinguish kernel bugs from non-bugs is a very important and practically useful capability, which in particular enables systematic testing, but also makes things simpler for all kernel users. There must be a very significant reason to abandon this capability. What is that reason in this case? I also don't understand what is so special about this case. If we want user message for kmalloc failures, kmalloc is the right place for such warning, rather than a random call site out of thousands. Consider, the allocation failure can happen on the very next or previous kmalloc call, and user won't be warned. The rest of the kernel (including the rest of input sybsystem) does not warn on allocation failures, so that looks like what we need to do here as well. Or, if there is something very special about this particular kmalloc call site, something that makes it different from thousands of other call sites, why don't you want to replace it with pr_err which would both give the diagnostics but also not block systematic testing? Which looks like a win-win to me. Thanks So, Dmitry, do you mind fixing this in the name of unblocking kernel testing? Let's tell syzbot about the pending fix: #syz fix: Input: do not use WARN() in input_alloc_absinfo() Can't find the corresponding bug. -- You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/CACT4Y%2Ba%2Bc6skSwS8WfY9GUs9mnjmf_aa7C5crW-m2Jb54ZbyuA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: WARNING in input_alloc_absinfo
On Thu, Jul 26, 2018 at 11:40 AM, Dmitry Vyukov wrote: > On Mon, Jul 2, 2018 at 11:30 AM, Dmitry Vyukov wrote: >> On Fri, Jun 29, 2018 at 11:59 PM, wrote: >>> On Monday, June 25, 2018 at 5:43:02 AM UTC-7, Dmitry Vyukov wrote: >>>> >>>> On Tue, Jun 19, 2018 at 8:51 PM, Dmitry Torokhov >>>> wrote: >>>> > On Thu, Jun 14, 2018 at 05:47:03AM -0700, syzbot wrote: >>>> >> Hello, >>>> >> >>>> >> syzbot found the following crash on: >>>> >> >>>> >> HEAD commit:d2d741e5d189 kmsan: add initialization for shmem pages >>>> >> git tree: https://github.com/google/kmsan.git/master >>>> >> console output: >>>> >> https://syzkaller.appspot.com/x/log.txt?x=1775bae780 >>>> >> kernel config: >>>> >> https://syzkaller.appspot.com/x/.config?x=48f9de3384bcd0f >>>> >> dashboard link: >>>> >> https://syzkaller.appspot.com/bug?extid=c382812c78d98ecd9fb8 >>>> >> compiler: clang version 7.0.0 (trunk 329391) >>>> >> syzkaller >>>> >> repro:https://syzkaller.appspot.com/x/repro.syz?x=13b31ae780 >>>> >> C reproducer: >>>> >> https://syzkaller.appspot.com/x/repro.c?x=1733255b80 >>>> >> >>>> >> IMPORTANT: if you fix the bug, please add the following tag to the >>>> >> commit: >>>> >> Reported-by: syzbot+c38281...@syzkaller.appspotmail.com >>>> >> >>>> >> RBP: 006cb018 R08: 0001 R09: 7ffe93080031 >>>> >> R10: R11: 0246 R12: 0004 >>>> >> R13: R14: R15: >>>> >> [ cut here ] >>>> >> input_alloc_absinfo(): kcalloc() failed? >>>> >> WARNING: CPU: 1 PID: 4498 at drivers/input/input.c:487 >>>> >> input_alloc_absinfo+0x183/0x190 drivers/input/input.c:487 >>>> >> Kernel panic - not syncing: panic_on_warn set ... >>>> > >>>> > Hmm, so there is not really a problem as far as I am concerned. We do >>>> > generate a warning if we can't allocate memory for absinfo, as this is >>>> > really unexpected, but the case is handled properly by the callers so >>>> > there is no reason for us to go belly up here. >>>> >>>> Note to myself: ping this bug when "include/asm-generic/bug.h: clarify >>>> valid uses of WARN()" is fully merged. >>> >>> >>> No, this warning will still be there even after the "clarifying" patch is >>> merged. It does not check user inputs, it warns that the system is so low on >>> memory that we could not allocate measly amount needed for absinfo. Treat it >>> as you treat OOM warnings from kmalloc() itself. >> >> Hi Dmitry, >> >> kmalloc does not produce WARNING on OOM. The rule is not only about >> invalid inputs, it's also about any transient conditions and "WARNING >> only for kernel bugs". >> >> To put this in larger context, being able to distinguish kernel bugs >> from non-bugs is a very important and practically useful capability, >> which in particular enables systematic testing, but also makes things >> simpler for all kernel users. There must be a very significant reason >> to abandon this capability. What is that reason in this case? >> >> I also don't understand what is so special about this case. If we want >> user message for kmalloc failures, kmalloc is the right place for such >> warning, rather than a random call site out of thousands. Consider, >> the allocation failure can happen on the very next or previous kmalloc >> call, and user won't be warned. The rest of the kernel (including the >> rest of input sybsystem) does not warn on allocation failures, so that >> looks like what we need to do here as well. Or, if there is something >> very special about this particular kmalloc call site, something that >> makes it different from thousands of other call sites, why don't you >> want to replace it with pr_err which would both give the diagnostics >> but also not block systematic testing? Which looks like a win-win to >> me. >> >> Thanks > > > So, Dmitry, do you mind fixing this in the name of unblocking kernel testing? Let's tell syzbot about the pending fix: #syz fix: Input: do not use WARN() in input_alloc_absinfo()
Re: WARNING in input_alloc_absinfo
On Thu, Jul 26, 2018 at 11:40 AM, Dmitry Vyukov wrote: > On Mon, Jul 2, 2018 at 11:30 AM, Dmitry Vyukov wrote: >> On Fri, Jun 29, 2018 at 11:59 PM, wrote: >>> On Monday, June 25, 2018 at 5:43:02 AM UTC-7, Dmitry Vyukov wrote: >>>> >>>> On Tue, Jun 19, 2018 at 8:51 PM, Dmitry Torokhov >>>> wrote: >>>> > On Thu, Jun 14, 2018 at 05:47:03AM -0700, syzbot wrote: >>>> >> Hello, >>>> >> >>>> >> syzbot found the following crash on: >>>> >> >>>> >> HEAD commit:d2d741e5d189 kmsan: add initialization for shmem pages >>>> >> git tree: https://github.com/google/kmsan.git/master >>>> >> console output: >>>> >> https://syzkaller.appspot.com/x/log.txt?x=1775bae780 >>>> >> kernel config: >>>> >> https://syzkaller.appspot.com/x/.config?x=48f9de3384bcd0f >>>> >> dashboard link: >>>> >> https://syzkaller.appspot.com/bug?extid=c382812c78d98ecd9fb8 >>>> >> compiler: clang version 7.0.0 (trunk 329391) >>>> >> syzkaller >>>> >> repro:https://syzkaller.appspot.com/x/repro.syz?x=13b31ae780 >>>> >> C reproducer: >>>> >> https://syzkaller.appspot.com/x/repro.c?x=1733255b80 >>>> >> >>>> >> IMPORTANT: if you fix the bug, please add the following tag to the >>>> >> commit: >>>> >> Reported-by: syzbot+c38281...@syzkaller.appspotmail.com >>>> >> >>>> >> RBP: 006cb018 R08: 0001 R09: 7ffe93080031 >>>> >> R10: R11: 0246 R12: 0004 >>>> >> R13: R14: R15: >>>> >> [ cut here ] >>>> >> input_alloc_absinfo(): kcalloc() failed? >>>> >> WARNING: CPU: 1 PID: 4498 at drivers/input/input.c:487 >>>> >> input_alloc_absinfo+0x183/0x190 drivers/input/input.c:487 >>>> >> Kernel panic - not syncing: panic_on_warn set ... >>>> > >>>> > Hmm, so there is not really a problem as far as I am concerned. We do >>>> > generate a warning if we can't allocate memory for absinfo, as this is >>>> > really unexpected, but the case is handled properly by the callers so >>>> > there is no reason for us to go belly up here. >>>> >>>> Note to myself: ping this bug when "include/asm-generic/bug.h: clarify >>>> valid uses of WARN()" is fully merged. >>> >>> >>> No, this warning will still be there even after the "clarifying" patch is >>> merged. It does not check user inputs, it warns that the system is so low on >>> memory that we could not allocate measly amount needed for absinfo. Treat it >>> as you treat OOM warnings from kmalloc() itself. >> >> Hi Dmitry, >> >> kmalloc does not produce WARNING on OOM. The rule is not only about >> invalid inputs, it's also about any transient conditions and "WARNING >> only for kernel bugs". >> >> To put this in larger context, being able to distinguish kernel bugs >> from non-bugs is a very important and practically useful capability, >> which in particular enables systematic testing, but also makes things >> simpler for all kernel users. There must be a very significant reason >> to abandon this capability. What is that reason in this case? >> >> I also don't understand what is so special about this case. If we want >> user message for kmalloc failures, kmalloc is the right place for such >> warning, rather than a random call site out of thousands. Consider, >> the allocation failure can happen on the very next or previous kmalloc >> call, and user won't be warned. The rest of the kernel (including the >> rest of input sybsystem) does not warn on allocation failures, so that >> looks like what we need to do here as well. Or, if there is something >> very special about this particular kmalloc call site, something that >> makes it different from thousands of other call sites, why don't you >> want to replace it with pr_err which would both give the diagnostics >> but also not block systematic testing? Which looks like a win-win to >> me. >> >> Thanks > > > So, Dmitry, do you mind fixing this in the name of unblocking kernel testing? Let's tell syzbot about the pending fix: #syz fix: Input: do not use WARN() in input_alloc_absinfo()
Re: WARNING in input_alloc_absinfo
On Mon, Jul 2, 2018 at 11:30 AM, Dmitry Vyukov wrote: > On Fri, Jun 29, 2018 at 11:59 PM, wrote: >> On Monday, June 25, 2018 at 5:43:02 AM UTC-7, Dmitry Vyukov wrote: >>> >>> On Tue, Jun 19, 2018 at 8:51 PM, Dmitry Torokhov >>> wrote: >>> > On Thu, Jun 14, 2018 at 05:47:03AM -0700, syzbot wrote: >>> >> Hello, >>> >> >>> >> syzbot found the following crash on: >>> >> >>> >> HEAD commit:d2d741e5d189 kmsan: add initialization for shmem pages >>> >> git tree: https://github.com/google/kmsan.git/master >>> >> console output: >>> >> https://syzkaller.appspot.com/x/log.txt?x=1775bae780 >>> >> kernel config: >>> >> https://syzkaller.appspot.com/x/.config?x=48f9de3384bcd0f >>> >> dashboard link: >>> >> https://syzkaller.appspot.com/bug?extid=c382812c78d98ecd9fb8 >>> >> compiler: clang version 7.0.0 (trunk 329391) >>> >> syzkaller >>> >> repro:https://syzkaller.appspot.com/x/repro.syz?x=13b31ae780 >>> >> C reproducer: >>> >> https://syzkaller.appspot.com/x/repro.c?x=1733255b80 >>> >> >>> >> IMPORTANT: if you fix the bug, please add the following tag to the >>> >> commit: >>> >> Reported-by: syzbot+c38281...@syzkaller.appspotmail.com >>> >> >>> >> RBP: 006cb018 R08: 0001 R09: 7ffe93080031 >>> >> R10: R11: 0246 R12: 0004 >>> >> R13: R14: R15: >>> >> [ cut here ] >>> >> input_alloc_absinfo(): kcalloc() failed? >>> >> WARNING: CPU: 1 PID: 4498 at drivers/input/input.c:487 >>> >> input_alloc_absinfo+0x183/0x190 drivers/input/input.c:487 >>> >> Kernel panic - not syncing: panic_on_warn set ... >>> > >>> > Hmm, so there is not really a problem as far as I am concerned. We do >>> > generate a warning if we can't allocate memory for absinfo, as this is >>> > really unexpected, but the case is handled properly by the callers so >>> > there is no reason for us to go belly up here. >>> >>> Note to myself: ping this bug when "include/asm-generic/bug.h: clarify >>> valid uses of WARN()" is fully merged. >> >> >> No, this warning will still be there even after the "clarifying" patch is >> merged. It does not check user inputs, it warns that the system is so low on >> memory that we could not allocate measly amount needed for absinfo. Treat it >> as you treat OOM warnings from kmalloc() itself. > > Hi Dmitry, > > kmalloc does not produce WARNING on OOM. The rule is not only about > invalid inputs, it's also about any transient conditions and "WARNING > only for kernel bugs". > > To put this in larger context, being able to distinguish kernel bugs > from non-bugs is a very important and practically useful capability, > which in particular enables systematic testing, but also makes things > simpler for all kernel users. There must be a very significant reason > to abandon this capability. What is that reason in this case? > > I also don't understand what is so special about this case. If we want > user message for kmalloc failures, kmalloc is the right place for such > warning, rather than a random call site out of thousands. Consider, > the allocation failure can happen on the very next or previous kmalloc > call, and user won't be warned. The rest of the kernel (including the > rest of input sybsystem) does not warn on allocation failures, so that > looks like what we need to do here as well. Or, if there is something > very special about this particular kmalloc call site, something that > makes it different from thousands of other call sites, why don't you > want to replace it with pr_err which would both give the diagnostics > but also not block systematic testing? Which looks like a win-win to > me. > > Thanks So, Dmitry, do you mind fixing this in the name of unblocking kernel testing?
Re: WARNING in input_alloc_absinfo
On Mon, Jul 2, 2018 at 11:30 AM, Dmitry Vyukov wrote: > On Fri, Jun 29, 2018 at 11:59 PM, wrote: >> On Monday, June 25, 2018 at 5:43:02 AM UTC-7, Dmitry Vyukov wrote: >>> >>> On Tue, Jun 19, 2018 at 8:51 PM, Dmitry Torokhov >>> wrote: >>> > On Thu, Jun 14, 2018 at 05:47:03AM -0700, syzbot wrote: >>> >> Hello, >>> >> >>> >> syzbot found the following crash on: >>> >> >>> >> HEAD commit:d2d741e5d189 kmsan: add initialization for shmem pages >>> >> git tree: https://github.com/google/kmsan.git/master >>> >> console output: >>> >> https://syzkaller.appspot.com/x/log.txt?x=1775bae780 >>> >> kernel config: >>> >> https://syzkaller.appspot.com/x/.config?x=48f9de3384bcd0f >>> >> dashboard link: >>> >> https://syzkaller.appspot.com/bug?extid=c382812c78d98ecd9fb8 >>> >> compiler: clang version 7.0.0 (trunk 329391) >>> >> syzkaller >>> >> repro:https://syzkaller.appspot.com/x/repro.syz?x=13b31ae780 >>> >> C reproducer: >>> >> https://syzkaller.appspot.com/x/repro.c?x=1733255b80 >>> >> >>> >> IMPORTANT: if you fix the bug, please add the following tag to the >>> >> commit: >>> >> Reported-by: syzbot+c38281...@syzkaller.appspotmail.com >>> >> >>> >> RBP: 006cb018 R08: 0001 R09: 7ffe93080031 >>> >> R10: R11: 0246 R12: 0004 >>> >> R13: R14: R15: >>> >> [ cut here ] >>> >> input_alloc_absinfo(): kcalloc() failed? >>> >> WARNING: CPU: 1 PID: 4498 at drivers/input/input.c:487 >>> >> input_alloc_absinfo+0x183/0x190 drivers/input/input.c:487 >>> >> Kernel panic - not syncing: panic_on_warn set ... >>> > >>> > Hmm, so there is not really a problem as far as I am concerned. We do >>> > generate a warning if we can't allocate memory for absinfo, as this is >>> > really unexpected, but the case is handled properly by the callers so >>> > there is no reason for us to go belly up here. >>> >>> Note to myself: ping this bug when "include/asm-generic/bug.h: clarify >>> valid uses of WARN()" is fully merged. >> >> >> No, this warning will still be there even after the "clarifying" patch is >> merged. It does not check user inputs, it warns that the system is so low on >> memory that we could not allocate measly amount needed for absinfo. Treat it >> as you treat OOM warnings from kmalloc() itself. > > Hi Dmitry, > > kmalloc does not produce WARNING on OOM. The rule is not only about > invalid inputs, it's also about any transient conditions and "WARNING > only for kernel bugs". > > To put this in larger context, being able to distinguish kernel bugs > from non-bugs is a very important and practically useful capability, > which in particular enables systematic testing, but also makes things > simpler for all kernel users. There must be a very significant reason > to abandon this capability. What is that reason in this case? > > I also don't understand what is so special about this case. If we want > user message for kmalloc failures, kmalloc is the right place for such > warning, rather than a random call site out of thousands. Consider, > the allocation failure can happen on the very next or previous kmalloc > call, and user won't be warned. The rest of the kernel (including the > rest of input sybsystem) does not warn on allocation failures, so that > looks like what we need to do here as well. Or, if there is something > very special about this particular kmalloc call site, something that > makes it different from thousands of other call sites, why don't you > want to replace it with pr_err which would both give the diagnostics > but also not block systematic testing? Which looks like a win-win to > me. > > Thanks So, Dmitry, do you mind fixing this in the name of unblocking kernel testing?
Re: WARNING in input_alloc_absinfo
On Fri, Jun 29, 2018 at 11:59 PM, wrote: > On Monday, June 25, 2018 at 5:43:02 AM UTC-7, Dmitry Vyukov wrote: >> >> On Tue, Jun 19, 2018 at 8:51 PM, Dmitry Torokhov >> wrote: >> > On Thu, Jun 14, 2018 at 05:47:03AM -0700, syzbot wrote: >> >> Hello, >> >> >> >> syzbot found the following crash on: >> >> >> >> HEAD commit:d2d741e5d189 kmsan: add initialization for shmem pages >> >> git tree: https://github.com/google/kmsan.git/master >> >> console output: >> >> https://syzkaller.appspot.com/x/log.txt?x=1775bae780 >> >> kernel config: >> >> https://syzkaller.appspot.com/x/.config?x=48f9de3384bcd0f >> >> dashboard link: >> >> https://syzkaller.appspot.com/bug?extid=c382812c78d98ecd9fb8 >> >> compiler: clang version 7.0.0 (trunk 329391) >> >> syzkaller >> >> repro:https://syzkaller.appspot.com/x/repro.syz?x=13b31ae780 >> >> C reproducer: >> >> https://syzkaller.appspot.com/x/repro.c?x=1733255b80 >> >> >> >> IMPORTANT: if you fix the bug, please add the following tag to the >> >> commit: >> >> Reported-by: syzbot+c38281...@syzkaller.appspotmail.com >> >> >> >> RBP: 006cb018 R08: 0001 R09: 7ffe93080031 >> >> R10: R11: 0246 R12: 0004 >> >> R13: R14: R15: >> >> [ cut here ] >> >> input_alloc_absinfo(): kcalloc() failed? >> >> WARNING: CPU: 1 PID: 4498 at drivers/input/input.c:487 >> >> input_alloc_absinfo+0x183/0x190 drivers/input/input.c:487 >> >> Kernel panic - not syncing: panic_on_warn set ... >> > >> > Hmm, so there is not really a problem as far as I am concerned. We do >> > generate a warning if we can't allocate memory for absinfo, as this is >> > really unexpected, but the case is handled properly by the callers so >> > there is no reason for us to go belly up here. >> >> Note to myself: ping this bug when "include/asm-generic/bug.h: clarify >> valid uses of WARN()" is fully merged. > > > No, this warning will still be there even after the "clarifying" patch is > merged. It does not check user inputs, it warns that the system is so low on > memory that we could not allocate measly amount needed for absinfo. Treat it > as you treat OOM warnings from kmalloc() itself. Hi Dmitry, kmalloc does not produce WARNING on OOM. The rule is not only about invalid inputs, it's also about any transient conditions and "WARNING only for kernel bugs". To put this in larger context, being able to distinguish kernel bugs from non-bugs is a very important and practically useful capability, which in particular enables systematic testing, but also makes things simpler for all kernel users. There must be a very significant reason to abandon this capability. What is that reason in this case? I also don't understand what is so special about this case. If we want user message for kmalloc failures, kmalloc is the right place for such warning, rather than a random call site out of thousands. Consider, the allocation failure can happen on the very next or previous kmalloc call, and user won't be warned. The rest of the kernel (including the rest of input sybsystem) does not warn on allocation failures, so that looks like what we need to do here as well. Or, if there is something very special about this particular kmalloc call site, something that makes it different from thousands of other call sites, why don't you want to replace it with pr_err which would both give the diagnostics but also not block systematic testing? Which looks like a win-win to me. Thanks
Re: WARNING in input_alloc_absinfo
On Fri, Jun 29, 2018 at 11:59 PM, wrote: > On Monday, June 25, 2018 at 5:43:02 AM UTC-7, Dmitry Vyukov wrote: >> >> On Tue, Jun 19, 2018 at 8:51 PM, Dmitry Torokhov >> wrote: >> > On Thu, Jun 14, 2018 at 05:47:03AM -0700, syzbot wrote: >> >> Hello, >> >> >> >> syzbot found the following crash on: >> >> >> >> HEAD commit:d2d741e5d189 kmsan: add initialization for shmem pages >> >> git tree: https://github.com/google/kmsan.git/master >> >> console output: >> >> https://syzkaller.appspot.com/x/log.txt?x=1775bae780 >> >> kernel config: >> >> https://syzkaller.appspot.com/x/.config?x=48f9de3384bcd0f >> >> dashboard link: >> >> https://syzkaller.appspot.com/bug?extid=c382812c78d98ecd9fb8 >> >> compiler: clang version 7.0.0 (trunk 329391) >> >> syzkaller >> >> repro:https://syzkaller.appspot.com/x/repro.syz?x=13b31ae780 >> >> C reproducer: >> >> https://syzkaller.appspot.com/x/repro.c?x=1733255b80 >> >> >> >> IMPORTANT: if you fix the bug, please add the following tag to the >> >> commit: >> >> Reported-by: syzbot+c38281...@syzkaller.appspotmail.com >> >> >> >> RBP: 006cb018 R08: 0001 R09: 7ffe93080031 >> >> R10: R11: 0246 R12: 0004 >> >> R13: R14: R15: >> >> [ cut here ] >> >> input_alloc_absinfo(): kcalloc() failed? >> >> WARNING: CPU: 1 PID: 4498 at drivers/input/input.c:487 >> >> input_alloc_absinfo+0x183/0x190 drivers/input/input.c:487 >> >> Kernel panic - not syncing: panic_on_warn set ... >> > >> > Hmm, so there is not really a problem as far as I am concerned. We do >> > generate a warning if we can't allocate memory for absinfo, as this is >> > really unexpected, but the case is handled properly by the callers so >> > there is no reason for us to go belly up here. >> >> Note to myself: ping this bug when "include/asm-generic/bug.h: clarify >> valid uses of WARN()" is fully merged. > > > No, this warning will still be there even after the "clarifying" patch is > merged. It does not check user inputs, it warns that the system is so low on > memory that we could not allocate measly amount needed for absinfo. Treat it > as you treat OOM warnings from kmalloc() itself. Hi Dmitry, kmalloc does not produce WARNING on OOM. The rule is not only about invalid inputs, it's also about any transient conditions and "WARNING only for kernel bugs". To put this in larger context, being able to distinguish kernel bugs from non-bugs is a very important and practically useful capability, which in particular enables systematic testing, but also makes things simpler for all kernel users. There must be a very significant reason to abandon this capability. What is that reason in this case? I also don't understand what is so special about this case. If we want user message for kmalloc failures, kmalloc is the right place for such warning, rather than a random call site out of thousands. Consider, the allocation failure can happen on the very next or previous kmalloc call, and user won't be warned. The rest of the kernel (including the rest of input sybsystem) does not warn on allocation failures, so that looks like what we need to do here as well. Or, if there is something very special about this particular kmalloc call site, something that makes it different from thousands of other call sites, why don't you want to replace it with pr_err which would both give the diagnostics but also not block systematic testing? Which looks like a win-win to me. Thanks
Re: WARNING in input_alloc_absinfo
On Thu, Jun 14, 2018 at 05:47:03AM -0700, syzbot wrote: > Hello, > > syzbot found the following crash on: > > HEAD commit:d2d741e5d189 kmsan: add initialization for shmem pages > git tree: https://github.com/google/kmsan.git/master > console output: https://syzkaller.appspot.com/x/log.txt?x=1775bae780 > kernel config: https://syzkaller.appspot.com/x/.config?x=48f9de3384bcd0f > dashboard link: https://syzkaller.appspot.com/bug?extid=c382812c78d98ecd9fb8 > compiler: clang version 7.0.0 (trunk 329391) > syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=13b31ae780 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1733255b80 > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+c382812c78d98ecd9...@syzkaller.appspotmail.com > > RBP: 006cb018 R08: 0001 R09: 7ffe93080031 > R10: R11: 0246 R12: 0004 > R13: R14: R15: 0000 > [ cut here ]---- > input_alloc_absinfo(): kcalloc() failed? > WARNING: CPU: 1 PID: 4498 at drivers/input/input.c:487 > input_alloc_absinfo+0x183/0x190 drivers/input/input.c:487 > Kernel panic - not syncing: panic_on_warn set ... Hmm, so there is not really a problem as far as I am concerned. We do generate a warning if we can't allocate memory for absinfo, as this is really unexpected, but the case is handled properly by the callers so there is no reason for us to go belly up here. > > CPU: 1 PID: 4498 Comm: syz-executor465 Not tainted 4.16.0+ #87 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > Call Trace: > __dump_stack lib/dump_stack.c:17 [inline] > dump_stack+0x185/0x1d0 lib/dump_stack.c:53 > panic+0x39d/0x940 kernel/panic.c:183 > __warn+0x40f/0x580 kernel/panic.c:547 > report_bug+0x72a/0x880 lib/bug.c:186 > fixup_bug arch/x86/kernel/traps.c:179 [inline] > do_error_trap+0x1aa/0x600 arch/x86/kernel/traps.c:297 > do_invalid_op+0x46/0x50 arch/x86/kernel/traps.c:316 > invalid_op+0x1b/0x40 arch/x86/entry/entry_64.S:986 > RIP: 0010:input_alloc_absinfo+0x183/0x190 drivers/input/input.c:487 > RSP: 0018:88019651faa8 EFLAGS: 00010282 > RAX: 0028 RBX: RCX: > RDX: RSI: b000 RDI: ea00 > RBP: 88019651fae0 R08: 01080020 R09: 0002 > R10: R11: R12: > R13: 8801a19ec140 R14: 88019796e198 R15: > uinput_abs_setup drivers/input/misc/uinput.c:507 [inline] > uinput_ioctl_handler+0x38a2/0x39f0 drivers/input/misc/uinput.c:1035 > uinput_ioctl+0x9a/0xb0 drivers/input/misc/uinput.c:1047 > vfs_ioctl fs/ioctl.c:46 [inline] > do_vfs_ioctl+0xaf0/0x2440 fs/ioctl.c:686 > SYSC_ioctl+0x1d2/0x260 fs/ioctl.c:701 > SyS_ioctl+0x54/0x80 fs/ioctl.c:692 > do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287 > entry_SYSCALL_64_after_hwframe+0x3d/0xa2 > RIP: 0033:0x440429 > RSP: 002b:7ffe9308d2b8 EFLAGS: 0246 ORIG_RAX: 0010 > RAX: ffda RBX: RCX: 00440429 > RDX: RSI: 40005504 RDI: 0003 > RBP: 006cb018 R08: 0001 R09: 7ffe93080031 > R10: R11: 0246 R12: 0004 > R13: R14: R15: > Dumping ftrace buffer: >(ftrace buffer empty) > 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 syzkal...@googlegroups.com. > > 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 Thanks. -- Dmitry
Re: WARNING in input_alloc_absinfo
On Thu, Jun 14, 2018 at 05:47:03AM -0700, syzbot wrote: > Hello, > > syzbot found the following crash on: > > HEAD commit:d2d741e5d189 kmsan: add initialization for shmem pages > git tree: https://github.com/google/kmsan.git/master > console output: https://syzkaller.appspot.com/x/log.txt?x=1775bae780 > kernel config: https://syzkaller.appspot.com/x/.config?x=48f9de3384bcd0f > dashboard link: https://syzkaller.appspot.com/bug?extid=c382812c78d98ecd9fb8 > compiler: clang version 7.0.0 (trunk 329391) > syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=13b31ae780 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1733255b80 > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+c382812c78d98ecd9...@syzkaller.appspotmail.com > > RBP: 006cb018 R08: 0001 R09: 7ffe93080031 > R10: R11: 0246 R12: 0004 > R13: R14: R15: 0000 > [ cut here ]---- > input_alloc_absinfo(): kcalloc() failed? > WARNING: CPU: 1 PID: 4498 at drivers/input/input.c:487 > input_alloc_absinfo+0x183/0x190 drivers/input/input.c:487 > Kernel panic - not syncing: panic_on_warn set ... Hmm, so there is not really a problem as far as I am concerned. We do generate a warning if we can't allocate memory for absinfo, as this is really unexpected, but the case is handled properly by the callers so there is no reason for us to go belly up here. > > CPU: 1 PID: 4498 Comm: syz-executor465 Not tainted 4.16.0+ #87 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > Call Trace: > __dump_stack lib/dump_stack.c:17 [inline] > dump_stack+0x185/0x1d0 lib/dump_stack.c:53 > panic+0x39d/0x940 kernel/panic.c:183 > __warn+0x40f/0x580 kernel/panic.c:547 > report_bug+0x72a/0x880 lib/bug.c:186 > fixup_bug arch/x86/kernel/traps.c:179 [inline] > do_error_trap+0x1aa/0x600 arch/x86/kernel/traps.c:297 > do_invalid_op+0x46/0x50 arch/x86/kernel/traps.c:316 > invalid_op+0x1b/0x40 arch/x86/entry/entry_64.S:986 > RIP: 0010:input_alloc_absinfo+0x183/0x190 drivers/input/input.c:487 > RSP: 0018:88019651faa8 EFLAGS: 00010282 > RAX: 0028 RBX: RCX: > RDX: RSI: b000 RDI: ea00 > RBP: 88019651fae0 R08: 01080020 R09: 0002 > R10: R11: R12: > R13: 8801a19ec140 R14: 88019796e198 R15: > uinput_abs_setup drivers/input/misc/uinput.c:507 [inline] > uinput_ioctl_handler+0x38a2/0x39f0 drivers/input/misc/uinput.c:1035 > uinput_ioctl+0x9a/0xb0 drivers/input/misc/uinput.c:1047 > vfs_ioctl fs/ioctl.c:46 [inline] > do_vfs_ioctl+0xaf0/0x2440 fs/ioctl.c:686 > SYSC_ioctl+0x1d2/0x260 fs/ioctl.c:701 > SyS_ioctl+0x54/0x80 fs/ioctl.c:692 > do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287 > entry_SYSCALL_64_after_hwframe+0x3d/0xa2 > RIP: 0033:0x440429 > RSP: 002b:7ffe9308d2b8 EFLAGS: 0246 ORIG_RAX: 0010 > RAX: ffda RBX: RCX: 00440429 > RDX: RSI: 40005504 RDI: 0003 > RBP: 006cb018 R08: 0001 R09: 7ffe93080031 > R10: R11: 0246 R12: 0004 > R13: R14: R15: > Dumping ftrace buffer: >(ftrace buffer empty) > 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 syzkal...@googlegroups.com. > > 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 Thanks. -- Dmitry
WARNING in input_alloc_absinfo
Hello, syzbot found the following crash on: HEAD commit:d2d741e5d189 kmsan: add initialization for shmem pages git tree: https://github.com/google/kmsan.git/master console output: https://syzkaller.appspot.com/x/log.txt?x=1775bae780 kernel config: https://syzkaller.appspot.com/x/.config?x=48f9de3384bcd0f dashboard link: https://syzkaller.appspot.com/bug?extid=c382812c78d98ecd9fb8 compiler: clang version 7.0.0 (trunk 329391) syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=13b31ae780 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1733255b80 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+c382812c78d98ecd9...@syzkaller.appspotmail.com RBP: 006cb018 R08: 0001 R09: 7ffe93080031 R10: R11: 0246 R12: 0004 R13: R14: R15: [ cut here ] input_alloc_absinfo(): kcalloc() failed? WARNING: CPU: 1 PID: 4498 at drivers/input/input.c:487 input_alloc_absinfo+0x183/0x190 drivers/input/input.c:487 Kernel panic - not syncing: panic_on_warn set ... CPU: 1 PID: 4498 Comm: syz-executor465 Not tainted 4.16.0+ #87 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:17 [inline] dump_stack+0x185/0x1d0 lib/dump_stack.c:53 panic+0x39d/0x940 kernel/panic.c:183 __warn+0x40f/0x580 kernel/panic.c:547 report_bug+0x72a/0x880 lib/bug.c:186 fixup_bug arch/x86/kernel/traps.c:179 [inline] do_error_trap+0x1aa/0x600 arch/x86/kernel/traps.c:297 do_invalid_op+0x46/0x50 arch/x86/kernel/traps.c:316 invalid_op+0x1b/0x40 arch/x86/entry/entry_64.S:986 RIP: 0010:input_alloc_absinfo+0x183/0x190 drivers/input/input.c:487 RSP: 0018:88019651faa8 EFLAGS: 00010282 RAX: 0028 RBX: RCX: RDX: RSI: b000 RDI: ea00 RBP: 88019651fae0 R08: 01080020 R09: 0002 R10: R11: R12: R13: 8801a19ec140 R14: 88019796e198 R15: uinput_abs_setup drivers/input/misc/uinput.c:507 [inline] uinput_ioctl_handler+0x38a2/0x39f0 drivers/input/misc/uinput.c:1035 uinput_ioctl+0x9a/0xb0 drivers/input/misc/uinput.c:1047 vfs_ioctl fs/ioctl.c:46 [inline] do_vfs_ioctl+0xaf0/0x2440 fs/ioctl.c:686 SYSC_ioctl+0x1d2/0x260 fs/ioctl.c:701 SyS_ioctl+0x54/0x80 fs/ioctl.c:692 do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x3d/0xa2 RIP: 0033:0x440429 RSP: 002b:7ffe9308d2b8 EFLAGS: 0246 ORIG_RAX: 0010 RAX: ffda RBX: RCX: 00440429 RDX: RSI: 40005504 RDI: 0003 RBP: 006cb018 R08: 0001 R09: 7ffe93080031 R10: R11: 0246 R12: 0004 R13: R14: R15: Dumping ftrace buffer: (ftrace buffer empty) 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 syzkal...@googlegroups.com. 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
WARNING in input_alloc_absinfo
Hello, syzbot found the following crash on: HEAD commit:d2d741e5d189 kmsan: add initialization for shmem pages git tree: https://github.com/google/kmsan.git/master console output: https://syzkaller.appspot.com/x/log.txt?x=1775bae780 kernel config: https://syzkaller.appspot.com/x/.config?x=48f9de3384bcd0f dashboard link: https://syzkaller.appspot.com/bug?extid=c382812c78d98ecd9fb8 compiler: clang version 7.0.0 (trunk 329391) syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=13b31ae780 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1733255b80 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+c382812c78d98ecd9...@syzkaller.appspotmail.com RBP: 006cb018 R08: 0001 R09: 7ffe93080031 R10: R11: 0246 R12: 0004 R13: R14: R15: [ cut here ] input_alloc_absinfo(): kcalloc() failed? WARNING: CPU: 1 PID: 4498 at drivers/input/input.c:487 input_alloc_absinfo+0x183/0x190 drivers/input/input.c:487 Kernel panic - not syncing: panic_on_warn set ... CPU: 1 PID: 4498 Comm: syz-executor465 Not tainted 4.16.0+ #87 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:17 [inline] dump_stack+0x185/0x1d0 lib/dump_stack.c:53 panic+0x39d/0x940 kernel/panic.c:183 __warn+0x40f/0x580 kernel/panic.c:547 report_bug+0x72a/0x880 lib/bug.c:186 fixup_bug arch/x86/kernel/traps.c:179 [inline] do_error_trap+0x1aa/0x600 arch/x86/kernel/traps.c:297 do_invalid_op+0x46/0x50 arch/x86/kernel/traps.c:316 invalid_op+0x1b/0x40 arch/x86/entry/entry_64.S:986 RIP: 0010:input_alloc_absinfo+0x183/0x190 drivers/input/input.c:487 RSP: 0018:88019651faa8 EFLAGS: 00010282 RAX: 0028 RBX: RCX: RDX: RSI: b000 RDI: ea00 RBP: 88019651fae0 R08: 01080020 R09: 0002 R10: R11: R12: R13: 8801a19ec140 R14: 88019796e198 R15: uinput_abs_setup drivers/input/misc/uinput.c:507 [inline] uinput_ioctl_handler+0x38a2/0x39f0 drivers/input/misc/uinput.c:1035 uinput_ioctl+0x9a/0xb0 drivers/input/misc/uinput.c:1047 vfs_ioctl fs/ioctl.c:46 [inline] do_vfs_ioctl+0xaf0/0x2440 fs/ioctl.c:686 SYSC_ioctl+0x1d2/0x260 fs/ioctl.c:701 SyS_ioctl+0x54/0x80 fs/ioctl.c:692 do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x3d/0xa2 RIP: 0033:0x440429 RSP: 002b:7ffe9308d2b8 EFLAGS: 0246 ORIG_RAX: 0010 RAX: ffda RBX: RCX: 00440429 RDX: RSI: 40005504 RDI: 0003 RBP: 006cb018 R08: 0001 R09: 7ffe93080031 R10: R11: 0246 R12: 0004 R13: R14: R15: Dumping ftrace buffer: (ftrace buffer empty) 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 syzkal...@googlegroups.com. 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
