On Fri, Sep 11, 2015 at 10:19:47AM +0800, Boqun Feng wrote:
> Subject: [PATCH 01/27] rcu: Don't disable preemption for Tiny and Tree RCU
> Because preempt_disable() maps to barrier() for non-debug builds,
> it forces the compiler to spill and reload registers. Because Tree
> RCU and Tiny RCU now only appear in CONFIG_PREEMPT=n builds, these
> barrier() instances generate needless extra code for each instance of
> rcu_read_lock() and rcu_read_unlock(). This extra code slows down Tree
> RCU and bloats Tiny RCU.
> This commit therefore removes the preempt_disable() and preempt_enable()
> from the non-preemptible implementations of __rcu_read_lock() and
> __rcu_read_unlock(), respectively.
> For debug purposes, preempt_disable() and preempt_enable() are still
> kept if CONFIG_PREEMPT_COUNT=y, which makes the detection of sleeping
> inside atomic sections still work in non-preemptible kernels.
> Signed-off-by: Boqun Feng <boqun.feng(a)gmail.com>
> Signed-off-by: Paul E. McKenney <paulmck(a)linux.vnet.ibm.com>
> include/linux/rcupdate.h | 6 ++++--
> include/linux/rcutiny.h | 1 +
> kernel/rcu/tree.c | 9 +++++++++
> 3 files changed, 14 insertions(+), 2 deletions(-)
> diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> index d63bb77..6c3cece 100644
> --- a/include/linux/rcupdate.h
> +++ b/include/linux/rcupdate.h
> @@ -297,12 +297,14 @@ void synchronize_rcu(void);
> static inline void __rcu_read_lock(void)
> - preempt_disable();
> + if (IS_ENABLED(CONFIG_PREEMPT_COUNT))
> + preempt_disable();
preempt_disable() is a no-op when !CONFIG_PREEMPT_COUNT, right?
Or rather it's a barrier(), which is anyway implied by rcu_read_lock().
So perhaps we can get rid of the IS_ENABLED() check?
Hi Fengguang / LKP-folk,
Quick question -- how easy is it to add extra builds/tests/checks to
your marvellous 0-day kbuild system?
The reason I ask is that I've recently been exploring syzkaller ,
which is a system call fuzzer written by some of my colleagues here at
Google (cc'ed). Although it's fairly new, it has uncovered a bunch of
kernel bugs already  so I wondered if it might be a good candidate
for inclusion in the 0-day checks at some point.
(As an aside, I'm in the process of writing an article about syzkaller
for LWN, which might also expose it to more folk.)
What do you think?
Would it make sense to add some basic Xen PV testing to the kbuild bot?
qemu can boot Xen like this:
qemu-system-x86_64 -kernel path/to/xen-4.5.2 -initrd 'path/to/bzImage
kernelarg otherkernelarg=value" -append 'xenarg other_xen_arg'
This should work with any kernel image for x86 or x86_64 with CONFIG_XEN=y.
Linux has never been been able to do virtio under Xen, which will
screw up your scripts, but I'm cautiously optimistic that virtio will
work as expected on a Xen guest starting with Linux 4.6. If you want
to play around, it should work in this tree:
I'm hoping to get that queued up for real in the next couple of days.
On Tue, Mar 29, 2016 at 8:49 AM, Toshi Kani <toshi.kani(a)hpe.com> wrote:
> On Tue, 2016-03-29 at 10:46 -0400, Boris Ostrovsky wrote:
>> On 03/29/2016 10:19 AM, Toshi Kani wrote:
>> > On Tue, 2016-03-29 at 12:34 +0200, Ingo Molnar wrote:
>> > > > I'd appreciate if someone can test this patch-set on Xen to verify
>> > > > that there is no change in "x86/PAT: Configuration [0-7] .."
>> > > > message in dmesg.
>> > > So I don't have a Xen setup, but hopefully such testing will happen
>> > > once these changes show up in linux-next, tomorrow or so.
>> > I will address if any issue is found in testing.
>> I ran a subset of out nightly test. Nobody died.
>> So this all looks good. (It actually may have also fixed another bug
>> that was reported recently by Olaf, copied here)
> Cool! Thanks Boris!
Hoping Boris or someone on the Xen front would test this prior to
merging helps but it also slows us down, a while ago we discussed the
possibility of getting Linux Xen guests automatically tested as part
of 0-day, this way then when a developer (in this case Toshi) pushes
to his own tree, he'd be able to just sit and wait for the results,
without having to hope Boris or someone goes out and tests.
Its a major undertaking to get Linux Xen guests boot strapped into
0-day, however such prospects were raised a while ago and it seems we
may be able to get there. Just wanted to send a reminder about this
possibility, and highlight this patch set as an ideal candidate where
a proactive test could have helped as well. I proactively caught the
original Xen issue, but git logs shows we are not doing so great in
this area, so any help on the Xen side as well to help with 0-day
integration would be appreciated.
I'll follow up on another thread on that.
On Thu, Jan 21, 2016 at 11:17 AM, Luis R. Rodriguez
> On Tue, Aug 25, 2015 at 1:47 PM, Fengguang Wu <fengguang.wu(a)intel.com> wrote:
>> On Tue, Aug 25, 2015 at 04:37:37PM -0400, Konrad Rzeszutek Wilk wrote:
>>> On Wed, Aug 26, 2015 at 04:29:10AM +0800, Fengguang Wu wrote:
>>> > Hi Vitaly,
>>> > On Tue, Aug 25, 2015 at 02:11:57AM -0700, Vitaly Kuznetsov wrote:
>>> > > "Luis R. Rodriguez" <mcgrof(a)do-not-panic.com> writes:
>>> > >
>>> > > >> Robert Hu is from Intel VT QA team. I synced with him and it looks
>>> > > >> possible for him to bootstrap Xen from PXE, which is how 0day
>>> > > >> bootstraps Linux kernel. We rely mainly on kexec for kernel testing,
>>> > > >> not sure if that's possible for Xen.
>>> > > >
>>> > > > Kexec support requires some more work, the status of which Vitaly and
>>> > > > Olaf may be able to provide best.
>>> > > >
>>> > >
>>> > > (not sure which kexec was meant here: for Xen hypervisor itself, for
>>> > > hardware domain (aka Dom0) or for guest domains. In case guest kexec is
>>> > > required read the below comment:)
>>> > It is kexec support for the test target, eg. Xen hypervisor if we are
>>> > going to test/bisect it and switch among its different git commits from
>>> > time to time.
>>> It should work. Make sure you have the latest version of kexec and you
>>> build it against the version of Xen you are booting.
>> That'd be great! Thanks for the info!
> Fengguang, curious if there was some effort in this area.
> Also since we have tons of test suites out there in the wild a while
> ago I had asked help by LF admins for a wiki we could use to
> centralize documentation. Projects might have their own wiki already /
> project home page, but we didn't have anything centric, we also didn't
> have a place where any test work could just create their own page
> should they want to avoid that and instead use an existing wiki. To
> help with this we now have this:
> If your test work has no public page it can use that. I've tried to
> document things I know of already. My understanding is zero day bot
> has no central documentation wiki, perhaps we can use that as its home
I've updated the wiki to point to the new 0-day home page but still
curious about ongoing efforts over Xen integration. I realize the task
at hand is huge undertaking -- but just curious if its on the roadmap.
Thanks so much for all your awesome work folks!