1. 13 Feb, 2013 11 commits
    • Rafał Miłecki's avatar
      bgmac: return error on failed PHY write · 217a55a3
      Rafał Miłecki authored
      
      
      Some callers may want to know if PHY write succeed. Also make PHY
      functions static, they are not exported anywhere.
      Signed-off-by: default avatarRafał Miłecki <zajec5@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      217a55a3
    • Sathya Perla's avatar
      be2net: remove BUG_ON() in be_mcc_compl_is_new() · 9e9ff4b7
      Sathya Perla authored
      
      
      The current code expects that the last word (with valid bit)
      of an MCC compl is DMAed in one shot. This may not be the case.
      Remove this assertion.
      Signed-off-by: default avatarSathya Perla <sathya.perla@emulex.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9e9ff4b7
    • Cyril Roelandt's avatar
      net: ethernet: ti: remove redundant NULL check. · 79876e03
      Cyril Roelandt authored
      
      
      cpdma_chan_destroy() on a NULL pointer is a no-op, so the NULL check in
      cpdma_ctlr_destroy() can safely be removed.
      Signed-off-by: default avatarCyril Roelandt <tipecaml@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      79876e03
    • Pravin B Shelar's avatar
      net: Fix possible wrong checksum generation. · c9af6db4
      Pravin B Shelar authored
      Patch cef401de
      
       (net: fix possible wrong checksum
      generation) fixed wrong checksum calculation but it broke TSO by
      defining new GSO type but not a netdev feature for that type.
      net_gso_ok() would not allow hardware checksum/segmentation
      offload of such packets without the feature.
      
      Following patch fixes TSO and wrong checksum. This patch uses
      same logic that Eric Dumazet used. Patch introduces new flag
      SKBTX_SHARED_FRAG if at least one frag can be modified by
      the user. but SKBTX_SHARED_FRAG flag is kept in skb shared
      info tx_flags rather than gso_type.
      
      tx_flags is better compared to gso_type since we can have skb with
      shared frag without gso packet. It does not link SHARED_FRAG to
      GSO, So there is no need to define netdev feature for this.
      Signed-off-by: default avatarPravin B Shelar <pshelar@nicira.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c9af6db4
    • David S. Miller's avatar
      Merge branch 'tcp_tsoffset' · b8fa4100
      David S. Miller authored
      
      
      Andrey Vagin says:
      
      ====================
      If a TCP socket will get live-migrated from one box to another the
      timestamps (which are typically ON) will get screwed up -- the new
      kernel will generate TS values that has nothing to do with what they
      were on dump. The solution is to yet again fix the kernel and put a
      "timestamp offset" on a socket.
      
      A socket offset is added in places where externally visible tcp
      timestamp option is parsed/initialized.
      
      Connections in the SYN_RECV state are not supported, global
      tcp_time_stamp is used for them, because repair mode doesn't support
      this state. In a future it can be implemented by the similar way as for
      TIME_WAIT sockets.
      
      For time-wait sockets offset is inhereted by a proper tcp_sock.
      
      A per-socket offset can be set only for sockets in repair mode.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b8fa4100
    • Andrey Vagin's avatar
      tcp: send packets with a socket timestamp · ee684b6f
      Andrey Vagin authored
      
      
      A socket timestamp is a sum of the global tcp_time_stamp and
      a per-socket offset.
      
      A socket offset is added in places where externally visible
      tcp timestamp option is parsed/initialized.
      
      Connections in the SYN_RECV state are not supported, global
      tcp_time_stamp is used for them, because repair mode doesn't support
      this state. In a future it can be implemented by the similar way
      as for TIME_WAIT sockets.
      
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
      Cc: James Morris <jmorris@namei.org>
      Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
      Cc: Patrick McHardy <kaber@trash.net>
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: Pavel Emelyanov <xemul@parallels.com>
      Signed-off-by: default avatarAndrey Vagin <avagin@openvz.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ee684b6f
    • Andrey Vagin's avatar
      tcp: set and get per-socket timestamp · 93be6ce0
      Andrey Vagin authored
      
      
      A timestamp can be set, only if a socket is in the repair mode.
      
      This patch adds a new socket option TCP_TIMESTAMP, which allows to
      get and set current tcp times stamp.
      
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
      Cc: James Morris <jmorris@namei.org>
      Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
      Cc: Patrick McHardy <kaber@trash.net>
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: Pavel Emelyanov <xemul@parallels.com>
      Signed-off-by: default avatarAndrey Vagin <avagin@openvz.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      93be6ce0
    • Andrey Vagin's avatar
      tcp: adding a per-socket timestamp offset · ceaa1fef
      Andrey Vagin authored
      
      
      This functionality is used for restoring tcp sockets. A tcp timestamp
      depends on how long a system has been running, so it's differ for each
      host. The solution is to set a per-socket offset.
      
      A per-socket offset for a TIME_WAIT socket is inherited from a proper
      tcp socket.
      
      tcp_request_sock doesn't have a timestamp offset, because the repair
      mode for them are not implemented.
      
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
      Cc: James Morris <jmorris@namei.org>
      Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
      Cc: Patrick McHardy <kaber@trash.net>
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: Pavel Emelyanov <xemul@parallels.com>
      Signed-off-by: default avatarAndrey Vagin <avagin@openvz.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ceaa1fef
    • David S. Miller's avatar
      Merge branch 'gfar-ethtool-atomic' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux · d0023f82
      David S. Miller authored
      
      
      Paul Gortmaker says:
      
      ====================
      Eric noticed that the handling of local u64 ethtool counters for
      this driver commonly found on Freescale ppc-32 boards was racy.
      
      However, before converting them over to atomic64_t, I noticed
      that an internal struct was being used to determine the offsets
      for exporting this data into the ethtool buffer, and in doing
      so, it assumed that the counters would always be u64.  Rather
      than keep this implicit assumption, a simple code cleanup gets
      rid of the struct completely, and leaves less conversion sites.
      
      The alternative solution would have been to take advantage of
      the fact that the counters are all relating to error conditions,
      and hence make them internally u32.  In doing so, we'd be assuming
      that U32_MAX of any particular error condition is highly unlikely.
      This might have made sense if any increments were in a hot path.
      
      Tested with "ethtool -S eth0" on sbc8548 board.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d0023f82
    • Neil Horman's avatar
      netpoll: fix smatch warnings in netpoll core code · 959d5fde
      Neil Horman authored
      
      
      Dan Carpenter contacted me with some notes regarding some smatch warnings in the
      netpoll code, some of which I introduced with my recent netpoll locking fixes,
      some which were there prior.   Specifically they were:
      
      net-next/net/core/netpoll.c:243 netpoll_poll_dev() warn: inconsistent
        returns mutex:&ni->dev_lock: locked (213,217) unlocked (210,243)
      net-next/net/core/netpoll.c:706 netpoll_neigh_reply() warn: potential
        pointer math issue ('skb_transport_header(send_skb)' is a 128 bit pointer)
      
      This patch corrects the locking imbalance (the first error), and adds some
      parenthesis to correct the second error.  Tested by myself. Applies to net-next
      Signed-off-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      CC: Dan Carpenter <dan.carpenter@oracle.com>
      CC: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      959d5fde
    • James Hogan's avatar
      net: skbuff: fix compile error in skb_panic() · 99d5851e
      James Hogan authored
      I get the following build error on next-20130213 due to the following
      commit:
      
      commit f05de73b
      
       ("skbuff: create
      skb_panic() function and its wrappers").
      
      It adds an argument called panic to a function that uses the BUG() macro
      which tries to call panic, but the argument masks the panic() function
      declaration, resulting in the following error (gcc 4.2.4):
      
      net/core/skbuff.c In function 'skb_panic':
      net/core/skbuff.c +126 : error: called object 'panic' is not a function
      
      This is fixed by renaming the argument to msg.
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: Jean Sacren <sakiwit@gmail.com>
      Cc: Jiri Pirko <jiri@resnulli.us>
      Cc: David S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      99d5851e
  2. 12 Feb, 2013 23 commits
  3. 11 Feb, 2013 6 commits
    • Neil Horman's avatar
      netpoll: cleanup sparse warnings · 0790bbb6
      Neil Horman authored
      
      
      With my recent commit I introduced two sparse warnings.  Looking closer there
      were a few more in the same file, so I fixed them all up.  Basic rcu pointer
      dereferencing suff.
      
      I've validated these changes using CONFIG_PROVE_RCU while starting and stopping
      netconsole repeatedly in bonded and non-bonded configurations
      Signed-off-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      CC: fengguang.wu@intel.com
      CC: David Miller <davem@davemloft.net>
      CC: eric.dumazet@gmail.com
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0790bbb6
    • Neil Horman's avatar
      netpoll: Fix __netpoll_rcu_free so that it can hold the rtnl lock · 2cde6acd
      Neil Horman authored
      
      
      __netpoll_rcu_free is used to free netpoll structures when the rtnl_lock is
      already held.  The mechanism is used to asynchronously call __netpoll_cleanup
      outside of the holding of the rtnl_lock, so as to avoid deadlock.
      Unfortunately, __netpoll_cleanup modifies pointers (dev->np), which means the
      rtnl_lock must be held while calling it.  Further, it cannot be held, because
      rcu callbacks may be issued in softirq contexts, which cannot sleep.
      
      Fix this by converting the rcu callback to a work queue that is guaranteed to
      get scheduled in process context, so that we can hold the rtnl properly while
      calling __netpoll_cleanup
      
      Tested successfully by myself.
      Signed-off-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      CC: "David S. Miller" <davem@davemloft.net>
      CC: Cong Wang <amwang@redhat.com>
      CC: Eric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2cde6acd
    • Jean Sacren's avatar
      skbuff: create skb_panic() function and its wrappers · f05de73b
      Jean Sacren authored
      
      
      Create skb_panic() function in lieu of both skb_over_panic() and
      skb_under_panic() so that code duplication would be avoided. Update type
      and variable name where necessary.
      
      Jiri Pirko suggested using wrappers so that we would be able to keep the
      fruits of the original code.
      Signed-off-by: default avatarJean Sacren <sakiwit@gmail.com>
      Cc: Jiri Pirko <jiri@resnulli.us>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f05de73b
    • Jonas Gorski's avatar
      mwl8k: fix band for supported channels · d786f67e
      Jonas Gorski authored
      
      
      The band field for the supported channels were left unpopulated, making
      them default to 0 == IEEE80211_BAND_2GHZ, even for the 5GHz channels.
      
      This resulted in null pointer accesses if anything tries to access
      wiphy->bands[channel->band] of a 5GHz channel on 5GHz only cards, since
      wiphy->bands[2GHZ] is NULL for them (e.g. cfg80211_chandef_usable does).
      
      Example kernel OOPS:
      
      [  665.669993] Unable to handle kernel NULL pointer dereference at virtual address 00000016
      [  665.678194] pgd = c6d58000
      [  665.680941] [00000016] *pgd=06f8a831, *pte=00000000, *ppte=00000000
      [  665.687303] Internal error: Oops: 17 [#1]
      (...)
      [  666.116373] Backtrace:
      [  666.118866] [<bf0368dc>] (cfg80211_chandef_usable+0x0/0x1bc [cfg80211]) from [<bf025e64>] (nl80211_leave_mesh+0x244/0x264 [cfg80211])
      [  666.130919]  r7:c6d12100 r6:0000143c r5:c0611c48 r4:c0611b98
      [  666.136668] [<bf025d84>] (nl80211_leave_mesh+0x164/0x264 [cfg80211]) from [<bf02634c>] (nl80211_remain_on_channel+0x2a0/0x358 [cfg80211])
      [  666.149074]  r7:c6d12000 r6:c6d12000 r5:c6f4f368 r4:00000003
      [  666.154814] [<bf0262ec>] (nl80211_remain_on_channel+0x240/0x358 [cfg80211]) from [<bf02ddb0>] (nl80211_set_wiphy+0x264/0x560 [cfg80211])
      [  666.167150] [<bf02db4c>] (nl80211_set_wiphy+0x0/0x560 [cfg80211]) from [<c01f94e0>] (genl_rcv_msg+0x1b8/0x1f8)
      [  666.177205] [<c01f9328>] (genl_rcv_msg+0x0/0x1f8) from [<c01f89a0>] (netlink_rcv_skb+0x58/0xb4)
      [  666.185949] [<c01f8948>] (netlink_rcv_skb+0x0/0xb4) from [<c01f931c>] (genl_rcv+0x20/0x2c)
      [  666.194251]  r6:c6f70780 r5:0000002c r4:c6f70780 r3:00000001
      [  666.199973] [<c01f92fc>] (genl_rcv+0x0/0x2c) from [<c01f8418>] (netlink_unicast+0x154/0x1f4)
      [  666.208449]  r4:c785ea00 r3:c01f92fc
      [  666.212057] [<c01f82c4>] (netlink_unicast+0x0/0x1f4) from [<c01f8790>] (netlink_sendmsg+0x230/0x2b0)
      [  666.221240] [<c01f8560>] (netlink_sendmsg+0x0/0x2b0) from [<c01cccf8>] (sock_sendmsg+0x90/0xa4)
      [  666.229986] [<c01ccc68>] (sock_sendmsg+0x0/0xa4) from [<c01cdcb0>] (__sys_sendmsg+0x290/0x298)
      [  666.238637]  r9:00000000 r8:c0611ec8 r6:0000002c r5:c0610000 r4:c0611f64
      [  666.245411] [<c01cda20>] (__sys_sendmsg+0x0/0x298) from [<c01cf52c>] (sys_sendmsg+0x44/0x6c)
      [  666.253897] [<c01cf4e8>] (sys_sendmsg+0x0/0x6c) from [<c00090a0>] (ret_fast_syscall+0x0/0x2c)
      [  666.262460]  r6:00000000 r5:beeff96c r4:00000005
      Signed-off-by: default avatarJonas Gorski <jogo@openwrt.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      d786f67e
    • John W. Linville's avatar
    • Stephen Hemminger's avatar
      bridge: set priority of STP packets · 547b4e71
      Stephen Hemminger authored
      
      
      Spanning Tree Protocol packets should have always been marked as
      control packets, this causes them to get queued in the high prirority
      FIFO. As Radia Perlman mentioned in her LCA talk, STP dies if bridge
      gets overloaded and can't communicate. This is a long-standing bug back
      to the first versions of Linux bridge.
      Signed-off-by: default avatarStephen Hemminger <stephen@networkplumber.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      547b4e71