1. 29 Jun, 2017 13 commits
    • 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>
      d58299a4
    • 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
      implemented.
      
      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>
      e44699d2
    • 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>
      6bdf6abc
    • 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>
      00778f7c
    • 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>
      2a0ea04c
    • 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>
      cb108619
    • 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>
      0d494fcf
    • 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>
      5b858403
    • 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>
      acb4b7df
    • 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 192.168.0.1/24
      $ ip address del dev enp3s0np9.111 192.168.0.1/24
      $ 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>
      6b27c8ad
    • 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>
      c1a4872e
    • 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>
      713a98d9
  2. 27 Jun, 2017 3 commits
  3. 25 Jun, 2017 3 commits
  4. 23 Jun, 2017 7 commits
    • David S. Miller's avatar
      Merge branch 'bnxt_en-fixes' · 92cc8a51
      David S. Miller authored
      Michael Chan says:
      
      ====================
      bnxt_en: Error handling and netpoll fixes.
      
      Add missing error handling and fix netpoll handling.  The current code
      handles RX and TX events in netpoll mode and is causing lots of warnings
      and errors in the RX code path in netpoll mode.  The fix is to only handle
      TX events in netpoll mode.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      92cc8a51
    • Michael Chan's avatar
      bnxt_en: Fix netpoll handling. · 2270bc5d
      Michael Chan authored
      To handle netpoll properly, the driver must only handle TX packets
      during NAPI.  Handling RX events cause warnings and errors in
      netpoll mode. The ndo_poll_controller() method should call
      napi_schedule() directly so that a NAPI weight of zero will be used
      during netpoll mode.
      
      The bnxt_en driver supports 2 ring modes: combined, and separate rx/tx.
      In separate rx/tx mode, the ndo_poll_controller() method will only
      process the tx rings.  In combined mode, the rx and tx completion
      entries are mixed in the completion ring and we need to drop the rx
      entries and recycle the rx buffers.
      
      Add a function bnxt_force_rx_discard() to handle this in netpoll mode
      when we see rx entries in combined ring mode.
      Reported-by: default avatarCalvin Owens <calvinowens@fb.com>
      Signed-off-by: default avatarMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2270bc5d
    • Michael Chan's avatar
      bnxt_en: Add missing logic to handle TPA end error conditions. · 69c149e2
      Michael Chan authored
      When we get a TPA_END completion to handle a completed LRO packet, it
      is possible that hardware would indicate errors.  The current code is
      not checking for the error condition.  Define the proper error bits and
      the macro to check for this error and abort properly.
      Signed-off-by: default avatarMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      69c149e2
    • Richard Cochran's avatar
      net: dp83640: Avoid NULL pointer dereference. · db9d8b29
      Richard Cochran authored
      The function, skb_complete_tx_timestamp(), used to allow passing in a
      NULL pointer for the time stamps, but that was changed in commit
      62bccb8c ("net-timestamp: Make the
      clone operation stand-alone from phy timestamping"), and the existing
      call sites, all of which are in the dp83640 driver, were fixed up.
      
      Even though the kernel-doc was subsequently updated in commit
      7a76a021 ("net-timestamp: Update
      skb_complete_tx_timestamp comment"), still a bug fix from Manfred
      Rudigier came into the driver using the old semantics.  Probably
      Manfred derived that patch from an older kernel version.
      
      This fix should be applied to the stable trees as well.
      
      Fixes: 81e8f2e9 ("net: dp83640: Fix tx timestamp overflow handling.")
      Signed-off-by: default avatarRichard Cochran <richardcochran@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      db9d8b29
    • David S. Miller's avatar
      Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec · 43b786c6
      David S. Miller authored
      Steffen Klassert says:
      
      ====================
      pull request (net): ipsec 2017-06-23
      
      1) Fix xfrm garbage collecting when unregistering a netdevice.
         From Hangbin Liu.
      
      2) Fix NULL pointer derefernce when exiting a network namespace.
         From Hangbin Liu.
      
      3) Fix some error codes in pfkey to prevent a NULL pointer derefernce.
         From Dan Carpenter.
      
      4) Fix NULL pointer derefernce on allocation failure in pfkey.
         From Dan Carpenter.
      
      5) Adjust IPv6 payload_len to include extension headers. Otherwise
         we corrupt the packets when doing ESP GRO on transport mode.
         From Yossi Kuperman.
      
      6) Set nhoff to the proper offset of the IPv6 nexthdr when doing ESP GRO.
         From Yossi Kuperman.
      
      Please pull or let me know if there are problems.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      43b786c6
    • WANG Cong's avatar
      sit: use __GFP_NOWARN for user controlled allocation · 0ccc22f4
      WANG Cong authored
      The memory allocation size is controlled by user-space,
      if it is too large just fail silently and return NULL,
      not to mention there is a fallback allocation later.
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Tested-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0ccc22f4
    • Michal Kubeček's avatar
      net: account for current skb length when deciding about UFO · a5cb659b
      Michal Kubeček authored
      Our customer encountered stuck NFS writes for blocks starting at specific
      offsets w.r.t. page boundary caused by networking stack sending packets via
      UFO enabled device with wrong checksum. The problem can be reproduced by
      composing a long UDP datagram from multiple parts using MSG_MORE flag:
      
        sendto(sd, buff, 1000, MSG_MORE, ...);
        sendto(sd, buff, 1000, MSG_MORE, ...);
        sendto(sd, buff, 3000, 0, ...);
      
      Assume this packet is to be routed via a device with MTU 1500 and
      NETIF_F_UFO enabled. When second sendto() gets into __ip_append_data(),
      this condition is tested (among others) to decide whether to call
      ip_ufo_append_data():
      
        ((length + fragheaderlen) > mtu) || (skb && skb_is_gso(skb))
      
      At the moment, we already have skb with 1028 bytes of data which is not
      marked for GSO so that the test is false (fragheaderlen is usually 20).
      Thus we append second 1000 bytes to this skb without invoking UFO. Third
      sendto(), however, has sufficient length to trigger the UFO path so that we
      end up with non-UFO skb followed by a UFO one. Later on, udp_send_skb()
      uses udp_csum() to calculate the checksum but that assumes all fragments
      have correct checksum in skb->csum which is not true for UFO fragments.
      
      When checking against MTU, we need to add skb->len to length of new segment
      if we already have a partially filled skb and fragheaderlen only if there
      isn't one.
      
      In the IPv6 case, skb can only be null if this is the first segment so that
      we have to use headersize (length of the first IPv6 header) rather than
      fragheaderlen (length of IPv6 header of further fragments) for skb == NULL.
      
      Fixes: e89e9cf5 ("[IPv4/IPv6]: UFO Scatter-gather approach")
      Fixes: e4c5e13a ("ipv6: Should use consistent conditional judgement for
      	ip6 fragment between __ip6_append_data and ip6_finish_output")
      Signed-off-by: default avatarMichal Kubecek <mkubecek@suse.cz>
      Acked-by: default avatarVlad Yasevich <vyasevic@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a5cb659b
  5. 22 Jun, 2017 14 commits