1. 01 10月, 2018 1 次提交
  2. 26 9月, 2018 1 次提交
  3. 20 9月, 2018 4 次提交
  4. 08 9月, 2018 3 次提交
  5. 05 9月, 2018 1 次提交
    • S
      tracing: Add back in rcu_irq_enter/exit_irqson() for rcuidle tracepoints · 865e63b0
      Steven Rostedt (VMware) 提交于
      Borislav reported the following splat:
      
       =============================
       WARNING: suspicious RCU usage
       4.19.0-rc1+ #1 Not tainted
       -----------------------------
       ./include/linux/rcupdate.h:631 rcu_read_lock() used illegally while idle!
       other info that might help us debug this:
      
       RCU used illegally from idle CPU!
       rcu_scheduler_active = 2, debug_locks = 1
       RCU used illegally from extended quiescent state!
       1 lock held by swapper/0/0:
        #0: 000000004557ee0e (rcu_read_lock){....}, at: perf_event_output_forward+0x0/0x130
      
       stack backtrace:
       CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.19.0-rc1+ #1
       Hardware name: LENOVO 2320CTO/2320CTO, BIOS G2ET86WW (2.06 ) 11/13/2012
       Call Trace:
        dump_stack+0x85/0xcb
        perf_event_output_forward+0xf6/0x130
        __perf_event_overflow+0x52/0xe0
        perf_swevent_overflow+0x91/0xb0
        perf_tp_event+0x11a/0x350
        ? find_held_lock+0x2d/0x90
        ? __lock_acquire+0x2ce/0x1350
        ? __lock_acquire+0x2ce/0x1350
        ? retint_kernel+0x2d/0x2d
        ? find_held_lock+0x2d/0x90
        ? tick_nohz_get_sleep_length+0x83/0xb0
        ? perf_trace_cpu+0xbb/0xd0
        ? perf_trace_buf_alloc+0x5a/0xa0
        perf_trace_cpu+0xbb/0xd0
        cpuidle_enter_state+0x185/0x340
        do_idle+0x1eb/0x260
        cpu_startup_entry+0x5f/0x70
        start_kernel+0x49b/0x4a6
        secondary_startup_64+0xa4/0xb0
      
      This is due to the tracepoints moving to SRCU usage which does not require
      RCU to be "watching". But perf uses these tracepoints with RCU and expects
      it to be. Hence, we still need to add in the rcu_irq_enter/exit_irqson()
      calls for "rcuidle" tracepoints. This is a temporary fix until we have SRCU
      working in NMI context, and then perf can be converted to use that instead
      of normal RCU.
      
      Link: http://lkml.kernel.org/r/20180904162611.6a120068@gandalf.local.home
      
      Cc: x86-ml <x86@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Reported-by: NBorislav Petkov <bp@alien8.de>
      Tested-by: NBorislav Petkov <bp@alien8.de>
      Reviewed-by: N"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Fixes: e6753f23 ("tracepoint: Make rcuidle tracepoint callers use SRCU")
      Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      865e63b0
  6. 04 9月, 2018 1 次提交
  7. 01 9月, 2018 2 次提交
    • D
      blkcg: delay blkg destruction until after writeback has finished · 59b57717
      Dennis Zhou (Facebook) 提交于
      Currently, blkcg destruction relies on a sequence of events:
        1. Destruction starts. blkcg_css_offline() is called and blkgs
           release their reference to the blkcg. This immediately destroys
           the cgwbs (writeback).
        2. With blkgs giving up their reference, the blkcg ref count should
           become zero and eventually call blkcg_css_free() which finally
           frees the blkcg.
      
      Jiufei Xue reported that there is a race between blkcg_bio_issue_check()
      and cgroup_rmdir(). To remedy this, blkg destruction becomes contingent
      on the completion of all writeback associated with the blkcg. A count of
      the number of cgwbs is maintained and once that goes to zero, blkg
      destruction can follow. This should prevent premature blkg destruction
      related to writeback.
      
      The new process for blkcg cleanup is as follows:
        1. Destruction starts. blkcg_css_offline() is called which offlines
           writeback. Blkg destruction is delayed on the cgwb_refcnt count to
           avoid punting potentially large amounts of outstanding writeback
           to root while maintaining any ongoing policies. Here, the base
           cgwb_refcnt is put back.
        2. When the cgwb_refcnt becomes zero, blkcg_destroy_blkgs() is called
           and handles destruction of blkgs. This is where the css reference
           held by each blkg is released.
        3. Once the blkcg ref count goes to zero, blkcg_css_free() is called.
           This finally frees the blkg.
      
      It seems in the past blk-throttle didn't do the most understandable
      things with taking data from a blkg while associating with current. So,
      the simplification and unification of what blk-throttle is doing caused
      this.
      
      Fixes: 08e18eab ("block: add bi_blkg to the bio for cgroups")
      Reviewed-by: NJosef Bacik <josef@toxicpanda.com>
      Signed-off-by: NDennis Zhou <dennisszhou@gmail.com>
      Cc: Jiufei Xue <jiufei.xue@linux.alibaba.com>
      Cc: Joseph Qi <joseph.qi@linux.alibaba.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Josef Bacik <josef@toxicpanda.com>
      Cc: Jens Axboe <axboe@kernel.dk>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      59b57717
    • D
      Revert "blk-throttle: fix race between blkcg_bio_issue_check() and cgroup_rmdir()" · 6b065462
      Dennis Zhou (Facebook) 提交于
      This reverts commit 4c699480.
      
      Destroying blkgs is tricky because of the nature of the relationship. A
      blkg should go away when either a blkcg or a request_queue goes away.
      However, blkg's pin the blkcg to ensure they remain valid. To break this
      cycle, when a blkcg is offlined, blkgs put back their css ref. This
      eventually lets css_free() get called which frees the blkcg.
      
      The above commit (4c699480) breaks this order of events by trying to
      destroy blkgs in css_free(). As the blkgs still hold references to the
      blkcg, css_free() is never called.
      
      The race between blkcg_bio_issue_check() and cgroup_rmdir() will be
      addressed in the following patch by delaying destruction of a blkg until
      all writeback associated with the blkcg has been finished.
      
      Fixes: 4c699480 ("blk-throttle: fix race between blkcg_bio_issue_check() and cgroup_rmdir()")
      Reviewed-by: NJosef Bacik <josef@toxicpanda.com>
      Signed-off-by: NDennis Zhou <dennisszhou@gmail.com>
      Cc: Jiufei Xue <jiufei.xue@linux.alibaba.com>
      Cc: Joseph Qi <joseph.qi@linux.alibaba.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Jens Axboe <axboe@kernel.dk>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      6b065462
  8. 31 8月, 2018 3 次提交
  9. 30 8月, 2018 1 次提交
    • M
      arm/arm64: smccc-1.1: Handle function result as parameters · 755a8bf5
      Marc Zyngier 提交于
      If someone has the silly idea to write something along those lines:
      
      	extern u64 foo(void);
      
      	void bar(struct arm_smccc_res *res)
      	{
      		arm_smccc_1_1_smc(0xbad, foo(), res);
      	}
      
      they are in for a surprise, as this gets compiled as:
      
      	0000000000000588 <bar>:
      	 588:   a9be7bfd        stp     x29, x30, [sp, #-32]!
      	 58c:   910003fd        mov     x29, sp
      	 590:   f9000bf3        str     x19, [sp, #16]
      	 594:   aa0003f3        mov     x19, x0
      	 598:   aa1e03e0        mov     x0, x30
      	 59c:   94000000        bl      0 <_mcount>
      	 5a0:   94000000        bl      0 <foo>
      	 5a4:   aa0003e1        mov     x1, x0
      	 5a8:   d4000003        smc     #0x0
      	 5ac:   b4000073        cbz     x19, 5b8 <bar+0x30>
      	 5b0:   a9000660        stp     x0, x1, [x19]
      	 5b4:   a9010e62        stp     x2, x3, [x19, #16]
      	 5b8:   f9400bf3        ldr     x19, [sp, #16]
      	 5bc:   a8c27bfd        ldp     x29, x30, [sp], #32
      	 5c0:   d65f03c0        ret
      	 5c4:   d503201f        nop
      
      The call to foo "overwrites" the x0 register for the return value,
      and we end up calling the wrong secure service.
      
      A solution is to evaluate all the parameters before assigning
      anything to specific registers, leading to the expected result:
      
      	0000000000000588 <bar>:
      	 588:   a9be7bfd        stp     x29, x30, [sp, #-32]!
      	 58c:   910003fd        mov     x29, sp
      	 590:   f9000bf3        str     x19, [sp, #16]
      	 594:   aa0003f3        mov     x19, x0
      	 598:   aa1e03e0        mov     x0, x30
      	 59c:   94000000        bl      0 <_mcount>
      	 5a0:   94000000        bl      0 <foo>
      	 5a4:   aa0003e1        mov     x1, x0
      	 5a8:   d28175a0        mov     x0, #0xbad
      	 5ac:   d4000003        smc     #0x0
      	 5b0:   b4000073        cbz     x19, 5bc <bar+0x34>
      	 5b4:   a9000660        stp     x0, x1, [x19]
      	 5b8:   a9010e62        stp     x2, x3, [x19, #16]
      	 5bc:   f9400bf3        ldr     x19, [sp, #16]
      	 5c0:   a8c27bfd        ldp     x29, x30, [sp], #32
      	 5c4:   d65f03c0        ret
      Reported-by: NJulien Grall <julien.grall@arm.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      755a8bf5
  10. 29 8月, 2018 2 次提交
  11. 27 8月, 2018 1 次提交
  12. 24 8月, 2018 6 次提交
  13. 23 8月, 2018 14 次提交