1. 13 Feb, 2013 6 commits
    • 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
    • Paul Gortmaker's avatar
      gianfar: convert u64 status counters to atomic64_t · 212079df
      Paul Gortmaker authored
      While looking at some asm dump for an unrelated change, Eric
      noticed in the following stats count increment code:
      
          50b8:       81 3c 01 f8     lwz     r9,504(r28)
          50bc:       81 5c 01 fc     lwz     r10,508(r28)
          50c0:       31 4a 00 01     addic   r10,r10,1
          50c4:       7d 29 01 94     addze   r9,r9
          50c8:       91 3c 01 f8     stw     r9,504(r28)
          50cc:       91 5c 01 fc     stw     r10,508(r28)
      
      that a 64 bit counter was used on ppc-32 without sync
      and hence the "ethtool -S" output was racy.
      
      Here we convert all the values to use atomic64_t so that
      the output will always be consistent.
      Reported-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      212079df
    • Paul Gortmaker's avatar
      gianfar: remove largely unused gfar_stats struct · 68719786
      Paul Gortmaker authored
      The gfar_stats struct is only used in copying out data
      via ethtool.  It is declared as the extra stats, followed
      by the rmon stats.  However, the rmon stats are never
      actually ever used in the driver; instead the rmon data
      is a u32 register read that is cast directly into the
      ethtool buf.
      
      It seems the only reason rmon is in the struct at all is
      to give the offset(s) at which it should be exported into
      the ethtool buffer.  But note gfar_stats doesn't contain
      a gfar_extra_stats as a substruct -- instead it contains
      a u64 array of equal element count.  This implicitly means
      we have two independent declarations of what gfar_extra_stats
      really is.  Rather than have this duality, we already have
      defines which give us the offset directly, and hence do not
      need the struct at all.
      
      Further, since we know the extra_stats is unconditionally
      always present, we can write it out to the ethtool buf
      1st, and then optionally write out the rmon data.  There
      is no need for two independent loops, both of which are
      simply copying out the extra_stats to buf offset zero.
      
      This also helps pave the way towards allowing the extra
      stats fields to be converted to atomic64_t values, without
      having their types directly influencing the ethtool stats
      export code (gfar_fill_stats) that expects to deal with u64.
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      68719786
  2. 12 Feb, 2013 24 commits
  3. 11 Feb, 2013 10 commits