1. 30 6月, 2017 6 次提交
    • C
    • M
      arcnet: change irq handler to lock irqsave · 5b858403
      Michael Grzeschik 提交于
      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: NMichael Grzeschik <m.grzeschik@pengutronix.de>
      
         ---
         v1 -> v2: removed unneeded zero assignment of flags
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5b858403
    • D
      rocker: move dereference before free · acb4b7df
      Dan Carpenter 提交于
      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: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      acb4b7df
    • I
      mlxsw: spectrum_router: Fix NULL pointer dereference · 6b27c8ad
      Ido Schimmel 提交于
      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: NIdo Schimmel <idosch@mellanox.com>
      Reported-by: NPetr Machata <petrm@mellanox.com>
      Tested-by: NPetr Machata <petrm@mellanox.com>
      Reviewed-by: NPetr Machata <petrm@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6b27c8ad
    • G
      net: sched: Fix one possible panic when no destroy callback · c1a4872e
      Gao Feng 提交于
      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: NGao Feng <gfree.wind@vip.163.com>
      Acked-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c1a4872e
    • J
      virtio-net: serialize tx routine during reset · 713a98d9
      Jason Wang 提交于
      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: NJean-Philippe Menil <jpmenil@gmail.com>
      Tested-by: NJean-Philippe Menil <jpmenil@gmail.com>
      Fixes commit f600b690 ("virtio_net: Add XDP support")
      Cc: John Fastabend <john.fastabend@gmail.com>
      Signed-off-by: NJason Wang <jasowang@redhat.com>
      Acked-by: NMichael S. Tsirkin <mst@redhat.com>
      Acked-by: NRobert McCabe <robert.mccabe@rockwellcollins.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      713a98d9
  2. 28 6月, 2017 3 次提交
  3. 26 6月, 2017 1 次提交
  4. 25 6月, 2017 2 次提交
  5. 24 6月, 2017 7 次提交
    • D
      Merge branch 'bnxt_en-fixes' · 92cc8a51
      David S. Miller 提交于
      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: NDavid S. Miller <davem@davemloft.net>
      92cc8a51
    • M
      bnxt_en: Fix netpoll handling. · 2270bc5d
      Michael Chan 提交于
      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: NCalvin Owens <calvinowens@fb.com>
      Signed-off-by: NMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2270bc5d
    • M
      bnxt_en: Add missing logic to handle TPA end error conditions. · 69c149e2
      Michael Chan 提交于
      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: NMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      69c149e2
    • R
      net: dp83640: Avoid NULL pointer dereference. · db9d8b29
      Richard Cochran 提交于
      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: NRichard Cochran <richardcochran@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      db9d8b29
    • D
      Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec · 43b786c6
      David S. Miller 提交于
      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: NDavid S. Miller <davem@davemloft.net>
      43b786c6
    • W
      sit: use __GFP_NOWARN for user controlled allocation · 0ccc22f4
      WANG Cong 提交于
      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: NAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
      Tested-by: NAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0ccc22f4
    • M
      net: account for current skb length when deciding about UFO · a5cb659b
      Michal Kubeček 提交于
      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: NMichal Kubecek <mkubecek@suse.cz>
      Acked-by: NVlad Yasevich <vyasevic@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a5cb659b
  6. 23 6月, 2017 3 次提交
  7. 22 6月, 2017 18 次提交
    • D
      Merge branch 'macvlan-Fix-some-issues-with-changing-mac-addresses' · 8c4354ef
      David S. Miller 提交于
      Vladislav Yasevich says:
      
      ====================
      macvlan: Fix some issues with changing mac addresses
      
      There are some issues in macvlan wrt to changing it's mac address.
      * An error is returned in the specified address is the same as an already
        assigned address.
      * In passthru mode, the mac address of the macvlan device doesn't change.
      * After changing the mac address of a passthru macvlan and then removing it,
        the mac address of the physical device remains changed.
      
      This patch series attempts to resolve these issues.
      
      V2: Address a small issue in p4 where we save the address from the lowerdev
          (from girish.moodalbail@oracle.com)
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8c4354ef
    • V
      macvlan: Let passthru macvlan correctly restore lower mac address · 18c8c54d
      Vlad Yasevich 提交于
      Passthru macvlans directly change the mac address of the lower
      level device.  That's OK, but after the macvlan is deleted,
      the lower device is left with changed address and one needs to
      reboot to bring back the origina HW addresses.
      
      This scenario is actually quite common with passthru macvtap devices.
      
      This patch attempts to solve this, by storing the mac address
      of the lower device in macvlan_port structure and keeping track of
      it through the changes.
      
      After this patch, any changes to the lower device mac address
      done trough the macvlan device, will be reverted back.  Any
      changs done directly to the lower device mac address will be kept.
      Signed-off-by: NVladislav Yasevich <vyasevic@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      18c8c54d
    • V
      macvlan: convert port passthru to flags. · 43c2d578
      Vlad Yasevich 提交于
      Convert the port passthru boolean into flags with accesor functions.
      Signed-off-by: NVladislav Yasevich <vyasevic@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      43c2d578
    • V
      macvlan: Fix passthru macvlan mac address inheritance · e696cda7
      Vlad Yasevich 提交于
      When a lower device of the passthru macvlan changes it's address,
      passthru macvlan is supposed to change it's own address as well.
      However, that doesn't happen correctly because the check in
      macvlan_addr_busy() will catch the fact that the lower level
      (port) mac address is the same as the address we are trying to
      assign to the macvlan, and return an error.  As a reasult,
      the address of the passthru macvlan device is never changed.
      
      The same thing happens when the user attempts to change the
      mac address of the passthru macvlan.
      
      The simple solution appers to be to not check against
      the lower device in case of passthru macvlan device, since
      the 2 addresses are _supposed_ to be the same.
      Signed-off-by: NVladislav Yasevich <vyasevic@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e696cda7
    • V
      macvlan: Do not return error when setting the same mac address · e26f43fa
      Vlad Yasevich 提交于
      The user currently gets an EBUSY error when attempting to set
      the mac address on a macvlan device to the same value.
      
      This should really be a no-op as nothing changes.  Catch
      the condition and return early.
      Signed-off-by: NVladislav Yasevich <vyasevic@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e26f43fa
    • W
      xen-netback: correctly schedule rate-limited queues · dfa523ae
      Wei Liu 提交于
      Add a flag to indicate if a queue is rate-limited. Test the flag in
      NAPI poll handler and avoid rescheduling the queue if true, otherwise
      we risk locking up the host. The rescheduling will be done in the
      timer callback function.
      Reported-by: NJean-Louis Dupond <jean-louis@dupond.be>
      Signed-off-by: NWei Liu <wei.liu2@citrix.com>
      Tested-by: NJean-Louis Dupond <jean-louis@dupond.be>
      Reviewed-by: NPaul Durrant <paul.durrant@citrix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      dfa523ae
    • S
      veth: Be more robust on network device creation when no attributes · 191cdb38
      Serhey Popovych 提交于
      There are number of problems with configuration peer
      network device in absence of IFLA_VETH_PEER attributes
      where attributes for main network device shared with
      peer.
      
      First it is not feasible to configure both network
      devices with same MAC address since this makes
      communication in such configuration problematic.
      
      This case can be reproduced with following sequence:
      
        # ip link add address 02:11:22:33:44:55 type veth
        # ip li sh
        ...
        26: veth0@veth1: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc \
        noop state DOWN mode DEFAULT qlen 1000
            link/ether 00:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff
        27: veth1@veth0: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc \
        noop state DOWN mode DEFAULT qlen 1000
            link/ether 00:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff
      
      Second it is not possible to register both main and
      peer network devices with same name, that happens
      when name for main interface is given with IFLA_IFNAME
      and same attribute reused for peer.
      
      This case can be reproduced with following sequence:
      
        # ip link add dev veth1a type veth
        RTNETLINK answers: File exists
      
      To fix both of the cases check if corresponding netlink
      attributes are taken from peer_tb when valid or
      name based on rtnl ops kind and random address is used.
      Signed-off-by: NSerhey Popovych <serhe.popovych@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      191cdb38
    • L
      drivers: net: cpsw-common: Fix reading of mac address for am43 SoCs · b88ff4f8
      Lokesh Vutla 提交于
      cpsw driver tries to get macid for am43xx SoCs using the compatible
      ti,am4372. But not all variants of am43x uses this complatible like
      epos evm uses ti,am438x. So use a generic compatible ti,am43 to get
      macid for all am43 based platforms.
      Reviewed-by: NDave Gerlach <d-gerlach@ti.com>
      Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b88ff4f8
    • W
      ipv6: only call ip6_route_dev_notify() once for NETDEV_UNREGISTER · 76da0704
      WANG Cong 提交于
      In commit 242d3a49 ("ipv6: reorder ip6_route_dev_notifier after ipv6_dev_notf")
      I assumed NETDEV_REGISTER and NETDEV_UNREGISTER are paired,
      unfortunately, as reported by jeffy, netdev_wait_allrefs()
      could rebroadcast NETDEV_UNREGISTER event until all refs are
      gone.
      
      We have to add an additional check to avoid this corner case.
      For netdev_wait_allrefs() dev->reg_state is NETREG_UNREGISTERED,
      for dev_change_net_namespace(), dev->reg_state is
      NETREG_REGISTERED. So check for dev->reg_state != NETREG_UNREGISTERED.
      
      Fixes: 242d3a49 ("ipv6: reorder ip6_route_dev_notifier after ipv6_dev_notf")
      Reported-by: Njeffy <jeffy.chen@rock-chips.com>
      Cc: David Ahern <dsahern@gmail.com>
      Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
      Acked-by: NDavid Ahern <dsahern@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      76da0704
    • Z
      net/phy: micrel: configure intterupts after autoneg workaround · b866203d
      Zach Brown 提交于
      The commit ("net/phy: micrel: Add workaround for bad autoneg") fixes an
      autoneg failure case by resetting the hardware. This turns off
      intterupts. Things will work themselves out if the phy polls, as it will
      figure out it's state during a poll. However if the phy uses only
      intterupts, the phy will stall, since interrupts are off. This patch
      fixes the issue by calling config_intr after resetting the phy.
      
      Fixes: d2fd719b ("net/phy: micrel: Add workaround for bad autoneg ")
      Signed-off-by: NZach Brown <zach.brown@ni.com>
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b866203d
    • Y
      esp6_offload: Fix IP6CB(skb)->nhoff for ESP GRO · ca3a1b85
      Yossi Kuperman 提交于
      IP6CB(skb)->nhoff is the offset of the nexthdr field in an IPv6
      header, unless there are extension headers present, in which case
      nhoff points to the nexthdr field of the last extension header.
      
      In non-GRO code path, nhoff is set by ipv6_rcv before any XFRM code
      is executed. Conversely, in GRO code path (when esp6_offload is loaded),
      nhoff is not set. The following functions fail to read the correct value
      and eventually the packet is dropped:
      
          xfrm6_transport_finish
          xfrm6_tunnel_input
          xfrm6_rcv_tnl
      
      Set nhoff to the proper offset of nexthdr in esp6_gro_receive.
      
      Fixes: 7785bba2 ("esp: Add a software GRO codepath")
      Signed-off-by: NYossi Kuperman <yossiku@mellanox.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      ca3a1b85
    • Y
      xfrm6: Fix IPv6 payload_len in xfrm6_transport_finish · 7c88e21a
      Yossi Kuperman 提交于
      IPv6 payload length indicates the size of the payload, including any
      extension headers.
      
      In xfrm6_transport_finish, ipv6_hdr(skb)->payload_len is set to the
      payload size only, regardless of the presence of any extension headers.
      After ESP GRO transport mode decapsulation, ipv6_rcv trims the packet
      according to the wrong payload_len, thus corrupting the packet.
      
      Set payload_len to account for extension headers as well.
      
      Fixes: 7785bba2 ("esp: Add a software GRO codepath")
      Signed-off-by: NYossi Kuperman <yossiku@mellanox.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      7c88e21a
    • L
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net · 48b6bbef
      Linus Torvalds 提交于
      Pull networking fixes from David Miller:
      
       1) Fix refcounting wrt timers which hold onto inet6 address objects,
          from Xin Long.
      
       2) Fix an ancient bug in wireless wext ioctls, from Johannes Berg.
      
       3) Firmware handling fixes in brcm80211 driver, from Arend Van Spriel.
      
       4) Several mlx5 driver fixes (firmware readiness, timestamp cap
          reporting, devlink command validity checking, tc offloading, etc.)
          From Eli Cohen, Maor Dickman, Chris Mi, and Or Gerlitz.
      
       5) Fix dst leak in IP/IP6 tunnels, from Haishuang Yan.
      
       6) Fix dst refcount bug in decnet, from Wei Wang.
      
       7) Netdev can be double freed in register_vlan_device(). Fix from Gao
          Feng.
      
       8) Don't allow object to be destroyed while it is being dumped in SCTP,
          from Xin Long.
      
       9) Fix dpaa_eth build when modular, from Madalin Bucur.
      
      10) Fix throw route leaks, from Serhey Popovych.
      
      11) IFLA_GROUP missing from if_nlmsg_size() and ifla_policy[] table,
          also from Serhey Popovych.
      
      12) Fix premature TX SKB free in stmmac, from Niklas Cassel.
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (36 commits)
        igmp: add a missing spin_lock_init()
        net: stmmac: free an skb first when there are no longer any descriptors using it
        sfc: remove duplicate up_write on VF filter_sem
        rtnetlink: add IFLA_GROUP to ifla_policy
        ipv6: Do not leak throw route references
        dt-bindings: net: sms911x: Add missing optional VDD regulators
        dpaa_eth: reuse the dma_ops provided by the FMan MAC device
        fsl/fman: propagate dma_ops
        net/core: remove explicit do_softirq() from busy_poll_stop()
        fib_rules: Resolve goto rules target on delete
        sctp: ensure ep is not destroyed before doing the dump
        net/hns:bugfix of ethtool -t phy self_test
        net: 8021q: Fix one possible panic caused by BUG_ON in free_netdev
        cxgb4: notify uP to route ctrlq compl to rdma rspq
        ip6_tunnel: Correct tos value in collect_md mode
        decnet: always not take dst->__refcnt when inserting dst into hash table
        ip6_tunnel: fix potential issue in __ip6_tnl_rcv
        ip_tunnel: fix potential issue in ip_tunnel_rcv
        brcmfmac: fix uninitialized warning in brcmf_usb_probe_phase2()
        net/mlx5e: Avoid doing a cleanup call if the profile doesn't have it
        ...
      48b6bbef
    • L
      Merge tag 'pinctrl-v4.12-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl · ce879b64
      Linus Torvalds 提交于
      Pull more pin control fixes from Linus Walleij:
       "Some late arriving fixes. I should have sent earlier, just swamped
        with work as usual. Thomas patch makes AMD systems usable despite
        firmware bugs so it is fairly important.
      
         - Make the AMD driver use a regular interrupt rather than a chained
           one, so the system does not lock up.
      
         - Fix a function call error deep inside the STM32 driver"
      
      * tag 'pinctrl-v4.12-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
        pinctrl: stm32: Fix bad function call
        pinctrl/amd: Use regular interrupt instead of chained
      ce879b64
    • L
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid · db1b5ccd
      Linus Torvalds 提交于
      Pull HID fixes from Jiri Kosina:
      
       - revert of a commit to magicmouse driver that regressess certain
         devices, from Daniel Stone
      
       - quirk for a specific Dell mouse, from Sebastian Parschauer
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid:
        Revert "HID: magicmouse: Set multi-touch keybits for Magic Mouse"
        HID: Add quirk for Dell PIXART OEM mouse
      db1b5ccd
    • L
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/livepatching · dcba7108
      Linus Torvalds 提交于
      Pull livepatching fix from Jiri Kosina:
       "Fix the way how livepatches are being stacked with respect to RCU,
        from Petr Mladek"
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/livepatching:
        livepatch: Fix stacking of patches with respect to RCU
      dcba7108
    • L
      Merge branch 'ufs-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs · 021f6019
      Linus Torvalds 提交于
      Pull more ufs fixes from Al Viro:
       "More UFS fixes, unfortunately including build regression fix for the
        64-bit s_dsize commit. Fixed in this pile:
      
         - trivial bug in signedness of 32bit timestamps on ufs1
      
         - ESTALE instead of ufs_error() when doing open-by-fhandle on
           something deleted
      
         - build regression on 32bit in ufs_new_fragments() - calculating that
           many percents of u64 pulls libgcc stuff on some of those. Mea
           culpa.
      
         - fix hysteresis loop broken by typo in 2.4.14.7 (right next to the
           location of previous bug).
      
         - fix the insane limits of said hysteresis loop on filesystems with
           very low percentage of reserved blocks. If it's 5% or less, just
           use the OPTSPACE policy.
      
         - calculate those limits once and mount time.
      
        This tree does pass xfstests clean (both ufs1 and ufs2) and it _does_
        survive cross-builds.
      
        Again, my apologies for missing that, especially since I have noticed
        a related percentage-of-64bit issue in earlier patches (when dealing
        with amount of reserved blocks). Self-LART applied..."
      
      * 'ufs-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
        ufs: fix the logics for tail relocation
        ufs_iget(): fail with -ESTALE on deleted inode
        fix signedness of timestamps on ufs1
      021f6019
    • H
      Allow stack to grow up to address space limit · bd726c90
      Helge Deller 提交于
      Fix expand_upwards() on architectures with an upward-growing stack (parisc,
      metag and partly IA-64) to allow the stack to reliably grow exactly up to
      the address space limit given by TASK_SIZE.
      Signed-off-by: NHelge Deller <deller@gmx.de>
      Acked-by: NHugh Dickins <hughd@google.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      bd726c90