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?
I am working on KASLR (PIE for x86_64). I previously used Kees (CCed)
branches for lkp bot testing but someone told be I could ask you to add a
custom github path to monitor all branches on it.
I pushed my changes to: https://github.com/thgarnie/linux (kasrl_pie_v2
Can you add it? Anything I need to do?
FYI, we noticed the following commit (built with gcc-7):
commit: 5209e8ac937261925c12db63a28cfaa033fa30ed ("x86/unwinder: Handle stack overflows more gracefully")
in testcase: vm-scalability
with following parameters:
test-description: The motivation behind this suite is to exercise functions and regions of the mm/ of the Linux kernel which are of interest to us.
on test machine: 144 threads Intel(R) Xeon(R) CPU E7-8890 v3 @ 2.50GHz with 512G memory
caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
kern :warn : [ 188.061048] WARNING: can't dereference registers at 000000003fb3add8 for ip ret_from_intr+0x6/0x19
kern :warn : [ 190.564038] WARNING: stack recursion on stack type 1
On Fri, Apr 27, 2018 at 06:52:58PM -0600, Jens Axboe wrote:
>On 4/24/18 3:00 PM, kernel test robot wrote:
>> 0day kernel testing robot got the below dmesg and the first bad commit is
>> https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git for-linus
>> commit ed74ae03424684a6ad8a973c3fa727c6b4162432
>> Author: Bart Van Assche <bart.vanassche(a)wdc.com>
>> AuthorDate: Thu Apr 19 09:43:53 2018 -0700
>> Commit: Jens Axboe <axboe(a)kernel.dk>
>> CommitDate: Thu Apr 19 14:21:47 2018 -0600
>> blk-mq: Avoid that a completion can be ignored for BLK_EH_RESET_TIMER
>Any chance you can try with the newer version?
Tested-by: Fengguang Wu <fengguang.wu(a)intel.com>