Re: INFO: rcu detected stall in memcpy

2018-02-14 Thread Dmitry Vyukov 
On Mon, Jan 8, 2018 at 2:15 PM, Takashi Iwai  wrote:
> On Sun, 07 Jan 2018 12:30:53 +0100,
> Dmitry Vyukov wrote:
>>
>> On Thu, Jan 4, 2018 at 6:03 PM, Takashi Iwai  wrote:
>> > On Thu, 04 Jan 2018 15:17:23 +0100,
>> > Takashi Iwai wrote:
>> >>
>> >> On Thu, 04 Jan 2018 15:01:06 +0100,
>> >> Dmitry Vyukov wrote:
>> >> >
>> >> > On Thu, Jan 4, 2018 at 1:57 PM, Takashi Iwai  wrote:
>> >> > > On Thu, 04 Jan 2018 13:08:45 +0100,
>> >> > > Dmitry Vyukov wrote:
>> >> > >>
>> >> > >> On Thu, Jan 4, 2018 at 1:03 PM, syzbot
>> >> > >>  wrote:
>> >> > >> > Hello,
>> >> > >> >
>> >> > >> > syzkaller hit the following crash on
>> >> > >> > 30a7acd573899fd8b8ac39236eff6468b195ac7d
>> >> > >> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
>> >> > >> > compiler: gcc (GCC) 7.1.1 20170620
>> >> > >> > .config is attached
>> >> > >> > Raw console output is attached.
>> >> > >> > Unfortunately, I don't have any reproducer for this bug yet.
>> >> > >> >
>> >> > >> >
>> >> > >> > IMPORTANT: if you fix the bug, please add the following tag to the 
>> >> > >> > commit:
>> >> > >> > Reported-by: syzbot+387f48da65cb522ab...@syzkaller.appspotmail.com
>> >> > >> > It will help syzbot understand when the bug is fixed. See footer 
>> >> > >> > for
>> >> > >> > details.
>> >> > >> > If you forward the report, please keep this part and the footer.
>> >> > >>
>> >> > >> This looks ALSA-related. +ALSA maintainers.
>> >> > >
>> >> > > Not sure exactly what triggers it.  It's the simple memcpy(), and I
>> >> > > don't know where RCU is involved in that code path.
>> >> > >
>> >> > > BTW, other two suspicious RCU usage reports are actually stopped at
>> >> > > the second WARN_ON() after the RCU message, and the second WARN_ON()
>> >> > > is independent from RCU; it's the known spurious WARN_ON() and was
>> >> > > already removed in the sound git tree.
>> >> >
>> >> >
>> >> > Hi Takashi,
>> >> >
>> >> > Another similar one just popped up:
>> >> >
>> >> > https://groups.google.com/forum/#!topic/syzkaller-bugs/X3d6-PIrJM0
>> >> >
>> >> > This looks like mulaw_decode enters an infinite loop, or at least
>> >> > doing very large amount of computations without a resched, e.g.
>> >> > (uint64_t)-1 number of iterations of something along these lines.
>> >>
>> >> OK, that makes sense.
>> >>
>> >> My rough guess is that it's the misconfigured aloop device by
>> >> concurrent setup.  The aloop device allows to restrict the parameters
>> >> of the other side of the connection, and something bad may happen
>> >> there if both sides are updated concurrently.
>> >>
>> >> We've seen segfault by memset() at loopback_preapre() in
>> >> sound/drivers/aloop.c by syzbot+3902b5220e8ca27889ca, too, which
>> >> indicates also the wrongly setup parameters that overflows the
>> >> allocated buffer.
>> >
>> > Below two patches may possibly plug the holes, but I'm not entirely
>> > sure whether that's the exact culprit.  Could you put them into syzbot
>> > to watch whether they have any influence?
>>
>> Hi Takashi,
>>
>> I've gave an answer to this here:
>> https://groups.google.com/d/msg/syzkaller-bugs/7ucgCkAJKSk/skZjgavRAQAJ
>
> OK, noted.
>
>> > In anyway, they are obvious bugs to be fixed, so I'm going to queue to
>> > my tree.
>>
>> The options are:
>> 1. You can ask syzbot to test the patch separately. This requires a
>> reproducer, but there is this bug which has a reproducer and seems to
>> have the same root cause:
>> https://groups.google.com/d/msg/syzkaller-bugs/KrPUlf-nm5g/Vk0xEq-HAAAJ
>
> Ah, I didn't know that each bot can test patches individually.
>
>> 2. You can reproduce it with the reproducer from here:
>> https://groups.google.com/d/msg/syzkaller-bugs/KrPUlf-nm5g/Vk0xEq-HAAAJ
>> and then test the patch as extensively as needed.
>
> Yes, I could test and find the culprit with the given reproducer.
>
>> 3. If you have some confidence that the patch fixes the problem, then
>> mark the commit with the tag:
>> Reported-by: syzbot+387f48da65cb522ab...@syzkaller.appspotmail.com
>> then syzbot will notify if this still happens after the commit reaches
>> tested trees.
>
> Some have been already tagged with reported-by.  Some are mostly
> irrelevant but casually found during the debug session for the bugs
> syzkaller spotted.


I think this is fixed with:

#syz fix: ALSA: pcm: Abort properly at pending signal in OSS read/write loops

Re: INFO: rcu detected stall in memcpy

2018-02-14 Thread Dmitry Vyukov 
On Mon, Jan 8, 2018 at 2:15 PM, Takashi Iwai  wrote:
> On Sun, 07 Jan 2018 12:30:53 +0100,
> Dmitry Vyukov wrote:
>>
>> On Thu, Jan 4, 2018 at 6:03 PM, Takashi Iwai  wrote:
>> > On Thu, 04 Jan 2018 15:17:23 +0100,
>> > Takashi Iwai wrote:
>> >>
>> >> On Thu, 04 Jan 2018 15:01:06 +0100,
>> >> Dmitry Vyukov wrote:
>> >> >
>> >> > On Thu, Jan 4, 2018 at 1:57 PM, Takashi Iwai  wrote:
>> >> > > On Thu, 04 Jan 2018 13:08:45 +0100,
>> >> > > Dmitry Vyukov wrote:
>> >> > >>
>> >> > >> On Thu, Jan 4, 2018 at 1:03 PM, syzbot
>> >> > >>  wrote:
>> >> > >> > Hello,
>> >> > >> >
>> >> > >> > syzkaller hit the following crash on
>> >> > >> > 30a7acd573899fd8b8ac39236eff6468b195ac7d
>> >> > >> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
>> >> > >> > compiler: gcc (GCC) 7.1.1 20170620
>> >> > >> > .config is attached
>> >> > >> > Raw console output is attached.
>> >> > >> > Unfortunately, I don't have any reproducer for this bug yet.
>> >> > >> >
>> >> > >> >
>> >> > >> > IMPORTANT: if you fix the bug, please add the following tag to the 
>> >> > >> > commit:
>> >> > >> > Reported-by: syzbot+387f48da65cb522ab...@syzkaller.appspotmail.com
>> >> > >> > It will help syzbot understand when the bug is fixed. See footer 
>> >> > >> > for
>> >> > >> > details.
>> >> > >> > If you forward the report, please keep this part and the footer.
>> >> > >>
>> >> > >> This looks ALSA-related. +ALSA maintainers.
>> >> > >
>> >> > > Not sure exactly what triggers it.  It's the simple memcpy(), and I
>> >> > > don't know where RCU is involved in that code path.
>> >> > >
>> >> > > BTW, other two suspicious RCU usage reports are actually stopped at
>> >> > > the second WARN_ON() after the RCU message, and the second WARN_ON()
>> >> > > is independent from RCU; it's the known spurious WARN_ON() and was
>> >> > > already removed in the sound git tree.
>> >> >
>> >> >
>> >> > Hi Takashi,
>> >> >
>> >> > Another similar one just popped up:
>> >> >
>> >> > https://groups.google.com/forum/#!topic/syzkaller-bugs/X3d6-PIrJM0
>> >> >
>> >> > This looks like mulaw_decode enters an infinite loop, or at least
>> >> > doing very large amount of computations without a resched, e.g.
>> >> > (uint64_t)-1 number of iterations of something along these lines.
>> >>
>> >> OK, that makes sense.
>> >>
>> >> My rough guess is that it's the misconfigured aloop device by
>> >> concurrent setup.  The aloop device allows to restrict the parameters
>> >> of the other side of the connection, and something bad may happen
>> >> there if both sides are updated concurrently.
>> >>
>> >> We've seen segfault by memset() at loopback_preapre() in
>> >> sound/drivers/aloop.c by syzbot+3902b5220e8ca27889ca, too, which
>> >> indicates also the wrongly setup parameters that overflows the
>> >> allocated buffer.
>> >
>> > Below two patches may possibly plug the holes, but I'm not entirely
>> > sure whether that's the exact culprit.  Could you put them into syzbot
>> > to watch whether they have any influence?
>>
>> Hi Takashi,
>>
>> I've gave an answer to this here:
>> https://groups.google.com/d/msg/syzkaller-bugs/7ucgCkAJKSk/skZjgavRAQAJ
>
> OK, noted.
>
>> > In anyway, they are obvious bugs to be fixed, so I'm going to queue to
>> > my tree.
>>
>> The options are:
>> 1. You can ask syzbot to test the patch separately. This requires a
>> reproducer, but there is this bug which has a reproducer and seems to
>> have the same root cause:
>> https://groups.google.com/d/msg/syzkaller-bugs/KrPUlf-nm5g/Vk0xEq-HAAAJ
>
> Ah, I didn't know that each bot can test patches individually.
>
>> 2. You can reproduce it with the reproducer from here:
>> https://groups.google.com/d/msg/syzkaller-bugs/KrPUlf-nm5g/Vk0xEq-HAAAJ
>> and then test the patch as extensively as needed.
>
> Yes, I could test and find the culprit with the given reproducer.
>
>> 3. If you have some confidence that the patch fixes the problem, then
>> mark the commit with the tag:
>> Reported-by: syzbot+387f48da65cb522ab...@syzkaller.appspotmail.com
>> then syzbot will notify if this still happens after the commit reaches
>> tested trees.
>
> Some have been already tagged with reported-by.  Some are mostly
> irrelevant but casually found during the debug session for the bugs
> syzkaller spotted.


I think this is fixed with:

#syz fix: ALSA: pcm: Abort properly at pending signal in OSS read/write loops

Re: INFO: rcu detected stall in memcpy

2018-01-08 Thread Takashi Iwai 
On Sun, 07 Jan 2018 12:30:53 +0100,
Dmitry Vyukov wrote:
> 
> On Thu, Jan 4, 2018 at 6:03 PM, Takashi Iwai  wrote:
> > On Thu, 04 Jan 2018 15:17:23 +0100,
> > Takashi Iwai wrote:
> >>
> >> On Thu, 04 Jan 2018 15:01:06 +0100,
> >> Dmitry Vyukov wrote:
> >> >
> >> > On Thu, Jan 4, 2018 at 1:57 PM, Takashi Iwai  wrote:
> >> > > On Thu, 04 Jan 2018 13:08:45 +0100,
> >> > > Dmitry Vyukov wrote:
> >> > >>
> >> > >> On Thu, Jan 4, 2018 at 1:03 PM, syzbot
> >> > >>  wrote:
> >> > >> > Hello,
> >> > >> >
> >> > >> > syzkaller hit the following crash on
> >> > >> > 30a7acd573899fd8b8ac39236eff6468b195ac7d
> >> > >> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> >> > >> > compiler: gcc (GCC) 7.1.1 20170620
> >> > >> > .config is attached
> >> > >> > Raw console output is attached.
> >> > >> > Unfortunately, I don't have any reproducer for this bug yet.
> >> > >> >
> >> > >> >
> >> > >> > IMPORTANT: if you fix the bug, please add the following tag to the 
> >> > >> > commit:
> >> > >> > Reported-by: syzbot+387f48da65cb522ab...@syzkaller.appspotmail.com
> >> > >> > It will help syzbot understand when the bug is fixed. See footer for
> >> > >> > details.
> >> > >> > If you forward the report, please keep this part and the footer.
> >> > >>
> >> > >> This looks ALSA-related. +ALSA maintainers.
> >> > >
> >> > > Not sure exactly what triggers it.  It's the simple memcpy(), and I
> >> > > don't know where RCU is involved in that code path.
> >> > >
> >> > > BTW, other two suspicious RCU usage reports are actually stopped at
> >> > > the second WARN_ON() after the RCU message, and the second WARN_ON()
> >> > > is independent from RCU; it's the known spurious WARN_ON() and was
> >> > > already removed in the sound git tree.
> >> >
> >> >
> >> > Hi Takashi,
> >> >
> >> > Another similar one just popped up:
> >> >
> >> > https://groups.google.com/forum/#!topic/syzkaller-bugs/X3d6-PIrJM0
> >> >
> >> > This looks like mulaw_decode enters an infinite loop, or at least
> >> > doing very large amount of computations without a resched, e.g.
> >> > (uint64_t)-1 number of iterations of something along these lines.
> >>
> >> OK, that makes sense.
> >>
> >> My rough guess is that it's the misconfigured aloop device by
> >> concurrent setup.  The aloop device allows to restrict the parameters
> >> of the other side of the connection, and something bad may happen
> >> there if both sides are updated concurrently.
> >>
> >> We've seen segfault by memset() at loopback_preapre() in
> >> sound/drivers/aloop.c by syzbot+3902b5220e8ca27889ca, too, which
> >> indicates also the wrongly setup parameters that overflows the
> >> allocated buffer.
> >
> > Below two patches may possibly plug the holes, but I'm not entirely
> > sure whether that's the exact culprit.  Could you put them into syzbot
> > to watch whether they have any influence?
> 
> Hi Takashi,
> 
> I've gave an answer to this here:
> https://groups.google.com/d/msg/syzkaller-bugs/7ucgCkAJKSk/skZjgavRAQAJ

OK, noted.

> > In anyway, they are obvious bugs to be fixed, so I'm going to queue to
> > my tree.
> 
> The options are:
> 1. You can ask syzbot to test the patch separately. This requires a
> reproducer, but there is this bug which has a reproducer and seems to
> have the same root cause:
> https://groups.google.com/d/msg/syzkaller-bugs/KrPUlf-nm5g/Vk0xEq-HAAAJ

Ah, I didn't know that each bot can test patches individually.

> 2. You can reproduce it with the reproducer from here:
> https://groups.google.com/d/msg/syzkaller-bugs/KrPUlf-nm5g/Vk0xEq-HAAAJ
> and then test the patch as extensively as needed.

Yes, I could test and find the culprit with the given reproducer.

> 3. If you have some confidence that the patch fixes the problem, then
> mark the commit with the tag:
> Reported-by: syzbot+387f48da65cb522ab...@syzkaller.appspotmail.com
> then syzbot will notify if this still happens after the commit reaches
> tested trees.

Some have been already tagged with reported-by.  Some are mostly
irrelevant but casually found during the debug session for the bugs
syzkaller spotted.


thanks,

Takashi

Re: INFO: rcu detected stall in memcpy

2018-01-08 Thread Takashi Iwai 
On Sun, 07 Jan 2018 12:30:53 +0100,
Dmitry Vyukov wrote:
> 
> On Thu, Jan 4, 2018 at 6:03 PM, Takashi Iwai  wrote:
> > On Thu, 04 Jan 2018 15:17:23 +0100,
> > Takashi Iwai wrote:
> >>
> >> On Thu, 04 Jan 2018 15:01:06 +0100,
> >> Dmitry Vyukov wrote:
> >> >
> >> > On Thu, Jan 4, 2018 at 1:57 PM, Takashi Iwai  wrote:
> >> > > On Thu, 04 Jan 2018 13:08:45 +0100,
> >> > > Dmitry Vyukov wrote:
> >> > >>
> >> > >> On Thu, Jan 4, 2018 at 1:03 PM, syzbot
> >> > >>  wrote:
> >> > >> > Hello,
> >> > >> >
> >> > >> > syzkaller hit the following crash on
> >> > >> > 30a7acd573899fd8b8ac39236eff6468b195ac7d
> >> > >> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> >> > >> > compiler: gcc (GCC) 7.1.1 20170620
> >> > >> > .config is attached
> >> > >> > Raw console output is attached.
> >> > >> > Unfortunately, I don't have any reproducer for this bug yet.
> >> > >> >
> >> > >> >
> >> > >> > IMPORTANT: if you fix the bug, please add the following tag to the 
> >> > >> > commit:
> >> > >> > Reported-by: syzbot+387f48da65cb522ab...@syzkaller.appspotmail.com
> >> > >> > It will help syzbot understand when the bug is fixed. See footer for
> >> > >> > details.
> >> > >> > If you forward the report, please keep this part and the footer.
> >> > >>
> >> > >> This looks ALSA-related. +ALSA maintainers.
> >> > >
> >> > > Not sure exactly what triggers it.  It's the simple memcpy(), and I
> >> > > don't know where RCU is involved in that code path.
> >> > >
> >> > > BTW, other two suspicious RCU usage reports are actually stopped at
> >> > > the second WARN_ON() after the RCU message, and the second WARN_ON()
> >> > > is independent from RCU; it's the known spurious WARN_ON() and was
> >> > > already removed in the sound git tree.
> >> >
> >> >
> >> > Hi Takashi,
> >> >
> >> > Another similar one just popped up:
> >> >
> >> > https://groups.google.com/forum/#!topic/syzkaller-bugs/X3d6-PIrJM0
> >> >
> >> > This looks like mulaw_decode enters an infinite loop, or at least
> >> > doing very large amount of computations without a resched, e.g.
> >> > (uint64_t)-1 number of iterations of something along these lines.
> >>
> >> OK, that makes sense.
> >>
> >> My rough guess is that it's the misconfigured aloop device by
> >> concurrent setup.  The aloop device allows to restrict the parameters
> >> of the other side of the connection, and something bad may happen
> >> there if both sides are updated concurrently.
> >>
> >> We've seen segfault by memset() at loopback_preapre() in
> >> sound/drivers/aloop.c by syzbot+3902b5220e8ca27889ca, too, which
> >> indicates also the wrongly setup parameters that overflows the
> >> allocated buffer.
> >
> > Below two patches may possibly plug the holes, but I'm not entirely
> > sure whether that's the exact culprit.  Could you put them into syzbot
> > to watch whether they have any influence?
> 
> Hi Takashi,
> 
> I've gave an answer to this here:
> https://groups.google.com/d/msg/syzkaller-bugs/7ucgCkAJKSk/skZjgavRAQAJ

OK, noted.

> > In anyway, they are obvious bugs to be fixed, so I'm going to queue to
> > my tree.
> 
> The options are:
> 1. You can ask syzbot to test the patch separately. This requires a
> reproducer, but there is this bug which has a reproducer and seems to
> have the same root cause:
> https://groups.google.com/d/msg/syzkaller-bugs/KrPUlf-nm5g/Vk0xEq-HAAAJ

Ah, I didn't know that each bot can test patches individually.

> 2. You can reproduce it with the reproducer from here:
> https://groups.google.com/d/msg/syzkaller-bugs/KrPUlf-nm5g/Vk0xEq-HAAAJ
> and then test the patch as extensively as needed.

Yes, I could test and find the culprit with the given reproducer.

> 3. If you have some confidence that the patch fixes the problem, then
> mark the commit with the tag:
> Reported-by: syzbot+387f48da65cb522ab...@syzkaller.appspotmail.com
> then syzbot will notify if this still happens after the commit reaches
> tested trees.

Some have been already tagged with reported-by.  Some are mostly
irrelevant but casually found during the debug session for the bugs
syzkaller spotted.


thanks,

Takashi

Re: INFO: rcu detected stall in memcpy

2018-01-07 Thread Dmitry Vyukov 
On Thu, Jan 4, 2018 at 6:03 PM, Takashi Iwai  wrote:
> On Thu, 04 Jan 2018 15:17:23 +0100,
> Takashi Iwai wrote:
>>
>> On Thu, 04 Jan 2018 15:01:06 +0100,
>> Dmitry Vyukov wrote:
>> >
>> > On Thu, Jan 4, 2018 at 1:57 PM, Takashi Iwai  wrote:
>> > > On Thu, 04 Jan 2018 13:08:45 +0100,
>> > > Dmitry Vyukov wrote:
>> > >>
>> > >> On Thu, Jan 4, 2018 at 1:03 PM, syzbot
>> > >>  wrote:
>> > >> > Hello,
>> > >> >
>> > >> > syzkaller hit the following crash on
>> > >> > 30a7acd573899fd8b8ac39236eff6468b195ac7d
>> > >> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
>> > >> > compiler: gcc (GCC) 7.1.1 20170620
>> > >> > .config is attached
>> > >> > Raw console output is attached.
>> > >> > Unfortunately, I don't have any reproducer for this bug yet.
>> > >> >
>> > >> >
>> > >> > IMPORTANT: if you fix the bug, please add the following tag to the 
>> > >> > commit:
>> > >> > Reported-by: syzbot+387f48da65cb522ab...@syzkaller.appspotmail.com
>> > >> > It will help syzbot understand when the bug is fixed. See footer for
>> > >> > details.
>> > >> > If you forward the report, please keep this part and the footer.
>> > >>
>> > >> This looks ALSA-related. +ALSA maintainers.
>> > >
>> > > Not sure exactly what triggers it.  It's the simple memcpy(), and I
>> > > don't know where RCU is involved in that code path.
>> > >
>> > > BTW, other two suspicious RCU usage reports are actually stopped at
>> > > the second WARN_ON() after the RCU message, and the second WARN_ON()
>> > > is independent from RCU; it's the known spurious WARN_ON() and was
>> > > already removed in the sound git tree.
>> >
>> >
>> > Hi Takashi,
>> >
>> > Another similar one just popped up:
>> >
>> > https://groups.google.com/forum/#!topic/syzkaller-bugs/X3d6-PIrJM0
>> >
>> > This looks like mulaw_decode enters an infinite loop, or at least
>> > doing very large amount of computations without a resched, e.g.
>> > (uint64_t)-1 number of iterations of something along these lines.
>>
>> OK, that makes sense.
>>
>> My rough guess is that it's the misconfigured aloop device by
>> concurrent setup.  The aloop device allows to restrict the parameters
>> of the other side of the connection, and something bad may happen
>> there if both sides are updated concurrently.
>>
>> We've seen segfault by memset() at loopback_preapre() in
>> sound/drivers/aloop.c by syzbot+3902b5220e8ca27889ca, too, which
>> indicates also the wrongly setup parameters that overflows the
>> allocated buffer.
>
> Below two patches may possibly plug the holes, but I'm not entirely
> sure whether that's the exact culprit.  Could you put them into syzbot
> to watch whether they have any influence?

Hi Takashi,

I've gave an answer to this here:
https://groups.google.com/d/msg/syzkaller-bugs/7ucgCkAJKSk/skZjgavRAQAJ

> In anyway, they are obvious bugs to be fixed, so I'm going to queue to
> my tree.

The options are:
1. You can ask syzbot to test the patch separately. This requires a
reproducer, but there is this bug which has a reproducer and seems to
have the same root cause:
https://groups.google.com/d/msg/syzkaller-bugs/KrPUlf-nm5g/Vk0xEq-HAAAJ
2. You can reproduce it with the reproducer from here:
https://groups.google.com/d/msg/syzkaller-bugs/KrPUlf-nm5g/Vk0xEq-HAAAJ
and then test the patch as extensively as needed.
3. If you have some confidence that the patch fixes the problem, then
mark the commit with the tag:
Reported-by: syzbot+387f48da65cb522ab...@syzkaller.appspotmail.com
then syzbot will notify if this still happens after the commit reaches
tested trees.

Re: INFO: rcu detected stall in memcpy

2018-01-07 Thread Dmitry Vyukov 
On Thu, Jan 4, 2018 at 6:03 PM, Takashi Iwai  wrote:
> On Thu, 04 Jan 2018 15:17:23 +0100,
> Takashi Iwai wrote:
>>
>> On Thu, 04 Jan 2018 15:01:06 +0100,
>> Dmitry Vyukov wrote:
>> >
>> > On Thu, Jan 4, 2018 at 1:57 PM, Takashi Iwai  wrote:
>> > > On Thu, 04 Jan 2018 13:08:45 +0100,
>> > > Dmitry Vyukov wrote:
>> > >>
>> > >> On Thu, Jan 4, 2018 at 1:03 PM, syzbot
>> > >>  wrote:
>> > >> > Hello,
>> > >> >
>> > >> > syzkaller hit the following crash on
>> > >> > 30a7acd573899fd8b8ac39236eff6468b195ac7d
>> > >> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
>> > >> > compiler: gcc (GCC) 7.1.1 20170620
>> > >> > .config is attached
>> > >> > Raw console output is attached.
>> > >> > Unfortunately, I don't have any reproducer for this bug yet.
>> > >> >
>> > >> >
>> > >> > IMPORTANT: if you fix the bug, please add the following tag to the 
>> > >> > commit:
>> > >> > Reported-by: syzbot+387f48da65cb522ab...@syzkaller.appspotmail.com
>> > >> > It will help syzbot understand when the bug is fixed. See footer for
>> > >> > details.
>> > >> > If you forward the report, please keep this part and the footer.
>> > >>
>> > >> This looks ALSA-related. +ALSA maintainers.
>> > >
>> > > Not sure exactly what triggers it.  It's the simple memcpy(), and I
>> > > don't know where RCU is involved in that code path.
>> > >
>> > > BTW, other two suspicious RCU usage reports are actually stopped at
>> > > the second WARN_ON() after the RCU message, and the second WARN_ON()
>> > > is independent from RCU; it's the known spurious WARN_ON() and was
>> > > already removed in the sound git tree.
>> >
>> >
>> > Hi Takashi,
>> >
>> > Another similar one just popped up:
>> >
>> > https://groups.google.com/forum/#!topic/syzkaller-bugs/X3d6-PIrJM0
>> >
>> > This looks like mulaw_decode enters an infinite loop, or at least
>> > doing very large amount of computations without a resched, e.g.
>> > (uint64_t)-1 number of iterations of something along these lines.
>>
>> OK, that makes sense.
>>
>> My rough guess is that it's the misconfigured aloop device by
>> concurrent setup.  The aloop device allows to restrict the parameters
>> of the other side of the connection, and something bad may happen
>> there if both sides are updated concurrently.
>>
>> We've seen segfault by memset() at loopback_preapre() in
>> sound/drivers/aloop.c by syzbot+3902b5220e8ca27889ca, too, which
>> indicates also the wrongly setup parameters that overflows the
>> allocated buffer.
>
> Below two patches may possibly plug the holes, but I'm not entirely
> sure whether that's the exact culprit.  Could you put them into syzbot
> to watch whether they have any influence?

Hi Takashi,

I've gave an answer to this here:
https://groups.google.com/d/msg/syzkaller-bugs/7ucgCkAJKSk/skZjgavRAQAJ

> In anyway, they are obvious bugs to be fixed, so I'm going to queue to
> my tree.

The options are:
1. You can ask syzbot to test the patch separately. This requires a
reproducer, but there is this bug which has a reproducer and seems to
have the same root cause:
https://groups.google.com/d/msg/syzkaller-bugs/KrPUlf-nm5g/Vk0xEq-HAAAJ
2. You can reproduce it with the reproducer from here:
https://groups.google.com/d/msg/syzkaller-bugs/KrPUlf-nm5g/Vk0xEq-HAAAJ
and then test the patch as extensively as needed.
3. If you have some confidence that the patch fixes the problem, then
mark the commit with the tag:
Reported-by: syzbot+387f48da65cb522ab...@syzkaller.appspotmail.com
then syzbot will notify if this still happens after the commit reaches
tested trees.

Re: INFO: rcu detected stall in memcpy

2018-01-04 Thread Takashi Iwai 
On Thu, 04 Jan 2018 15:17:23 +0100,
Takashi Iwai wrote:
> 
> On Thu, 04 Jan 2018 15:01:06 +0100,
> Dmitry Vyukov wrote:
> > 
> > On Thu, Jan 4, 2018 at 1:57 PM, Takashi Iwai  wrote:
> > > On Thu, 04 Jan 2018 13:08:45 +0100,
> > > Dmitry Vyukov wrote:
> > >>
> > >> On Thu, Jan 4, 2018 at 1:03 PM, syzbot
> > >>  wrote:
> > >> > Hello,
> > >> >
> > >> > syzkaller hit the following crash on
> > >> > 30a7acd573899fd8b8ac39236eff6468b195ac7d
> > >> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> > >> > compiler: gcc (GCC) 7.1.1 20170620
> > >> > .config is attached
> > >> > Raw console output is attached.
> > >> > Unfortunately, I don't have any reproducer for this bug yet.
> > >> >
> > >> >
> > >> > IMPORTANT: if you fix the bug, please add the following tag to the 
> > >> > commit:
> > >> > Reported-by: syzbot+387f48da65cb522ab...@syzkaller.appspotmail.com
> > >> > It will help syzbot understand when the bug is fixed. See footer for
> > >> > details.
> > >> > If you forward the report, please keep this part and the footer.
> > >>
> > >> This looks ALSA-related. +ALSA maintainers.
> > >
> > > Not sure exactly what triggers it.  It's the simple memcpy(), and I
> > > don't know where RCU is involved in that code path.
> > >
> > > BTW, other two suspicious RCU usage reports are actually stopped at
> > > the second WARN_ON() after the RCU message, and the second WARN_ON()
> > > is independent from RCU; it's the known spurious WARN_ON() and was
> > > already removed in the sound git tree.
> > 
> > 
> > Hi Takashi,
> > 
> > Another similar one just popped up:
> > 
> > https://groups.google.com/forum/#!topic/syzkaller-bugs/X3d6-PIrJM0
> > 
> > This looks like mulaw_decode enters an infinite loop, or at least
> > doing very large amount of computations without a resched, e.g.
> > (uint64_t)-1 number of iterations of something along these lines.
> 
> OK, that makes sense.
> 
> My rough guess is that it's the misconfigured aloop device by
> concurrent setup.  The aloop device allows to restrict the parameters
> of the other side of the connection, and something bad may happen
> there if both sides are updated concurrently.
> 
> We've seen segfault by memset() at loopback_preapre() in
> sound/drivers/aloop.c by syzbot+3902b5220e8ca27889ca, too, which
> indicates also the wrongly setup parameters that overflows the
> allocated buffer.

Below two patches may possibly plug the holes, but I'm not entirely
sure whether that's the exact culprit.  Could you put them into syzbot
to watch whether they have any influence?

In anyway, they are obvious bugs to be fixed, so I'm going to queue to
my tree.


thanks,

Takashi



0001-ALSA-pcm-Add-missing-error-checks-in-OSS-emulation-p.patch
Description: Binary data


0002-ALSA-aloop-Fix-racy-hw-constraints-adjustment.patch
Description: Binary data

Re: INFO: rcu detected stall in memcpy

2018-01-04 Thread Takashi Iwai 
On Thu, 04 Jan 2018 15:17:23 +0100,
Takashi Iwai wrote:
> 
> On Thu, 04 Jan 2018 15:01:06 +0100,
> Dmitry Vyukov wrote:
> > 
> > On Thu, Jan 4, 2018 at 1:57 PM, Takashi Iwai  wrote:
> > > On Thu, 04 Jan 2018 13:08:45 +0100,
> > > Dmitry Vyukov wrote:
> > >>
> > >> On Thu, Jan 4, 2018 at 1:03 PM, syzbot
> > >>  wrote:
> > >> > Hello,
> > >> >
> > >> > syzkaller hit the following crash on
> > >> > 30a7acd573899fd8b8ac39236eff6468b195ac7d
> > >> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> > >> > compiler: gcc (GCC) 7.1.1 20170620
> > >> > .config is attached
> > >> > Raw console output is attached.
> > >> > Unfortunately, I don't have any reproducer for this bug yet.
> > >> >
> > >> >
> > >> > IMPORTANT: if you fix the bug, please add the following tag to the 
> > >> > commit:
> > >> > Reported-by: syzbot+387f48da65cb522ab...@syzkaller.appspotmail.com
> > >> > It will help syzbot understand when the bug is fixed. See footer for
> > >> > details.
> > >> > If you forward the report, please keep this part and the footer.
> > >>
> > >> This looks ALSA-related. +ALSA maintainers.
> > >
> > > Not sure exactly what triggers it.  It's the simple memcpy(), and I
> > > don't know where RCU is involved in that code path.
> > >
> > > BTW, other two suspicious RCU usage reports are actually stopped at
> > > the second WARN_ON() after the RCU message, and the second WARN_ON()
> > > is independent from RCU; it's the known spurious WARN_ON() and was
> > > already removed in the sound git tree.
> > 
> > 
> > Hi Takashi,
> > 
> > Another similar one just popped up:
> > 
> > https://groups.google.com/forum/#!topic/syzkaller-bugs/X3d6-PIrJM0
> > 
> > This looks like mulaw_decode enters an infinite loop, or at least
> > doing very large amount of computations without a resched, e.g.
> > (uint64_t)-1 number of iterations of something along these lines.
> 
> OK, that makes sense.
> 
> My rough guess is that it's the misconfigured aloop device by
> concurrent setup.  The aloop device allows to restrict the parameters
> of the other side of the connection, and something bad may happen
> there if both sides are updated concurrently.
> 
> We've seen segfault by memset() at loopback_preapre() in
> sound/drivers/aloop.c by syzbot+3902b5220e8ca27889ca, too, which
> indicates also the wrongly setup parameters that overflows the
> allocated buffer.

Below two patches may possibly plug the holes, but I'm not entirely
sure whether that's the exact culprit.  Could you put them into syzbot
to watch whether they have any influence?

In anyway, they are obvious bugs to be fixed, so I'm going to queue to
my tree.


thanks,

Takashi



0001-ALSA-pcm-Add-missing-error-checks-in-OSS-emulation-p.patch
Description: Binary data


0002-ALSA-aloop-Fix-racy-hw-constraints-adjustment.patch
Description: Binary data

Re: INFO: rcu detected stall in memcpy

2018-01-04 Thread Takashi Iwai 
On Thu, 04 Jan 2018 15:01:06 +0100,
Dmitry Vyukov wrote:
> 
> On Thu, Jan 4, 2018 at 1:57 PM, Takashi Iwai  wrote:
> > On Thu, 04 Jan 2018 13:08:45 +0100,
> > Dmitry Vyukov wrote:
> >>
> >> On Thu, Jan 4, 2018 at 1:03 PM, syzbot
> >>  wrote:
> >> > Hello,
> >> >
> >> > syzkaller hit the following crash on
> >> > 30a7acd573899fd8b8ac39236eff6468b195ac7d
> >> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> >> > compiler: gcc (GCC) 7.1.1 20170620
> >> > .config is attached
> >> > Raw console output is attached.
> >> > Unfortunately, I don't have any reproducer for this bug yet.
> >> >
> >> >
> >> > IMPORTANT: if you fix the bug, please add the following tag to the 
> >> > commit:
> >> > Reported-by: syzbot+387f48da65cb522ab...@syzkaller.appspotmail.com
> >> > It will help syzbot understand when the bug is fixed. See footer for
> >> > details.
> >> > If you forward the report, please keep this part and the footer.
> >>
> >> This looks ALSA-related. +ALSA maintainers.
> >
> > Not sure exactly what triggers it.  It's the simple memcpy(), and I
> > don't know where RCU is involved in that code path.
> >
> > BTW, other two suspicious RCU usage reports are actually stopped at
> > the second WARN_ON() after the RCU message, and the second WARN_ON()
> > is independent from RCU; it's the known spurious WARN_ON() and was
> > already removed in the sound git tree.
> 
> 
> Hi Takashi,
> 
> Another similar one just popped up:
> 
> https://groups.google.com/forum/#!topic/syzkaller-bugs/X3d6-PIrJM0
> 
> This looks like mulaw_decode enters an infinite loop, or at least
> doing very large amount of computations without a resched, e.g.
> (uint64_t)-1 number of iterations of something along these lines.

OK, that makes sense.

My rough guess is that it's the misconfigured aloop device by
concurrent setup.  The aloop device allows to restrict the parameters
of the other side of the connection, and something bad may happen
there if both sides are updated concurrently.

We've seen segfault by memset() at loopback_preapre() in
sound/drivers/aloop.c by syzbot+3902b5220e8ca27889ca, too, which
indicates also the wrongly setup parameters that overflows the
allocated buffer.


thanks,

Takashi

Re: INFO: rcu detected stall in memcpy

2018-01-04 Thread Takashi Iwai 
On Thu, 04 Jan 2018 15:01:06 +0100,
Dmitry Vyukov wrote:
> 
> On Thu, Jan 4, 2018 at 1:57 PM, Takashi Iwai  wrote:
> > On Thu, 04 Jan 2018 13:08:45 +0100,
> > Dmitry Vyukov wrote:
> >>
> >> On Thu, Jan 4, 2018 at 1:03 PM, syzbot
> >>  wrote:
> >> > Hello,
> >> >
> >> > syzkaller hit the following crash on
> >> > 30a7acd573899fd8b8ac39236eff6468b195ac7d
> >> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> >> > compiler: gcc (GCC) 7.1.1 20170620
> >> > .config is attached
> >> > Raw console output is attached.
> >> > Unfortunately, I don't have any reproducer for this bug yet.
> >> >
> >> >
> >> > IMPORTANT: if you fix the bug, please add the following tag to the 
> >> > commit:
> >> > Reported-by: syzbot+387f48da65cb522ab...@syzkaller.appspotmail.com
> >> > It will help syzbot understand when the bug is fixed. See footer for
> >> > details.
> >> > If you forward the report, please keep this part and the footer.
> >>
> >> This looks ALSA-related. +ALSA maintainers.
> >
> > Not sure exactly what triggers it.  It's the simple memcpy(), and I
> > don't know where RCU is involved in that code path.
> >
> > BTW, other two suspicious RCU usage reports are actually stopped at
> > the second WARN_ON() after the RCU message, and the second WARN_ON()
> > is independent from RCU; it's the known spurious WARN_ON() and was
> > already removed in the sound git tree.
> 
> 
> Hi Takashi,
> 
> Another similar one just popped up:
> 
> https://groups.google.com/forum/#!topic/syzkaller-bugs/X3d6-PIrJM0
> 
> This looks like mulaw_decode enters an infinite loop, or at least
> doing very large amount of computations without a resched, e.g.
> (uint64_t)-1 number of iterations of something along these lines.

OK, that makes sense.

My rough guess is that it's the misconfigured aloop device by
concurrent setup.  The aloop device allows to restrict the parameters
of the other side of the connection, and something bad may happen
there if both sides are updated concurrently.

We've seen segfault by memset() at loopback_preapre() in
sound/drivers/aloop.c by syzbot+3902b5220e8ca27889ca, too, which
indicates also the wrongly setup parameters that overflows the
allocated buffer.


thanks,

Takashi

Re: INFO: rcu detected stall in memcpy

2018-01-04 Thread Dmitry Vyukov 
On Thu, Jan 4, 2018 at 1:57 PM, Takashi Iwai  wrote:
> On Thu, 04 Jan 2018 13:08:45 +0100,
> Dmitry Vyukov wrote:
>>
>> On Thu, Jan 4, 2018 at 1:03 PM, syzbot
>>  wrote:
>> > Hello,
>> >
>> > syzkaller hit the following crash on
>> > 30a7acd573899fd8b8ac39236eff6468b195ac7d
>> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
>> > compiler: gcc (GCC) 7.1.1 20170620
>> > .config is attached
>> > Raw console output is attached.
>> > Unfortunately, I don't have any reproducer for this bug yet.
>> >
>> >
>> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> > Reported-by: syzbot+387f48da65cb522ab...@syzkaller.appspotmail.com
>> > It will help syzbot understand when the bug is fixed. See footer for
>> > details.
>> > If you forward the report, please keep this part and the footer.
>>
>> This looks ALSA-related. +ALSA maintainers.
>
> Not sure exactly what triggers it.  It's the simple memcpy(), and I
> don't know where RCU is involved in that code path.
>
> BTW, other two suspicious RCU usage reports are actually stopped at
> the second WARN_ON() after the RCU message, and the second WARN_ON()
> is independent from RCU; it's the known spurious WARN_ON() and was
> already removed in the sound git tree.


Hi Takashi,

Another similar one just popped up:

https://groups.google.com/forum/#!topic/syzkaller-bugs/X3d6-PIrJM0

This looks like mulaw_decode enters an infinite loop, or at least
doing very large amount of computations without a resched, e.g.
(uint64_t)-1 number of iterations of something along these lines.



>> > INFO: rcu_sched detected stalls on CPUs/tasks:
>> > (detected by 0, t=125002 jiffies, g=15654, c=15653, q=133)
>> > All QSes seen, last rcu_sched kthread activity 125002
>> > (4294863411-4294738409), jiffies_till_next_fqs=3, root ->qsmask 0x0
>> > syz-executor1   R  running task24936 11943   3739 0x000c
>> > Call Trace:
>> >  
>> >  sched_show_task+0x4a3/0x5e0 kernel/sched/core.c:5198
>> >  print_other_cpu_stall+0x996/0x1090 kernel/rcu/tree.c:1564
>> >  check_cpu_stall.isra.61+0x6e6/0x15b0 kernel/rcu/tree.c:1682
>> >  __rcu_pending kernel/rcu/tree.c:3440 [inline]
>> >  rcu_pending kernel/rcu/tree.c:3502 [inline]
>> >  rcu_check_callbacks+0x256/0xd00 kernel/rcu/tree.c:2842
>> >  update_process_times+0x30/0x60 kernel/time/timer.c:1628
>> >  tick_sched_handle+0x85/0x160 kernel/time/tick-sched.c:162
>> >  tick_sched_timer+0x42/0x120 kernel/time/tick-sched.c:1194
>> >  __run_hrtimer kernel/time/hrtimer.c:1211 [inline]
>> >  __hrtimer_run_queues+0x358/0xe20 kernel/time/hrtimer.c:1275
>> >  hrtimer_interrupt+0x1c2/0x5e0 kernel/time/hrtimer.c:1309
>> >  local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1025 [inline]
>> >  smp_apic_timer_interrupt+0x14a/0x700 arch/x86/kernel/apic/apic.c:1050
>> >  apic_timer_interrupt+0xa9/0xb0 arch/x86/entry/entry_64.S:920
>> >  
>> > RIP: 0010:kasan_mem_to_shadow include/linux/kasan.h:30 [inline]
>> > RIP: 0010:memory_is_poisoned_n mm/kasan/kasan.c:210 [inline]
>> > RIP: 0010:memory_is_poisoned mm/kasan/kasan.c:241 [inline]
>> > RIP: 0010:check_memory_region_inline mm/kasan/kasan.c:257 [inline]
>> > RIP: 0010:check_memory_region+0x38/0x190 mm/kasan/kasan.c:267
>> > RSP: :8801bd2ff868 EFLAGS: 0212 ORIG_RAX: ff11
>> > RAX: 7fff RBX: c9000160020b RCX: 841fceaf
>> > RDX: 0001 RSI: 0002 RDI: c9000160020a
>> > RBP: 8801bd2ff878 R08: c9000160020a R09: dc00
>> > R10: 0001 R11: ed0037a5ff2e R12: c9000160020a
>> > R13: 8801bd2ff970 R14: dc00 R15: c9000160020a
>> >  memcpy+0x37/0x50 mm/kasan/kasan.c:303
>> >  memcpy include/linux/string.h:344 [inline]
>> >  cvt_s16_to_native sound/core/oss/mulaw.c:164 [inline]
>> >  mulaw_decode+0x52f/0x770 sound/core/oss/mulaw.c:195
>> >  mulaw_transfer+0x222/0x270 sound/core/oss/mulaw.c:273
>> >  snd_pcm_plug_write_transfer+0x22d/0x420 sound/core/oss/pcm_plugin.c:611
>> >  snd_pcm_oss_write2+0x260/0x420 sound/core/oss/pcm_oss.c:1311
>> >  snd_pcm_oss_write1 sound/core/oss/pcm_oss.c:1372 [inline]
>> >  snd_pcm_oss_write+0x5fe/0x830 sound/core/oss/pcm_oss.c:2646
>> >  __vfs_write+0xef/0x970 fs/read_write.c:480
>> >  vfs_write+0x189/0x510 fs/read_write.c:544
>> >  SYSC_write fs/read_write.c:589 [inline]
>> >  SyS_write+0xef/0x220 fs/read_write.c:581
>> >  entry_SYSCALL_64_fastpath+0x23/0x9a
>> > RIP: 0033:0x452ac9
>> > RSP: 002b:7fa354a13c58 EFLAGS: 0212 ORIG_RAX: 0001
>> > RAX: ffda RBX: cccd RCX: 00452ac9
>> > RDX: feb2 RSI: 20083fc6 RDI: 0014
>> > RBP: 05b5 R08:  R09: 
>> > R10:  R11: 0212 R12: 006f6998
>> > R13:  R14: 7fa354a146d4 R15: 
>> > rcu_sched kthread starved for

Re: INFO: rcu detected stall in memcpy

2018-01-04 Thread Dmitry Vyukov 
On Thu, Jan 4, 2018 at 1:57 PM, Takashi Iwai  wrote:
> On Thu, 04 Jan 2018 13:08:45 +0100,
> Dmitry Vyukov wrote:
>>
>> On Thu, Jan 4, 2018 at 1:03 PM, syzbot
>>  wrote:
>> > Hello,
>> >
>> > syzkaller hit the following crash on
>> > 30a7acd573899fd8b8ac39236eff6468b195ac7d
>> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
>> > compiler: gcc (GCC) 7.1.1 20170620
>> > .config is attached
>> > Raw console output is attached.
>> > Unfortunately, I don't have any reproducer for this bug yet.
>> >
>> >
>> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> > Reported-by: syzbot+387f48da65cb522ab...@syzkaller.appspotmail.com
>> > It will help syzbot understand when the bug is fixed. See footer for
>> > details.
>> > If you forward the report, please keep this part and the footer.
>>
>> This looks ALSA-related. +ALSA maintainers.
>
> Not sure exactly what triggers it.  It's the simple memcpy(), and I
> don't know where RCU is involved in that code path.
>
> BTW, other two suspicious RCU usage reports are actually stopped at
> the second WARN_ON() after the RCU message, and the second WARN_ON()
> is independent from RCU; it's the known spurious WARN_ON() and was
> already removed in the sound git tree.


Hi Takashi,

Another similar one just popped up:

https://groups.google.com/forum/#!topic/syzkaller-bugs/X3d6-PIrJM0

This looks like mulaw_decode enters an infinite loop, or at least
doing very large amount of computations without a resched, e.g.
(uint64_t)-1 number of iterations of something along these lines.



>> > INFO: rcu_sched detected stalls on CPUs/tasks:
>> > (detected by 0, t=125002 jiffies, g=15654, c=15653, q=133)
>> > All QSes seen, last rcu_sched kthread activity 125002
>> > (4294863411-4294738409), jiffies_till_next_fqs=3, root ->qsmask 0x0
>> > syz-executor1   R  running task24936 11943   3739 0x000c
>> > Call Trace:
>> >  
>> >  sched_show_task+0x4a3/0x5e0 kernel/sched/core.c:5198
>> >  print_other_cpu_stall+0x996/0x1090 kernel/rcu/tree.c:1564
>> >  check_cpu_stall.isra.61+0x6e6/0x15b0 kernel/rcu/tree.c:1682
>> >  __rcu_pending kernel/rcu/tree.c:3440 [inline]
>> >  rcu_pending kernel/rcu/tree.c:3502 [inline]
>> >  rcu_check_callbacks+0x256/0xd00 kernel/rcu/tree.c:2842
>> >  update_process_times+0x30/0x60 kernel/time/timer.c:1628
>> >  tick_sched_handle+0x85/0x160 kernel/time/tick-sched.c:162
>> >  tick_sched_timer+0x42/0x120 kernel/time/tick-sched.c:1194
>> >  __run_hrtimer kernel/time/hrtimer.c:1211 [inline]
>> >  __hrtimer_run_queues+0x358/0xe20 kernel/time/hrtimer.c:1275
>> >  hrtimer_interrupt+0x1c2/0x5e0 kernel/time/hrtimer.c:1309
>> >  local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1025 [inline]
>> >  smp_apic_timer_interrupt+0x14a/0x700 arch/x86/kernel/apic/apic.c:1050
>> >  apic_timer_interrupt+0xa9/0xb0 arch/x86/entry/entry_64.S:920
>> >  
>> > RIP: 0010:kasan_mem_to_shadow include/linux/kasan.h:30 [inline]
>> > RIP: 0010:memory_is_poisoned_n mm/kasan/kasan.c:210 [inline]
>> > RIP: 0010:memory_is_poisoned mm/kasan/kasan.c:241 [inline]
>> > RIP: 0010:check_memory_region_inline mm/kasan/kasan.c:257 [inline]
>> > RIP: 0010:check_memory_region+0x38/0x190 mm/kasan/kasan.c:267
>> > RSP: :8801bd2ff868 EFLAGS: 0212 ORIG_RAX: ff11
>> > RAX: 7fff RBX: c9000160020b RCX: 841fceaf
>> > RDX: 0001 RSI: 0002 RDI: c9000160020a
>> > RBP: 8801bd2ff878 R08: c9000160020a R09: dc00
>> > R10: 0001 R11: ed0037a5ff2e R12: c9000160020a
>> > R13: 8801bd2ff970 R14: dc00 R15: c9000160020a
>> >  memcpy+0x37/0x50 mm/kasan/kasan.c:303
>> >  memcpy include/linux/string.h:344 [inline]
>> >  cvt_s16_to_native sound/core/oss/mulaw.c:164 [inline]
>> >  mulaw_decode+0x52f/0x770 sound/core/oss/mulaw.c:195
>> >  mulaw_transfer+0x222/0x270 sound/core/oss/mulaw.c:273
>> >  snd_pcm_plug_write_transfer+0x22d/0x420 sound/core/oss/pcm_plugin.c:611
>> >  snd_pcm_oss_write2+0x260/0x420 sound/core/oss/pcm_oss.c:1311
>> >  snd_pcm_oss_write1 sound/core/oss/pcm_oss.c:1372 [inline]
>> >  snd_pcm_oss_write+0x5fe/0x830 sound/core/oss/pcm_oss.c:2646
>> >  __vfs_write+0xef/0x970 fs/read_write.c:480
>> >  vfs_write+0x189/0x510 fs/read_write.c:544
>> >  SYSC_write fs/read_write.c:589 [inline]
>> >  SyS_write+0xef/0x220 fs/read_write.c:581
>> >  entry_SYSCALL_64_fastpath+0x23/0x9a
>> > RIP: 0033:0x452ac9
>> > RSP: 002b:7fa354a13c58 EFLAGS: 0212 ORIG_RAX: 0001
>> > RAX: ffda RBX: cccd RCX: 00452ac9
>> > RDX: feb2 RSI: 20083fc6 RDI: 0014
>> > RBP: 05b5 R08:  R09: 
>> > R10:  R11: 0212 R12: 006f6998
>> > R13:  R14: 7fa354a146d4 R15: 
>> > rcu_sched kthread starved for 125002 jiffies! g15654 c15653 f0x2
>> > RCU_GP_WAIT_FQS(3) ->state=0x0

Re: INFO: rcu detected stall in memcpy

2018-01-04 Thread Takashi Iwai 
On Thu, 04 Jan 2018 13:08:45 +0100,
Dmitry Vyukov wrote:
> 
> On Thu, Jan 4, 2018 at 1:03 PM, syzbot
>  wrote:
> > Hello,
> >
> > syzkaller hit the following crash on
> > 30a7acd573899fd8b8ac39236eff6468b195ac7d
> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> > compiler: gcc (GCC) 7.1.1 20170620
> > .config is attached
> > Raw console output is attached.
> > Unfortunately, I don't have any reproducer for this bug yet.
> >
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+387f48da65cb522ab...@syzkaller.appspotmail.com
> > It will help syzbot understand when the bug is fixed. See footer for
> > details.
> > If you forward the report, please keep this part and the footer.
> 
> This looks ALSA-related. +ALSA maintainers.

Not sure exactly what triggers it.  It's the simple memcpy(), and I
don't know where RCU is involved in that code path.

BTW, other two suspicious RCU usage reports are actually stopped at
the second WARN_ON() after the RCU message, and the second WARN_ON()
is independent from RCU; it's the known spurious WARN_ON() and was
already removed in the sound git tree.


thanks,

Takashi

> > INFO: rcu_sched detected stalls on CPUs/tasks:
> > (detected by 0, t=125002 jiffies, g=15654, c=15653, q=133)
> > All QSes seen, last rcu_sched kthread activity 125002
> > (4294863411-4294738409), jiffies_till_next_fqs=3, root ->qsmask 0x0
> > syz-executor1   R  running task24936 11943   3739 0x000c
> > Call Trace:
> >  
> >  sched_show_task+0x4a3/0x5e0 kernel/sched/core.c:5198
> >  print_other_cpu_stall+0x996/0x1090 kernel/rcu/tree.c:1564
> >  check_cpu_stall.isra.61+0x6e6/0x15b0 kernel/rcu/tree.c:1682
> >  __rcu_pending kernel/rcu/tree.c:3440 [inline]
> >  rcu_pending kernel/rcu/tree.c:3502 [inline]
> >  rcu_check_callbacks+0x256/0xd00 kernel/rcu/tree.c:2842
> >  update_process_times+0x30/0x60 kernel/time/timer.c:1628
> >  tick_sched_handle+0x85/0x160 kernel/time/tick-sched.c:162
> >  tick_sched_timer+0x42/0x120 kernel/time/tick-sched.c:1194
> >  __run_hrtimer kernel/time/hrtimer.c:1211 [inline]
> >  __hrtimer_run_queues+0x358/0xe20 kernel/time/hrtimer.c:1275
> >  hrtimer_interrupt+0x1c2/0x5e0 kernel/time/hrtimer.c:1309
> >  local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1025 [inline]
> >  smp_apic_timer_interrupt+0x14a/0x700 arch/x86/kernel/apic/apic.c:1050
> >  apic_timer_interrupt+0xa9/0xb0 arch/x86/entry/entry_64.S:920
> >  
> > RIP: 0010:kasan_mem_to_shadow include/linux/kasan.h:30 [inline]
> > RIP: 0010:memory_is_poisoned_n mm/kasan/kasan.c:210 [inline]
> > RIP: 0010:memory_is_poisoned mm/kasan/kasan.c:241 [inline]
> > RIP: 0010:check_memory_region_inline mm/kasan/kasan.c:257 [inline]
> > RIP: 0010:check_memory_region+0x38/0x190 mm/kasan/kasan.c:267
> > RSP: :8801bd2ff868 EFLAGS: 0212 ORIG_RAX: ff11
> > RAX: 7fff RBX: c9000160020b RCX: 841fceaf
> > RDX: 0001 RSI: 0002 RDI: c9000160020a
> > RBP: 8801bd2ff878 R08: c9000160020a R09: dc00
> > R10: 0001 R11: ed0037a5ff2e R12: c9000160020a
> > R13: 8801bd2ff970 R14: dc00 R15: c9000160020a
> >  memcpy+0x37/0x50 mm/kasan/kasan.c:303
> >  memcpy include/linux/string.h:344 [inline]
> >  cvt_s16_to_native sound/core/oss/mulaw.c:164 [inline]
> >  mulaw_decode+0x52f/0x770 sound/core/oss/mulaw.c:195
> >  mulaw_transfer+0x222/0x270 sound/core/oss/mulaw.c:273
> >  snd_pcm_plug_write_transfer+0x22d/0x420 sound/core/oss/pcm_plugin.c:611
> >  snd_pcm_oss_write2+0x260/0x420 sound/core/oss/pcm_oss.c:1311
> >  snd_pcm_oss_write1 sound/core/oss/pcm_oss.c:1372 [inline]
> >  snd_pcm_oss_write+0x5fe/0x830 sound/core/oss/pcm_oss.c:2646
> >  __vfs_write+0xef/0x970 fs/read_write.c:480
> >  vfs_write+0x189/0x510 fs/read_write.c:544
> >  SYSC_write fs/read_write.c:589 [inline]
> >  SyS_write+0xef/0x220 fs/read_write.c:581
> >  entry_SYSCALL_64_fastpath+0x23/0x9a
> > RIP: 0033:0x452ac9
> > RSP: 002b:7fa354a13c58 EFLAGS: 0212 ORIG_RAX: 0001
> > RAX: ffda RBX: cccd RCX: 00452ac9
> > RDX: feb2 RSI: 20083fc6 RDI: 0014
> > RBP: 05b5 R08:  R09: 
> > R10:  R11: 0212 R12: 006f6998
> > R13:  R14: 7fa354a146d4 R15: 
> > rcu_sched kthread starved for 125002 jiffies! g15654 c15653 f0x2
> > RCU_GP_WAIT_FQS(3) ->state=0x0 ->cpu=0
> > rcu_sched   R  running task23456 8  2 0x8000
> > Call Trace:
> >  context_switch kernel/sched/core.c:2799 [inline]
> >  __schedule+0x8eb/0x2060 kernel/sched/core.c:3375
> >  schedule+0xf5/0x430 kernel/sched/core.c:3434
> >  schedule_timeout+0x118/0x230 kernel/time/timer.c:1793
> >  rcu_gp_kthread+0x9e5/0x1930 kernel/rcu/tree.c:2314
> >  kthread+0x33c/0x400

Re: INFO: rcu detected stall in memcpy

2018-01-04 Thread Takashi Iwai 
On Thu, 04 Jan 2018 13:08:45 +0100,
Dmitry Vyukov wrote:
> 
> On Thu, Jan 4, 2018 at 1:03 PM, syzbot
>  wrote:
> > Hello,
> >
> > syzkaller hit the following crash on
> > 30a7acd573899fd8b8ac39236eff6468b195ac7d
> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> > compiler: gcc (GCC) 7.1.1 20170620
> > .config is attached
> > Raw console output is attached.
> > Unfortunately, I don't have any reproducer for this bug yet.
> >
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+387f48da65cb522ab...@syzkaller.appspotmail.com
> > It will help syzbot understand when the bug is fixed. See footer for
> > details.
> > If you forward the report, please keep this part and the footer.
> 
> This looks ALSA-related. +ALSA maintainers.

Not sure exactly what triggers it.  It's the simple memcpy(), and I
don't know where RCU is involved in that code path.

BTW, other two suspicious RCU usage reports are actually stopped at
the second WARN_ON() after the RCU message, and the second WARN_ON()
is independent from RCU; it's the known spurious WARN_ON() and was
already removed in the sound git tree.


thanks,

Takashi

> > INFO: rcu_sched detected stalls on CPUs/tasks:
> > (detected by 0, t=125002 jiffies, g=15654, c=15653, q=133)
> > All QSes seen, last rcu_sched kthread activity 125002
> > (4294863411-4294738409), jiffies_till_next_fqs=3, root ->qsmask 0x0
> > syz-executor1   R  running task24936 11943   3739 0x000c
> > Call Trace:
> >  
> >  sched_show_task+0x4a3/0x5e0 kernel/sched/core.c:5198
> >  print_other_cpu_stall+0x996/0x1090 kernel/rcu/tree.c:1564
> >  check_cpu_stall.isra.61+0x6e6/0x15b0 kernel/rcu/tree.c:1682
> >  __rcu_pending kernel/rcu/tree.c:3440 [inline]
> >  rcu_pending kernel/rcu/tree.c:3502 [inline]
> >  rcu_check_callbacks+0x256/0xd00 kernel/rcu/tree.c:2842
> >  update_process_times+0x30/0x60 kernel/time/timer.c:1628
> >  tick_sched_handle+0x85/0x160 kernel/time/tick-sched.c:162
> >  tick_sched_timer+0x42/0x120 kernel/time/tick-sched.c:1194
> >  __run_hrtimer kernel/time/hrtimer.c:1211 [inline]
> >  __hrtimer_run_queues+0x358/0xe20 kernel/time/hrtimer.c:1275
> >  hrtimer_interrupt+0x1c2/0x5e0 kernel/time/hrtimer.c:1309
> >  local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1025 [inline]
> >  smp_apic_timer_interrupt+0x14a/0x700 arch/x86/kernel/apic/apic.c:1050
> >  apic_timer_interrupt+0xa9/0xb0 arch/x86/entry/entry_64.S:920
> >  
> > RIP: 0010:kasan_mem_to_shadow include/linux/kasan.h:30 [inline]
> > RIP: 0010:memory_is_poisoned_n mm/kasan/kasan.c:210 [inline]
> > RIP: 0010:memory_is_poisoned mm/kasan/kasan.c:241 [inline]
> > RIP: 0010:check_memory_region_inline mm/kasan/kasan.c:257 [inline]
> > RIP: 0010:check_memory_region+0x38/0x190 mm/kasan/kasan.c:267
> > RSP: :8801bd2ff868 EFLAGS: 0212 ORIG_RAX: ff11
> > RAX: 7fff RBX: c9000160020b RCX: 841fceaf
> > RDX: 0001 RSI: 0002 RDI: c9000160020a
> > RBP: 8801bd2ff878 R08: c9000160020a R09: dc00
> > R10: 0001 R11: ed0037a5ff2e R12: c9000160020a
> > R13: 8801bd2ff970 R14: dc00 R15: c9000160020a
> >  memcpy+0x37/0x50 mm/kasan/kasan.c:303
> >  memcpy include/linux/string.h:344 [inline]
> >  cvt_s16_to_native sound/core/oss/mulaw.c:164 [inline]
> >  mulaw_decode+0x52f/0x770 sound/core/oss/mulaw.c:195
> >  mulaw_transfer+0x222/0x270 sound/core/oss/mulaw.c:273
> >  snd_pcm_plug_write_transfer+0x22d/0x420 sound/core/oss/pcm_plugin.c:611
> >  snd_pcm_oss_write2+0x260/0x420 sound/core/oss/pcm_oss.c:1311
> >  snd_pcm_oss_write1 sound/core/oss/pcm_oss.c:1372 [inline]
> >  snd_pcm_oss_write+0x5fe/0x830 sound/core/oss/pcm_oss.c:2646
> >  __vfs_write+0xef/0x970 fs/read_write.c:480
> >  vfs_write+0x189/0x510 fs/read_write.c:544
> >  SYSC_write fs/read_write.c:589 [inline]
> >  SyS_write+0xef/0x220 fs/read_write.c:581
> >  entry_SYSCALL_64_fastpath+0x23/0x9a
> > RIP: 0033:0x452ac9
> > RSP: 002b:7fa354a13c58 EFLAGS: 0212 ORIG_RAX: 0001
> > RAX: ffda RBX: cccd RCX: 00452ac9
> > RDX: feb2 RSI: 20083fc6 RDI: 0014
> > RBP: 05b5 R08:  R09: 
> > R10:  R11: 0212 R12: 006f6998
> > R13:  R14: 7fa354a146d4 R15: 
> > rcu_sched kthread starved for 125002 jiffies! g15654 c15653 f0x2
> > RCU_GP_WAIT_FQS(3) ->state=0x0 ->cpu=0
> > rcu_sched   R  running task23456 8  2 0x8000
> > Call Trace:
> >  context_switch kernel/sched/core.c:2799 [inline]
> >  __schedule+0x8eb/0x2060 kernel/sched/core.c:3375
> >  schedule+0xf5/0x430 kernel/sched/core.c:3434
> >  schedule_timeout+0x118/0x230 kernel/time/timer.c:1793
> >  rcu_gp_kthread+0x9e5/0x1930 kernel/rcu/tree.c:2314
> >  kthread+0x33c/0x400 kernel/kthread.c:238
> >  ret_from_fork+0x24/0x30

Re: INFO: rcu detected stall in memcpy

2018-01-04 Thread Dmitry Vyukov 
On Thu, Jan 4, 2018 at 1:03 PM, syzbot
 wrote:
> Hello,
>
> syzkaller hit the following crash on
> 30a7acd573899fd8b8ac39236eff6468b195ac7d
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> Unfortunately, I don't have any reproducer for this bug yet.
>
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+387f48da65cb522ab...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.

This looks ALSA-related. +ALSA maintainers.


> INFO: rcu_sched detected stalls on CPUs/tasks:
> (detected by 0, t=125002 jiffies, g=15654, c=15653, q=133)
> All QSes seen, last rcu_sched kthread activity 125002
> (4294863411-4294738409), jiffies_till_next_fqs=3, root ->qsmask 0x0
> syz-executor1   R  running task24936 11943   3739 0x000c
> Call Trace:
>  
>  sched_show_task+0x4a3/0x5e0 kernel/sched/core.c:5198
>  print_other_cpu_stall+0x996/0x1090 kernel/rcu/tree.c:1564
>  check_cpu_stall.isra.61+0x6e6/0x15b0 kernel/rcu/tree.c:1682
>  __rcu_pending kernel/rcu/tree.c:3440 [inline]
>  rcu_pending kernel/rcu/tree.c:3502 [inline]
>  rcu_check_callbacks+0x256/0xd00 kernel/rcu/tree.c:2842
>  update_process_times+0x30/0x60 kernel/time/timer.c:1628
>  tick_sched_handle+0x85/0x160 kernel/time/tick-sched.c:162
>  tick_sched_timer+0x42/0x120 kernel/time/tick-sched.c:1194
>  __run_hrtimer kernel/time/hrtimer.c:1211 [inline]
>  __hrtimer_run_queues+0x358/0xe20 kernel/time/hrtimer.c:1275
>  hrtimer_interrupt+0x1c2/0x5e0 kernel/time/hrtimer.c:1309
>  local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1025 [inline]
>  smp_apic_timer_interrupt+0x14a/0x700 arch/x86/kernel/apic/apic.c:1050
>  apic_timer_interrupt+0xa9/0xb0 arch/x86/entry/entry_64.S:920
>  
> RIP: 0010:kasan_mem_to_shadow include/linux/kasan.h:30 [inline]
> RIP: 0010:memory_is_poisoned_n mm/kasan/kasan.c:210 [inline]
> RIP: 0010:memory_is_poisoned mm/kasan/kasan.c:241 [inline]
> RIP: 0010:check_memory_region_inline mm/kasan/kasan.c:257 [inline]
> RIP: 0010:check_memory_region+0x38/0x190 mm/kasan/kasan.c:267
> RSP: :8801bd2ff868 EFLAGS: 0212 ORIG_RAX: ff11
> RAX: 7fff RBX: c9000160020b RCX: 841fceaf
> RDX: 0001 RSI: 0002 RDI: c9000160020a
> RBP: 8801bd2ff878 R08: c9000160020a R09: dc00
> R10: 0001 R11: ed0037a5ff2e R12: c9000160020a
> R13: 8801bd2ff970 R14: dc00 R15: c9000160020a
>  memcpy+0x37/0x50 mm/kasan/kasan.c:303
>  memcpy include/linux/string.h:344 [inline]
>  cvt_s16_to_native sound/core/oss/mulaw.c:164 [inline]
>  mulaw_decode+0x52f/0x770 sound/core/oss/mulaw.c:195
>  mulaw_transfer+0x222/0x270 sound/core/oss/mulaw.c:273
>  snd_pcm_plug_write_transfer+0x22d/0x420 sound/core/oss/pcm_plugin.c:611
>  snd_pcm_oss_write2+0x260/0x420 sound/core/oss/pcm_oss.c:1311
>  snd_pcm_oss_write1 sound/core/oss/pcm_oss.c:1372 [inline]
>  snd_pcm_oss_write+0x5fe/0x830 sound/core/oss/pcm_oss.c:2646
>  __vfs_write+0xef/0x970 fs/read_write.c:480
>  vfs_write+0x189/0x510 fs/read_write.c:544
>  SYSC_write fs/read_write.c:589 [inline]
>  SyS_write+0xef/0x220 fs/read_write.c:581
>  entry_SYSCALL_64_fastpath+0x23/0x9a
> RIP: 0033:0x452ac9
> RSP: 002b:7fa354a13c58 EFLAGS: 0212 ORIG_RAX: 0001
> RAX: ffda RBX: cccd RCX: 00452ac9
> RDX: feb2 RSI: 20083fc6 RDI: 0014
> RBP: 05b5 R08:  R09: 
> R10:  R11: 0212 R12: 006f6998
> R13:  R14: 7fa354a146d4 R15: 
> rcu_sched kthread starved for 125002 jiffies! g15654 c15653 f0x2
> RCU_GP_WAIT_FQS(3) ->state=0x0 ->cpu=0
> rcu_sched   R  running task23456 8  2 0x8000
> Call Trace:
>  context_switch kernel/sched/core.c:2799 [inline]
>  __schedule+0x8eb/0x2060 kernel/sched/core.c:3375
>  schedule+0xf5/0x430 kernel/sched/core.c:3434
>  schedule_timeout+0x118/0x230 kernel/time/timer.c:1793
>  rcu_gp_kthread+0x9e5/0x1930 kernel/rcu/tree.c:2314
>  kthread+0x33c/0x400 kernel/kthread.c:238
>  ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:524
>
>
> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to syzkal...@googlegroups.com.
>
> syzbot will keep track of this bug report.
> If you forgot to add the Reported-by tag, once the fix for this bug is
> merged
> into any tree, please reply to this email with:
> #syz fix: exact-commit-title
> To mark this as a duplicate of another syzbot report, please reply with:
> #syz dup: exact-subject-of-another-report
> If it's a one-off invalid bug report,

Re: INFO: rcu detected stall in memcpy

2018-01-04 Thread Dmitry Vyukov 
On Thu, Jan 4, 2018 at 1:03 PM, syzbot
 wrote:
> Hello,
>
> syzkaller hit the following crash on
> 30a7acd573899fd8b8ac39236eff6468b195ac7d
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> Unfortunately, I don't have any reproducer for this bug yet.
>
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+387f48da65cb522ab...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.

This looks ALSA-related. +ALSA maintainers.


> INFO: rcu_sched detected stalls on CPUs/tasks:
> (detected by 0, t=125002 jiffies, g=15654, c=15653, q=133)
> All QSes seen, last rcu_sched kthread activity 125002
> (4294863411-4294738409), jiffies_till_next_fqs=3, root ->qsmask 0x0
> syz-executor1   R  running task24936 11943   3739 0x000c
> Call Trace:
>  
>  sched_show_task+0x4a3/0x5e0 kernel/sched/core.c:5198
>  print_other_cpu_stall+0x996/0x1090 kernel/rcu/tree.c:1564
>  check_cpu_stall.isra.61+0x6e6/0x15b0 kernel/rcu/tree.c:1682
>  __rcu_pending kernel/rcu/tree.c:3440 [inline]
>  rcu_pending kernel/rcu/tree.c:3502 [inline]
>  rcu_check_callbacks+0x256/0xd00 kernel/rcu/tree.c:2842
>  update_process_times+0x30/0x60 kernel/time/timer.c:1628
>  tick_sched_handle+0x85/0x160 kernel/time/tick-sched.c:162
>  tick_sched_timer+0x42/0x120 kernel/time/tick-sched.c:1194
>  __run_hrtimer kernel/time/hrtimer.c:1211 [inline]
>  __hrtimer_run_queues+0x358/0xe20 kernel/time/hrtimer.c:1275
>  hrtimer_interrupt+0x1c2/0x5e0 kernel/time/hrtimer.c:1309
>  local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1025 [inline]
>  smp_apic_timer_interrupt+0x14a/0x700 arch/x86/kernel/apic/apic.c:1050
>  apic_timer_interrupt+0xa9/0xb0 arch/x86/entry/entry_64.S:920
>  
> RIP: 0010:kasan_mem_to_shadow include/linux/kasan.h:30 [inline]
> RIP: 0010:memory_is_poisoned_n mm/kasan/kasan.c:210 [inline]
> RIP: 0010:memory_is_poisoned mm/kasan/kasan.c:241 [inline]
> RIP: 0010:check_memory_region_inline mm/kasan/kasan.c:257 [inline]
> RIP: 0010:check_memory_region+0x38/0x190 mm/kasan/kasan.c:267
> RSP: :8801bd2ff868 EFLAGS: 0212 ORIG_RAX: ff11
> RAX: 7fff RBX: c9000160020b RCX: 841fceaf
> RDX: 0001 RSI: 0002 RDI: c9000160020a
> RBP: 8801bd2ff878 R08: c9000160020a R09: dc00
> R10: 0001 R11: ed0037a5ff2e R12: c9000160020a
> R13: 8801bd2ff970 R14: dc00 R15: c9000160020a
>  memcpy+0x37/0x50 mm/kasan/kasan.c:303
>  memcpy include/linux/string.h:344 [inline]
>  cvt_s16_to_native sound/core/oss/mulaw.c:164 [inline]
>  mulaw_decode+0x52f/0x770 sound/core/oss/mulaw.c:195
>  mulaw_transfer+0x222/0x270 sound/core/oss/mulaw.c:273
>  snd_pcm_plug_write_transfer+0x22d/0x420 sound/core/oss/pcm_plugin.c:611
>  snd_pcm_oss_write2+0x260/0x420 sound/core/oss/pcm_oss.c:1311
>  snd_pcm_oss_write1 sound/core/oss/pcm_oss.c:1372 [inline]
>  snd_pcm_oss_write+0x5fe/0x830 sound/core/oss/pcm_oss.c:2646
>  __vfs_write+0xef/0x970 fs/read_write.c:480
>  vfs_write+0x189/0x510 fs/read_write.c:544
>  SYSC_write fs/read_write.c:589 [inline]
>  SyS_write+0xef/0x220 fs/read_write.c:581
>  entry_SYSCALL_64_fastpath+0x23/0x9a
> RIP: 0033:0x452ac9
> RSP: 002b:7fa354a13c58 EFLAGS: 0212 ORIG_RAX: 0001
> RAX: ffda RBX: cccd RCX: 00452ac9
> RDX: feb2 RSI: 20083fc6 RDI: 0014
> RBP: 05b5 R08:  R09: 
> R10:  R11: 0212 R12: 006f6998
> R13:  R14: 7fa354a146d4 R15: 
> rcu_sched kthread starved for 125002 jiffies! g15654 c15653 f0x2
> RCU_GP_WAIT_FQS(3) ->state=0x0 ->cpu=0
> rcu_sched   R  running task23456 8  2 0x8000
> Call Trace:
>  context_switch kernel/sched/core.c:2799 [inline]
>  __schedule+0x8eb/0x2060 kernel/sched/core.c:3375
>  schedule+0xf5/0x430 kernel/sched/core.c:3434
>  schedule_timeout+0x118/0x230 kernel/time/timer.c:1793
>  rcu_gp_kthread+0x9e5/0x1930 kernel/rcu/tree.c:2314
>  kthread+0x33c/0x400 kernel/kthread.c:238
>  ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:524
>
>
> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to syzkal...@googlegroups.com.
>
> syzbot will keep track of this bug report.
> If you forgot to add the Reported-by tag, once the fix for this bug is
> merged
> into any tree, please reply to this email with:
> #syz fix: exact-commit-title
> To mark this as a duplicate of another syzbot report, please reply with:
> #syz dup: exact-subject-of-another-report
> If it's a one-off invalid bug report, please reply with:
> #syz invalid
> Note: if the crash