1. 08 11月, 2013 26 次提交
  2. 07 11月, 2013 6 次提交
  3. 06 11月, 2013 8 次提交
    • J
      virtio-net: switch to use XPS to choose txq · 9bb8ca86
      Jason Wang 提交于
      We used to use a percpu structure vq_index to record the cpu to queue
      mapping, this is suboptimal since it duplicates the work of XPS and
      loses all other XPS functionality such as allowing user to configure
      their own transmission steering strategy.
      
      So this patch switches to use XPS and suggest a default mapping when
      the number of cpus is equal to the number of queues. With XPS support,
      there's no need for keeping per-cpu vq_index and .ndo_select_queue(),
      so they were removed also.
      
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Michael S. Tsirkin <mst@redhat.com>
      Acked-by: NRusty Russell <rusty@rustcorp.com.au>
      Acked-by: NMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: NJason Wang <jasowang@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9bb8ca86
    • D
      ipv6: drop the judgement in rt6_alloc_cow() · 249a3630
      Duan Jiong 提交于
      Now rt6_alloc_cow() is only called by ip6_pol_route() when
      rt->rt6i_flags doesn't contain both RTF_NONEXTHOP and RTF_GATEWAY,
      and rt->rt6i_flags hasn't been changed in ip6_rt_copy().
      So there is no neccessary to judge whether rt->rt6i_flags contains
      RTF_GATEWAY or not.
      Signed-off-by: NDuan Jiong <duanj.fnst@cn.fujitsu.com>
      Acked-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      249a3630
    • H
      ipv6: fix headroom calculation in udp6_ufo_fragment · 0e033e04
      Hannes Frederic Sowa 提交于
      Commit 1e2bd517 ("udp6: Fix udp
      fragmentation for tunnel traffic.") changed the calculation if
      there is enough space to include a fragment header in the skb from a
      skb->mac_header dervived one to skb_headroom. Because we already peeled
      off the skb to transport_header this is wrong. Change this back to check
      if we have enough room before the mac_header.
      
      This fixes a panic Saran Neti reported. He used the tbf scheduler which
      skb_gso_segments the skb. The offsets get negative and we panic in memcpy
      because the skb was erroneously not expanded at the head.
      Reported-by: NSaran Neti <Saran.Neti@telus.com>
      Cc: Pravin B Shelar <pshelar@nicira.com>
      Signed-off-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0e033e04
    • J
      net: mv643xx_eth: Add missing phy_addr_set in DT mode · 1cce16d3
      Jason Gunthorpe 提交于
      Commit cc9d4598 'net: mv643xx_eth: use of_phy_connect if phy_node
      present' made the call to phy_scan optional, if the DT has a link to
      the phy node.
      
      However phy_scan has the side effect of calling phy_addr_set, which
      writes the phy MDIO address to the ethernet controller. If phy_addr_set
      is not called, and the bootloader has not set the correct address then
      the driver will fail to function.
      
      Tested on Kirkwood.
      Signed-off-by: NJason Gunthorpe <jgunthorpe@obsidianresearch.com>
      Acked-by: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
      Tested-by: NArnaud Ebalard <arno@natisbad.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1cce16d3
    • H
      ipv4: introduce new IP_MTU_DISCOVER mode IP_PMTUDISC_INTERFACE · 482fc609
      Hannes Frederic Sowa 提交于
      Sockets marked with IP_PMTUDISC_INTERFACE won't do path mtu discovery,
      their sockets won't accept and install new path mtu information and they
      will always use the interface mtu for outgoing packets. It is guaranteed
      that the packet is not fragmented locally. But we won't set the DF-Flag
      on the outgoing frames.
      
      Florian Weimer had the idea to use this flag to ensure DNS servers are
      never generating outgoing fragments. They may well be fragmented on the
      path, but the server never stores or usees path mtu values, which could
      well be forged in an attack.
      
      (The root of the problem with path MTU discovery is that there is
      no reliable way to authenticate ICMP Fragmentation Needed But DF Set
      messages because they are sent from intermediate routers with their
      source addresses, and the IMCP payload will not always contain sufficient
      information to identify a flow.)
      
      Recent research in the DNS community showed that it is possible to
      implement an attack where DNS cache poisoning is feasible by spoofing
      fragments. This work was done by Amir Herzberg and Haya Shulman:
      <https://sites.google.com/site/hayashulman/files/fragmentation-poisoning.pdf>
      
      This issue was previously discussed among the DNS community, e.g.
      <http://www.ietf.org/mail-archive/web/dnsext/current/msg01204.html>,
      without leading to fixes.
      
      This patch depends on the patch "ipv4: fix DO and PROBE pmtu mode
      regarding local fragmentation with UFO/CORK" for the enforcement of the
      non-fragmentable checks. If other users than ip_append_page/data should
      use this semantic too, we have to add a new flag to IPCB(skb)->flags to
      suppress local fragmentation and check for this in ip_finish_output.
      
      Many thanks to Florian Weimer for the idea and feedback while implementing
      this patch.
      
      Cc: David S. Miller <davem@davemloft.net>
      Suggested-by: NFlorian Weimer <fweimer@redhat.com>
      Signed-off-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      482fc609
    • D
      Merge branch 'huawei_cdc_ncm' · b9155501
      David S. Miller 提交于
      Bjørn Mork says:
      
      ====================
      The huawei_cdc_ncm driver.
      
      Enrico has been kind enough to let me repost his driver with the changes
      requested by Oliver Neukum during the last review of this series.
      
      The changes I have made from Enricos original v5 series to this version
      are:
      
      v6:
       - fix to avoid corrupting drvstate->pmcount
       - fix error return value from huawei_cdc_ncm_suspend()
       - drop redundant testing for subdriver->suspend during resume
       - broke a few lines to keep within the 80 columns recommendation
       - rebased on top of current net-next
      
      Enrico's orginal introduction to the v5 series follows below.  It explains
      the background much better than I can.
      
      Bjørn
      
      [quote Enrico Mioso]
      
      So this is a new, revised, edition of the huawei_cdc_ncm.c driver, which
      supports devices resembling the NCM standard, but using it also as a mean
      to encapsulate other protocols, as is the case for the Huawei E3131 and
      E3251 modem devices.
      Some precisations are needed however - and I encourage discussion on this: and
      that's why I'm sending this message with a broader CC.
      Merging those patches might change:
      - the way Modem Manager interacts with those devices
      - some regressions might be possible if there are some unknown firmware
        variants around (Franko?)
      
      First of all: I observed the behaviours of two devices.
      Huawei E3131: this device doesn't accept NDIS setup requests unless they're
      sent via the embedded AT channel exposed by this driver.
      So actually we gain funcionality in this case!
      
      The second case, is the Huawei E3251: which works with standard NCM driver,
      still exposing an AT embedded channel. Whith this patch set applied, you gain
      some funcionality, loosing the ability to catch standard NCM events for now.
      The device will work in both ways with no problems, but this has to be
      acknowledged and discussed. Might be we can develop this driver further to
      change this, when more devices are tested.
      
      We where thinking Huawei changed their interfaces on new devices - but probably
      this driver only works around a nice firmware bug present in E3131, which
      prevented the modem from being used in NDIS mode.
      
      I think committing this is definitely wortth-while, since it will allow for
      more Huawei devices to be used without serial connection. Some devices like the
      E3251 also, reports some status information only via the embedded AT channel,
      at least in my case.
      Note: I'm not subscribed to any list except the Modem Manager's one, so please
      CC me, thanks!!
      
      [/quote]
      
      Enrico Mioso (3):
        net: cdc_ncm: Export cdc_ncm_{tx,rx}_fixup functions for re-use
        net: huawei_cdc_ncm: Introduce the huawei_cdc_ncm driver
        net: cdc_ncm: remove non-standard NCM device IDs
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b9155501
    • E
      net: cdc_ncm: remove non-standard NCM device IDs · 9fea037d
      Enrico Mioso 提交于
      Remove device IDs of NCM-like (but not NCM-conformant) devices, that are
      handled by the huawwei_cdc_ncm driver now.
      Signed-off-by: NEnrico Mioso <mrkiko.rs@gmail.com>
      Signed-off-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9fea037d
    • E
      net: huawei_cdc_ncm: Introduce the huawei_cdc_ncm driver · 41c47d8c
      Enrico Mioso 提交于
      This driver supports devices using the NCM protocol as an encapsulation layer
      for other protocols, like the E3131 Huawei 3G modem. This drivers approach was
      heavily inspired by the qmi_wwan/cdc_mbim approach & code model.
      Signed-off-by: NEnrico Mioso <mrkiko.rs@gmail.com>
      Signed-off-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      41c47d8c