From: "Zhangjian (Bamvor)" <bamvor.zhangjian@huawei.com>
To: Joseph Myers <joseph@codesourcery.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
Linux-Arch <linux-arch@vger.kernel.org>,
libc-alpha@sourceware.org, trinity@vger.kernel.org,
syzkaller <syzkaller@googlegroups.com>,
aponomarenko@rosalab.ru, Jess Hertz <jesse.hertz@nccgroup.trust>,
Tim Newsham <tim.newsham@nccgroup.trust>,
Arnd Bergmann <arnd@arndb.de>,
Catalin Marinas <catalin.marinas@arm.com>,
Mark Brown <broonie@kernel.org>,
Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org>,
Yury Norov <ynorov@caviumnetworks.com>,
Andrew Pinski <pinskia@gmail.com>,
Andreas Schwab <schwab@suse.de>, Alexander Graf <agraf@suse.de>,
marcus.shawcroft@arm.com, Ding Tianhong <dingtianhong@huawei.com>,
Hanjun Guo <guohanjun@huawei.com>,
cuibixuan@huawei.com, lijinyue@huawei.com,
Zefan Li <lizefan@huawei.com>
Subject: Re: [RFD] Efficient unit test and fuzz tools for kernel/libc porting
Date: Thu, 21 Jul 2016 20:39:11 +0800 [thread overview]
Message-ID: <5790C26F.4080408@huawei.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1607201544220.12251@digraph.polyomino.org.uk>
Hi, Joseph
On 2016/7/20 23:47, Joseph Myers wrote:
> On Wed, 6 Jul 2016, Zhangjian (Bamvor) wrote:
>
>> correct or not. After learn and compare some fuzz tools, I feel that there is
>> no such fuzz tools could help me. So, I wrote a new fuzz tools base on the
>> trinity and it found several wrapper issues in glibc. I will first explain the
>> different with existing fuzz tools and paste my propsosal in the end.
>
> I'm not at all clear on whether any of the people working on AArch64 ILP32
> glibc have run the glibc testsuite and investigated the results in detail
> (the patch submissions have failed to include glibc testsuite results and
> have included bugs that would have been detected by the glibc testsuite).
I run test glibc testsuite in previous glibc version with v6 kernel patch
backport to kernel-4.1, without regression. I usually run glibc testsuite
after ltp test result looks good. So, maybe it hard to find a issue by
glibc testsuite in this case.
> But, if you've found bugs in a new glibc port that were not detected by
> the existing testsuite, then tests for those bugs should be contributed to
> glibc (even if no existing port has those bugs, improving the test
> coverage is still a good idea).
It is good idea. I will review the fixed issues(such as wrong context in
signal, wrong parameter in off_t/stat relative syscalls) and check if it is
suitable to add it to glibc testsuite. (Actually, I do not know which
test suite (ltp or glibc) I should improve for a specific issue).
I hope our tools could help on improving the coverage of syscall relative
code at least.
Thanks.
Bamvor
WARNING: multiple messages have this Message-ID (diff)
From: "Zhangjian (Bamvor)" <bamvor.zhangjian@huawei.com>
To: Joseph Myers <joseph@codesourcery.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
Linux-Arch <linux-arch@vger.kernel.org>,
<libc-alpha@sourceware.org>, <trinity@vger.kernel.org>,
syzkaller <syzkaller@googlegroups.com>, <aponomarenko@rosalab.ru>,
Jess Hertz <jesse.hertz@nccgroup.trust>,
"Tim Newsham" <tim.newsham@nccgroup.trust>,
Arnd Bergmann <arnd@arndb.de>,
"Catalin Marinas" <catalin.marinas@arm.com>,
Mark Brown <broonie@kernel.org>,
"Maxim Kuvyrkov" <maxim.kuvyrkov@linaro.org>,
Yury Norov <ynorov@caviumnetworks.com>,
Andrew Pinski <pinskia@gmail.com>,
Andreas Schwab <schwab@suse.de>, "Alexander Graf" <agraf@suse.de>,
<marcus.shawcroft@arm.com>,
Ding Tianhong <dingtianhong@huawei.com>,
Hanjun Guo <guohanjun@huawei.com>, <cuibixuan@huawei.com>,
<lijinyue@huawei.com>, Zefan Li <lizefan@huawei.com>
Subject: Re: [RFD] Efficient unit test and fuzz tools for kernel/libc porting
Date: Thu, 21 Jul 2016 20:39:11 +0800 [thread overview]
Message-ID: <5790C26F.4080408@huawei.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1607201544220.12251@digraph.polyomino.org.uk>
Hi, Joseph
On 2016/7/20 23:47, Joseph Myers wrote:
> On Wed, 6 Jul 2016, Zhangjian (Bamvor) wrote:
>
>> correct or not. After learn and compare some fuzz tools, I feel that there is
>> no such fuzz tools could help me. So, I wrote a new fuzz tools base on the
>> trinity and it found several wrapper issues in glibc. I will first explain the
>> different with existing fuzz tools and paste my propsosal in the end.
>
> I'm not at all clear on whether any of the people working on AArch64 ILP32
> glibc have run the glibc testsuite and investigated the results in detail
> (the patch submissions have failed to include glibc testsuite results and
> have included bugs that would have been detected by the glibc testsuite).
I run test glibc testsuite in previous glibc version with v6 kernel patch
backport to kernel-4.1, without regression. I usually run glibc testsuite
after ltp test result looks good. So, maybe it hard to find a issue by
glibc testsuite in this case.
> But, if you've found bugs in a new glibc port that were not detected by
> the existing testsuite, then tests for those bugs should be contributed to
> glibc (even if no existing port has those bugs, improving the test
> coverage is still a good idea).
It is good idea. I will review the fixed issues(such as wrong context in
signal, wrong parameter in off_t/stat relative syscalls) and check if it is
suitable to add it to glibc testsuite. (Actually, I do not know which
test suite (ltp or glibc) I should improve for a specific issue).
I hope our tools could help on improving the coverage of syscall relative
code at least.
Thanks.
Bamvor
next prev parent reply other threads:[~2016-07-21 12:39 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-06 7:39 [RFD] Efficient unit test and fuzz tools for kernel/libc porting Zhangjian (Bamvor)
2016-07-06 7:39 ` Zhangjian (Bamvor)
2016-07-06 7:39 ` Zhangjian (Bamvor)
2016-07-06 8:00 ` Dmitry Vyukov
2016-07-06 8:24 ` Zhangjian (Bamvor)
2016-07-06 8:24 ` Zhangjian (Bamvor)
2016-07-06 9:09 ` Dmitry Vyukov
2016-07-06 10:38 ` Zhangjian (Bamvor)
2016-07-06 10:38 ` Zhangjian (Bamvor)
2016-07-06 8:00 ` Zhangjian (Bamvor)
2016-07-06 8:00 ` Zhangjian (Bamvor)
2016-07-06 8:00 ` Zhangjian (Bamvor)
2016-07-20 15:47 ` Joseph Myers
2016-07-20 15:47 ` Joseph Myers
2016-07-21 12:39 ` Zhangjian (Bamvor) [this message]
2016-07-21 12:39 ` Zhangjian (Bamvor)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5790C26F.4080408@huawei.com \
--to=bamvor.zhangjian@huawei.com \
--cc=agraf@suse.de \
--cc=aponomarenko@rosalab.ru \
--cc=arnd@arndb.de \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=cuibixuan@huawei.com \
--cc=dingtianhong@huawei.com \
--cc=guohanjun@huawei.com \
--cc=jesse.hertz@nccgroup.trust \
--cc=joseph@codesourcery.com \
--cc=libc-alpha@sourceware.org \
--cc=lijinyue@huawei.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lizefan@huawei.com \
--cc=marcus.shawcroft@arm.com \
--cc=maxim.kuvyrkov@linaro.org \
--cc=pinskia@gmail.com \
--cc=schwab@suse.de \
--cc=syzkaller@googlegroups.com \
--cc=tim.newsham@nccgroup.trust \
--cc=trinity@vger.kernel.org \
--cc=ynorov@caviumnetworks.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.