1. 21 10月, 2016 3 次提交
    • C
      Revert "clocksource/drivers/timer_sun5i: Replace code by clocksource_mmio_init" · 59387683
      Chen-Yu Tsai 提交于
      struct clocksource is also used by the clk notifier callback, to
      unregister and re-register the clocksource with a different clock rate.
      clocksource_mmio_init does not pass back a pointer to the struct used,
      and the clk notifier callback assumes that the struct clocksource in
      struct sun5i_timer_clksrc is valid. This results in a kernel NULL
      pointer dereference when the hstimer clock is changed:
      
      Unable to handle kernel NULL pointer dereference at virtual address 00000004
      [<c03a4678>] (clocksource_unbind) from [<c03a46d4>] (clocksource_unregister+0x2c/0x44)
      [<c03a46d4>] (clocksource_unregister) from [<c0a6f350>] (sun5i_rate_cb_clksrc+0x34/0x3c)
      [<c0a6f350>] (sun5i_rate_cb_clksrc) from [<c035ea50>] (notifier_call_chain+0x44/0x84)
      [<c035ea50>] (notifier_call_chain) from [<c035edc0>] (__srcu_notifier_call_chain+0x44/0x60)
      [<c035edc0>] (__srcu_notifier_call_chain) from [<c035edf4>] (srcu_notifier_call_chain+0x18/0x20)
      [<c035edf4>] (srcu_notifier_call_chain) from [<c0670174>] (__clk_notify+0x70/0x7c)
      [<c0670174>] (__clk_notify) from [<c06702c0>] (clk_propagate_rate_change+0xa4/0xc4)
      [<c06702c0>] (clk_propagate_rate_change) from [<c0670288>] (clk_propagate_rate_change+0x6c/0xc4)
      
      Revert the commit for now. clocksource_mmio_init can be made to pass back
      a pointer, but the code churn and usage of an inner struct might not be
      worth it.
      
      Fixes: 157dfade ("clocksource/drivers/timer_sun5i: Replace code by clocksource_mmio_init")
      Reported-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
      Signed-off-by: NChen-Yu Tsai <wens@csie.org>
      Cc: linux-sunxi@googlegroups.com
      Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
      Cc: linux-arm-kernel@lists.infradead.org
      Link: http://lkml.kernel.org/r/20161018054918.26855-1-wens@csie.orgSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      59387683
    • R
      clocksource: Add J-Core timer/clocksource driver · 9995f4f1
      Rich Felker 提交于
      At the hardware level, the J-Core PIT is integrated with the interrupt
      controller, but it is represented as its own device and has an
      independent programming interface. It provides a 12-bit countdown
      timer, which is not presently used, and a periodic timer. The interval
      length for the latter is programmable via a 32-bit throttle register
      whose units are determined by a bus-period register. The periodic
      timer is used to implement both periodic and oneshot clock event
      modes; in oneshot mode the interrupt handler simply disables the timer
      as soon as it fires.
      
      Despite its device tree node representing an interrupt for the PIT,
      the actual irq generated is programmable, not hard-wired. The driver
      is responsible for programming the PIT to generate the hardware irq
      number that the DT assigns to it.
      
      On SMP configurations, J-Core provides cpu-local instances of the PIT;
      no broadcast timer is needed. This driver supports the creation of the
      necessary per-cpu clock_event_device instances.
      
      A nanosecond-resolution clocksource is provided using the J-Core "RTC"
      registers, which give a 64-bit seconds count and 32-bit nanoseconds
      that wrap every second. The driver converts these to a full-range
      32-bit nanoseconds count.
      Signed-off-by: NRich Felker <dalias@libc.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: devicetree@vger.kernel.org
      Cc: linux-sh@vger.kernel.org
      Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
      Cc: Rob Herring <robh+dt@kernel.org>
      Link: http://lkml.kernel.org/r/b591ff12cc5ebf63d1edc98da26046f95a233814.1476393790.git.dalias@libc.orgSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      9995f4f1
    • R
      of: Add J-Core timer bindings · a2ce092b
      Rich Felker 提交于
      Signed-off-by: NRich Felker <dalias@libc.org>
      Acked-by: NRob Herring <robh@kernel.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: devicetree@vger.kernel.org
      Cc: linux-sh@vger.kernel.org
      Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
      Cc: Rob Herring <robh+dt@kernel.org>
      Link: http://lkml.kernel.org/r/8b107c292ed8cf8eed0fa283071fc8a930098628.1476393790.git.dalias@libc.orgSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      a2ce092b
  2. 19 10月, 2016 7 次提交
  3. 18 10月, 2016 8 次提交
  4. 17 10月, 2016 11 次提交
  5. 16 10月, 2016 11 次提交
    • D
      perf/x86/intel: Remove an inconsistent NULL check · 5c38181c
      Dan Carpenter 提交于
      Smatch complains that we don't check "event->ctx" consistently.  It's
      never NULL so we can just remove the check.
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: David Carrillo-Cisneros <davidcc@google.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Kan Liang <kan.liang@intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Cc: kernel-janitors@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      5c38181c
    • I
      1d33369d
    • D
      x86/e820: Don't merge consecutive E820_PRAM ranges · 23446cb6
      Dan Williams 提交于
      Commit:
      
        917db484 ("x86/boot: Fix kdump, cleanup aborted E820_PRAM max_pfn manipulation")
      
      ... fixed up the broken manipulations of max_pfn in the presence of
      E820_PRAM ranges.
      
      However, it also broke the sanitize_e820_map() support for not merging
      E820_PRAM ranges.
      
      Re-introduce the enabling to keep resource boundaries between
      consecutive defined ranges. Otherwise, for example, an environment that
      boots with memmap=2G!8G,2G!10G will end up with a single 4G /dev/pmem0
      device instead of a /dev/pmem0 and /dev/pmem1 device 2G in size.
      Reported-by: NDave Chinner <david@fromorbit.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      Cc: <stable@vger.kernel.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Jeff Moyer <jmoyer@redhat.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Zhang Yi <yizhan@redhat.com>
      Cc: linux-nvdimm@lists.01.org
      Fixes: 917db484 ("x86/boot: Fix kdump, cleanup aborted E820_PRAM max_pfn manipulation")
      Link: http://lkml.kernel.org/r/147629530854.10618.10383744751594021268.stgit@dwillia2-desk3.amr.corp.intel.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      23446cb6
    • J
      cpu/hotplug: Use distinct name for cpu_hotplug.dep_map · a705e07b
      Joonas Lahtinen 提交于
      Use distinctive name for cpu_hotplug.dep_map to avoid the actual
      cpu_hotplug.lock appearing as cpu_hotplug.lock#2 in lockdep splats.
      Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Acked-by: NGautham R. Shenoy <ego@linux.vnet.ibm.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Gautham R . Shenoy <ego@linux.vnet.ibm.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: intel-gfx@lists.freedesktop.org
      Cc: trivial@kernel.org
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      a705e07b
    • D
      kprobes: Unpoison stack in jprobe_return() for KASAN · 9f7d416c
      Dmitry Vyukov 提交于
      I observed false KSAN positives in the sctp code, when
      sctp uses jprobe_return() in jsctp_sf_eat_sack().
      
      The stray 0xf4 in shadow memory are stack redzones:
      
      [     ] ==================================================================
      [     ] BUG: KASAN: stack-out-of-bounds in memcmp+0xe9/0x150 at addr ffff88005e48f480
      [     ] Read of size 1 by task syz-executor/18535
      [     ] page:ffffea00017923c0 count:0 mapcount:0 mapping:          (null) index:0x0
      [     ] flags: 0x1fffc0000000000()
      [     ] page dumped because: kasan: bad access detected
      [     ] CPU: 1 PID: 18535 Comm: syz-executor Not tainted 4.8.0+ #28
      [     ] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      [     ]  ffff88005e48f2d0 ffffffff82d2b849 ffffffff0bc91e90 fffffbfff10971e8
      [     ]  ffffed000bc91e90 ffffed000bc91e90 0000000000000001 0000000000000000
      [     ]  ffff88005e48f480 ffff88005e48f350 ffffffff817d3169 ffff88005e48f370
      [     ] Call Trace:
      [     ]  [<ffffffff82d2b849>] dump_stack+0x12e/0x185
      [     ]  [<ffffffff817d3169>] kasan_report+0x489/0x4b0
      [     ]  [<ffffffff817d31a9>] __asan_report_load1_noabort+0x19/0x20
      [     ]  [<ffffffff82d49529>] memcmp+0xe9/0x150
      [     ]  [<ffffffff82df7486>] depot_save_stack+0x176/0x5c0
      [     ]  [<ffffffff817d2031>] save_stack+0xb1/0xd0
      [     ]  [<ffffffff817d27f2>] kasan_slab_free+0x72/0xc0
      [     ]  [<ffffffff817d05b8>] kfree+0xc8/0x2a0
      [     ]  [<ffffffff85b03f19>] skb_free_head+0x79/0xb0
      [     ]  [<ffffffff85b0900a>] skb_release_data+0x37a/0x420
      [     ]  [<ffffffff85b090ff>] skb_release_all+0x4f/0x60
      [     ]  [<ffffffff85b11348>] consume_skb+0x138/0x370
      [     ]  [<ffffffff8676ad7b>] sctp_chunk_put+0xcb/0x180
      [     ]  [<ffffffff8676ae88>] sctp_chunk_free+0x58/0x70
      [     ]  [<ffffffff8677fa5f>] sctp_inq_pop+0x68f/0xef0
      [     ]  [<ffffffff8675ee36>] sctp_assoc_bh_rcv+0xd6/0x4b0
      [     ]  [<ffffffff8677f2c1>] sctp_inq_push+0x131/0x190
      [     ]  [<ffffffff867bad69>] sctp_backlog_rcv+0xe9/0xa20
      [ ... ]
      [     ] Memory state around the buggy address:
      [     ]  ffff88005e48f380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      [     ]  ffff88005e48f400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      [     ] >ffff88005e48f480: f4 f4 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      [     ]                    ^
      [     ]  ffff88005e48f500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      [     ]  ffff88005e48f580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      [     ] ==================================================================
      
      KASAN stack instrumentation poisons stack redzones on function entry
      and unpoisons them on function exit. If a function exits abnormally
      (e.g. with a longjmp like jprobe_return()), stack redzones are left
      poisoned. Later this leads to random KASAN false reports.
      
      Unpoison stack redzones in the frames we are going to jump over
      before doing actual longjmp in jprobe_return().
      Signed-off-by: NDmitry Vyukov <dvyukov@google.com>
      Acked-by: NMasami Hiramatsu <mhiramat@kernel.org>
      Reviewed-by: NMark Rutland <mark.rutland@arm.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
      Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Cc: Alexander Potapenko <glider@google.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
      Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: kasan-dev@googlegroups.com
      Cc: surovegin@google.com
      Cc: rostedt@goodmis.org
      Link: http://lkml.kernel.org/r/1476454043-101898-1-git-send-email-dvyukov@google.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      9f7d416c
    • D
      kprobes: Avoid false KASAN reports during stack copy · 9254139a
      Dmitry Vyukov 提交于
      Kprobes save and restore raw stack chunks with memcpy().
      With KASAN these chunks can contain poisoned stack redzones,
      as the result memcpy() interceptor produces false
      stack out-of-bounds reports.
      
      Use __memcpy() instead of memcpy() for stack copying.
      __memcpy() is not instrumented by KASAN and does not lead
      to the false reports.
      
      Currently there is a spew of KASAN reports during boot
      if CONFIG_KPROBES_SANITY_TEST is enabled:
      
      [   ] Kprobe smoke test: started
      [   ] ==================================================================
      [   ] BUG: KASAN: stack-out-of-bounds in setjmp_pre_handler+0x17c/0x280 at addr ffff88085259fba8
      [   ] Read of size 64 by task swapper/0/1
      [   ] page:ffffea00214967c0 count:0 mapcount:0 mapping:          (null) index:0x0
      [   ] flags: 0x2fffff80000000()
      [   ] page dumped because: kasan: bad access detected
      [...]
      Reported-by: NCAI Qian <caiqian@redhat.com>
      Tested-by: NCAI Qian <caiqian@redhat.com>
      Signed-off-by: NDmitry Vyukov <dvyukov@google.com>
      Acked-by: NMasami Hiramatsu <mhiramat@kernel.org>
      Cc: Alexander Potapenko <glider@google.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: kasan-dev@googlegroups.com
      [ Improved various details. ]
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      9254139a
    • J
      objtool: Skip all "unreachable instruction" warnings for gcov kernels · 9cfffb11
      Josh Poimboeuf 提交于
      Recently objtool has started reporting a few "unreachable instruction"
      warnings when CONFIG_GCOV is enabled for newer versions of GCC.  Usually
      this warning means there's some new control flow that objtool doesn't
      understand.  But in this case, objtool is correct and the instructions
      really are inaccessible.  It's an annoying quirk of gcov, but it's
      harmless, so it's ok to just silence the warnings.
      
      With older versions of GCC, it was relatively easy to detect
      gcov-specific instructions and to skip any unreachable warnings produced
      by them.  But GCC 6 has gotten craftier.
      
      Instead of continuing to play whack-a-mole with gcov, just use a bigger,
      more permanent hammer and disable unreachable warnings for the whole
      file when gcov is enabled.  This is fine to do because a) unreachable
      warnings are usually of questionable value; and b) gcov isn't used for
      production kernels and we can relax the checks a bit there.
      Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
      Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/38d5c87d61d9cd46486dd2c86f46603dff0df86f.1476393584.git.jpoimboe@redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      9cfffb11
    • J
      objtool: Improve rare switch jump table pattern detection · 3732710f
      Josh Poimboeuf 提交于
      GCC 6 added a new switch statement jump table optimization which makes
      objtool's life harder.  It looks like:
      
        mov [rodata addr],%reg1
        ... some instructions ...
        jmpq *(%reg1,%reg2,8)
      
      The optimization is quite rare, but objtool still needs to be able to
      identify the pattern so that it can follow all possible control flow
      paths related to the switch statement.
      
      In order to detect the pattern, objtool starts from the indirect jump
      and scans backwards through the function until it finds the first
      instruction in the pattern.  If it encounters an unconditional jump
      along the way, it stops and considers the pattern to be not found.
      
      As it turns out, unconditional jumps can happen, as long as they are
      small forward jumps within the range being scanned.
      
      This fixes the following warnings:
      
        drivers/infiniband/sw/rxe/rxe_comp.o: warning: objtool: rxe_completer()+0x2f4: sibling call from callable instruction with changed frame pointer
        drivers/infiniband/sw/rxe/rxe_resp.o: warning: objtool: rxe_responder()+0x10f: sibling call from callable instruction with changed frame pointer
      Reported-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/8a9ed68ae1780e8d3963e4ee13f2f257fe3a3c33.1476393584.git.jpoimboe@redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      3732710f
    • L
      Linux 4.9-rc1 · 1001354c
      Linus Torvalds 提交于
      1001354c
    • L
      Merge tag 'befs-v4.9-rc1' of git://github.com/luisbg/linux-befs · df34d04a
      Linus Torvalds 提交于
      Pull befs fixes from Luis de Bethencourt:
       "I recently took maintainership of the befs file system [0]. This is
        the first time I send you a git pull request, so please let me know if
        all the below is OK.
      
        Salah Triki and myself have been cleaning the code and fixing a few
        small bugs.
      
        Sorry I couldn't send this sooner in the merge window, I was waiting
        to have my GPG key signed by kernel members at ELCE in Berlin a few
        days ago."
      
      [0] https://lkml.org/lkml/2016/7/27/502
      
      * tag 'befs-v4.9-rc1' of git://github.com/luisbg/linux-befs: (39 commits)
        befs: befs: fix style issues in datastream.c
        befs: improve documentation in datastream.c
        befs: fix typos in datastream.c
        befs: fix typos in btree.c
        befs: fix style issues in super.c
        befs: fix comment style
        befs: add check for ag_shift in superblock
        befs: dump inode_size superblock information
        befs: remove unnecessary initialization
        befs: fix typo in befs_sb_info
        befs: add flags field to validate superblock state
        befs: fix typo in befs_find_key
        befs: remove unused BEFS_BT_PARMATCH
        fs: befs: remove ret variable
        fs: befs: remove in vain variable assignment
        fs: befs: remove unnecessary *befs_sb variable
        fs: befs: remove useless initialization to zero
        fs: befs: remove in vain variable assignment
        fs: befs: Insert NULL inode to dentry
        fs: befs: Remove useless calls to brelse in befs_find_brun_dblindirect
        ...
      df34d04a
    • L
      Merge tag 'gcc-plugins-v4.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux · 9ffc6694
      Linus Torvalds 提交于
      Pull gcc plugins update from Kees Cook:
       "This adds a new gcc plugin named "latent_entropy". It is designed to
        extract as much possible uncertainty from a running system at boot
        time as possible, hoping to capitalize on any possible variation in
        CPU operation (due to runtime data differences, hardware differences,
        SMP ordering, thermal timing variation, cache behavior, etc).
      
        At the very least, this plugin is a much more comprehensive example
        for how to manipulate kernel code using the gcc plugin internals"
      
      * tag 'gcc-plugins-v4.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux:
        latent_entropy: Mark functions with __latent_entropy
        gcc-plugins: Add latent_entropy plugin
      9ffc6694