1. 12 Jan, 2018 3 commits
    • David S. Miller's avatar
      Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec · 9c70f1a7
      David S. Miller authored
      Steffen Klassert says:
      
      ====================
      pull request (net): ipsec 2018-01-11
      
      1) Don't allow to change the encap type on state updates.
         The encap type is set on state initialization and
         should not change anymore. From Herbert Xu.
      
      2) Skip dead policies when rehashing to fix a
         slab-out-of-bounds bug in xfrm_hash_rebuild.
         From Florian Westphal.
      
      3) Two buffer overread fixes in pfkey.
         From Eric Biggers.
      
      4) Fix rcu usage in xfrm_get_type_offload,
         request_module can sleep, so can't be used
         under rcu_read_lock. From Sabrina Dubroca.
      
      5) Fix an uninitialized lock in xfrm_trans_queue.
         Use __skb_queue_tail instead of skb_queue_tail
         in xfrm_trans_queue as we don't need the lock.
         From Herbert Xu.
      
      6) Currently it is possible to create an xfrm state with an
         unknown encap type in ESP IPv4. Fix this by returning an
         error on unknown encap types. Also from Herbert Xu.
      
      7) Fix sleeping inside a spinlock in xfrm_policy_cache_flush.
         From Florian Westphal.
      
      8) Fix ESP GRO when the headers not fully in the linear part
         of the skb. We need to pull before we can access them.
      
      9) Fix a skb leak on error in key_notify_policy.
      
      10) Fix a race in the xdst pcpu cache, we need to
          run the resolver routines with bottom halfes
          off like the old flowcache did.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9c70f1a7
    • Linus Torvalds's avatar
      Merge tag 'ceph-for-4.15-rc8' of git://github.com/ceph/ceph-client · 1545dec4
      Linus Torvalds authored
      Pull ceph fixes from Ilya Dryomov:
       "Two rbd fixes for 4.12 and 4.2 issues respectively, marked for
        stable"
      
      * tag 'ceph-for-4.15-rc8' of git://github.com/ceph/ceph-client:
        rbd: set max_segments to USHRT_MAX
        rbd: reacquire lock should update lock owner client id
      1545dec4
    • Linus Torvalds's avatar
      Merge tag 'gpio-v4.15-4' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio · ab278159
      Linus Torvalds authored
      Pull GPIO fix from Linus Walleij:
       "Fix a raw vs elaborate GPIO descriptor bug introduced by yours truly"
      
      * tag 'gpio-v4.15-4' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
        gpio: Add missing open drain/source handling to gpiod_set_value_cansleep()
      ab278159
  2. 11 Jan, 2018 2 commits
    • 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
  3. 10 Jan, 2018 22 commits
  4. 09 Jan, 2018 13 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
    • David S. Miller's avatar
      Merge branch 'Ether-fixes-for-the-SolutionEngine771x-boards' · 22dd8e6b
      David S. Miller authored
      Sergei Shtylyov says:
      
      ====================
      Ether fixes for the SolutionEngine771x boards
      
      Here's the series of 2 patches against Linus' repo. This series should
      (hoplefully) fix the Ether support on the SolutionEngine771x boards...
      
      [1/2] SolutionEngine771x: fix Ether platform data
      [2/2] SolutionEngine771x: add Ether TSU resource
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      22dd8e6b
    • Sergei Shtylyov's avatar
      SolutionEngine771x: add Ether TSU resource · f9a531d6
      Sergei Shtylyov authored
      After the  Ether platform data is fixed, the driver probe() method would
      still fail since the 'struct sh_eth_cpu_data' corresponding  to SH771x
      indicates the presence of TSU but the memory resource for it is absent.
      Add the missing TSU resource  to both Ether devices and fix the harmless
      off-by-one error in the main memory resources, while at it...
      
      Fixes: 4986b996 ("net: sh_eth: remove the SH_TSU_ADDR")
      Signed-off-by: default avatarSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f9a531d6
    • Sergei Shtylyov's avatar
      SolutionEngine771x: fix Ether platform data · 195e2add
      Sergei Shtylyov authored
      The 'sh_eth' driver's probe() method would fail  on the SolutionEngine7710
      board and crash on SolutionEngine7712 board  as the platform code is
      hopelessly behind the driver's platform data --  it passes the PHY address
      instead of 'struct sh_eth_plat_data *'; pass the latter to the driver in
      order to fix the bug...
      
      Fixes: 71557a37 ("[netdrvr] sh_eth: Add SH7619 support")
      Signed-off-by: default avatarSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      195e2add
    • Mike Rapoport's avatar
      docs-rst: networking: wire up msg_zerocopy · 2fdd1811
      Mike Rapoport authored
      Fix the following 'make htmldocs' complaint:
      
      Documentation/networking/msg_zerocopy.rst:: WARNING: document isn't included in any toctree.
      Signed-off-by: default avatarMike Rapoport <rppt@linux.vnet.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2fdd1811
    • Nicolai Stange's avatar
      net: ipv4: emulate READ_ONCE() on ->hdrincl bit-field in raw_sendmsg() · 20b50d79
      Nicolai Stange authored
      Commit 8f659a03 ("net: ipv4: fix for a race condition in
      raw_sendmsg") fixed the issue of possibly inconsistent ->hdrincl handling
      due to concurrent updates by reading this bit-field member into a local
      variable and using the thus stabilized value in subsequent tests.
      
      However, aforementioned commit also adds the (correct) comment that
      
        /* hdrincl should be READ_ONCE(inet->hdrincl)
         * but READ_ONCE() doesn't work with bit fields
         */
      
      because as it stands, the compiler is free to shortcut or even eliminate
      the local variable at its will.
      
      Note that I have not seen anything like this happening in reality and thus,
      the concern is a theoretical one.
      
      However, in order to be on the safe side, emulate a READ_ONCE() on the
      bit-field by doing it on the local 'hdrincl' variable itself:
      
      	int hdrincl = inet->hdrincl;
      	hdrincl = READ_ONCE(hdrincl);
      
      This breaks the chain in the sense that the compiler is not allowed
      to replace subsequent reads from hdrincl with reloads from inet->hdrincl.
      
      Fixes: 8f659a03 ("net: ipv4: fix for a race condition in raw_sendmsg")
      Signed-off-by: default avatarNicolai Stange <nstange@suse.de>
      Reviewed-by: default avatarStefano Brivio <sbrivio@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      20b50d79
    • Xiongfeng Wang's avatar
      net: caif: use strlcpy() instead of strncpy() · 3dc2fa47
      Xiongfeng Wang authored
      gcc-8 reports
      
      net/caif/caif_dev.c: In function 'caif_enroll_dev':
      ./include/linux/string.h:245:9: warning: '__builtin_strncpy' output may
      be truncated copying 15 bytes from a string of length 15
      [-Wstringop-truncation]
      
      net/caif/cfctrl.c: In function 'cfctrl_linkup_request':
      ./include/linux/string.h:245:9: warning: '__builtin_strncpy' output may
      be truncated copying 15 bytes from a string of length 15
      [-Wstringop-truncation]
      
      net/caif/cfcnfg.c: In function 'caif_connect_client':
      ./include/linux/string.h:245:9: warning: '__builtin_strncpy' output may
      be truncated copying 15 bytes from a string of length 15
      [-Wstringop-truncation]
      
      The compiler require that the input param 'len' of strncpy() should be
      greater than the length of the src string, so that '\0' is copied as
      well. We can just use strlcpy() to avoid this warning.
      Signed-off-by: default avatarXiongfeng Wang <xiongfeng.wang@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3dc2fa47
    • Ilya Dryomov's avatar
      rbd: set max_segments to USHRT_MAX · 21acdf45
      Ilya Dryomov authored
      Commit d3834fef ("rbd: bump queue_max_segments") bumped
      max_segments (unsigned short) to max_hw_sectors (unsigned int).
      max_hw_sectors is set to the number of 512-byte sectors in an object
      and overflows unsigned short for 32M (largest possible) objects, making
      the block layer resort to handing us single segment (i.e. single page
      or even smaller) bios in that case.
      
      Cc: stable@vger.kernel.org
      Fixes: d3834fef ("rbd: bump queue_max_segments")
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Reviewed-by: default avatarAlex Elder <elder@linaro.org>
      21acdf45