lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 20 Feb 2017 11:03:52 +0800 From: Fengguang Wu <fengguang.wu@...el.com> To: Borislav Petkov <bp@...e.de> Cc: LKP <lkp@...org>, lkml <linux-kernel@...r.kernel.org>, Ye Xiaolong <xiaolong.ye@...el.com>, Philip Li <philip.li@...el.com>, Huang Ying <ying.huang@...el.com> Subject: Re: [clear_page] 0ad07c8104 BUG: unable to handle kernel NULL pointer dereference at 0000000000000040 Hi Borislav, On Sun, Feb 19, 2017 at 02:50:19PM +0100, Borislav Petkov wrote: >On Sun, Feb 19, 2017 at 09:06:51AM +0800, Fengguang Wu wrote: >> Yes if we add it as a line below the branch URL, it could be a time saver. > >Right. > >> Since it's hard to teach ALL people about the rule, it'd be best if we >> can work w/o any rules -- unless you want to be accurate&helpful or to >> customize test behaviors. >> >> Since we already tested the original patch/commit (hence the report), >> we should know where the fixup should be applied to. And it'd be >> reasonably easy to tell whether the fix is incremental or a >> replacement -- just try git-am onto the original commit first, if >> failed, continue to try the parent commit. For old bugs the fix could >> be against linus/master or linux-next/master, which could be tried too. > >Makes sense. > >> Yes, that'd be most convenient. In general the email interface could >> be something like this: >> >> # "key: value" fields; if you Re: to an earlier bug report, they can be auto retrieved >> compiler: gcc-6 # optional >> base-commit: v4.10-rc8 # the robot knows kernel commits from hundreds of public git trees >> --- >> the patch >> --- >> attach kconfig files > >Yap, just stick those rules somewhere on a website. OK, will do when the feature is ready. According to Xiaolong, the automated test-of-fixup-patches feature is already in our plan. For introductions of the now-working build/boot test services and instructions on customization, we could probably add some markdown document under https://github.com/fengguang/lkp-tests/tree/master/doc Philip/Ying, what do you think? I can draft it. >Btw, this is not only useful for a follow-on, fix patch but also for >initial test request. For example, I want to backport patch to stable >and would like to run it on a bunch of kernels: > >base-commit: v4.4-stable, v4.9-stable, ... > >i.e., a list of trees to apply it to. I believe people might like this a >lot. > >Or, for example, a patch touching a bunch of arches and author doesn't >necessarily have access to all those different toolchains. Shoot a mail >to the 0day bot: > >base-commit: linus/master >arch: x86_64, powerpc, sparc, ... > >Would be very useful too. We actually already test LKML patch in that way (Xiaolong maintains this feature). Nevertheless if developers specify "base-commit:" it could help eliminate the guessing works by the dumb robot. We'll appreciate if the "base-commit:" or "base-patchid:" tags are listed in the patches, especially in some non-obvious situations. Such tags could be regarded as "explicit" test requests, where we could send "BUILD COMPLETE" emails as a response (comparing to our normal LKML patch tests, which only build regressions will trigger an email notification). >Anyway, just a couple of ideas. > >What would also be cool if you guys had a 0day bot howto with all those >things we should pay attention to and we can go and look up. OK. Your ideas are very welcome, thanks! Regards, Fengguang
Powered by blists - more mailing lists