Previous patch set at [1] has a problem when using hw_breakpoints on
ARM and ARM64. This new version fix that by introducing
is_default_overflow_handler() to replace all '!overflow_handler'
checking.
[1]
http://lkml.kernel.org/g/1457322619-170254-1-git-send-email-wangn...@huawei.com
Wang Nan (5)
On Wed, Mar 9, 2016 at 11:53 AM, Borislav Petkov wrote:
> On Tue, Mar 08, 2016 at 04:54:23PM +0100, Ingo Molnar wrote:
>> triton:~/go/src/github.com/google/syzkaller> cat perf.cfg
>> {
>> "http": "localhost:5",
>> "workdir": "/home/mingo/go/src/github.com/google/syzkaller/workd
On Tue, Mar 08, 2016 at 04:54:23PM +0100, Ingo Molnar wrote:
> triton:~/go/src/github.com/google/syzkaller> cat perf.cfg
> {
> "http": "localhost:5",
> "workdir": "/home/mingo/go/src/github.com/google/syzkaller/workdir",
> "syzkaller": "/home/mingo/go/src/github.com/goo
On Tue, Mar 08, 2016 at 09:44:58PM +0100, Jiri Olsa wrote:
> On Tue, Mar 08, 2016 at 09:07:46PM +0100, Peter Zijlstra wrote:
> > On Tue, Mar 08, 2016 at 08:56:42PM +0100, Jiri Olsa wrote:
> > > > # cat go-fuzz.sh
> > > > #!/bin/bash
> > > >
> > > > echo 1 > /proc/sys/kernel/traceoff_on_warning
> >
On Tue, Mar 08, 2016 at 09:07:46PM +0100, Peter Zijlstra wrote:
> On Tue, Mar 08, 2016 at 08:56:42PM +0100, Jiri Olsa wrote:
> > > # cat go-fuzz.sh
> > > #!/bin/bash
> > >
> > > echo 1 > /proc/sys/kernel/traceoff_on_warning
> > > echo 1 > /debug/tracing/options/stacktrace
> > > echo 1 > /debug/tra
On Tue, Mar 08, 2016 at 08:56:42PM +0100, Jiri Olsa wrote:
> > # cat go-fuzz.sh
> > #!/bin/bash
> >
> > echo 1 > /proc/sys/kernel/traceoff_on_warning
> > echo 1 > /debug/tracing/options/stacktrace
> > echo 1 > /debug/tracing/events/sched/enable
>
> are you running this under root?
Of course ;-)
On Tue, Mar 08, 2016 at 02:57:59PM +0100, Peter Zijlstra wrote:
> On Tue, Mar 08, 2016 at 02:49:01PM +0100, Ingo Molnar wrote:
> >
> > * Peter Zijlstra wrote:
> >
> > > On Mon, Mar 07, 2016 at 03:50:14AM +, Wang Nan wrote:
> > > > This patch set has been posted multiple times (with and witho
* Ingo Molnar wrote:
> so it's eating about 10% of system overhead despite doing nothing (!).
>
> The workaround for that systemd bug is a brutal:
>
> [root@fomalhaut ~]# mv /usr/lib/systemd/systemd-journald
> /usr/lib/systemd/systemd-journald.dontuse
> [root@fomalhaut ~]#
Except that if
* Ingo Molnar wrote:
> With nproc set to 120 it seems to be chugging along at about 25% system
> utilization:
>
> Tasks: 1271 total, 1 running, 1270 sleeping, 0 stopped, 0 zombie
> %Cpu(s): 4.5 us, 35.3 sy, 0.0 ni, 55.2 id, 0.5 wa, 4.5 hi, 0.0 si, 0.0
> st
> KiB Mem : 26401230+tot
* Ingo Molnar wrote:
>
> * Ingo Molnar wrote:
>
> > Things got a lot more lively after that!
> >
> > But most of the overhead seems to come from systemd trying to dump core or
> > something like that:
> >
> > 85872 mingo 20 0 34712 3016 2656 S 4.6 0.0 0:00.14
> > systemd
* Ingo Molnar wrote:
> Things got a lot more lively after that!
>
> But most of the overhead seems to come from systemd trying to dump core or
> something like that:
>
> 85872 mingo 20 0 34712 3016 2656 S 4.6 0.0 0:00.14
> systemd-coredum
On Tue, Mar 08, 2016 at 06:37:09PM +0100, Ingo Molnar wrote:
> Peter, do you experience with running syz-kaller on larger CPU count Intel
> systems?
I run it on a 20 core (40 cpu) system mostly, as that tends to not take
ages to come back up again once I wrecked it.
On Tue, Mar 8, 2016 at 6:48 PM, Ingo Molnar wrote:
>
> * Dmitry Vyukov wrote:
>
>> On Tue, Mar 8, 2016 at 6:37 PM, Ingo Molnar wrote:
>> >
>> > * Dmitry Vyukov wrote:
>> >
>> >> > fomalhaut:~/go/src/github.com/google/syzkaller> ps aux | grep -i syz
>> >> > mingo 1374 0.0 0.0 118476 2376
On Tue, Mar 08, 2016 at 06:48:56PM +0100, Ingo Molnar wrote:
> weird ... Has any of you seen such behavior?
No systemd on any of my machines ;-)
* Dmitry Vyukov wrote:
> On Tue, Mar 8, 2016 at 6:37 PM, Ingo Molnar wrote:
> >
> > * Dmitry Vyukov wrote:
> >
> >> > fomalhaut:~/go/src/github.com/google/syzkaller> ps aux | grep -i syz
> >> > mingo 1374 0.0 0.0 118476 2376 pts/2S+ 18:23 0:00 grep
> >> > --color=auto -i syz
>
On Tue, Mar 8, 2016 at 6:37 PM, Ingo Molnar wrote:
>
> * Dmitry Vyukov wrote:
>
>> > fomalhaut:~/go/src/github.com/google/syzkaller> ps aux | grep -i syz
>> > mingo 1374 0.0 0.0 118476 2376 pts/2S+ 18:23 0:00 grep
>> > --color=auto -i syz
>> >
>> > and with no kernel messages in
* Dmitry Vyukov wrote:
> > fomalhaut:~/go/src/github.com/google/syzkaller> ps aux | grep -i syz
> > mingo 1374 0.0 0.0 118476 2376 pts/2S+ 18:23 0:00 grep
> > --color=auto -i syz
> >
> > and with no kernel messages in dmesg - and with a fully functional system.
> >
> > I'm runni
On Tue, Mar 8, 2016 at 6:24 PM, Ingo Molnar wrote:
>
> * Dmitry Vyukov wrote:
>
>> On Tue, Mar 8, 2016 at 5:48 PM, Ingo Molnar wrote:
>> >
>> > * Ingo Molnar wrote:
>> >
>> >> It only had a couple of seconds of runtime:
>> >>
>> >> 49652 mingo 20 0 1434276 52144 11344 S 0.0 0.0 0:
* Dmitry Vyukov wrote:
> On Tue, Mar 8, 2016 at 5:48 PM, Ingo Molnar wrote:
> >
> > * Ingo Molnar wrote:
> >
> >> It only had a couple of seconds of runtime:
> >>
> >> 49652 mingo 20 0 1434276 52144 11344 S 0.0 0.0 0:00.54
> >> syz-manager
> >> 49661 mingo 20 0 2196672 4
On Tue, Mar 8, 2016 at 5:48 PM, Ingo Molnar wrote:
>
> * Ingo Molnar wrote:
>
>> It only had a couple of seconds of runtime:
>>
>> 49652 mingo 20 0 1434276 52144 11344 S 0.0 0.0 0:00.54
>> syz-manager
>> 49661 mingo 20 0 2196672 43948 10448 S 0.0 0.0 0:05.59
>> syz-f
* Ingo Molnar wrote:
> It only had a couple of seconds of runtime:
>
> 49652 mingo 20 0 1434276 52144 11344 S 0.0 0.0 0:00.54
> syz-manager
>
> 49661 mingo 20 0 2196672
* Dmitry Vyukov wrote:
> On Tue, Mar 8, 2016 at 5:27 PM, Ingo Molnar wrote:
> >
> > * Dmitry Vyukov wrote:
> >
> >> On Tue, Mar 8, 2016 at 4:54 PM, Ingo Molnar wrote:
> >> >
> >> > * Dmitry Vyukov wrote:
> >> >
> >> >> > so, according to the error message it wants a writable directory.
> >>
* Dmitry Vyukov wrote:
> On Tue, Mar 8, 2016 at 4:54 PM, Ingo Molnar wrote:
> >
> > * Dmitry Vyukov wrote:
> >
> >> > so, according to the error message it wants a writable directory. Lets
> >> > try it that
> >> > way:
> >> >
> >> > triton:~> mkdir go
> >> > triton:~>
> >> > triton:~> exp
On Tue, Mar 08, 2016 at 05:29:50PM +0100, Dmitry Vyukov wrote:
> KCOV will increase efficiency of the fuzzer, but it is not necessary.
> As far as I understand Peter tested without KCOV.
Correct, I never quite got around to enabling it. Still on the TODO list
somewhere.
On Tue, Mar 08, 2016 at 05:27:03PM +0100, Ingo Molnar wrote:
> > > triton:~/go/src/github.com/google/syzkaller> cat perf.cfg
> > > {
> > > "http": "localhost:5",
> > > "workdir":
> > > "/home/mingo/go/src/github.com/google/syzkaller/workdir",
> > > "syzkaller": "/home/m
On Tue, Mar 8, 2016 at 5:27 PM, Ingo Molnar wrote:
>
> * Dmitry Vyukov wrote:
>
>> On Tue, Mar 8, 2016 at 4:54 PM, Ingo Molnar wrote:
>> >
>> > * Dmitry Vyukov wrote:
>> >
>> >> > so, according to the error message it wants a writable directory. Lets
>> >> > try it that
>> >> > way:
>> >> >
>>
On Tue, Mar 8, 2016 at 4:54 PM, Ingo Molnar wrote:
>
> * Dmitry Vyukov wrote:
>
>> > so, according to the error message it wants a writable directory. Lets try
>> > it that
>> > way:
>> >
>> > triton:~> mkdir go
>> > triton:~>
>> > triton:~> export GOPATH=/home/mingo/go/
>> > triton:~> go ge
* Dmitry Vyukov wrote:
> > so, according to the error message it wants a writable directory. Lets try
> > it that
> > way:
> >
> > triton:~> mkdir go
> > triton:~>
> > triton:~> export GOPATH=/home/mingo/go/
> > triton:~> go get github.com/google/syzkaller
> > can't load package: package g
On Tue, Mar 8, 2016 at 4:29 PM, Ingo Molnar wrote:
>
> * Peter Zijlstra wrote:
>
>> Here's a thread on syz-kaller:
>>
>>
>> lkml.kernel.org/r/CACT4Y+Ym0TZLkmRrM0ZGgLpu8kqS-YjoWTMrvaLz=tx2tny...@mail.gmail.com
>>
>> If things have shifted again I'm sure Dmitry is willing to help.
>
> So I tried
* Peter Zijlstra wrote:
> Here's a thread on syz-kaller:
>
>
> lkml.kernel.org/r/CACT4Y+Ym0TZLkmRrM0ZGgLpu8kqS-YjoWTMrvaLz=tx2tny...@mail.gmail.com
>
> If things have shifted again I'm sure Dmitry is willing to help.
So I tried to install 'go' but it's a _really_ unintuitive tool I have to
On Tue, Mar 08, 2016 at 02:49:01PM +0100, Ingo Molnar wrote:
>
> * Peter Zijlstra wrote:
>
> > On Mon, Mar 07, 2016 at 03:50:14AM +, Wang Nan wrote:
> > > This patch set has been posted multiple times (with and without
> > > corresponding 'perf tool' patches), and doesn't receive further
> >
* Peter Zijlstra wrote:
> On Mon, Mar 07, 2016 at 03:50:14AM +, Wang Nan wrote:
> > This patch set has been posted multiple times (with and without
> > corresponding 'perf tool' patches), and doesn't receive further
> > comment. I think it should be okay to merge them into mainline.
> > Ther
On Mon, Mar 07, 2016 at 03:50:14AM +, Wang Nan wrote:
> This patch set has been posted multiple times (with and without
> corresponding 'perf tool' patches), and doesn't receive further
> comment. I think it should be okay to merge them into mainline.
> There are many perf's improvement depend
This patch set has been posted multiple times (with and without
corresponding 'perf tool' patches), and doesn't receive further
comment. I think it should be okay to merge them into mainline.
There are many perf's improvement depend on it. However, Peter
is not responsive after I fixed some problem
34 matches
Mail list logo
