Skip to content

L
linux
Switch branch/tag
  1. 17 Jan, 2018 1 commit
  3. 12 Jan, 2018 3 commits
  5. 11 Jan, 2018 3 commits
    • Ingo Molnar's avatar
      Merge tag 'perf-core-for-mingo-4.16-20180110' of... · 1ccb8fed
      Ingo Molnar authored 
      Merge tag 'perf-core-for-mingo-4.16-20180110' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core

Pull perf/core improvements and fixes from Arnaldo Carvalho de Melo:

- The 'perf test bpf' entry hooked a eBPF proggie to the
  SyS_epoll_wait() kernel function and expected it to be hit when calling
  the epoll_wait() libc wrapper, which changed recently, in systems such
  as Fedora 27, with the glibc wrapper calling instead the epoll_pwait()
  syscall, so switch to epoll_pwait() for both the kernel and libc
  function, getting it to work both in old and new systems (Arnaldo Carvalho de Melo)

- Beautify 'gettid' syscall result in 'perf trace', and in doing so
  noticed that we need to handle namespaces in 'perf trace', will be
  dealt with in follow up patches where we'll try to figure out if
  the recent support for namespace in tools/perf/ can be used for this
  purpose as well. (Arnaldo Carvalho de Melo)

- Introduce 'perf report --mmaps' and 'perf report --tasks' to show
  info present in 'perf.data' (Jiri Olsa, Arnaldo Carvalho de Melo)

- Synchronize kernel <-> tooling headers wrt meltdown/spectre changes
  (Arnaldo Carvalho de Melo)

- Fix a wrong offset issue when using /proc/kcore (Jin Yao)

- Fix bug that prevented annotating symbols in perf.data files
  generated with 'perf record --branch-any'  (Jin Yao)

- Add infrastructure to record first and last sample time to the
  perf.data file header, so that when processing all samples in
  a 'perf record' session, such as when doing build-id processing,
  or when specifically requesting that that info be recorded, use
  that in 'perf report --time', that also got support for percent
  slices in addition to absolute ones.

  I.e. now it is possible to ask for the samples in the 10%-20%
  time slice of a perf.data file (Jin Yao)

- Enable building with libbabeltrace by default (Jiri Olsa)

- Display perf_event_attr::namespaces when duping the attributes
  in verbose mode (Jiri Olsa)

- Allocate context task_ctx_data for child event (Jiri Olsa)

- Update comments for PERF_RECORD_ITRACE_START and PERF_RECORD_MISC_* (Jiri Olsa)

- Add support for showing PERF_RECORD_LOST events in 'perf script' (Jiri Olsa)

- Add 'perf report --stats' option to display quick statistics about
  metadata events (PERF_RECORD_*) i.e. what we get at the end of 'perf
  report -D' (Jiri Olsa)

- Fix compile error with libunwind x86 (Wang Nan)
Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      1ccb8fed
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs · cbd0a6a2
      Linus Torvalds authored 
      Pull vfs regression fix from Al Viro/

Fix a leak in socket() introduced by commit 8e1611e2 ("make
sock_alloc_file() do sock_release() on failures").

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
  Fix a leak in socket(2) when we fail to allocate a file descriptor.
      cbd0a6a2
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net · 64fce444
      Linus Torvalds authored 
      Pull networking fixes from David Miller:

 1) BPF speculation prevention and BPF_JIT_ALWAYS_ON, from Alexei
    Starovoitov.

 2) Revert dev_get_random_name() changes as adjust the error code
    returns seen by userspace definitely breaks stuff.

 3) Fix TX DMA map/unmap on older iwlwifi devices, from Emmanuel
    Grumbach.

 4) From wrong AF family when requesting sock diag modules, from Andrii
    Vladyka.

 5) Don't add new ipv6 routes attached to the null_entry, from Wei Wang.

 6) Some SCTP sockopt length fixes from Marcelo Ricardo Leitner.

 7) Don't leak when removing VLAN ID 0, from Cong Wang.

 8) Hey there's a potential leak in ipv6_make_skb() too, from Eric
    Dumazet.

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (27 commits)
  ipv6: sr: fix TLVs not being copied using setsockopt
  ipv6: fix possible mem leaks in ipv6_make_skb()
  mlxsw: spectrum_qdisc: Don't use variable array in mlxsw_sp_tclass_congestion_enable
  mlxsw: pci: Wait after reset before accessing HW
  nfp: always unmask aux interrupts at init
  8021q: fix a memory leak for VLAN 0 device
  of_mdio: avoid MDIO bus removal when a PHY is missing
  caif_usb: use strlcpy() instead of strncpy()
  doc: clarification about setting SO_ZEROCOPY
  net: gianfar_ptp: move set_fipers() to spinlock protecting area
  sctp: make use of pre-calculated len
  sctp: add a ceiling to optlen in some sockopts
  sctp: GFP_ATOMIC is not needed in sctp_setsockopt_events
  bpf: introduce BPF_JIT_ALWAYS_ON config
  bpf: avoid false sharing of map refcount with max_entries
  ipv6: remove null_entry before adding default route
  SolutionEngine771x: add Ether TSU resource
  SolutionEngine771x: fix Ether platform data
  docs-rst: networking: wire up msg_zerocopy
  net: ipv4: emulate READ_ONCE() on ->hdrincl bit-field in raw_sendmsg()
  ...
      64fce444
  7. 10 Jan, 2018 27 commits
  9. 09 Jan, 2018 6 commits
    • Linus Torvalds's avatar
      Merge tag 'riscv-for-linus-4.15-rc8_cleanups' of... · cf1fb158
      Linus Torvalds authored 
      Merge tag 'riscv-for-linus-4.15-rc8_cleanups' of git://git.kernel.org/pub/scm/linux/kernel/git/palmer/linux

Pull RISC-V updates from Palmer Dabbelt:
 "This contains what I hope are the last RISC-V changes to go into 4.15.
  I know it's a bit last minute, but I think they're all fairly small
  changes:

   - SR_* constants have been renamed to match the latest ISA
     specification.

   - Some CONFIG_MMU #ifdef cruft has been removed. We've never
     supported !CONFIG_MMU.

   - __NR_riscv_flush_icache is now visible to userspace. We were hoping
     to avoid making this public in order to force userspace to call the
     vDSO entry, but it looks like QEMU's user-mode emulation doesn't
     want to emulate a vDSO. In order to allow glibc to fall back to a
     system call when the vDSO entry doesn't exist we're just

   - Our defconfig is no long empty. This is another one that just
     slipped through the cracks. The defconfig isn't perfect, but it's
     at least close to what users will want for the first RISC-V
     development board. Getting closer is kind of splitting hairs here:
     none of the RISC-V specific drivers are in yet, so it's not like
     things will boot out of the box.

  The only one that's strictly necessary is the __NR_riscv_flush_icache
  change, as I want that to be part of the public API starting from our
  first kernel so nobody has to worry about it. The others are nice to
  haves, but they seem sane for 4.15 to me"

* tag 'riscv-for-linus-4.15-rc8_cleanups' of git://git.kernel.org/pub/scm/linux/kernel/git/palmer/linux:
  riscv: rename SR_* constants to match the spec
  riscv: remove CONFIG_MMU ifdefs
  RISC-V: Make __NR_riscv_flush_icache visible to userspace
  RISC-V: Add a basic defconfig
      cf1fb158
    • Linus Torvalds's avatar
      Merge branch 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus · 44cae9b2
      Linus Torvalds authored 
      Pull MIPS fixes from Ralf Baechle:
 "Another round of MIPS fixes for 4.15.

   - Maciej Rozycki found another series of FP issues which requires a
     seven part series to restructure and fix.

   - James fixes a warning about .set mt which gas doesn't like when
     building for R1 processors"

* 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
  MIPS: Validate PR_SET_FP_MODE prctl(2) requests against the ABI of the task
  MIPS: Disallow outsized PTRACE_SETREGSET NT_PRFPREG regset accesses
  MIPS: Also verify sizeof `elf_fpreg_t' with PTRACE_SETREGSET
  MIPS: Fix an FCSR access API regression with NT_PRFPREG and MSA
  MIPS: Consistently handle buffer counter with PTRACE_SETREGSET
  MIPS: Guard against any partial write attempt with PTRACE_SETREGSET
  MIPS: Factor out NT_PRFPREG regset access helpers
  MIPS: CPS: Fix r1 .set mt assembler warning
      44cae9b2
    • Alexei Starovoitov's avatar
      bpf: introduce BPF_JIT_ALWAYS_ON config · 290af866
      Alexei Starovoitov authored 
      The BPF interpreter has been used as part of the spectre 2 attack CVE-2017-5715.

A quote from goolge project zero blog:
"At this point, it would normally be necessary to locate gadgets in
the host kernel code that can be used to actually leak data by reading
from an attacker-controlled location, shifting and masking the result
appropriately and then using the result of that as offset to an
attacker-controlled address for a load. But piecing gadgets together
and figuring out which ones work in a speculation context seems annoying.
So instead, we decided to use the eBPF interpreter, which is built into
the host kernel - while there is no legitimate way to invoke it from inside
a VM, the presence of the code in the host kernel's text section is sufficient
to make it usable for the attack, just like with ordinary ROP gadgets."

To make attacker job harder introduce BPF_JIT_ALWAYS_ON config
option that removes interpreter from the kernel in favor of JIT-only mode.
So far eBPF JIT is supported by:
x64, arm64, arm32, sparc64, s390, powerpc64, mips64

The start of JITed program is randomized and code page is marked as read-only.
In addition "constant blinding" can be turned on with net.core.bpf_jit_harden

v2->v3:
- move __bpf_prog_ret0 under ifdef (Daniel)

v1->v2:
- fix init order, test_bpf and cBPF (Daniel's feedback)
- fix offloaded bpf (Jakub's feedback)
- add 'return 0' dummy in case something can invoke prog->bpf_func
- retarget bpf tree. For bpf-next the patch would need one extra hunk.
  It will be sent when the trees are merged back to net-next

Considered doing:
  int bpf_jit_enable __read_mostly = BPF_EBPF_JIT_DEFAULT;
but it seems better to land the patch as-is and in bpf-next remove
bpf_jit_enable global variable from all JITs, consolidate in one place
and remove this jit_init() function.
Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      290af866
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.dk/linux-block · d476c533
      Linus Torvalds authored 
      Pull block fixes from Jens Axboe:
 "A set of fixes that should go into this release. This contains:

   - An NVMe pull request from Christoph, with a few critical fixes for
     NVMe.

   - A block drain queue fix from Ming.

   - The concurrent lo_open/release fix for loop"

* 'for-linus' of git://git.kernel.dk/linux-block:
  loop: fix concurrent lo_open/lo_release
  block: drain queue before waiting for q_usage_counter becoming zero
  nvme-fcloop: avoid possible uninitialized variable warning
  nvme-mpath: fix last path removal during traffic
  nvme-rdma: fix concurrent reset and reconnect
  nvme: fix sector units when going between formats
  nvme-pci: move use_sgl initialization to nvme_init_iod()
      d476c533
    • Daniel Borkmann's avatar
      bpf: avoid false sharing of map refcount with max_entries · be95a845
      Daniel Borkmann authored 
      In addition to commit b2157399 ("bpf: prevent out-of-bounds
speculation") also change the layout of struct bpf_map such that
false sharing of fast-path members like max_entries is avoided
when the maps reference counter is altered. Therefore enforce
them to be placed into separate cachelines.

pahole dump after change:

  struct bpf_map {
        const struct bpf_map_ops  * ops;                 /*     0     8 */
        struct bpf_map *           inner_map_meta;       /*     8     8 */
        void *                     security;             /*    16     8 */
        enum bpf_map_type          map_type;             /*    24     4 */
        u32                        key_size;             /*    28     4 */
        u32                        value_size;           /*    32     4 */
        u32                        max_entries;          /*    36     4 */
        u32                        map_flags;            /*    40     4 */
        u32                        pages;                /*    44     4 */
        u32                        id;                   /*    48     4 */
        int                        numa_node;            /*    52     4 */
        bool                       unpriv_array;         /*    56     1 */

        /* XXX 7 bytes hole, try to pack */

        /* --- cacheline 1 boundary (64 bytes) --- */
        struct user_struct *       user;                 /*    64     8 */
        atomic_t                   refcnt;               /*    72     4 */
        atomic_t                   usercnt;              /*    76     4 */
        struct work_struct         work;                 /*    80    32 */
        char                       name[16];             /*   112    16 */
        /* --- cacheline 2 boundary (128 bytes) --- */

        /* size: 128, cachelines: 2, members: 17 */
        /* sum members: 121, holes: 1, sum holes: 7 */
  };

Now all entries in the first cacheline are read only throughout
the life time of the map, set up once during map creation. Overall
struct size and number of cachelines doesn't change from the
reordering. struct bpf_map is usually first member and embedded
in map structs in specific map implementations, so also avoid those
members to sit at the end where it could potentially share the
cacheline with first map values e.g. in the array since remote
CPUs could trigger map updates just as well for those (easily
dirtying members like max_entries intentionally as well) while
having subsequent values in cache.

Quoting from Google's Project Zero blog [1]:

  Additionally, at least on the Intel machine on which this was
  tested, bouncing modified cache lines between cores is slow,
  apparently because the MESI protocol is used for cache coherence
  [8]. Changing the reference counter of an eBPF array on one
  physical CPU core causes the cache line containing the reference
  counter to be bounced over to that CPU core, making reads of the
  reference counter on all other CPU cores slow until the changed
  reference counter has been written back to memory. Because the
  length and the reference counter of an eBPF array are stored in
  the same cache line, this also means that changing the reference
  counter on one physical CPU core causes reads of the eBPF array's
  length to be slow on other physical CPU cores (intentional false
  sharing).

While this doesn't 'control' the out-of-bounds speculation through
masking the index as in commit b2157399, triggering a manipulation
of the map's reference counter is really trivial, so lets not allow
to easily affect max_entries from it.

Splitting to separate cachelines also generally makes sense from
a performance perspective anyway in that fast-path won't have a
cache miss if the map gets pinned, reused in other progs, etc out
of control path, thus also avoids unintentional false sharing.

  [1] https://googleprojectzero.blogspot.ch/2018/01/reading-privileged-memory-with-side.htmlSigned-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      be95a845
    • Wei Wang's avatar
      ipv6: remove null_entry before adding default route · 4512c43e
      Wei Wang authored 
      In the current code, when creating a new fib6 table, tb6_root.leaf gets
initialized to net->ipv6.ip6_null_entry.
If a default route is being added with rt->rt6i_metric = 0xffffffff,
fib6_add() will add this route after net->ipv6.ip6_null_entry. As
null_entry is shared, it could cause problem.

In order to fix it, set fn->leaf to NULL before calling
fib6_add_rt2node() when trying to add the first default route.
And reset fn->leaf to null_entry when adding fails or when deleting the
last default route.

syzkaller reported the following issue which is fixed by this commit:

WARNING: suspicious RCU usage
4.15.0-rc5+ #171 Not tainted
-----------------------------
net/ipv6/ip6_fib.c:1702 suspicious rcu_dereference_protected() usage!

other info that might help us debug this:

rcu_scheduler_active = 2, debug_locks = 1
4 locks held by swapper/0/0:
 #0:  ((&net->ipv6.ip6_fib_timer)){+.-.}, at: [<00000000d43f631b>] lockdep_copy_map include/linux/lockdep.h:178 [inline]
 #0:  ((&net->ipv6.ip6_fib_timer)){+.-.}, at: [<00000000d43f631b>] call_timer_fn+0x1c6/0x820 kernel/time/timer.c:1310
 #1:  (&(&net->ipv6.fib6_gc_lock)->rlock){+.-.}, at: [<000000002ff9d65c>] spin_lock_bh include/linux/spinlock.h:315 [inline]
 #1:  (&(&net->ipv6.fib6_gc_lock)->rlock){+.-.}, at: [<000000002ff9d65c>] fib6_run_gc+0x9d/0x3c0 net/ipv6/ip6_fib.c:2007
 #2:  (rcu_read_lock){....}, at: [<0000000091db762d>] __fib6_clean_all+0x0/0x3a0 net/ipv6/ip6_fib.c:1560
 #3:  (&(&tb->tb6_lock)->rlock){+.-.}, at: [<000000009e503581>] spin_lock_bh include/linux/spinlock.h:315 [inline]
 #3:  (&(&tb->tb6_lock)->rlock){+.-.}, at: [<000000009e503581>] __fib6_clean_all+0x1d0/0x3a0 net/ipv6/ip6_fib.c:1948

stack backtrace:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.15.0-rc5+ #171
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
 <IRQ>
 __dump_stack lib/dump_stack.c:17 [inline]
 dump_stack+0x194/0x257 lib/dump_stack.c:53
 lockdep_rcu_suspicious+0x123/0x170 kernel/locking/lockdep.c:4585
 fib6_del+0xcaa/0x11b0 net/ipv6/ip6_fib.c:1701
 fib6_clean_node+0x3aa/0x4f0 net/ipv6/ip6_fib.c:1892
 fib6_walk_continue+0x46c/0x8a0 net/ipv6/ip6_fib.c:1815
 fib6_walk+0x91/0xf0 net/ipv6/ip6_fib.c:1863
 fib6_clean_tree+0x1e6/0x340 net/ipv6/ip6_fib.c:1933
 __fib6_clean_all+0x1f4/0x3a0 net/ipv6/ip6_fib.c:1949
 fib6_clean_all net/ipv6/ip6_fib.c:1960 [inline]
 fib6_run_gc+0x16b/0x3c0 net/ipv6/ip6_fib.c:2016
 fib6_gc_timer_cb+0x20/0x30 net/ipv6/ip6_fib.c:2033
 call_timer_fn+0x228/0x820 kernel/time/timer.c:1320
 expire_timers kernel/time/timer.c:1357 [inline]
 __run_timers+0x7ee/0xb70 kernel/time/timer.c:1660
 run_timer_softirq+0x4c/0xb0 kernel/time/timer.c:1686
 __do_softirq+0x2d7/0xb85 kernel/softirq.c:285
 invoke_softirq kernel/softirq.c:365 [inline]
 irq_exit+0x1cc/0x200 kernel/softirq.c:405
 exiting_irq arch/x86/include/asm/apic.h:540 [inline]
 smp_apic_timer_interrupt+0x16b/0x700 arch/x86/kernel/apic/apic.c:1052
 apic_timer_interrupt+0xa9/0xb0 arch/x86/entry/entry_64.S:904
 </IRQ>
Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
Fixes: 66f5d6ce ("ipv6: replace rwlock with rcu and spinlock in fib6_table")
Signed-off-by: default avatarWei Wang <weiwan@google.com>
Acked-by: default avatarMartin KaFai Lau <kafai@fb.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4512c43e
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7