1. 30 Jun, 2017 3 commits
  2. 29 Jun, 2017 16 commits
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net · 4d8a991d
      Linus Torvalds authored
      Pull networking fixes from David Miller:
       1) Need to access netdev->num_rx_queues behind an accessor in netvsc
          driver otherwise the build breaks with some configs, from Arnd
       2) Add dummy xfrm_dev_event() so that build doesn't fail when
          CONFIG_XFRM_OFFLOAD is not set. From Hangbin Liu.
       3) Don't OOPS when pfkey_msg2xfrm_state() signals an erros, from Dan
       4) Fix MCDI command size for filter operations in sfc driver, from
          Martin Habets.
       5) Fix UFO segmenting so that we don't calculate incorrect checksums,
          from Michal Kubecek.
       6) When ipv6 datagram connects fail, reset destination address and
          port. From Wei Wang.
       7) TCP disconnect must reset the cached receive DST, from WANG Cong.
       8) Fix sign extension bug on 32-bit in dev_get_stats(), from Eric
       9) fman driver has to depend on HAS_DMA, from Madalin Bucur.
      10) Fix bpf pointer leak with xadd in verifier, from Daniel Borkmann.
      11) Fix negative page counts with GFO, from Michal Kubecek.
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (41 commits)
        sfc: fix attempt to translate invalid filter ID
        net: handle NAPI_GRO_FREE_STOLEN_HEAD case also in napi_frags_finish()
        bpf: prevent leaking pointer via xadd on unpriviledged
        arcnet: com20020-pci: add missing pdev setup in netdev structure
        arcnet: com20020-pci: fix dev_id calculation
        arcnet: com20020: remove needless base_addr assignment
        Trivial fix to spelling mistake in arc_printk message
        arcnet: change irq handler to lock irqsave
        rocker: move dereference before free
        mlxsw: spectrum_router: Fix NULL pointer dereference
        net: sched: Fix one possible panic when no destroy callback
        virtio-net: serialize tx routine during reset
        net: usb: asix88179_178a: Add support for the Belkin B2B128
        fsl/fman: add dependency on HAS_DMA
        net: prevent sign extension in dev_get_stats()
        tcp: reset sk_rx_dst in tcp_disconnect()
        net: ipv6: reset daddr and dport in sk if connect() fails
        bnx2x: Don't log mc removal needlessly
        bnxt_en: Fix netpoll handling.
        bnxt_en: Add missing logic to handle TPA end error conditions.
    • Linus Torvalds's avatar
      Merge tag 'for-4.12/dm-fixes-5' of... · 27bc3440
      Linus Torvalds authored
      Merge tag 'for-4.12/dm-fixes-5' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm
      Pull device mapper fixes from Mike Snitzer:
       - dm thinp fix for crash that will occur when metadata device failure
         races with discard passdown to the underlying data device.
       - dm raid fix to not access the superblock's >= 1.9.0 'sectors' member
      * tag 'for-4.12/dm-fixes-5' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
        dm thin: do not queue freed thin mapping for next stage processing
        dm raid: fix oops on upgrading to extended superblock format
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.dk/linux-block · 374bf883
      Linus Torvalds authored
      Pull block fixes from Jens Axboe:
       "Two fixes that should go into this release.
        One is an nvme regression fix from Keith, fixing a missing queue
        freeze if the controller is being reset. This causes the reset to
        The other is a fix for a leak of the bio protection info, if smaller
        sized O_DIRECT is used. This fix should be more involved as we have
        other problematic paths in the kernel, but given as this isn't a
        regression in this series, we'll tackle those for 4.13"
      * 'for-linus' of git://git.kernel.dk/linux-block:
        block: provide bio_uninit() free freeing integrity/task associations
        nvme/pci: Fix stuck nvme reset
    • Edward Cree's avatar
      sfc: fix attempt to translate invalid filter ID · d58299a4
      Edward Cree authored
      When filter insertion fails with no rollback, we were trying to convert
       EFX_EF10_FILTER_ID_INVALID to an id to store in 'ids' (which is either
       vlan->uc or vlan->mc).  This would WARN_ON_ONCE and then record a bogus
       filter ID of 0x1fff, neither of which is a good thing.
      Fixes: 0ccb998b ("sfc: fix filter_id misinterpretation in edge case")
      Signed-off-by: default avatarEdward Cree <ecree@solarflare.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Michal Kubeček's avatar
      net: handle NAPI_GRO_FREE_STOLEN_HEAD case also in napi_frags_finish() · e44699d2
      Michal Kubeček authored
      Recently I started seeing warnings about pages with refcount -1. The
      problem was traced to packets being reused after their head was merged into
      a GRO packet by skb_gro_receive(). While bisecting the issue pointed to
      commit c21b48cc ("net: adjust skb->truesize in ___pskb_trim()") and
      I have never seen it on a kernel with it reverted, I believe the real
      problem appeared earlier when the option to merge head frag in GRO was
      Handling NAPI_GRO_FREE_STOLEN_HEAD state was only added to GRO_MERGED_FREE
      branch of napi_skb_finish() so that if the driver uses napi_gro_frags()
      and head is merged (which in my case happens after the skb_condense()
      call added by the commit mentioned above), the skb is reused including the
      head that has been merged. As a result, we release the page reference
      twice and eventually end up with negative page refcount.
      To fix the problem, handle NAPI_GRO_FREE_STOLEN_HEAD in napi_frags_finish()
      the same way it's done in napi_skb_finish().
      Fixes: d7e8883c ("net: make GRO aware of skb->head_frag")
      Signed-off-by: default avatarMichal Kubecek <mkubecek@suse.cz>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Daniel Borkmann's avatar
      bpf: prevent leaking pointer via xadd on unpriviledged · 6bdf6abc
      Daniel Borkmann authored
      Leaking kernel addresses on unpriviledged is generally disallowed,
      for example, verifier rejects the following:
        0: (b7) r0 = 0
        1: (18) r2 = 0xffff897e82304400
        3: (7b) *(u64 *)(r1 +48) = r2
        R2 leaks addr into ctx
      Doing pointer arithmetic on them is also forbidden, so that they
      don't turn into unknown value and then get leaked out. However,
      there's xadd as a special case, where we don't check the src reg
      for being a pointer register, e.g. the following will pass:
        0: (b7) r0 = 0
        1: (7b) *(u64 *)(r1 +48) = r0
        2: (18) r2 = 0xffff897e82304400 ; map
        4: (db) lock *(u64 *)(r1 +48) += r2
        5: (95) exit
      We could store the pointer into skb->cb, loose the type context,
      and then read it out from there again to leak it eventually out
      of a map value. Or more easily in a different variant, too:
         0: (bf) r6 = r1
         1: (7a) *(u64 *)(r10 -8) = 0
         2: (bf) r2 = r10
         3: (07) r2 += -8
         4: (18) r1 = 0x0
         6: (85) call bpf_map_lookup_elem#1
         7: (15) if r0 == 0x0 goto pc+3
         R0=map_value(ks=8,vs=8,id=0),min_value=0,max_value=0 R6=ctx R10=fp
         8: (b7) r3 = 0
         9: (7b) *(u64 *)(r0 +0) = r3
        10: (db) lock *(u64 *)(r0 +0) += r6
        11: (b7) r0 = 0
        12: (95) exit
        from 7 to 11: R0=inv,min_value=0,max_value=0 R6=ctx R10=fp
        11: (b7) r0 = 0
        12: (95) exit
      Prevent this by checking xadd src reg for pointer types. Also
      add a couple of test cases related to this.
      Fixes: 1be7f75d ("bpf: enable non-root eBPF programs")
      Fixes: 17a52670 ("bpf: verifier (add verifier core)")
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Acked-by: default avatarMartin KaFai Lau <kafai@fb.com>
      Acked-by: default avatarEdward Cree <ecree@solarflare.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • David S. Miller's avatar
      Merge branch 'arcnet-fixes' · 00778f7c
      David S. Miller authored
      Michael Grzeschik says:
      arcnet: Collection of latest fixes
      Here we sum up the recent fixes I collected on the way to use and
      stabilise the framework. Part of it is an possible deadlock that we
      prevent as well to fix the calculation of the dev_id that can be setup
      by an rotary encoder. Beside that we added an trivial spelling patch and
      fix some wrong and missing assignments that improves the code footprint.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Michael Grzeschik's avatar
      arcnet: com20020-pci: add missing pdev setup in netdev structure · 2a0ea04c
      Michael Grzeschik authored
      We add the pdev data to the pci devices netdev structure. This way
      the interface get consistent device names in the userspace (udev).
      Signed-off-by: default avatarMichael Grzeschik <m.grzeschik@pengutronix.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Michael Grzeschik's avatar
      arcnet: com20020-pci: fix dev_id calculation · cb108619
      Michael Grzeschik authored
      The dev_id was miscalculated. Only the two bits 4-5 are relevant for the
      MA1 card. PCIARC1 and PCIFB2 use the four bits 4-7 for id selection.
      Signed-off-by: default avatarMichael Grzeschik <m.grzeschik@pengutronix.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Michael Grzeschik's avatar
      arcnet: com20020: remove needless base_addr assignment · 0d494fcf
      Michael Grzeschik authored
      The assignment is superfluous.
      Signed-off-by: default avatarMichael Grzeschik <m.grzeschik@pengutronix.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Colin Ian King's avatar
    • Michael Grzeschik's avatar
      arcnet: change irq handler to lock irqsave · 5b858403
      Michael Grzeschik authored
      This patch prevents the arcnet driver from the following deadlock.
      [   41.273910] ======================================================
      [   41.280397] [ INFO: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected ]
      [   41.287433] 4.4.0-00034-gc0ae784 #536 Not tainted
      [   41.292366] ------------------------------------------------------
      [   41.298863] arcecho/233 [HC0[0]:SC0[2]:HE0:SE0] is trying to acquire:
      [   41.305628]  (&(&lp->lock)->rlock){+.+...}, at: [<bf083bc8>] arcnet_send_packet+0x60/0x1c0 [arcnet]
      [   41.315199]
      [   41.315199] and this task is already holding:
      [   41.321324]  (_xmit_ARCNET#2){+.-...}, at: [<c06b934c>] packet_direct_xmit+0xfc/0x1c8
      [   41.329593] which would create a new lock dependency:
      [   41.334893]  (_xmit_ARCNET#2){+.-...} -> (&(&lp->lock)->rlock){+.+...}
      [   41.341801]
      [   41.341801] but this new dependency connects a SOFTIRQ-irq-safe lock:
      [   41.350108]  (_xmit_ARCNET#2){+.-...}
      ... which became SOFTIRQ-irq-safe at:
      [   41.357539]   [<c06f8fc8>] _raw_spin_lock+0x30/0x40
      [   41.362677]   [<c063ab8c>] dev_watchdog+0x5c/0x264
      [   41.367723]   [<c0094edc>] call_timer_fn+0x6c/0xf4
      [   41.372759]   [<c00950b8>] run_timer_softirq+0x154/0x210
      [   41.378340]   [<c0036b30>] __do_softirq+0x144/0x298
      [   41.383469]   [<c0036fb4>] irq_exit+0xcc/0x130
      [   41.388138]   [<c0085c50>] __handle_domain_irq+0x60/0xb4
      [   41.393728]   [<c0014578>] __irq_svc+0x58/0x78
      [   41.398402]   [<c0010274>] arch_cpu_idle+0x24/0x3c
      [   41.403443]   [<c007127c>] cpu_startup_entry+0x1f8/0x25c
      [   41.409029]   [<c09adc90>] start_kernel+0x3c0/0x3cc
      [   41.414170]
      [   41.414170] to a SOFTIRQ-irq-unsafe lock:
      [   41.419931]  (&(&lp->lock)->rlock){+.+...}
      ... which became SOFTIRQ-irq-unsafe at:
      [   41.427996] ...  [<c06f8fc8>] _raw_spin_lock+0x30/0x40
      [   41.433409]   [<bf083d54>] arcnet_interrupt+0x2c/0x800 [arcnet]
      [   41.439646]   [<c0089120>] handle_nested_irq+0x8c/0xec
      [   41.445063]   [<c03c1170>] regmap_irq_thread+0x190/0x314
      [   41.450661]   [<c0087244>] irq_thread_fn+0x1c/0x34
      [   41.455700]   [<c0087548>] irq_thread+0x13c/0x1dc
      [   41.460649]   [<c0050f10>] kthread+0xe4/0xf8
      [   41.465158]   [<c000f810>] ret_from_fork+0x14/0x24
      [   41.470207]
      [   41.470207] other info that might help us debug this:
      [   41.470207]
      [   41.478627]  Possible interrupt unsafe locking scenario:
      [   41.478627]
      [   41.485763]        CPU0                    CPU1
      [   41.490521]        ----                    ----
      [   41.495279]   lock(&(&lp->lock)->rlock);
      [   41.499414]                                local_irq_disable();
      [   41.505636]                                lock(_xmit_ARCNET#2);
      [   41.511967]                                lock(&(&lp->lock)->rlock);
      [   41.518741]   <Interrupt>
      [   41.521490]     lock(_xmit_ARCNET#2);
      [   41.525356]
      [   41.525356]  *** DEADLOCK ***
      [   41.525356]
      [   41.531587] 1 lock held by arcecho/233:
      [   41.535617]  #0:  (_xmit_ARCNET#2){+.-...}, at: [<c06b934c>] packet_direct_xmit+0xfc/0x1c8
      [   41.544355]
      the dependencies between SOFTIRQ-irq-safe lock and the holding lock:
      [   41.552362] -> (_xmit_ARCNET#2){+.-...} ops: 27 {
      [   41.557357]    HARDIRQ-ON-W at:
      [   41.560664]                     [<c06f8fc8>] _raw_spin_lock+0x30/0x40
      [   41.567445]                     [<c063ba28>] dev_deactivate_many+0x114/0x304
      [   41.574866]                     [<c063bc3c>] dev_deactivate+0x24/0x38
      [   41.581646]                     [<c0630374>] linkwatch_do_dev+0x40/0x74
      [   41.588613]                     [<c06305d8>] __linkwatch_run_queue+0xec/0x140
      [   41.596120]                     [<c0630658>] linkwatch_event+0x2c/0x34
      [   41.602991]                     [<c004af30>] process_one_work+0x188/0x40c
      [   41.610131]                     [<c004b200>] worker_thread+0x4c/0x480
      [   41.616912]                     [<c0050f10>] kthread+0xe4/0xf8
      [   41.623048]                     [<c000f810>] ret_from_fork+0x14/0x24
      [   41.629735]    IN-SOFTIRQ-W at:
      [   41.633039]                     [<c06f8fc8>] _raw_spin_lock+0x30/0x40
      [   41.639820]                     [<c063ab8c>] dev_watchdog+0x5c/0x264
      [   41.646508]                     [<c0094edc>] call_timer_fn+0x6c/0xf4
      [   41.653190]                     [<c00950b8>] run_timer_softirq+0x154/0x210
      [   41.660425]                     [<c0036b30>] __do_softirq+0x144/0x298
      [   41.667201]                     [<c0036fb4>] irq_exit+0xcc/0x130
      [   41.673518]                     [<c0085c50>] __handle_domain_irq+0x60/0xb4
      [   41.680754]                     [<c0014578>] __irq_svc+0x58/0x78
      [   41.687077]                     [<c0010274>] arch_cpu_idle+0x24/0x3c
      [   41.693769]                     [<c007127c>] cpu_startup_entry+0x1f8/0x25c
      [   41.701006]                     [<c09adc90>] start_kernel+0x3c0/0x3cc
      [   41.707791]    INITIAL USE at:
      [   41.711003]                    [<c06f8fc8>] _raw_spin_lock+0x30/0x40
      [   41.717696]                    [<c063ba28>] dev_deactivate_many+0x114/0x304
      [   41.725026]                    [<c063bc3c>] dev_deactivate+0x24/0x38
      [   41.731718]                    [<c0630374>] linkwatch_do_dev+0x40/0x74
      [   41.738593]                    [<c06305d8>] __linkwatch_run_queue+0xec/0x140
      [   41.746011]                    [<c0630658>] linkwatch_event+0x2c/0x34
      [   41.752789]                    [<c004af30>] process_one_work+0x188/0x40c
      [   41.759847]                    [<c004b200>] worker_thread+0x4c/0x480
      [   41.766541]                    [<c0050f10>] kthread+0xe4/0xf8
      [   41.772596]                    [<c000f810>] ret_from_fork+0x14/0x24
      [   41.779198]  }
      [   41.780945]  ... key      at: [<c124d620>] netdev_xmit_lock_key+0x38/0x1c8
      [   41.788192]  ... acquired at:
      [   41.791309]    [<c007bed8>] lock_acquire+0x70/0x90
      [   41.796361]    [<c06f9140>] _raw_spin_lock_irqsave+0x40/0x54
      [   41.802324]    [<bf083bc8>] arcnet_send_packet+0x60/0x1c0 [arcnet]
      [   41.808844]    [<c06b9380>] packet_direct_xmit+0x130/0x1c8
      [   41.814622]    [<c06bc7e4>] packet_sendmsg+0x3b8/0x680
      [   41.820034]    [<c05fe8b0>] sock_sendmsg+0x14/0x24
      [   41.825091]    [<c05ffd68>] SyS_sendto+0xb8/0xe0
      [   41.829956]    [<c05ffda8>] SyS_send+0x18/0x20
      [   41.834638]    [<c000f780>] ret_fast_syscall+0x0/0x1c
      [   41.839954]
      [   41.841514]
      the dependencies between the lock to be acquired and SOFTIRQ-irq-unsafe lock:
      [   41.850302] -> (&(&lp->lock)->rlock){+.+...} ops: 5 {
      [   41.855644]    HARDIRQ-ON-W at:
      [   41.858945]                     [<c06f8fc8>] _raw_spin_lock+0x30/0x40
      [   41.865726]                     [<bf083d54>] arcnet_interrupt+0x2c/0x800 [arcnet]
      [   41.873607]                     [<c0089120>] handle_nested_irq+0x8c/0xec
      [   41.880666]                     [<c03c1170>] regmap_irq_thread+0x190/0x314
      [   41.887901]                     [<c0087244>] irq_thread_fn+0x1c/0x34
      [   41.894593]                     [<c0087548>] irq_thread+0x13c/0x1dc
      [   41.901195]                     [<c0050f10>] kthread+0xe4/0xf8
      [   41.907338]                     [<c000f810>] ret_from_fork+0x14/0x24
      [   41.914025]    SOFTIRQ-ON-W at:
      [   41.917328]                     [<c06f8fc8>] _raw_spin_lock+0x30/0x40
      [   41.924106]                     [<bf083d54>] arcnet_interrupt+0x2c/0x800 [arcnet]
      [   41.931981]                     [<c0089120>] handle_nested_irq+0x8c/0xec
      [   41.939028]                     [<c03c1170>] regmap_irq_thread+0x190/0x314
      [   41.946264]                     [<c0087244>] irq_thread_fn+0x1c/0x34
      [   41.952954]                     [<c0087548>] irq_thread+0x13c/0x1dc
      [   41.959548]                     [<c0050f10>] kthread+0xe4/0xf8
      [   41.965689]                     [<c000f810>] ret_from_fork+0x14/0x24
      [   41.972379]    INITIAL USE at:
      [   41.975595]                    [<c06f8fc8>] _raw_spin_lock+0x30/0x40
      [   41.982283]                    [<bf083d54>] arcnet_interrupt+0x2c/0x800 [arcnet]
      [   41.990063]                    [<c0089120>] handle_nested_irq+0x8c/0xec
      [   41.997027]                    [<c03c1170>] regmap_irq_thread+0x190/0x314
      [   42.004172]                    [<c0087244>] irq_thread_fn+0x1c/0x34
      [   42.010766]                    [<c0087548>] irq_thread+0x13c/0x1dc
      [   42.017267]                    [<c0050f10>] kthread+0xe4/0xf8
      [   42.023314]                    [<c000f810>] ret_from_fork+0x14/0x24
      [   42.029903]  }
      [   42.031648]  ... key      at: [<bf0854cc>] __key.42091+0x0/0xfffff0f8 [arcnet]
      [   42.039255]  ... acquired at:
      [   42.042372]    [<c007bed8>] lock_acquire+0x70/0x90
      [   42.047413]    [<c06f9140>] _raw_spin_lock_irqsave+0x40/0x54
      [   42.053364]    [<bf083bc8>] arcnet_send_packet+0x60/0x1c0 [arcnet]
      [   42.059872]    [<c06b9380>] packet_direct_xmit+0x130/0x1c8
      [   42.065634]    [<c06bc7e4>] packet_sendmsg+0x3b8/0x680
      [   42.071030]    [<c05fe8b0>] sock_sendmsg+0x14/0x24
      [   42.076069]    [<c05ffd68>] SyS_sendto+0xb8/0xe0
      [   42.080926]    [<c05ffda8>] SyS_send+0x18/0x20
      [   42.085601]    [<c000f780>] ret_fast_syscall+0x0/0x1c
      [   42.090918]
      [   42.092481]
      [   42.092481] stack backtrace:
      [   42.097065] CPU: 0 PID: 233 Comm: arcecho Not tainted 4.4.0-00034-gc0ae784 #536
      [   42.104751] Hardware name: Generic AM33XX (Flattened Device Tree)
      [   42.111183] [<c0017ec8>] (unwind_backtrace) from [<c00139d0>] (show_stack+0x10/0x14)
      [   42.119337] [<c00139d0>] (show_stack) from [<c02a82c4>] (dump_stack+0x8c/0x9c)
      [   42.126937] [<c02a82c4>] (dump_stack) from [<c0078260>] (check_usage+0x4bc/0x63c)
      [   42.134815] [<c0078260>] (check_usage) from [<c0078438>] (check_irq_usage+0x58/0xb0)
      [   42.142964] [<c0078438>] (check_irq_usage) from [<c007aaa0>] (__lock_acquire+0x1524/0x20b0)
      [   42.151740] [<c007aaa0>] (__lock_acquire) from [<c007bed8>] (lock_acquire+0x70/0x90)
      [   42.159886] [<c007bed8>] (lock_acquire) from [<c06f9140>] (_raw_spin_lock_irqsave+0x40/0x54)
      [   42.168768] [<c06f9140>] (_raw_spin_lock_irqsave) from [<bf083bc8>] (arcnet_send_packet+0x60/0x1c0 [arcnet])
      [   42.179115] [<bf083bc8>] (arcnet_send_packet [arcnet]) from [<c06b9380>] (packet_direct_xmit+0x130/0x1c8)
      [   42.189182] [<c06b9380>] (packet_direct_xmit) from [<c06bc7e4>] (packet_sendmsg+0x3b8/0x680)
      [   42.198059] [<c06bc7e4>] (packet_sendmsg) from [<c05fe8b0>] (sock_sendmsg+0x14/0x24)
      [   42.206199] [<c05fe8b0>] (sock_sendmsg) from [<c05ffd68>] (SyS_sendto+0xb8/0xe0)
      [   42.213978] [<c05ffd68>] (SyS_sendto) from [<c05ffda8>] (SyS_send+0x18/0x20)
      [   42.221388] [<c05ffda8>] (SyS_send) from [<c000f780>] (ret_fast_syscall+0x0/0x1c)
      Signed-off-by: default avatarMichael Grzeschik <m.grzeschik@pengutronix.de>
         v1 -> v2: removed unneeded zero assignment of flags
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Dan Carpenter's avatar
      rocker: move dereference before free · acb4b7df
      Dan Carpenter authored
      My static checker complains that ofdpa_neigh_del() can sometimes free
      "found".   It just makes sense to use it first before deleting it.
      Fixes: ecf244f7 ("rocker: fix maybe-uninitialized warning")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Ido Schimmel's avatar
      mlxsw: spectrum_router: Fix NULL pointer dereference · 6b27c8ad
      Ido Schimmel authored
      In case a VLAN device is enslaved to a bridge we shouldn't create a
      router interface (RIF) for it when it's configured with an IP address.
      This is already handled by the driver for other types of netdevs, such
      as physical ports and LAG devices.
      If this IP address is then removed and the interface is subsequently
      unlinked from the bridge, a NULL pointer dereference can happen, as the
      original 802.1d FID was replaced with an rFID which was then deleted.
      To reproduce:
      $ ip link set dev enp3s0np9 up
      $ ip link add name enp3s0np9.111 link enp3s0np9 type vlan id 111
      $ ip link set dev enp3s0np9.111 up
      $ ip link add name br0 type bridge
      $ ip link set dev br0 up
      $ ip link set enp3s0np9.111 master br0
      $ ip address add dev enp3s0np9.111
      $ ip address del dev enp3s0np9.111
      $ ip link set dev enp3s0np9.111 nomaster
      Fixes: 99724c18 ("mlxsw: spectrum: Introduce support for router interfaces")
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Reported-by: default avatarPetr Machata <petrm@mellanox.com>
      Tested-by: default avatarPetr Machata <petrm@mellanox.com>
      Reviewed-by: default avatarPetr Machata <petrm@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Gao Feng's avatar
      net: sched: Fix one possible panic when no destroy callback · c1a4872e
      Gao Feng authored
      When qdisc fail to init, qdisc_create would invoke the destroy callback
      to cleanup. But there is no check if the callback exists really. So it
      would cause the panic if there is no real destroy callback like the qdisc
      codel, fq, and so on.
      Take codel as an example following:
      When a malicious user constructs one invalid netlink msg, it would cause
      codel_init->codel_change->nla_parse_nested failed.
      Then kernel would invoke the destroy callback directly but qdisc codel
      doesn't define one. It causes one panic as a result.
      Now add one the check for destroy to avoid the possible panic.
      Fixes: 87b60cfa ("net_sched: fix error recovery at qdisc creation")
      Signed-off-by: default avatarGao Feng <gfree.wind@vip.163.com>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Jason Wang's avatar
      virtio-net: serialize tx routine during reset · 713a98d9
      Jason Wang authored
      We don't hold any tx lock when trying to disable TX during reset, this
      would lead a use after free since ndo_start_xmit() tries to access
      the virtqueue which has already been freed. Fix this by using
      netif_tx_disable() before freeing the vqs, this could make sure no tx
      after vq freeing.
      Reported-by: default avatarJean-Philippe Menil <jpmenil@gmail.com>
      Tested-by: default avatarJean-Philippe Menil <jpmenil@gmail.com>
      Fixes commit f600b690 ("virtio_net: Add XDP support")
      Cc: John Fastabend <john.fastabend@gmail.com>
      Signed-off-by: default avatarJason Wang <jasowang@redhat.com>
      Acked-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Acked-by: default avatarRobert McCabe <robert.mccabe@rockwellcollins.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  3. 28 Jun, 2017 13 commits
  4. 27 Jun, 2017 6 commits
    • Keith Busch's avatar
      nvme/pci: Fix stuck nvme reset · ebef7368
      Keith Busch authored
      The controller state is set to resetting prior to disabling the
      controller, so this patch accounts for that state when deciding if it
      needs to freeze the queues. Without this, an 'nvme reset /dev/nvme0'
      blocks forever because the queues were never frozen.
      Fixes: 82b057ca ("nvme-pci: fix multiple ctrl removal scheduling")
      Signed-off-by: default avatarKeith Busch <keith.busch@intel.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
    • Andrew F. Davis's avatar
      net: usb: asix88179_178a: Add support for the Belkin B2B128 · e20bd60b
      Andrew F. Davis authored
      The Belkin B2B128 is a USB 3.0 Hub + Gigabit Ethernet Adapter, the
      Ethernet adapter uses the ASIX AX88179 USB 3.0 to Gigabit Ethernet
      chip supported by this driver, add the USB ID for the same.
      This patch is based on work by Geoffrey Tran <geoffrey.tran@gmail.com>
      who has indicated they would like this upstreamed by someone more
      familiar with the upstreaming process.
      Signed-off-by: default avatarAndrew F. Davis <afd@ti.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Madalin Bucur's avatar
      fsl/fman: add dependency on HAS_DMA · 85688d9a
      Madalin Bucur authored
      A previous commit (5567e989) inserted a dependency on DMA
      API that requires HAS_DMA to be added in Kconfig.
      Signed-off-by: default avatarMadalin Bucur <madalin.bucur@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Vallish Vaidyeshwara's avatar
      dm thin: do not queue freed thin mapping for next stage processing · 00a0ea33
      Vallish Vaidyeshwara authored
      process_prepared_discard_passdown_pt1() should cleanup
      dm_thin_new_mapping in cases of error.
      dm_pool_inc_data_range() can fail trying to get a block reference:
      metadata operation 'dm_pool_inc_data_range' failed: error = -61
      When dm_pool_inc_data_range() fails, dm thin aborts current metadata
      transaction and marks pool as PM_READ_ONLY. Memory for thin mapping
      is released as well. However, current thin mapping will be queued
      onto next stage as part of queue_passdown_pt2() or passdown_endio().
      This dangling thin mapping memory when processed and accessed in
      next stage will lead to device mapper crashing.
      Code flow without fix:
      -> process_prepared_discard_passdown_pt1(m)
         -> dm_thin_remove_range()
         -> discard passdown
            --> passdown_endio(m) queues m onto next stage
         -> dm_pool_inc_data_range() fails, frees memory m
                  but does not remove it from next stage queue
      -> process_prepared_discard_passdown_pt2(m)
         -> processes freed memory m and crashes
      One such stack:
      Call Trace:
      [<ffffffffa037a46f>] dm_cell_release_no_holder+0x2f/0x70 [dm_bio_prison]
      [<ffffffffa039b6dc>] cell_defer_no_holder+0x3c/0x80 [dm_thin_pool]
      [<ffffffffa039b88b>] process_prepared_discard_passdown_pt2+0x4b/0x90 [dm_thin_pool]
      [<ffffffffa0399611>] process_prepared+0x81/0xa0 [dm_thin_pool]
      [<ffffffffa039e735>] do_worker+0xc5/0x820 [dm_thin_pool]
      [<ffffffff8152bf54>] ? __schedule+0x244/0x680
      [<ffffffff81087e72>] ? pwq_activate_delayed_work+0x42/0xb0
      [<ffffffff81089f53>] process_one_work+0x153/0x3f0
      [<ffffffff8108a71b>] worker_thread+0x12b/0x4b0
      [<ffffffff8108a5f0>] ? rescuer_thread+0x350/0x350
      [<ffffffff8108fd6a>] kthread+0xca/0xe0
      [<ffffffff8108fca0>] ? kthread_park+0x60/0x60
      [<ffffffff81530b45>] ret_from_fork+0x25/0x30
      The fix is to first take the block ref count for discarded block and
      then do a passdown discard of this block. If block ref count fails,
      then bail out aborting current metadata transaction, mark pool as
      PM_READ_ONLY and also free current thin mapping memory (existing error
      handling code) without queueing this thin mapping onto next stage of
      processing. If block ref count succeeds, then passdown discard of this
      block. Discard callback of passdown_endio() will queue this thin mapping
      onto next stage of processing.
      Code flow with fix:
      -> process_prepared_discard_passdown_pt1(m)
         -> dm_thin_remove_range()
         -> dm_pool_inc_data_range()
            --> if fails, free memory m and bail out
         -> discard passdown
            --> passdown_endio(m) queues m onto next stage
      Cc: stable <stable@vger.kernel.org> # v4.9+
      Reviewed-by: default avatarEduardo Valentin <eduval@amazon.com>
      Reviewed-by: default avatarCristian Gafton <gafton@amazon.com>
      Reviewed-by: default avatarAnchal Agarwal <anchalag@amazon.com>
      Signed-off-by: default avatarVallish Vaidyeshwara <vallish@amazon.com>
      Reviewed-by: default avatarJoe Thornber <ejt@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
    • Eric Dumazet's avatar
      net: prevent sign extension in dev_get_stats() · 6f64ec74
      Eric Dumazet authored
      Similar to the fix provided by Dominik Heidler in commit
      9b3dc0a1 ("l2tp: cast l2tp traffic counter to unsigned")
      we need to take care of 32bit kernels in dev_get_stats().
      When using atomic_long_read(), we add a 'long' to u64 and
      might misinterpret high order bit, unless we cast to unsigned.
      Fixes: caf586e5 ("net: add a core netdev->rx_dropped counter")
      Fixes: 015f0688 ("net: net: add a core netdev->tx_dropped counter")
      Fixes: 6e7333d3 ("net: add rx_nohandler stat counter")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Jarod Wilson <jarod@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Linus Torvalds's avatar
      Merge branch 'fixes' of git://git.armlinux.org.uk/~rmk/linux-arm · 3c2bfbaa
      Linus Torvalds authored
      Pull ARM fixes from Russell King:
       "Three more fixes:
         - Fix the previous fix merged in the last pull for the Thumb2
         - A fix from Vladimir to correctly identify the V7M cache type.
         - The optimised 3G vmsplit case does not work with LPAE, so don't
           allow this to be selected for LPAE configurations"
      * 'fixes' of git://git.armlinux.org.uk/~rmk/linux-arm:
        ARM: 8682/1: V7M: Set cacheid iff DminLine or IminLine is nonzero
        ARM: 8681/1: make VMSPLIT_3G_OPT depends on !ARM_LPAE
        ARM: 8680/1: boot/compressed: fix inappropriate Thumb2 mnemonic for __nop
  5. 26 Jun, 2017 2 commits