1. 03 1月, 2017 4 次提交
    • A
      Documentation/networking: fix typo in mpls-sysctl · 4e5da369
      Alexander Alemayhu 提交于
      s/utliziation/utilization
      Signed-off-by: NAlexander Alemayhu <alexander@alemayhu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4e5da369
    • M
      igmp: Make igmp group member RFC 3376 compliant · 7ababb78
      Michal Tesar 提交于
      5.2. Action on Reception of a Query
      
       When a system receives a Query, it does not respond immediately.
       Instead, it delays its response by a random amount of time, bounded
       by the Max Resp Time value derived from the Max Resp Code in the
       received Query message.  A system may receive a variety of Queries on
       different interfaces and of different kinds (e.g., General Queries,
       Group-Specific Queries, and Group-and-Source-Specific Queries), each
       of which may require its own delayed response.
      
       Before scheduling a response to a Query, the system must first
       consider previously scheduled pending responses and in many cases
       schedule a combined response.  Therefore, the system must be able to
       maintain the following state:
      
       o A timer per interface for scheduling responses to General Queries.
      
       o A per-group and interface timer for scheduling responses to Group-
         Specific and Group-and-Source-Specific Queries.
      
       o A per-group and interface list of sources to be reported in the
         response to a Group-and-Source-Specific Query.
      
       When a new Query with the Router-Alert option arrives on an
       interface, provided the system has state to report, a delay for a
       response is randomly selected in the range (0, [Max Resp Time]) where
       Max Resp Time is derived from Max Resp Code in the received Query
       message.  The following rules are then used to determine if a Report
       needs to be scheduled and the type of Report to schedule.  The rules
       are considered in order and only the first matching rule is applied.
      
       1. If there is a pending response to a previous General Query
          scheduled sooner than the selected delay, no additional response
          needs to be scheduled.
      
       2. If the received Query is a General Query, the interface timer is
          used to schedule a response to the General Query after the
          selected delay.  Any previously pending response to a General
          Query is canceled.
      --8<--
      
      Currently the timer is rearmed with new random expiration time for
      every incoming query regardless of possibly already pending report.
      Which is not aligned with the above RFE.
      It also might happen that higher rate of incoming queries can
      postpone the report after the expiration time of the first query
      causing group membership loss.
      
      Now the per interface general query timer is rearmed only
      when there is no pending report already scheduled on that interface or
      the newly selected expiration time is before the already pending
      scheduled report.
      Signed-off-by: NMichal Tesar <mtesar@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7ababb78
    • I
      flow_dissector: Update pptp handling to avoid null pointer deref. · d0af6834
      Ian Kumlien 提交于
      __skb_flow_dissect can be called with a skb or a data packet, either
      can be NULL. All calls seems to have been moved to __skb_header_pointer
      except the pptp handling which is still calling skb_header_pointer.
      
      skb_header_pointer will use skb->data and thus:
      [  109.556866] BUG: unable to handle kernel NULL pointer dereference at 0000000000000080
      [  109.557102] IP: [<ffffffff88dc02f8>] __skb_flow_dissect+0xa88/0xce0
      [  109.557263] PGD 0
      [  109.557338]
      [  109.557484] Oops: 0000 [#1] SMP
      [  109.557562] Modules linked in: chaoskey
      [  109.557783] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.9.0 #79
      [  109.557867] Hardware name: Supermicro A1SRM-LN7F/LN5F/A1SRM-LN7F-2758, BIOS 1.0c 11/04/2015
      [  109.557957] task: ffff94085c27bc00 task.stack: ffffb745c0068000
      [  109.558041] RIP: 0010:[<ffffffff88dc02f8>]  [<ffffffff88dc02f8>] __skb_flow_dissect+0xa88/0xce0
      [  109.558203] RSP: 0018:ffff94087fc83d40  EFLAGS: 00010206
      [  109.558286] RAX: 0000000000000130 RBX: ffffffff8975bf80 RCX: ffff94084fab6800
      [  109.558373] RDX: 0000000000000010 RSI: 000000000000000c RDI: 0000000000000000
      [  109.558460] RBP: 0000000000000b88 R08: 0000000000000000 R09: 0000000000000022
      [  109.558547] R10: 0000000000000008 R11: ffff94087fc83e04 R12: 0000000000000000
      [  109.558763] R13: ffff94084fab6800 R14: ffff94087fc83e04 R15: 000000000000002f
      [  109.558979] FS:  0000000000000000(0000) GS:ffff94087fc80000(0000) knlGS:0000000000000000
      [  109.559326] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  109.559539] CR2: 0000000000000080 CR3: 0000000281809000 CR4: 00000000001026e0
      [  109.559753] Stack:
      [  109.559957]  000000000000000c ffff94084fab6822 0000000000000001 ffff94085c2b5fc0
      [  109.560578]  0000000000000001 0000000000002000 0000000000000000 0000000000000000
      [  109.561200]  0000000000000000 0000000000000000 0000000000000000 0000000000000000
      [  109.561820] Call Trace:
      [  109.562027]  <IRQ>
      [  109.562108]  [<ffffffff88dfb4fa>] ? eth_get_headlen+0x7a/0xf0
      [  109.562522]  [<ffffffff88c5a35a>] ? igb_poll+0x96a/0xe80
      [  109.562737]  [<ffffffff88dc912b>] ? net_rx_action+0x20b/0x350
      [  109.562953]  [<ffffffff88546d68>] ? __do_softirq+0xe8/0x280
      [  109.563169]  [<ffffffff8854704a>] ? irq_exit+0xaa/0xb0
      [  109.563382]  [<ffffffff8847229b>] ? do_IRQ+0x4b/0xc0
      [  109.563597]  [<ffffffff8902d4ff>] ? common_interrupt+0x7f/0x7f
      [  109.563810]  <EOI>
      [  109.563890]  [<ffffffff88d57530>] ? cpuidle_enter_state+0x130/0x2c0
      [  109.564304]  [<ffffffff88d57520>] ? cpuidle_enter_state+0x120/0x2c0
      [  109.564520]  [<ffffffff8857eacf>] ? cpu_startup_entry+0x19f/0x1f0
      [  109.564737]  [<ffffffff8848d55a>] ? start_secondary+0x12a/0x140
      [  109.564950] Code: 83 e2 20 a8 80 0f 84 60 01 00 00 c7 04 24 08 00
      00 00 66 85 d2 0f 84 be fe ff ff e9 69 fe ff ff 8b 34 24 89 f2 83 c2
      04 66 85 c0 <41> 8b 84 24 80 00 00 00 0f 49 d6 41 8d 31 01 d6 41 2b 84
      24 84
      [  109.569959] RIP  [<ffffffff88dc02f8>] __skb_flow_dissect+0xa88/0xce0
      [  109.570245]  RSP <ffff94087fc83d40>
      [  109.570453] CR2: 0000000000000080
      
      Fixes: ab10dccb ("rps: Inspect PPTP encapsulated by GRE to get flow hash")
      Signed-off-by: NIan Kumlien <ian.kumlien@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d0af6834
    • D
      Merge tag 'mac80211-for-davem-2017-01-02' of... · 94ba998b
      David S. Miller 提交于
      Merge tag 'mac80211-for-davem-2017-01-02' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
      
      Johannes Berg says:
      
      ====================
      A single fix to avoid loading an skb->cb pointer too early.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      94ba998b
  2. 02 1月, 2017 6 次提交
  3. 30 12月, 2016 12 次提交
  4. 29 12月, 2016 16 次提交
  5. 28 12月, 2016 2 次提交
    • F
      net: stmmac: Fix race between stmmac_drv_probe and stmmac_open · 57016590
      Florian Fainelli 提交于
      There is currently a small window during which the network device registered by
      stmmac can be made visible, yet all resources, including and clock and MDIO bus
      have not had a chance to be set up, this can lead to the following error to
      occur:
      
      [  473.919358] stmmaceth 0000:01:00.0 (unnamed net_device) (uninitialized):
                      stmmac_dvr_probe: warning: cannot get CSR clock
      [  473.919382] stmmaceth 0000:01:00.0: no reset control found
      [  473.919412] stmmac - user ID: 0x10, Synopsys ID: 0x42
      [  473.919429] stmmaceth 0000:01:00.0: DMA HW capability register supported
      [  473.919436] stmmaceth 0000:01:00.0: RX Checksum Offload Engine supported
      [  473.919443] stmmaceth 0000:01:00.0: TX Checksum insertion supported
      [  473.919451] stmmaceth 0000:01:00.0 (unnamed net_device) (uninitialized):
                      Enable RX Mitigation via HW Watchdog Timer
      [  473.921395] libphy: PHY stmmac-1:00 not found
      [  473.921417] stmmaceth 0000:01:00.0 eth0: Could not attach to PHY
      [  473.921427] stmmaceth 0000:01:00.0 eth0: stmmac_open: Cannot attach to
                      PHY (error: -19)
      [  473.959710] libphy: stmmac: probed
      [  473.959724] stmmaceth 0000:01:00.0 eth0: PHY ID 01410cc2 at 0 IRQ POLL
                      (stmmac-1:00) active
      [  473.959728] stmmaceth 0000:01:00.0 eth0: PHY ID 01410cc2 at 1 IRQ POLL
                      (stmmac-1:01)
      [  473.959731] stmmaceth 0000:01:00.0 eth0: PHY ID 01410cc2 at 2 IRQ POLL
                      (stmmac-1:02)
      [  473.959734] stmmaceth 0000:01:00.0 eth0: PHY ID 01410cc2 at 3 IRQ POLL
                      (stmmac-1:03)
      
      Fix this by making sure that register_netdev() is the last thing being done,
      which guarantees that the clock and the MDIO bus are available.
      
      Fixes: 4bfcbd7a ("stmmac: Move the mdio_register/_unregister in probe/remove")
      Reported-by: NKweh, Hock Leong <hock.leong.kweh@intel.com>
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      57016590
    • L
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net · 8f18e4d0
      Linus Torvalds 提交于
      Pull networking fixes from David Miller:
      
       1) Various ipvlan fixes from Eric Dumazet and Mahesh Bandewar.
      
          The most important is to not assume the packet is RX just because
          the destination address matches that of the device. Such an
          assumption causes problems when an interface is put into loopback
          mode.
      
       2) If we retry when creating a new tc entry (because we dropped the
          RTNL mutex in order to load a module, for example) we end up with
          -EAGAIN and then loop trying to replay the request. But we didn't
          reset some state when looping back to the top like this, and if
          another thread meanwhile inserted the same tc entry we were trying
          to, we re-link it creating an enless loop in the tc chain. Fix from
          Daniel Borkmann.
      
       3) There are two different WRITE bits in the MDIO address register for
          the stmmac chip, depending upon the chip variant. Due to a bug we
          could set them both, fix from Hock Leong Kweh.
      
       4) Fix mlx4 bug in XDP_TX handling, from Tariq Toukan.
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net:
        net: stmmac: fix incorrect bit set in gmac4 mdio addr register
        r8169: add support for RTL8168 series add-on card.
        net: xdp: remove unused bfp_warn_invalid_xdp_buffer()
        openvswitch: upcall: Fix vlan handling.
        ipv4: Namespaceify tcp_tw_reuse knob
        net: korina: Fix NAPI versus resources freeing
        net, sched: fix soft lockup in tc_classify
        net/mlx4_en: Fix user prio field in XDP forward
        tipc: don't send FIN message from connectionless socket
        ipvlan: fix multicast processing
        ipvlan: fix various issues in ipvlan_process_multicast()
      8f18e4d0