* syzkaller reproducers @ 2019-10-08 11:46 dvyukov 2019-10-08 12:16 ` Dmitry Vyukov ` (2 more replies) 0 siblings, 3 replies; 33+ messages in thread From: dvyukov @ 2019-10-08 11:46 UTC (permalink / raw) To: Shuah Khan, open list:KERNEL SELFTEST FRAMEWORK, automated-testing, kernelci Cc: syzkaller Hi Shuah, We discussed collecting and uploading all syzkaller reproducers somewhere. You wanted to see how they look. I've uploaded all current reproducers here: https://github.com/dvyukov/syzkaller-repros Minimalistic build/run scripts are included. +some testing mailing lists too as this can be used as a test suite If you have any potential uses for this, you are welcome to use it. But then we probably need to find some more official and shared place for them than my private github. The test programs can also be bulk updated if necessary, because all of this is auto-generated. Thanks ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: syzkaller reproducers 2019-10-08 11:46 syzkaller reproducers dvyukov @ 2019-10-08 12:16 ` Dmitry Vyukov 2019-10-08 15:00 ` shuah 2019-10-08 16:35 ` George Kennedy 2019-10-08 12:37 ` [Automated-testing] " Richard Palethorpe 2019-10-10 14:27 ` Cyril Hrubis 2 siblings, 2 replies; 33+ messages in thread From: Dmitry Vyukov @ 2019-10-08 12:16 UTC (permalink / raw) To: Shuah Khan, open list:KERNEL SELFTEST FRAMEWORK, automated-testing, kernelci, George Kennedy, Dhaval Giani, Konrad Rzeszutek Wilk, Boris Ostrovsky, Jan Setje-Eilers Cc: syzkaller On Tue, Oct 8, 2019 at 1:46 PM Dmitry Vyukov <dvyukov@google.com> wrote: > > Hi Shuah, > > We discussed collecting and uploading all syzkaller reproducers > somewhere. You wanted to see how they look. I've uploaded all current > reproducers here: > https://github.com/dvyukov/syzkaller-repros > Minimalistic build/run scripts are included. > +some testing mailing lists too as this can be used as a test suite > If you have any potential uses for this, you are welcome to use it. > But then we probably need to find some more official and shared place > for them than my private github. > The test programs can also be bulk updated if necessary, because all > of this is auto-generated. > > Thanks +more people who expressed interest in the test suite before ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: syzkaller reproducers 2019-10-08 12:16 ` Dmitry Vyukov @ 2019-10-08 15:00 ` shuah 2019-10-11 17:38 ` shuah 2019-10-08 16:35 ` George Kennedy 1 sibling, 1 reply; 33+ messages in thread From: shuah @ 2019-10-08 15:00 UTC (permalink / raw) To: Dmitry Vyukov, open list:KERNEL SELFTEST FRAMEWORK, automated-testing, kernelci, George Kennedy, Dhaval Giani, Konrad Rzeszutek Wilk, Boris Ostrovsky, Jan Setje-Eilers Cc: syzkaller, shuah On 10/8/19 6:16 AM, Dmitry Vyukov wrote: > On Tue, Oct 8, 2019 at 1:46 PM Dmitry Vyukov <dvyukov@google.com> wrote: >> >> Hi Shuah, >> >> We discussed collecting and uploading all syzkaller reproducers >> somewhere. You wanted to see how they look. I've uploaded all current >> reproducers here: >> https://github.com/dvyukov/syzkaller-repros >> Minimalistic build/run scripts are included. >> +some testing mailing lists too as this can be used as a test suite >> If you have any potential uses for this, you are welcome to use it. >> But then we probably need to find some more official and shared place >> for them than my private github. >> The test programs can also be bulk updated if necessary, because all >> of this is auto-generated. >> >> Thanks > > +more people who expressed interest in the test suite before > Thanks for putting this together. I am going to create a repo on kernel.org t host these and pull your private git content in. I will work on it this week and set things up. thanks, -- Shuah ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: syzkaller reproducers 2019-10-08 15:00 ` shuah @ 2019-10-11 17:38 ` shuah 2019-10-11 18:02 ` [Automated-testing] " Cyril Hrubis 0 siblings, 1 reply; 33+ messages in thread From: shuah @ 2019-10-11 17:38 UTC (permalink / raw) To: Dmitry Vyukov, open list:KERNEL SELFTEST FRAMEWORK, automated-testing, kernelci, George Kennedy, Dhaval Giani, Konrad Rzeszutek Wilk, Boris Ostrovsky, Jan Setje-Eilers Cc: syzkaller, shuah On 10/8/19 9:00 AM, shuah wrote: > On 10/8/19 6:16 AM, Dmitry Vyukov wrote: >> On Tue, Oct 8, 2019 at 1:46 PM Dmitry Vyukov <dvyukov@google.com> wrote: >>> >>> Hi Shuah, >>> >>> We discussed collecting and uploading all syzkaller reproducers >>> somewhere. You wanted to see how they look. I've uploaded all current >>> reproducers here: >>> https://github.com/dvyukov/syzkaller-repros >>> Minimalistic build/run scripts are included. >>> +some testing mailing lists too as this can be used as a test suite >>> If you have any potential uses for this, you are welcome to use it. >>> But then we probably need to find some more official and shared place >>> for them than my private github. >>> The test programs can also be bulk updated if necessary, because all >>> of this is auto-generated. >>> >>> Thanks >> >> +more people who expressed interest in the test suite before >> > > Thanks for putting this together. I am going to create a repo on > kernel.org t host these and pull your private git content in. > > I will work on it this week and set things up. > Playing with the git getting ready to host it on kernel.org git repo. Build worked fine and I can't get the run.sh to work. I expected it to run what is in syzkaller-repros/bin It doesn't seem to do that. Looks like it wants to build. Here is what I see. What am I doing wrong? I did a build which worked. There are some errors due to sys/cdefs.h missing. ++ for f in * +++ pwd ++ bin=/mnt/data/lkml/syzkaller-repros/bin +++ mktemp -d ++ dir=/tmp/tmp.S8CjM8muRj ++ cd /tmp/tmp.S8CjM8muRj ++ timeout -s KILL 3 /mnt/data/lkml/syzkaller-repros/bin timeout: failed to run command ‘/mnt/data/lkml/syzkaller-repros/bin’: Permission denied ++ rm -rf /tmp/tmp.S8CjM8muRj ++ for f in * +++ pwd ++ bin=/mnt/data/lkml/syzkaller-repros/build.sh +++ mktemp -d ++ dir=/tmp/tmp.zAVygWdpkt ++ cd /tmp/tmp.zAVygWdpkt ++ timeout -s KILL 3 /mnt/data/lkml/syzkaller-repros/build.sh linux/*.c grep: linux/*.c: No such file or directory gcc: error: linux/*.c: No such file or directory gcc: fatal error: no input files compilation terminated. ++ rm -rf /tmp/tmp.zAVygWdpkt ++ for f in * +++ pwd ++ bin=/mnt/data/lkml/syzkaller-repros/LICENSE +++ mktemp -d ++ dir=/tmp/tmp.hhcvgOc8RA ++ cd /tmp/tmp.hhcvgOc8RA ++ timeout -s KILL 3 /mnt/data/lkml/syzkaller-repros/LICENSE timeout: failed to run command ‘/mnt/data/lkml/syzkaller-repros/LICENSE’: Permission denied ++ rm -rf /tmp/tmp.hhcvgOc8RA ++ for f in * +++ pwd ++ bin=/mnt/data/lkml/syzkaller-repros/linux +++ mktemp -d ++ dir=/tmp/tmp.sM5UO7BHRB ++ cd /tmp/tmp.sM5UO7BHRB ++ timeout -s KILL 3 /mnt/data/lkml/syzkaller-repros/linux timeout: failed to run command ‘/mnt/data/lkml/syzkaller-repros/linux’: Permission denied ++ rm -rf /tmp/tmp.sM5UO7BHRB ++ for f in * +++ pwd ++ bin=/mnt/data/lkml/syzkaller-repros/README.md +++ mktemp -d ++ dir=/tmp/tmp.4Kkrs6iLP5 ++ cd /tmp/tmp.4Kkrs6iLP5 ++ timeout -s KILL 3 /mnt/data/lkml/syzkaller-repros/README.md timeout: failed to run command ‘/mnt/data/lkml/syzkaller-repros/README.md’: Permission denied ++ rm -rf /tmp/tmp.4Kkrs6iLP5 ++ for f in * +++ pwd ++ bin=/mnt/data/lkml/syzkaller-repros/run.sh +++ mktemp -d ++ dir=/tmp/tmp.YFx5WEOvJn ++ cd /tmp/tmp.YFx5WEOvJn ++ timeout -s KILL 3 /mnt/data/lkml/syzkaller-repros/run.sh + pwd + bin=/tmp/tmp.YFx5WEOvJn/* + mktemp -d + dir=/tmp/tmp.qD4i4g9qYR + cd /tmp/tmp.qD4i4g9qYR + timeout -s KILL 3 /tmp/tmp.YFx5WEOvJn/* timeout: failed to run command ‘/tmp/tmp.YFx5WEOvJn/*’: No such file or directory + rm -rf /tmp/tmp.qD4i4g9qYR ++ rm -rf /tmp/tmp.YFx5WEOvJn thanks, -- Shuah ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Automated-testing] syzkaller reproducers 2019-10-11 17:38 ` shuah @ 2019-10-11 18:02 ` Cyril Hrubis 2019-10-11 19:11 ` shuah 0 siblings, 1 reply; 33+ messages in thread From: Cyril Hrubis @ 2019-10-11 18:02 UTC (permalink / raw) To: shuah Cc: Dmitry Vyukov, open list:KERNEL SELFTEST FRAMEWORK, automated-testing, kernelci, George Kennedy, Dhaval Giani, Konrad Rzeszutek Wilk, Boris Ostrovsky, Jan Setje-Eilers, syzkaller Hi! > Playing with the git getting ready to host it on kernel.org git repo. > Build worked fine and I can't get the run.sh to work. > > I expected it to run what is in > > syzkaller-repros/bin > > It doesn't seem to do that. Looks like it wants to build. Here is what > I see. What am I doing wrong? You are suposed to run the run.sh script in the bin directory. > I did a build which worked. There are some errors due to sys/cdefs.h > missing. That is because you are missing 32bit gcc and devel libs. -- Cyril Hrubis chrubis@suse.cz ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Automated-testing] syzkaller reproducers 2019-10-11 18:02 ` [Automated-testing] " Cyril Hrubis @ 2019-10-11 19:11 ` shuah 2019-10-14 8:54 ` Cyril Hrubis 0 siblings, 1 reply; 33+ messages in thread From: shuah @ 2019-10-11 19:11 UTC (permalink / raw) To: Cyril Hrubis Cc: Dmitry Vyukov, open list:KERNEL SELFTEST FRAMEWORK, automated-testing, kernelci, George Kennedy, Dhaval Giani, Konrad Rzeszutek Wilk, Boris Ostrovsky, Jan Setje-Eilers, syzkaller, shuah On 10/11/19 12:02 PM, Cyril Hrubis wrote: > Hi! >> Playing with the git getting ready to host it on kernel.org git repo. >> Build worked fine and I can't get the run.sh to work. >> >> I expected it to run what is in >> >> syzkaller-repros/bin >> >> It doesn't seem to do that. Looks like it wants to build. Here is what >> I see. What am I doing wrong? > > You are suposed to run the run.sh script in the bin directory. Yeah that does work. Would be helpful to have usage instructions instead of failing. :) > >> I did a build which worked. There are some errors due to sys/cdefs.h >> missing. > > That is because you are missing 32bit gcc and devel libs. > Yeah. I didn't think about that. thanks, -- Shuah ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Automated-testing] syzkaller reproducers 2019-10-11 19:11 ` shuah @ 2019-10-14 8:54 ` Cyril Hrubis 2019-10-14 11:19 ` Dmitry Vyukov 0 siblings, 1 reply; 33+ messages in thread From: Cyril Hrubis @ 2019-10-14 8:54 UTC (permalink / raw) To: shuah Cc: Dmitry Vyukov, open list:KERNEL SELFTEST FRAMEWORK, automated-testing, kernelci, George Kennedy, Dhaval Giani, Konrad Rzeszutek Wilk, Boris Ostrovsky, Jan Setje-Eilers, syzkaller Hi! > > You are suposed to run the run.sh script in the bin directory. > > Yeah that does work. > > Would be helpful to have usage instructions instead of failing. :) I do not think that these scripts are ever supposed to be the used in production testing, you need much more than this to produce results reliably. I would expect that they are supposed to be a form of very minimal documentation. -- Cyril Hrubis chrubis@suse.cz ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Automated-testing] syzkaller reproducers 2019-10-14 8:54 ` Cyril Hrubis @ 2019-10-14 11:19 ` Dmitry Vyukov 2019-10-15 13:04 ` George Kennedy 0 siblings, 1 reply; 33+ messages in thread From: Dmitry Vyukov @ 2019-10-14 11:19 UTC (permalink / raw) To: Cyril Hrubis Cc: shuah, open list:KERNEL SELFTEST FRAMEWORK, automated-testing, kernelci, George Kennedy, Dhaval Giani, Konrad Rzeszutek Wilk, Boris Ostrovsky, Jan Setje-Eilers, syzkaller On Mon, Oct 14, 2019 at 10:54 AM Cyril Hrubis <chrubis@suse.cz> wrote: > > Hi! > > > You are suposed to run the run.sh script in the bin directory. > > > > Yeah that does work. > > > > Would be helpful to have usage instructions instead of failing. :) > > I do not think that these scripts are ever supposed to be the used in > production testing, you need much more than this to produce results > reliably. I would expect that they are supposed to be a form of very > minimal documentation. Yes, I just added them as quick hints: some repros are 32-bits; each needs a new dir; some external timeout is needed for each test. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Automated-testing] syzkaller reproducers 2019-10-14 11:19 ` Dmitry Vyukov @ 2019-10-15 13:04 ` George Kennedy 2019-10-15 13:44 ` Cyril Hrubis 2019-12-06 20:06 ` George Kennedy 0 siblings, 2 replies; 33+ messages in thread From: George Kennedy @ 2019-10-15 13:04 UTC (permalink / raw) To: Dmitry Vyukov, Cyril Hrubis Cc: shuah, open list:KERNEL SELFTEST FRAMEWORK, automated-testing, kernelci, Dhaval Giani, Konrad Rzeszutek Wilk, Boris Ostrovsky, Jan Setje-Eilers, syzkaller On 10/14/2019 7:19 AM, Dmitry Vyukov wrote: > On Mon, Oct 14, 2019 at 10:54 AM Cyril Hrubis <chrubis@suse.cz> wrote: >> Hi! >>>> You are suposed to run the run.sh script in the bin directory. >>> Yeah that does work. >>> >>> Would be helpful to have usage instructions instead of failing. :) >> I do not think that these scripts are ever supposed to be the used in >> production testing, you need much more than this to produce results >> reliably. I would expect that they are supposed to be a form of very >> minimal documentation. > Yes, I just added them as quick hints: some repros are 32-bits; each > needs a new dir; some external timeout is needed for each test. Thank you again for the collection of repro C programs! Hitting a lot more crashes with the collection of repro C programs than in all the hours of running Syzkaller. Wonder why? Any idea? This is with the same kernel and VM that Syzkaller is run on. George ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Automated-testing] syzkaller reproducers 2019-10-15 13:04 ` George Kennedy @ 2019-10-15 13:44 ` Cyril Hrubis 2019-10-23 13:24 ` Dmitry Vyukov 2019-12-06 20:06 ` George Kennedy 1 sibling, 1 reply; 33+ messages in thread From: Cyril Hrubis @ 2019-10-15 13:44 UTC (permalink / raw) To: George Kennedy Cc: Dmitry Vyukov, shuah, open list:KERNEL SELFTEST FRAMEWORK, automated-testing, kernelci, Dhaval Giani, Konrad Rzeszutek Wilk, Boris Ostrovsky, Jan Setje-Eilers, syzkaller Hi! > >> I do not think that these scripts are ever supposed to be the used in > >> production testing, you need much more than this to produce results > >> reliably. I would expect that they are supposed to be a form of very > >> minimal documentation. > > Yes, I just added them as quick hints: some repros are 32-bits; each > > needs a new dir; some external timeout is needed for each test. > Thank you again for the collection of repro C programs! > > Hitting a lot more crashes with the collection of repro C programs than > in all the hours of running Syzkaller. Wonder why? Any idea? This is > with the same kernel and VM that Syzkaller is run on. I would guess that these reproducers are product of countless hours of fuzzing, so it's about to be expected... -- Cyril Hrubis chrubis@suse.cz ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Automated-testing] syzkaller reproducers 2019-10-15 13:44 ` Cyril Hrubis @ 2019-10-23 13:24 ` Dmitry Vyukov 0 siblings, 0 replies; 33+ messages in thread From: Dmitry Vyukov @ 2019-10-23 13:24 UTC (permalink / raw) To: Cyril Hrubis Cc: George Kennedy, shuah, open list:KERNEL SELFTEST FRAMEWORK, automated-testing, kernelci, Dhaval Giani, Konrad Rzeszutek Wilk, Boris Ostrovsky, Jan Setje-Eilers, syzkaller On Tue, Oct 15, 2019 at 3:44 PM Cyril Hrubis <chrubis@suse.cz> wrote: > > Hi! > > >> I do not think that these scripts are ever supposed to be the used in > > >> production testing, you need much more than this to produce results > > >> reliably. I would expect that they are supposed to be a form of very > > >> minimal documentation. > > > Yes, I just added them as quick hints: some repros are 32-bits; each > > > needs a new dir; some external timeout is needed for each test. > > Thank you again for the collection of repro C programs! > > > > Hitting a lot more crashes with the collection of repro C programs than > > in all the hours of running Syzkaller. Wonder why? Any idea? This is > > with the same kernel and VM that Syzkaller is run on. > > I would guess that these reproducers are product of countless hours of > fuzzing, so it's about to be expected... Probably. Hard to say. If you used KCOV, KCOV_ENABLE_COMPARISONS, KASAN, LOCKDEP, FAULT_INJECTION, all other debugging configs, compat instance and some required image/cmdline features, then the only reason for difference that I see is indeed longer fuzzing time. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Automated-testing] syzkaller reproducers 2019-10-15 13:04 ` George Kennedy 2019-10-15 13:44 ` Cyril Hrubis @ 2019-12-06 20:06 ` George Kennedy 2020-01-27 14:19 ` George Kennedy 1 sibling, 1 reply; 33+ messages in thread From: George Kennedy @ 2019-12-06 20:06 UTC (permalink / raw) To: Dmitry Vyukov, Cyril Hrubis Cc: shuah, open list:KERNEL SELFTEST FRAMEWORK, automated-testing, kernelci, Dhaval Giani, Jan Setje-Eilers, syzkaller Hello Dmitry, Could we get another drop of the Syzkaller C reproducers? Wonder if we could get the drop periodically (i.e. a drop/quarter or a drop to match a major linux release)? Thank you, George ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Automated-testing] syzkaller reproducers 2019-12-06 20:06 ` George Kennedy @ 2020-01-27 14:19 ` George Kennedy 2020-01-27 15:26 ` Dmitry Vyukov 0 siblings, 1 reply; 33+ messages in thread From: George Kennedy @ 2020-01-27 14:19 UTC (permalink / raw) To: Dmitry Vyukov, Cyril Hrubis Cc: shuah, open list:KERNEL SELFTEST FRAMEWORK, automated-testing, kernelci, Dhaval Giani, Jan Setje-Eilers, syzkaller, Dan Carpenter Hi Dmitry, Re-sending this request. Also, how do you track the Upstream branches with Syzkaller? Do you have a version of Syzkaller for each (i.e. 4.14, 4.19, etc)? Thank you, George On 12/6/2019 3:06 PM, George Kennedy wrote: > Hello Dmitry, > > Could we get another drop of the Syzkaller C reproducers? > > Wonder if we could get the drop periodically (i.e. a drop/quarter or a > drop to match a major linux release)? > > Thank you, > George ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Automated-testing] syzkaller reproducers 2020-01-27 14:19 ` George Kennedy @ 2020-01-27 15:26 ` Dmitry Vyukov 2020-01-27 17:06 ` George Kennedy 0 siblings, 1 reply; 33+ messages in thread From: Dmitry Vyukov @ 2020-01-27 15:26 UTC (permalink / raw) To: George Kennedy Cc: Cyril Hrubis, shuah, open list:KERNEL SELFTEST FRAMEWORK, automated-testing, kernelci, Dhaval Giani, Jan Setje-Eilers, syzkaller, Dan Carpenter Hi George, This was still starred in my inbox, but I never got to actually do anything with it. Thanks for pinging me. I thought that the script to extract the repros won't work for some reason and that I will need to fix it first. But turns out it's still working as-is (I wanted to submit some changes that would break it, but I never go to that as well. Good! :)). So here is a new drop in with 692 repros: https://github.com/dvyukov/syzkaller-repros/commit/6a06992209c328a3115c89c020f45b844b103573 Enjoy! Yes, we have separate managers for each version, the entries in the Instances table correspond to syz-manager one-to-one: https://syzkaller.appspot.com/upstream https://syzkaller.appspot.com/linux-4.19 https://syzkaller.appspot.com/android-54 On Mon, Jan 27, 2020 at 3:20 PM George Kennedy <george.kennedy@oracle.com> wrote: > > Hi Dmitry, > > Re-sending this request. > > Also, how do you track the Upstream branches with Syzkaller? Do you have > a version of Syzkaller for each (i.e. 4.14, 4.19, etc)? > > Thank you, > George > > On 12/6/2019 3:06 PM, George Kennedy wrote: > > Hello Dmitry, > > > > Could we get another drop of the Syzkaller C reproducers? > > > > Wonder if we could get the drop periodically (i.e. a drop/quarter or a > > drop to match a major linux release)? > > > > Thank you, > > George > ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Automated-testing] syzkaller reproducers 2020-01-27 15:26 ` Dmitry Vyukov @ 2020-01-27 17:06 ` George Kennedy 2020-03-03 8:45 ` Dmitry Vyukov 0 siblings, 1 reply; 33+ messages in thread From: George Kennedy @ 2020-01-27 17:06 UTC (permalink / raw) To: Dmitry Vyukov Cc: Cyril Hrubis, shuah, open list:KERNEL SELFTEST FRAMEWORK, automated-testing, kernelci, Dhaval Giani, Jan Setje-Eilers, syzkaller, Dan Carpenter On 1/27/2020 10:26 AM, Dmitry Vyukov wrote: > Hi George, > > This was still starred in my inbox, but I never got to actually do > anything with it. Thanks for pinging me. I thought that the script to > extract the repros won't work for some reason and that I will need to > fix it first. But turns out it's still working as-is (I wanted to > submit some changes that would break it, but I never go to that as > well. Good! :)). > > So here is a new drop in with 692 repros: > https://github.com/dvyukov/syzkaller-repros/commit/6a06992209c328a3115c89c020f45b844b103573 > Enjoy! > > Yes, we have separate managers for each version, the entries in the > Instances table correspond to syz-manager one-to-one: > https://syzkaller.appspot.com/upstream > https://syzkaller.appspot.com/linux-4.19 > https://syzkaller.appspot.com/android-54 Thank you Dmitry! George > > > > On Mon, Jan 27, 2020 at 3:20 PM George Kennedy > <george.kennedy@oracle.com> wrote: >> Hi Dmitry, >> >> Re-sending this request. >> >> Also, how do you track the Upstream branches with Syzkaller? Do you have >> a version of Syzkaller for each (i.e. 4.14, 4.19, etc)? >> >> Thank you, >> George >> >> On 12/6/2019 3:06 PM, George Kennedy wrote: >>> Hello Dmitry, >>> >>> Could we get another drop of the Syzkaller C reproducers? >>> >>> Wonder if we could get the drop periodically (i.e. a drop/quarter or a >>> drop to match a major linux release)? >>> >>> Thank you, >>> George ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Automated-testing] syzkaller reproducers 2020-01-27 17:06 ` George Kennedy @ 2020-03-03 8:45 ` Dmitry Vyukov 2020-03-03 13:46 ` George Kennedy 2020-03-13 15:59 ` shuah 0 siblings, 2 replies; 33+ messages in thread From: Dmitry Vyukov @ 2020-03-03 8:45 UTC (permalink / raw) To: George Kennedy, shuah Cc: Cyril Hrubis, open list:KERNEL SELFTEST FRAMEWORK, automated-testing, kernelci, Dhaval Giani, Jan Setje-Eilers, syzkaller, Dan Carpenter Shauh, We've added more reproducers to: https://github.com/dvyukov/syzkaller-repros/tree/master/linux It makes sense to pull in them to the kernel-arts repo. Not sure what's the most convenient way for you since it's not exactly a traditional "patch"? Perhaps you just copy linux/*.c files and commit? George, another throw in of 446 repros ;) On Mon, Jan 27, 2020 at 6:08 PM George Kennedy <george.kennedy@oracle.com> wrote: > > Hi George, > > > > This was still starred in my inbox, but I never got to actually do > > anything with it. Thanks for pinging me. I thought that the script to > > extract the repros won't work for some reason and that I will need to > > fix it first. But turns out it's still working as-is (I wanted to > > submit some changes that would break it, but I never go to that as > > well. Good! :)). > > > > So here is a new drop in with 692 repros: > > https://github.com/dvyukov/syzkaller-repros/commit/6a06992209c328a3115c89c020f45b844b103573 > > Enjoy! > > > > Yes, we have separate managers for each version, the entries in the > > Instances table correspond to syz-manager one-to-one: > > https://syzkaller.appspot.com/upstream > > https://syzkaller.appspot.com/linux-4.19 > > https://syzkaller.appspot.com/android-54 > > Thank you Dmitry! > George > > > > > > > > On Mon, Jan 27, 2020 at 3:20 PM George Kennedy > > <george.kennedy@oracle.com> wrote: > >> Hi Dmitry, > >> > >> Re-sending this request. > >> > >> Also, how do you track the Upstream branches with Syzkaller? Do you have > >> a version of Syzkaller for each (i.e. 4.14, 4.19, etc)? > >> > >> Thank you, > >> George > >> > >> On 12/6/2019 3:06 PM, George Kennedy wrote: > >>> Hello Dmitry, > >>> > >>> Could we get another drop of the Syzkaller C reproducers? > >>> > >>> Wonder if we could get the drop periodically (i.e. a drop/quarter or a > >>> drop to match a major linux release)? > >>> > >>> Thank you, > >>> George > ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Automated-testing] syzkaller reproducers 2020-03-03 8:45 ` Dmitry Vyukov @ 2020-03-03 13:46 ` George Kennedy 2020-03-13 15:59 ` shuah 1 sibling, 0 replies; 33+ messages in thread From: George Kennedy @ 2020-03-03 13:46 UTC (permalink / raw) To: Dmitry Vyukov, shuah Cc: Cyril Hrubis, open list:KERNEL SELFTEST FRAMEWORK, automated-testing, kernelci, Dhaval Giani, Jan Setje-Eilers, syzkaller, Dan Carpenter On 3/3/2020 3:45 AM, Dmitry Vyukov wrote: > Shauh, > > We've added more reproducers to: > https://github.com/dvyukov/syzkaller-repros/tree/master/linux > > It makes sense to pull in them to the kernel-arts repo. Not sure > what's the most convenient way for you since it's not exactly a > traditional "patch"? Perhaps you just copy linux/*.c files and commit? > > George, another throw in of 446 repros ;) Thank you Dmitry! George > > > > On Mon, Jan 27, 2020 at 6:08 PM George Kennedy > <george.kennedy@oracle.com> wrote: >>> Hi George, >>> >>> This was still starred in my inbox, but I never got to actually do >>> anything with it. Thanks for pinging me. I thought that the script to >>> extract the repros won't work for some reason and that I will need to >>> fix it first. But turns out it's still working as-is (I wanted to >>> submit some changes that would break it, but I never go to that as >>> well. Good! :)). >>> >>> So here is a new drop in with 692 repros: >>> https://github.com/dvyukov/syzkaller-repros/commit/6a06992209c328a3115c89c020f45b844b103573 >>> Enjoy! >>> >>> Yes, we have separate managers for each version, the entries in the >>> Instances table correspond to syz-manager one-to-one: >>> https://syzkaller.appspot.com/upstream >>> https://syzkaller.appspot.com/linux-4.19 >>> https://syzkaller.appspot.com/android-54 >> Thank you Dmitry! >> George >>> >>> >>> On Mon, Jan 27, 2020 at 3:20 PM George Kennedy >>> <george.kennedy@oracle.com> wrote: >>>> Hi Dmitry, >>>> >>>> Re-sending this request. >>>> >>>> Also, how do you track the Upstream branches with Syzkaller? Do you have >>>> a version of Syzkaller for each (i.e. 4.14, 4.19, etc)? >>>> >>>> Thank you, >>>> George >>>> >>>> On 12/6/2019 3:06 PM, George Kennedy wrote: >>>>> Hello Dmitry, >>>>> >>>>> Could we get another drop of the Syzkaller C reproducers? >>>>> >>>>> Wonder if we could get the drop periodically (i.e. a drop/quarter or a >>>>> drop to match a major linux release)? >>>>> >>>>> Thank you, >>>>> George ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Automated-testing] syzkaller reproducers 2020-03-03 8:45 ` Dmitry Vyukov 2020-03-03 13:46 ` George Kennedy @ 2020-03-13 15:59 ` shuah [not found] ` <cd301033-f152-4eeb-bce3-2d95f39a05fbn@googlegroups.com> 1 sibling, 1 reply; 33+ messages in thread From: shuah @ 2020-03-13 15:59 UTC (permalink / raw) To: Dmitry Vyukov, George Kennedy Cc: Cyril Hrubis, open list:KERNEL SELFTEST FRAMEWORK, automated-testing, kernelci, Dhaval Giani, Jan Setje-Eilers, syzkaller, Dan Carpenter, shuah On 3/3/20 1:45 AM, Dmitry Vyukov wrote: > Shauh, > > We've added more reproducers to: > https://github.com/dvyukov/syzkaller-repros/tree/master/linux > > It makes sense to pull in them to the kernel-arts repo. Not sure > what's the most convenient way for you since it's not exactly a > traditional "patch"? Perhaps you just copy linux/*.c files and commit? > Thanks Dmitry. I will pull these in. I will pull these in. thanks, -- Shuah ^ permalink raw reply [flat|nested] 33+ messages in thread
[parent not found: <cd301033-f152-4eeb-bce3-2d95f39a05fbn@googlegroups.com>]
* Re: [Automated-testing] syzkaller reproducers [not found] ` <cd301033-f152-4eeb-bce3-2d95f39a05fbn@googlegroups.com> @ 2022-05-12 18:05 ` Palash Oswal 2022-05-13 9:29 ` Dmitry Vyukov 0 siblings, 1 reply; 33+ messages in thread From: Palash Oswal @ 2022-05-12 18:05 UTC (permalink / raw) To: syzkaller, Shuah Khan, kernelci, automated-testing, george.kennedy + Shuah, George and mailing lists Google groups did not CC all of the members in the thread for my reply. It would be valuable to get everyone's feedback on this thread. On Sat, May 7, 2022 at 11:34 PM Palash <oswalpalash@gmail.com> wrote: > > Hello all, > > Reviving this old thread. Do we think there's value in automatically publishing a C reproducer(if it exists) whenever syzkaller determines a reported bug is patched and fixed? > This allows us to track these reproducers more diligently and we only have reproducers for the bugs that have been patched. > If this is valuable, then we could think about answering these questions - > 1. Is there a particular way we want to format the reproducers? (Example : SKIP/OK/FAIL/TIMEOUT (if output is possible)) > 2. Where do we want to submit the reproducers to be added to the testing project and what is the process we want to use? > 3. Is it valuable to record the crash report information for the original fuzzer crash when the c reproducer is filed to add context to it; in case developers want to troubleshoot? This could save valuable debugging time. > > Happy to contribute on this change to the upstream fuzzing system. > > Thanks, > Palash > On Friday, March 13, 2020 at 11:59:31 AM UTC-4 shuah wrote: >> >> On 3/3/20 1:45 AM, Dmitry Vyukov wrote: >> > Shauh, >> > >> > We've added more reproducers to: >> > https://github.com/dvyukov/syzkaller-repros/tree/master/linux >> > >> > It makes sense to pull in them to the kernel-arts repo. Not sure >> > what's the most convenient way for you since it's not exactly a >> > traditional "patch"? Perhaps you just copy linux/*.c files and commit? >> > >> >> Thanks Dmitry. I will pull these in. I will pull these in. >> >> thanks, >> -- Shuah > > -- > You received this message because you are subscribed to a topic in the Google Groups "syzkaller" group. > To unsubscribe from this topic, visit https://groups.google.com/d/topic/syzkaller/RQFLqAvdsEc/unsubscribe. > To unsubscribe from this group and all its topics, send an email to syzkaller+unsubscribe@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller/cd301033-f152-4eeb-bce3-2d95f39a05fbn%40googlegroups.com. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Automated-testing] syzkaller reproducers 2022-05-12 18:05 ` Palash Oswal @ 2022-05-13 9:29 ` Dmitry Vyukov 2022-05-13 11:35 ` George Kennedy 0 siblings, 1 reply; 33+ messages in thread From: Dmitry Vyukov @ 2022-05-13 9:29 UTC (permalink / raw) To: kernelci, oswalpalash Cc: syzkaller, Shuah Khan, automated-testing, george.kennedy On Fri, 13 May 2022 at 02:54, Palash Oswal <oswalpalash@gmail.com> wrote: > > + Shuah, George and mailing lists > > Google groups did not CC all of the members in the thread for my > reply. It would be valuable to get everyone's feedback on this thread. > > On Sat, May 7, 2022 at 11:34 PM Palash <oswalpalash@gmail.com> wrote: > > > > Hello all, > > > > Reviving this old thread. Do we think there's value in automatically publishing a C reproducer(if it exists) whenever syzkaller determines a reported bug is patched and fixed? > > This allows us to track these reproducers more diligently and we only have reproducers for the bugs that have been patched. > > If this is valuable, then we could think about answering these questions - > > 1. Is there a particular way we want to format the reproducers? (Example : SKIP/OK/FAIL/TIMEOUT (if output is possible)) > > 2. Where do we want to submit the reproducers to be added to the testing project and what is the process we want to use? > > 3. Is it valuable to record the crash report information for the original fuzzer crash when the c reproducer is filed to add context to it; in case developers want to troubleshoot? This could save valuable debugging time. > > > > Happy to contribute on this change to the upstream fuzzing system. More automation is definitely welcome. I am not sure how widely used is the current base of reproducers. But George keeps asking for updates and I keep failing at doing it in a timely manner. It would be easiest for the syzbot app to upload reproducers to a GCS bucket. But I am not sure what's a good format for this. Everything I can think of is somewhat clumsy. It could upload weekly archives, but then there is an issue of discoverability of new archives (since GCS is HTTP rather than FTP). Not sure if it's feasible to give it an auth token for a github repo to push individual files as we do now. Re format. Bonus points if the system will be able to regenerate and update meta-information. The chances that we will come up with the ultimately right format from day 1 are low. But that may complicate the implementation. > > Thanks, > > Palash > > On Friday, March 13, 2020 at 11:59:31 AM UTC-4 shuah wrote: > >> > >> On 3/3/20 1:45 AM, Dmitry Vyukov wrote: > >> > Shauh, > >> > > >> > We've added more reproducers to: > >> > https://github.com/dvyukov/syzkaller-repros/tree/master/linux > >> > > >> > It makes sense to pull in them to the kernel-arts repo. Not sure > >> > what's the most convenient way for you since it's not exactly a > >> > traditional "patch"? Perhaps you just copy linux/*.c files and commit? > >> > > >> > >> Thanks Dmitry. I will pull these in. I will pull these in. > >> > >> thanks, > >> -- Shuah > > > > -- > > You received this message because you are subscribed to a topic in the Google Groups "syzkaller" group. > > To unsubscribe from this topic, visit https://groups.google.com/d/topic/syzkaller/RQFLqAvdsEc/unsubscribe. > > To unsubscribe from this group and all its topics, send an email to syzkaller+unsubscribe@googlegroups.com. > > To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller/cd301033-f152-4eeb-bce3-2d95f39a05fbn%40googlegroups.com. > > > > > ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Automated-testing] syzkaller reproducers 2022-05-13 9:29 ` Dmitry Vyukov @ 2022-05-13 11:35 ` George Kennedy 2022-05-13 12:16 ` Dmitry Vyukov 0 siblings, 1 reply; 33+ messages in thread From: George Kennedy @ 2022-05-13 11:35 UTC (permalink / raw) To: Dmitry Vyukov, kernelci, oswalpalash Cc: syzkaller, Shuah Khan, automated-testing, Vegard Nossum On 5/13/2022 5:29 AM, Dmitry Vyukov wrote: > On Fri, 13 May 2022 at 02:54, Palash Oswal <oswalpalash@gmail.com> wrote: >> + Shuah, George and mailing lists >> >> Google groups did not CC all of the members in the thread for my >> reply. It would be valuable to get everyone's feedback on this thread. >> >> On Sat, May 7, 2022 at 11:34 PM Palash <oswalpalash@gmail.com> wrote: >>> Hello all, >>> >>> Reviving this old thread. Do we think there's value in automatically publishing a C reproducer(if it exists) whenever syzkaller determines a reported bug is patched and fixed? >>> This allows us to track these reproducers more diligently and we only have reproducers for the bugs that have been patched. >>> If this is valuable, then we could think about answering these questions - >>> 1. Is there a particular way we want to format the reproducers? (Example : SKIP/OK/FAIL/TIMEOUT (if output is possible)) >>> 2. Where do we want to submit the reproducers to be added to the testing project and what is the process we want to use? >>> 3. Is it valuable to record the crash report information for the original fuzzer crash when the c reproducer is filed to add context to it; in case developers want to troubleshoot? This could save valuable debugging time. >>> >>> Happy to contribute on this change to the upstream fuzzing system. > > More automation is definitely welcome. > I am not sure how widely used is the current base of reproducers. But > George keeps asking for updates and I keep failing at doing it in a > timely manner. We run the ~6000 reproducers as a regression test. Test takes ~4 hours. Having the reproducer before there is a patch is valuable to us as we know whether or not our distro branches have the same failure. As a way to reduce test time, some sort of repro classification would be helpful (i.e. open/closed/invalid). For crash troubleshooting info we try to match the crash string with syzbot's crash string. Thank you, George > > It would be easiest for the syzbot app to upload reproducers to a GCS > bucket. But I am not sure what's a good format for this. Everything I > can think of is somewhat clumsy. It could upload weekly archives, but > then there is an issue of discoverability of new archives (since GCS > is HTTP rather than FTP). > > Not sure if it's feasible to give it an auth token for a github repo > to push individual files as we do now. > > Re format. Bonus points if the system will be able to regenerate and > update meta-information. The chances that we will come up with the > ultimately right format from day 1 are low. But that may complicate > the implementation. > > > > >>> Thanks, >>> Palash >>> On Friday, March 13, 2020 at 11:59:31 AM UTC-4 shuah wrote: >>>> On 3/3/20 1:45 AM, Dmitry Vyukov wrote: >>>>> Shauh, >>>>> >>>>> We've added more reproducers to: >>>>> https://github.com/dvyukov/syzkaller-repros/tree/master/linux >>>>> >>>>> It makes sense to pull in them to the kernel-arts repo. Not sure >>>>> what's the most convenient way for you since it's not exactly a >>>>> traditional "patch"? Perhaps you just copy linux/*.c files and commit? >>>>> >>>> Thanks Dmitry. I will pull these in. I will pull these in. >>>> >>>> thanks, >>>> -- Shuah >>> -- >>> You received this message because you are subscribed to a topic in the Google Groups "syzkaller" group. >>> To unsubscribe from this topic, visit https://groups.google.com/d/topic/syzkaller/RQFLqAvdsEc/unsubscribe. >>> To unsubscribe from this group and all its topics, send an email to syzkaller+unsubscribe@googlegroups.com. >>> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller/cd301033-f152-4eeb-bce3-2d95f39a05fbn%40googlegroups.com. >> >> >> >> ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Automated-testing] syzkaller reproducers 2022-05-13 11:35 ` George Kennedy @ 2022-05-13 12:16 ` Dmitry Vyukov 2022-05-16 7:41 ` Dmitry Vyukov 0 siblings, 1 reply; 33+ messages in thread From: Dmitry Vyukov @ 2022-05-13 12:16 UTC (permalink / raw) To: George Kennedy Cc: kernelci, oswalpalash, syzkaller, Shuah Khan, automated-testing, Vegard Nossum On Fri, 13 May 2022 at 13:35, George Kennedy <george.kennedy@oracle.com> wrote: > >> + Shuah, George and mailing lists > >> > >> Google groups did not CC all of the members in the thread for my > >> reply. It would be valuable to get everyone's feedback on this thread. > >> > >> On Sat, May 7, 2022 at 11:34 PM Palash <oswalpalash@gmail.com> wrote: > >>> Hello all, > >>> > >>> Reviving this old thread. Do we think there's value in automatically publishing a C reproducer(if it exists) whenever syzkaller determines a reported bug is patched and fixed? > >>> This allows us to track these reproducers more diligently and we only have reproducers for the bugs that have been patched. > >>> If this is valuable, then we could think about answering these questions - > >>> 1. Is there a particular way we want to format the reproducers? (Example : SKIP/OK/FAIL/TIMEOUT (if output is possible)) > >>> 2. Where do we want to submit the reproducers to be added to the testing project and what is the process we want to use? > >>> 3. Is it valuable to record the crash report information for the original fuzzer crash when the c reproducer is filed to add context to it; in case developers want to troubleshoot? This could save valuable debugging time. > >>> > >>> Happy to contribute on this change to the upstream fuzzing system. > > > > More automation is definitely welcome. > > I am not sure how widely used is the current base of reproducers. But > > George keeps asking for updates and I keep failing at doing it in a > > timely manner. > We run the ~6000 reproducers as a regression test. Test takes ~4 hours. > > Having the reproducer before there is a patch is valuable to us as we > know whether or not our distro branches have the same failure. > > As a way to reduce test time, some sort of repro classification would be > helpful (i.e. open/closed/invalid). > > For crash troubleshooting info we try to match the crash string with > syzbot's crash string. > > Thank you, > George > > > > It would be easiest for the syzbot app to upload reproducers to a GCS > > bucket. But I am not sure what's a good format for this. Everything I > > can think of is somewhat clumsy. It could upload weekly archives, but > > then there is an issue of discoverability of new archives (since GCS > > is HTTP rather than FTP). > > > > Not sure if it's feasible to give it an auth token for a github repo > > to push individual files as we do now. > > > > Re format. Bonus points if the system will be able to regenerate and > > update meta-information. The chances that we will come up with the > > ultimately right format from day 1 are low. But that may complicate > > the implementation. The most feasible for syzbot automation seems to be to push to a public GCS bucket and then users will need to do "gsutil rsync" to download updates. Or another option is to expose a new json API to get reproducers list and then to fetch individual reproducers. Though this will need some custom tooling on the user side to fetch updates. Re exporting status open/closed/invalid and e.g. fixing patch, that would also be more natural to expose via the API since this information changes dynamically. It's also possible to use both. Namely, reproducers are uploaded to the GCS bucket and each repro file contains just some bug ID. Then the bug ID can be used to fetch any additional dynamically changing info via json API. > >>> Thanks, > >>> Palash > >>> On Friday, March 13, 2020 at 11:59:31 AM UTC-4 shuah wrote: > >>>> On 3/3/20 1:45 AM, Dmitry Vyukov wrote: > >>>>> Shauh, > >>>>> > >>>>> We've added more reproducers to: > >>>>> https://github.com/dvyukov/syzkaller-repros/tree/master/linux > >>>>> > >>>>> It makes sense to pull in them to the kernel-arts repo. Not sure > >>>>> what's the most convenient way for you since it's not exactly a > >>>>> traditional "patch"? Perhaps you just copy linux/*.c files and commit? > >>>>> > >>>> Thanks Dmitry. I will pull these in. I will pull these in. > >>>> > >>>> thanks, > >>>> -- Shuah ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Automated-testing] syzkaller reproducers 2022-05-13 12:16 ` Dmitry Vyukov @ 2022-05-16 7:41 ` Dmitry Vyukov 2022-05-16 12:42 ` George Kennedy 2022-05-16 16:51 ` Shuah Khan 0 siblings, 2 replies; 33+ messages in thread From: Dmitry Vyukov @ 2022-05-16 7:41 UTC (permalink / raw) To: George Kennedy Cc: kernelci, oswalpalash, syzkaller, Shuah Khan, automated-testing, Vegard Nossum On Fri, 13 May 2022 at 14:16, Dmitry Vyukov <dvyukov@google.com> wrote: > > On Fri, 13 May 2022 at 13:35, George Kennedy <george.kennedy@oracle.com> wrote: > > >> + Shuah, George and mailing lists > > >> > > >> Google groups did not CC all of the members in the thread for my > > >> reply. It would be valuable to get everyone's feedback on this thread. > > >> > > >> On Sat, May 7, 2022 at 11:34 PM Palash <oswalpalash@gmail.com> wrote: > > >>> Hello all, > > >>> > > >>> Reviving this old thread. Do we think there's value in automatically publishing a C reproducer(if it exists) whenever syzkaller determines a reported bug is patched and fixed? > > >>> This allows us to track these reproducers more diligently and we only have reproducers for the bugs that have been patched. > > >>> If this is valuable, then we could think about answering these questions - > > >>> 1. Is there a particular way we want to format the reproducers? (Example : SKIP/OK/FAIL/TIMEOUT (if output is possible)) > > >>> 2. Where do we want to submit the reproducers to be added to the testing project and what is the process we want to use? > > >>> 3. Is it valuable to record the crash report information for the original fuzzer crash when the c reproducer is filed to add context to it; in case developers want to troubleshoot? This could save valuable debugging time. > > >>> > > >>> Happy to contribute on this change to the upstream fuzzing system. > > > > > > More automation is definitely welcome. > > > I am not sure how widely used is the current base of reproducers. But > > > George keeps asking for updates and I keep failing at doing it in a > > > timely manner. > > We run the ~6000 reproducers as a regression test. Test takes ~4 hours. > > > > Having the reproducer before there is a patch is valuable to us as we > > know whether or not our distro branches have the same failure. > > > > As a way to reduce test time, some sort of repro classification would be > > helpful (i.e. open/closed/invalid). > > > > For crash troubleshooting info we try to match the crash string with > > syzbot's crash string. > > > > Thank you, > > George > > > > > > It would be easiest for the syzbot app to upload reproducers to a GCS > > > bucket. But I am not sure what's a good format for this. Everything I > > > can think of is somewhat clumsy. It could upload weekly archives, but > > > then there is an issue of discoverability of new archives (since GCS > > > is HTTP rather than FTP). > > > > > > Not sure if it's feasible to give it an auth token for a github repo > > > to push individual files as we do now. > > > > > > Re format. Bonus points if the system will be able to regenerate and > > > update meta-information. The chances that we will come up with the > > > ultimately right format from day 1 are low. But that may complicate > > > the implementation. > > The most feasible for syzbot automation seems to be to push to a > public GCS bucket and then users will need to do "gsutil rsync" to > download updates. > > Or another option is to expose a new json API to get reproducers list > and then to fetch individual reproducers. Though this will need some > custom tooling on the user side to fetch updates. > > Re exporting status open/closed/invalid and e.g. fixing patch, that > would also be more natural to expose via the API since this > information changes dynamically. > > It's also possible to use both. Namely, reproducers are uploaded to > the GCS bucket and each repro file contains just some bug ID. Then the > bug ID can be used to fetch any additional dynamically changing info > via json API. I've pushed a new drop of 898 reproducers: https://github.com/dvyukov/syzkaller-repros/commit/026c8891a19e672bba71481be250080e1a302ed8 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Automated-testing] syzkaller reproducers 2022-05-16 7:41 ` Dmitry Vyukov @ 2022-05-16 12:42 ` George Kennedy 2022-05-16 16:51 ` Shuah Khan 1 sibling, 0 replies; 33+ messages in thread From: George Kennedy @ 2022-05-16 12:42 UTC (permalink / raw) To: Dmitry Vyukov Cc: kernelci, oswalpalash, syzkaller, Shuah Khan, automated-testing, Vegard Nossum On 5/16/2022 3:41 AM, Dmitry Vyukov wrote: > On Fri, 13 May 2022 at 14:16, Dmitry Vyukov <dvyukov@google.com> wrote: >> On Fri, 13 May 2022 at 13:35, George Kennedy <george.kennedy@oracle.com> wrote: >>>>> + Shuah, George and mailing lists >>>>> >>>>> Google groups did not CC all of the members in the thread for my >>>>> reply. It would be valuable to get everyone's feedback on this thread. >>>>> >>>>> On Sat, May 7, 2022 at 11:34 PM Palash <oswalpalash@gmail.com> wrote: >>>>>> Hello all, >>>>>> >>>>>> Reviving this old thread. Do we think there's value in automatically publishing a C reproducer(if it exists) whenever syzkaller determines a reported bug is patched and fixed? >>>>>> This allows us to track these reproducers more diligently and we only have reproducers for the bugs that have been patched. >>>>>> If this is valuable, then we could think about answering these questions - >>>>>> 1. Is there a particular way we want to format the reproducers? (Example : SKIP/OK/FAIL/TIMEOUT (if output is possible)) >>>>>> 2. Where do we want to submit the reproducers to be added to the testing project and what is the process we want to use? >>>>>> 3. Is it valuable to record the crash report information for the original fuzzer crash when the c reproducer is filed to add context to it; in case developers want to troubleshoot? This could save valuable debugging time. >>>>>> >>>>>> Happy to contribute on this change to the upstream fuzzing system. >>>> More automation is definitely welcome. >>>> I am not sure how widely used is the current base of reproducers. But >>>> George keeps asking for updates and I keep failing at doing it in a >>>> timely manner. >>> We run the ~6000 reproducers as a regression test. Test takes ~4 hours. >>> >>> Having the reproducer before there is a patch is valuable to us as we >>> know whether or not our distro branches have the same failure. >>> >>> As a way to reduce test time, some sort of repro classification would be >>> helpful (i.e. open/closed/invalid). >>> >>> For crash troubleshooting info we try to match the crash string with >>> syzbot's crash string. >>> >>> Thank you, >>> George >>>> It would be easiest for the syzbot app to upload reproducers to a GCS >>>> bucket. But I am not sure what's a good format for this. Everything I >>>> can think of is somewhat clumsy. It could upload weekly archives, but >>>> then there is an issue of discoverability of new archives (since GCS >>>> is HTTP rather than FTP). >>>> >>>> Not sure if it's feasible to give it an auth token for a github repo >>>> to push individual files as we do now. >>>> >>>> Re format. Bonus points if the system will be able to regenerate and >>>> update meta-information. The chances that we will come up with the >>>> ultimately right format from day 1 are low. But that may complicate >>>> the implementation. >> The most feasible for syzbot automation seems to be to push to a >> public GCS bucket and then users will need to do "gsutil rsync" to >> download updates. >> >> Or another option is to expose a new json API to get reproducers list >> and then to fetch individual reproducers. Though this will need some >> custom tooling on the user side to fetch updates. >> >> Re exporting status open/closed/invalid and e.g. fixing patch, that >> would also be more natural to expose via the API since this >> information changes dynamically. >> >> It's also possible to use both. Namely, reproducers are uploaded to >> the GCS bucket and each repro file contains just some bug ID. Then the >> bug ID can be used to fetch any additional dynamically changing info >> via json API. > > I've pushed a new drop of 898 reproducers: > https://github.com/dvyukov/syzkaller-repros/commit/026c8891a19e672bba71481be250080e1a302ed8 Thank you, George ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Automated-testing] syzkaller reproducers 2022-05-16 7:41 ` Dmitry Vyukov 2022-05-16 12:42 ` George Kennedy @ 2022-05-16 16:51 ` Shuah Khan 2022-05-17 9:12 ` Dmitry Vyukov 1 sibling, 1 reply; 33+ messages in thread From: Shuah Khan @ 2022-05-16 16:51 UTC (permalink / raw) To: Dmitry Vyukov, George Kennedy Cc: kernelci, oswalpalash, syzkaller, automated-testing, Vegard Nossum, Shuah Khan On 5/16/22 1:41 AM, Dmitry Vyukov wrote: > On Fri, 13 May 2022 at 14:16, Dmitry Vyukov <dvyukov@google.com> wrote: >> >> On Fri, 13 May 2022 at 13:35, George Kennedy <george.kennedy@oracle.com> wrote: >>>>> + Shuah, George and mailing lists >>>>> >>>>> Google groups did not CC all of the members in the thread for my >>>>> reply. It would be valuable to get everyone's feedback on this thread. >>>>> >>>>> On Sat, May 7, 2022 at 11:34 PM Palash <oswalpalash@gmail.com> wrote: >>>>>> Hello all, >>>>>> >>>>>> Reviving this old thread. Do we think there's value in automatically publishing a C reproducer(if it exists) whenever syzkaller determines a reported bug is patched and fixed? >>>>>> This allows us to track these reproducers more diligently and we only have reproducers for the bugs that have been patched. >>>>>> If this is valuable, then we could think about answering these questions - >>>>>> 1. Is there a particular way we want to format the reproducers? (Example : SKIP/OK/FAIL/TIMEOUT (if output is possible)) >>>>>> 2. Where do we want to submit the reproducers to be added to the testing project and what is the process we want to use? >>>>>> 3. Is it valuable to record the crash report information for the original fuzzer crash when the c reproducer is filed to add context to it; in case developers want to troubleshoot? This could save valuable debugging time. >>>>>> >>>>>> Happy to contribute on this change to the upstream fuzzing system. >>>> >>>> More automation is definitely welcome. >>>> I am not sure how widely used is the current base of reproducers. But >>>> George keeps asking for updates and I keep failing at doing it in a >>>> timely manner. >>> We run the ~6000 reproducers as a regression test. Test takes ~4 hours. >>> >>> Having the reproducer before there is a patch is valuable to us as we >>> know whether or not our distro branches have the same failure. >>> >>> As a way to reduce test time, some sort of repro classification would be >>> helpful (i.e. open/closed/invalid). >>> >>> For crash troubleshooting info we try to match the crash string with >>> syzbot's crash string. >>> >>> Thank you, >>> George >>>> >>>> It would be easiest for the syzbot app to upload reproducers to a GCS >>>> bucket. But I am not sure what's a good format for this. Everything I >>>> can think of is somewhat clumsy. It could upload weekly archives, but >>>> then there is an issue of discoverability of new archives (since GCS >>>> is HTTP rather than FTP). >>>> >>>> Not sure if it's feasible to give it an auth token for a github repo >>>> to push individual files as we do now. >>>> >>>> Re format. Bonus points if the system will be able to regenerate and >>>> update meta-information. The chances that we will come up with the >>>> ultimately right format from day 1 are low. But that may complicate >>>> the implementation. >> >> The most feasible for syzbot automation seems to be to push to a >> public GCS bucket and then users will need to do "gsutil rsync" to >> download updates. >> >> Or another option is to expose a new json API to get reproducers list >> and then to fetch individual reproducers. Though this will need some >> custom tooling on the user side to fetch updates. >> >> Re exporting status open/closed/invalid and e.g. fixing patch, that >> would also be more natural to expose via the API since this >> information changes dynamically. >> >> It's also possible to use both. Namely, reproducers are uploaded to >> the GCS bucket and each repro file contains just some bug ID. Then the >> bug ID can be used to fetch any additional dynamically changing info >> via json API. > > > I've pushed a new drop of 898 reproducers: > https://github.com/dvyukov/syzkaller-repros/commit/026c8891a19e672bba71481be250080e1a302ed8 > Thank you. I will update the linux-arts repo with this drop thanks, -- Shuah ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Automated-testing] syzkaller reproducers 2022-05-16 16:51 ` Shuah Khan @ 2022-05-17 9:12 ` Dmitry Vyukov 0 siblings, 0 replies; 33+ messages in thread From: Dmitry Vyukov @ 2022-05-17 9:12 UTC (permalink / raw) To: Shuah Khan Cc: George Kennedy, kernelci, oswalpalash, syzkaller, automated-testing, Vegard Nossum On Mon, 16 May 2022 at 18:51, Shuah Khan <skhan@linuxfoundation.org> wrote: > > On 5/16/22 1:41 AM, Dmitry Vyukov wrote: > > On Fri, 13 May 2022 at 14:16, Dmitry Vyukov <dvyukov@google.com> wrote: > >> > >> On Fri, 13 May 2022 at 13:35, George Kennedy <george.kennedy@oracle.com> wrote: > >>>>> + Shuah, George and mailing lists > >>>>> > >>>>> Google groups did not CC all of the members in the thread for my > >>>>> reply. It would be valuable to get everyone's feedback on this thread. > >>>>> > >>>>> On Sat, May 7, 2022 at 11:34 PM Palash <oswalpalash@gmail.com> wrote: > >>>>>> Hello all, > >>>>>> > >>>>>> Reviving this old thread. Do we think there's value in automatically publishing a C reproducer(if it exists) whenever syzkaller determines a reported bug is patched and fixed? > >>>>>> This allows us to track these reproducers more diligently and we only have reproducers for the bugs that have been patched. > >>>>>> If this is valuable, then we could think about answering these questions - > >>>>>> 1. Is there a particular way we want to format the reproducers? (Example : SKIP/OK/FAIL/TIMEOUT (if output is possible)) > >>>>>> 2. Where do we want to submit the reproducers to be added to the testing project and what is the process we want to use? > >>>>>> 3. Is it valuable to record the crash report information for the original fuzzer crash when the c reproducer is filed to add context to it; in case developers want to troubleshoot? This could save valuable debugging time. > >>>>>> > >>>>>> Happy to contribute on this change to the upstream fuzzing system. > >>>> > >>>> More automation is definitely welcome. > >>>> I am not sure how widely used is the current base of reproducers. But > >>>> George keeps asking for updates and I keep failing at doing it in a > >>>> timely manner. > >>> We run the ~6000 reproducers as a regression test. Test takes ~4 hours. > >>> > >>> Having the reproducer before there is a patch is valuable to us as we > >>> know whether or not our distro branches have the same failure. > >>> > >>> As a way to reduce test time, some sort of repro classification would be > >>> helpful (i.e. open/closed/invalid). > >>> > >>> For crash troubleshooting info we try to match the crash string with > >>> syzbot's crash string. > >>> > >>> Thank you, > >>> George > >>>> > >>>> It would be easiest for the syzbot app to upload reproducers to a GCS > >>>> bucket. But I am not sure what's a good format for this. Everything I > >>>> can think of is somewhat clumsy. It could upload weekly archives, but > >>>> then there is an issue of discoverability of new archives (since GCS > >>>> is HTTP rather than FTP). > >>>> > >>>> Not sure if it's feasible to give it an auth token for a github repo > >>>> to push individual files as we do now. > >>>> > >>>> Re format. Bonus points if the system will be able to regenerate and > >>>> update meta-information. The chances that we will come up with the > >>>> ultimately right format from day 1 are low. But that may complicate > >>>> the implementation. > >> > >> The most feasible for syzbot automation seems to be to push to a > >> public GCS bucket and then users will need to do "gsutil rsync" to > >> download updates. > >> > >> Or another option is to expose a new json API to get reproducers list > >> and then to fetch individual reproducers. Though this will need some > >> custom tooling on the user side to fetch updates. > >> > >> Re exporting status open/closed/invalid and e.g. fixing patch, that > >> would also be more natural to expose via the API since this > >> information changes dynamically. > >> > >> It's also possible to use both. Namely, reproducers are uploaded to > >> the GCS bucket and each repro file contains just some bug ID. Then the > >> bug ID can be used to fetch any additional dynamically changing info > >> via json API. > > > > > > I've pushed a new drop of 898 reproducers: > > https://github.com/dvyukov/syzkaller-repros/commit/026c8891a19e672bba71481be250080e1a302ed8 > > > > Thank you. I will update the linux-arts repo with this drop Thank you! ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: syzkaller reproducers 2019-10-08 12:16 ` Dmitry Vyukov 2019-10-08 15:00 ` shuah @ 2019-10-08 16:35 ` George Kennedy 1 sibling, 0 replies; 33+ messages in thread From: George Kennedy @ 2019-10-08 16:35 UTC (permalink / raw) To: Dmitry Vyukov, Shuah Khan, open list:KERNEL SELFTEST FRAMEWORK, automated-testing, kernelci, Dhaval Giani, Konrad Rzeszutek Wilk, Boris Ostrovsky, Jan Setje-Eilers Cc: syzkaller On 10/8/2019 8:16 AM, Dmitry Vyukov wrote: > On Tue, Oct 8, 2019 at 1:46 PM Dmitry Vyukov <dvyukov@google.com> wrote: >> Hi Shuah, >> >> We discussed collecting and uploading all syzkaller reproducers >> somewhere. You wanted to see how they look. I've uploaded all current >> reproducers here: >> https://github.com/dvyukov/syzkaller-repros >> Minimalistic build/run scripts are included. >> +some testing mailing lists too as this can be used as a test suite >> If you have any potential uses for this, you are welcome to use it. >> But then we probably need to find some more official and shared place >> for them than my private github. >> The test programs can also be bulk updated if necessary, because all >> of this is auto-generated. Thank you for putting this together Dmitry, George >> >> Thanks > +more people who expressed interest in the test suite before ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Automated-testing] syzkaller reproducers 2019-10-08 11:46 syzkaller reproducers dvyukov 2019-10-08 12:16 ` Dmitry Vyukov @ 2019-10-08 12:37 ` Richard Palethorpe 2019-10-08 12:53 ` Dmitry Vyukov 2019-10-10 14:27 ` Cyril Hrubis 2 siblings, 1 reply; 33+ messages in thread From: Richard Palethorpe @ 2019-10-08 12:37 UTC (permalink / raw) To: automated-testing Cc: Shuah Khan, open list:KERNEL SELFTEST FRAMEWORK, kernelci, syzkaller Hello, Dmitry Vyukov <dvyukov@google.com> writes: > Hi Shuah, > > We discussed collecting and uploading all syzkaller reproducers > somewhere. You wanted to see how they look. I've uploaded all current > reproducers here: > https://github.com/dvyukov/syzkaller-repros > Minimalistic build/run scripts are included. > +some testing mailing lists too as this can be used as a test suite > If you have any potential uses for this, you are welcome to use it. > But then we probably need to find some more official and shared place > for them than my private github. > The test programs can also be bulk updated if necessary, because all > of this is auto-generated. > > Thanks I discussed this a bit with Metan. We think it would be fairly trivial to create an LTP wrapper for these. So we just create an LTP test which forks and execs one of these reproducers then checks for kernel taints after the child completes or is killed. It can take the reproducer path as an argument and we can generate a runtest file with all the reproducers in that we are able to compile. I imagine a lot of these reproducers will not work on older kernels, so this would just be a best efforts basis. We would ignore any problems during execution unless there is a kernel error. This should work with existing LTP runners with maybe a minor change or two to building and configuration. I will start experimenting with this and post the results to the LTP mailing list. -- Thank you, Richard. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Automated-testing] syzkaller reproducers 2019-10-08 12:37 ` [Automated-testing] " Richard Palethorpe @ 2019-10-08 12:53 ` Dmitry Vyukov 2019-10-08 13:14 ` Richard Palethorpe 0 siblings, 1 reply; 33+ messages in thread From: Dmitry Vyukov @ 2019-10-08 12:53 UTC (permalink / raw) To: rpalethorpe Cc: automated-testing, Shuah Khan, open list:KERNEL SELFTEST FRAMEWORK, kernelci, syzkaller On Tue, Oct 8, 2019 at 2:37 PM Richard Palethorpe <rpalethorpe@suse.de> wrote: > > Hello, > > Dmitry Vyukov <dvyukov@google.com> writes: > > > Hi Shuah, > > > > We discussed collecting and uploading all syzkaller reproducers > > somewhere. You wanted to see how they look. I've uploaded all current > > reproducers here: > > https://github.com/dvyukov/syzkaller-repros > > Minimalistic build/run scripts are included. > > +some testing mailing lists too as this can be used as a test suite > > If you have any potential uses for this, you are welcome to use it. > > But then we probably need to find some more official and shared place > > for them than my private github. > > The test programs can also be bulk updated if necessary, because all > > of this is auto-generated. > > > > Thanks > > I discussed this a bit with Metan. We think it would be fairly trivial > to create an LTP wrapper for these. > > So we just create an LTP test which forks and execs one of these > reproducers then checks for kernel taints after the child completes or > is killed. It can take the reproducer path as an argument and we can > generate a runtest file with all the reproducers in that we are able to > compile. > > I imagine a lot of these reproducers will not work on older kernels, so > this would just be a best efforts basis. We would ignore any problems > during execution unless there is a kernel error. > > This should work with existing LTP runners with maybe a minor change or > two to building and configuration. > > I will start experimenting with this and post the results to the LTP > mailing list. Hi Richard, Sounds great! Yes, these are totally best effort. May also require some configs, etc. Also note that each should be run in a clean temp dir and with a timeout b/c some have an infinite loop. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Automated-testing] syzkaller reproducers 2019-10-08 12:53 ` Dmitry Vyukov @ 2019-10-08 13:14 ` Richard Palethorpe 2019-10-08 13:22 ` Dmitry Vyukov 0 siblings, 1 reply; 33+ messages in thread From: Richard Palethorpe @ 2019-10-08 13:14 UTC (permalink / raw) To: Dmitry Vyukov Cc: rpalethorpe, automated-testing, Shuah Khan, open list:KERNEL SELFTEST FRAMEWORK, kernelci, syzkaller Hello, Dmitry Vyukov <dvyukov@google.com> writes: > On Tue, Oct 8, 2019 at 2:37 PM Richard Palethorpe <rpalethorpe@suse.de> wrote: >> >> Hello, >> >> Dmitry Vyukov <dvyukov@google.com> writes: >> >> > Hi Shuah, >> > >> > We discussed collecting and uploading all syzkaller reproducers >> > somewhere. You wanted to see how they look. I've uploaded all current >> > reproducers here: >> > https://github.com/dvyukov/syzkaller-repros >> > Minimalistic build/run scripts are included. >> > +some testing mailing lists too as this can be used as a test suite >> > If you have any potential uses for this, you are welcome to use it. >> > But then we probably need to find some more official and shared place >> > for them than my private github. >> > The test programs can also be bulk updated if necessary, because all >> > of this is auto-generated. >> > >> > Thanks >> >> I discussed this a bit with Metan. We think it would be fairly trivial >> to create an LTP wrapper for these. >> >> So we just create an LTP test which forks and execs one of these >> reproducers then checks for kernel taints after the child completes or >> is killed. It can take the reproducer path as an argument and we can >> generate a runtest file with all the reproducers in that we are able to >> compile. >> >> I imagine a lot of these reproducers will not work on older kernels, so >> this would just be a best efforts basis. We would ignore any problems >> during execution unless there is a kernel error. >> >> This should work with existing LTP runners with maybe a minor change or >> two to building and configuration. >> >> I will start experimenting with this and post the results to the LTP >> mailing list. > > > Hi Richard, > > Sounds great! > > Yes, these are totally best effort. May also require some configs, etc. > Also note that each should be run in a clean temp dir and with a > timeout b/c some have an infinite loop. Thanks, fortunately the LTP lib can do that automatically. However the default timeout is 5 minutes, but I guess this should be more like ~3 seconds as in the run script? -- Thank you, Richard. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Automated-testing] syzkaller reproducers 2019-10-08 13:14 ` Richard Palethorpe @ 2019-10-08 13:22 ` Dmitry Vyukov 0 siblings, 0 replies; 33+ messages in thread From: Dmitry Vyukov @ 2019-10-08 13:22 UTC (permalink / raw) To: rpalethorpe Cc: automated-testing, Shuah Khan, open list:KERNEL SELFTEST FRAMEWORK, kernelci, syzkaller On Tue, Oct 8, 2019 at 3:14 PM Richard Palethorpe <rpalethorpe@suse.de> wrote: > > Hello, > > Dmitry Vyukov <dvyukov@google.com> writes: > > > On Tue, Oct 8, 2019 at 2:37 PM Richard Palethorpe <rpalethorpe@suse.de> wrote: > >> > >> Hello, > >> > >> Dmitry Vyukov <dvyukov@google.com> writes: > >> > >> > Hi Shuah, > >> > > >> > We discussed collecting and uploading all syzkaller reproducers > >> > somewhere. You wanted to see how they look. I've uploaded all current > >> > reproducers here: > >> > https://github.com/dvyukov/syzkaller-repros > >> > Minimalistic build/run scripts are included. > >> > +some testing mailing lists too as this can be used as a test suite > >> > If you have any potential uses for this, you are welcome to use it. > >> > But then we probably need to find some more official and shared place > >> > for them than my private github. > >> > The test programs can also be bulk updated if necessary, because all > >> > of this is auto-generated. > >> > > >> > Thanks > >> > >> I discussed this a bit with Metan. We think it would be fairly trivial > >> to create an LTP wrapper for these. > >> > >> So we just create an LTP test which forks and execs one of these > >> reproducers then checks for kernel taints after the child completes or > >> is killed. It can take the reproducer path as an argument and we can > >> generate a runtest file with all the reproducers in that we are able to > >> compile. > >> > >> I imagine a lot of these reproducers will not work on older kernels, so > >> this would just be a best efforts basis. We would ignore any problems > >> during execution unless there is a kernel error. > >> > >> This should work with existing LTP runners with maybe a minor change or > >> two to building and configuration. > >> > >> I will start experimenting with this and post the results to the LTP > >> mailing list. > > > > > > Hi Richard, > > > > Sounds great! > > > > Yes, these are totally best effort. May also require some configs, etc. > > Also note that each should be run in a clean temp dir and with a > > timeout b/c some have an infinite loop. > > Thanks, fortunately the LTP lib can do that automatically. > > However the default timeout is 5 minutes, but I guess this should be > more like ~3 seconds as in the run script? This really depends on the bug type and specific bug. syzkaller runs reproducers for up to 7 minutes. Sometimes even that is not enough to reproduce some bugs. We also detect hung tasks only after 3-4 minutes (may produce flakes with smaller timeout). Most reproducers can also run in parallel, that may help to partially neutralize large timeouts. But also if these run repeatedly/continuously, we can use smaller timeout on each run (don't need to catch crash on every run). Let's start with somewhere, we can tune later as we gather experience. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Automated-testing] syzkaller reproducers 2019-10-08 11:46 syzkaller reproducers dvyukov 2019-10-08 12:16 ` Dmitry Vyukov 2019-10-08 12:37 ` [Automated-testing] " Richard Palethorpe @ 2019-10-10 14:27 ` Cyril Hrubis 2019-10-10 14:30 ` Dmitry Vyukov 2 siblings, 1 reply; 33+ messages in thread From: Cyril Hrubis @ 2019-10-10 14:27 UTC (permalink / raw) To: Dmitry Vyukov Cc: Shuah Khan, open list:KERNEL SELFTEST FRAMEWORK, automated-testing, kernelci, syzkaller Hi! > We discussed collecting and uploading all syzkaller reproducers > somewhere. You wanted to see how they look. I've uploaded all current > reproducers here: > https://github.com/dvyukov/syzkaller-repros > Minimalistic build/run scripts are included. What is the reason behind statically linking the reproducers? The difference between static and dynamic binary is a bit less than 4MB, which gives difference of several gigabytes for the whole repo. This amount of binary data would complicate and slow down any CI significantly... -- Cyril Hrubis chrubis@suse.cz ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Automated-testing] syzkaller reproducers 2019-10-10 14:27 ` Cyril Hrubis @ 2019-10-10 14:30 ` Dmitry Vyukov 0 siblings, 0 replies; 33+ messages in thread From: Dmitry Vyukov @ 2019-10-10 14:30 UTC (permalink / raw) To: Cyril Hrubis Cc: Shuah Khan, open list:KERNEL SELFTEST FRAMEWORK, automated-testing, kernelci, syzkaller On Thu, Oct 10, 2019 at 4:27 PM Cyril Hrubis <chrubis@suse.cz> wrote: > > Hi! > > We discussed collecting and uploading all syzkaller reproducers > > somewhere. You wanted to see how they look. I've uploaded all current > > reproducers here: > > https://github.com/dvyukov/syzkaller-repros > > Minimalistic build/run scripts are included. > > What is the reason behind statically linking the reproducers? > > The difference between static and dynamic binary is a bit less than 4MB, > which gives difference of several gigabytes for the whole repo. This > amount of binary data would complicate and slow down any CI > significantly... Simply being able to run programs on a different machine. Dynamic binaries generally don't run on a different linux machine. If you can build dynamic binaries so that they run on test machine, feel free to drop -static. ^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~2022-05-17 9:12 UTC | newest] Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-10-08 11:46 syzkaller reproducers dvyukov 2019-10-08 12:16 ` Dmitry Vyukov 2019-10-08 15:00 ` shuah 2019-10-11 17:38 ` shuah 2019-10-11 18:02 ` [Automated-testing] " Cyril Hrubis 2019-10-11 19:11 ` shuah 2019-10-14 8:54 ` Cyril Hrubis 2019-10-14 11:19 ` Dmitry Vyukov 2019-10-15 13:04 ` George Kennedy 2019-10-15 13:44 ` Cyril Hrubis 2019-10-23 13:24 ` Dmitry Vyukov 2019-12-06 20:06 ` George Kennedy 2020-01-27 14:19 ` George Kennedy 2020-01-27 15:26 ` Dmitry Vyukov 2020-01-27 17:06 ` George Kennedy 2020-03-03 8:45 ` Dmitry Vyukov 2020-03-03 13:46 ` George Kennedy 2020-03-13 15:59 ` shuah [not found] ` <cd301033-f152-4eeb-bce3-2d95f39a05fbn@googlegroups.com> 2022-05-12 18:05 ` Palash Oswal 2022-05-13 9:29 ` Dmitry Vyukov 2022-05-13 11:35 ` George Kennedy 2022-05-13 12:16 ` Dmitry Vyukov 2022-05-16 7:41 ` Dmitry Vyukov 2022-05-16 12:42 ` George Kennedy 2022-05-16 16:51 ` Shuah Khan 2022-05-17 9:12 ` Dmitry Vyukov 2019-10-08 16:35 ` George Kennedy 2019-10-08 12:37 ` [Automated-testing] " Richard Palethorpe 2019-10-08 12:53 ` Dmitry Vyukov 2019-10-08 13:14 ` Richard Palethorpe 2019-10-08 13:22 ` Dmitry Vyukov 2019-10-10 14:27 ` Cyril Hrubis 2019-10-10 14:30 ` Dmitry Vyukov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).