Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit be408cd3 authored by Linus Torvalds's avatar Linus Torvalds
Browse files

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net 

Pull networking fixes from David Miller:
 "I'm sending a pull request of these lingering bug fixes for networking
  before the normal merge window material because some of this stuff I'd
  like to get to -stable ASAP"

 1) cxgb3 stopped working on 32-bit machines, fix from Ben Hutchings.

 2) Structures passed via netlink for netfilter logging are not fully
    initialized.  From Mathias Krause.

 3) Properly unlink upper openvswitch device during notifications, from
    Alexei Starovoitov.

 4) Fix race conditions involving access to the IP compression scratch
    buffer, from Michal Kubrecek.

 5) We don't handle the expiration of MTU information contained in ipv6
    routes sometimes, fix from Hannes Frederic Sowa.

 6) With Fast Open we can miscompute the TCP SYN/ACK RTT, from Yuchung
    Cheng.

 7) Don't take TCP RTT sample when an ACK doesn't acknowledge new data,
    also from Yuchung Cheng.

 8) The decreased IPSEC garbage collection threshold causes problems for
    some people, bump it back up.  From Steffen Klassert.

 9) Fix skb->truesize calculated by tcp_tso_segment(), from Eric
    Dumazet.

10) flow_dissector doesn't validate packet lengths sufficiently, from
    Jason Wang

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (41 commits)
  net/mlx4_core: Fix call to __mlx4_unregister_mac
  net: sctp: do not trigger BUG_ON in sctp_cmd_delete_tcb
  net: flow_dissector: fail on evil iph->ihl
  xfrm: Fix null pointer dereference when decoding sessions
  can: kvaser_usb: fix usb endpoints detection
  can: c_can: Fix RX message handling, handle lost message before EOB
  doc:net: Fix typo in Documentation/networking
  bgmac: don't update slot on skb alloc/dma mapping error
  ibm emac: Fix locking for enable/disable eob irq
  ibm emac: Don't call napi_complete if napi_reschedule failed
  virtio-net: correctly handle cpu hotplug notifier during resuming
  bridge: pass correct vlan id to multicast code
  net: x25: Fix dead URLs in Kconfig
  netfilter: xt_NFQUEUE: fix --queue-bypass regression
  xen-netback: use jiffies_64 value to calculate credit timeout
  cxgb3: Fix length calculation in write_ofld_wr() on 32-bit architectures
  bnx2x: Disable VF access on PF removal
  bnx2x: prevent FW assert on low mem during unload
  tcp: gso: fix truesize tracking
  xfrm: Increase the garbage collector threshold
  ...
parents 5e01dc7b c32b7dfb

Documentation/networking/dccp.txt

+2 −2
Original line number Diff line number Diff line
@@ -18,8 +18,8 @@ Introduction 
Datagram Congestion Control Protocol (DCCP) is an unreliable, connection

oriented protocol designed to solve issues present in UDP and TCP, particularly

for real-time and multimedia (streaming) traffic.

It divides into a base protocol (RFC 4340) and plugable congestion control

modules called CCIDs. Like plugable TCP congestion control, at least one CCID

It divides into a base protocol (RFC 4340) and pluggable congestion control

modules called CCIDs. Like pluggable TCP congestion control, at least one CCID

needs to be enabled in order for the protocol to function properly. In the Linux

implementation, this is the TCP-like CCID2 (RFC 4341). Additional CCIDs, such as

the TCP-friendly CCID3 (RFC 4342), are optional.

Documentation/networking/e100.txt

+1 −1
Original line number Diff line number Diff line
@@ -103,7 +103,7 @@ Additional Configurations 
  PRO/100 Family of Adapters is e100.



  As an example, if you install the e100 driver for two PRO/100 adapters

  (eth0 and eth1), add the following to a configuraton file in /etc/modprobe.d/

  (eth0 and eth1), add the following to a configuration file in /etc/modprobe.d/



       alias eth0 e100

       alias eth1 e100

Documentation/networking/ieee802154.txt

+2 −2
Original line number Diff line number Diff line
@@ -4,7 +4,7 @@ 


Introduction

============

The IEEE 802.15.4 working group focuses on standartization of bottom

The IEEE 802.15.4 working group focuses on standardization of bottom

two layers: Medium Access Control (MAC) and Physical (PHY). And there

are mainly two options available for upper layers:

 - ZigBee - proprietary protocol from ZigBee Alliance
@@ -66,7 +66,7 @@ net_device, with .type = ARPHRD_IEEE802154. Data is exchanged with socket family 
code via plain sk_buffs. On skb reception skb->cb must contain additional

info as described in the struct ieee802154_mac_cb. During packet transmission

the skb->cb is used to provide additional data to device's header_ops->create

function. Be aware, that this data can be overriden later (when socket code

function. Be aware that this data can be overridden later (when socket code

submits skb to qdisc), so if you need something from that cb later, you should

store info in the skb->data on your own.

Documentation/networking/l2tp.txt

+1 −1
Original line number Diff line number Diff line
@@ -197,7 +197,7 @@ state information because the file format is subject to change. It is 
implemented to provide extra debug information to help diagnose

problems.) Users should use the netlink API.



/proc/net/pppol2tp is also provided for backwards compaibility with

/proc/net/pppol2tp is also provided for backwards compatibility with

the original pppol2tp driver. It lists information about L2TPv2

tunnels and sessions only. Its use is discouraged.

Documentation/networking/netdev-FAQ.txt

+12 −12
Original line number Diff line number Diff line
@@ -4,23 +4,23 @@ Information you need to know about netdev 


Q: What is netdev?



A: It is a mailing list for all network related linux stuff.  This includes

A: It is a mailing list for all network-related Linux stuff.  This includes

   anything found under net/  (i.e. core code like IPv6) and drivers/net

   (i.e. hardware specific drivers) in the linux source tree.

   (i.e. hardware specific drivers) in the Linux source tree.



   Note that some subsystems (e.g. wireless drivers) which have a high volume

   of traffic have their own specific mailing lists.



   The netdev list is managed (like many other linux mailing lists) through

   The netdev list is managed (like many other Linux mailing lists) through

   VGER ( http://vger.kernel.org/ ) and archives can be found below:



	http://marc.info/?l=linux-netdev

	http://www.spinics.net/lists/netdev/



   Aside from subsystems like that mentioned above, all network related linux

   development (i.e. RFC, review, comments, etc) takes place on netdev.

   Aside from subsystems like that mentioned above, all network-related Linux

   development (i.e. RFC, review, comments, etc.) takes place on netdev.



Q: How do the changes posted to netdev make their way into linux?

Q: How do the changes posted to netdev make their way into Linux?



A: There are always two trees (git repositories) in play.  Both are driven

   by David Miller, the main network maintainer.  There is the "net" tree,
@@ -35,7 +35,7 @@ A: There are always two trees (git repositories) in play. Both are driven 
Q: How often do changes from these trees make it to the mainline Linus tree?



A: To understand this, you need to know a bit of background information

   on the cadence of linux development.  Each new release starts off with

   on the cadence of Linux development.  Each new release starts off with

   a two week "merge window" where the main maintainers feed their new

   stuff to Linus for merging into the mainline tree.  After the two weeks,

   the merge window is closed, and it is called/tagged "-rc1".  No new
@@ -46,7 +46,7 @@ A: To understand this, you need to know a bit of background information 
   things are in a state of churn), and a week after the last vX.Y-rcN

   was done, the official "vX.Y" is released.



   Relating that to netdev:  At the beginning of the 2 week merge window,

   Relating that to netdev:  At the beginning of the 2-week merge window,

   the net-next tree will be closed - no new changes/features.  The

   accumulated new content of the past ~10 weeks will be passed onto

   mainline/Linus via a pull request for vX.Y -- at the same time,
@@ -59,16 +59,16 @@ A: To understand this, you need to know a bit of background information 
   IMPORTANT:  Do not send new net-next content to netdev during the

   period during which net-next tree is closed.



   Shortly after the two weeks have passed, (and vX.Y-rc1 is released) the

   Shortly after the two weeks have passed (and vX.Y-rc1 is released), the

   tree for net-next reopens to collect content for the next (vX.Y+1) release.



   If you aren't subscribed to netdev and/or are simply unsure if net-next

   has re-opened yet, simply check the net-next git repository link above for

   any new networking related commits.

   any new networking-related commits.



   The "net" tree continues to collect fixes for the vX.Y content, and

   is fed back to Linus at regular (~weekly) intervals.  Meaning that the

   focus for "net" is on stablilization and bugfixes.

   focus for "net" is on stabilization and bugfixes.



   Finally, the vX.Y gets released, and the whole cycle starts over.
@@ -217,7 +217,7 @@ A: Attention to detail. Re-read your own work as if you were the 
   to why it happens, and then if necessary, explain why the fix proposed

   is the best way to get things done.   Don't mangle whitespace, and as

   is common, don't mis-indent function arguments that span multiple lines.

   If it is your 1st patch, mail it to yourself so you can test apply

   If it is your first patch, mail it to yourself so you can test apply

   it to an unpatched tree to confirm infrastructure didn't mangle it.



   Finally, go back and read Documentation/SubmittingPatches to be