1. 07 Oct, 2014 3 commits
  2. 06 Oct, 2014 1 commit
    • Ivan Vecera's avatar
      bna: allow transmit tagged frames · 6654cf60
      Ivan Vecera authored
      When Tx VLAN offloading is disabled frames with size ~ MTU are not
      transmitted as the driver does not account 4 bytes of VLAN header added
      by stack. It should use VLAN_ETH_HLEN instead of ETH_HLEN.
      The second problem is with newer BNA chips (BNA 1860). These chips filter
      out any VLAN tagged frames in Tx path. This is a problem when Tx VLAN
      offloading is disabled and frames are tagged by stack. Older chips like
      1010/1020 are not affected as they probably don't do such filtering.
      Cc: Rasesh Mody <rasesh.mody@qlogic.com>
      Signed-off-by: default avatarIvan Vecera <ivecera@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  3. 05 Oct, 2014 5 commits
    • Vlad Yasevich's avatar
      sctp: handle association restarts when the socket is closed. · bdf6fa52
      Vlad Yasevich authored
      Currently association restarts do not take into consideration the
      state of the socket.  When a restart happens, the current assocation
      simply transitions into established state.  This creates a condition
      where a remote system, through a the restart procedure, may create a
      local association that is no way reachable by user.  The conditions
      to trigger this are as follows:
        1) Remote does not acknoledge some data causing data to remain
        2) Local application calls close() on the socket.  Since data
           is still outstanding, the association is placed in SHUTDOWN_PENDING
           state.  However, the socket is closed.
        3) The remote tries to create a new association, triggering a restart
           on the local system.  The association moves from SHUTDOWN_PENDING
           to ESTABLISHED.  At this point, it is no longer reachable by
           any socket on the local system.
      This patch addresses the above situation by moving the newly ESTABLISHED
      association into SHUTDOWN-SENT state and bundling a SHUTDOWN after
      the COOKIE-ACK chunk.  This way, the restarted associate immidiately
      enters the shutdown procedure and forces the termination of the
      unreachable association.
      Reported-by: default avatarDavid Laight <David.Laight@aculab.com>
      Signed-off-by: default avatarVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • David S. Miller's avatar
      Merge branch 'spider_net' · f408c3d9
      David S. Miller authored
      Antoine Tenart says:
      net: spider_net: fix possible bitops errors
      Dan reported a possible signedness issue on the pxa168_eth driver. While
      having a look at it, I came across a similar problem in the spider_net
      Here is one proposal to fix it. The first patch rework the
      spider_net_set_mac() function by removing the spider_net_get_mac_address()
      call and using memcpy() to set netdev->dev_addr (which is what's done in
      lots of Ethernet drivers) and the second one fix the actual signedness
      If for any reason you really want to keep a call to
      spider_net_get_mac_address() because the memcpy() is somehow not good
      enough here, we can also come up with a solution involving a temporary
      unsigned char variable.
      I couldn't test these changes, so please do.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Antoine Ténart's avatar
      net: spider_net: avoid using signed char for bitops · 96aacede
      Antoine Ténart authored
      Signedness bugs may occur when using signed char for bitops,
      depending on if the highest bit is ever used.
      Signed-off-by: default avatarAntoine Tenart <antoine.tenart@free-electrons.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Antoine Ténart's avatar
      net: spider_net: do not read mac address again after setting it · 0f6a6701
      Antoine Ténart authored
      This patch removes the spider_net_get_mac_address() call at the end of
      the spider_net_set_mac() function. The dev->dev_addr is instead updated
      with a memcpy() from sa->sa_data.
      Since spider_net_get_mac_address() is not used anywhere else, this patch
      also removes the function.
      Signed-off-by: default avatarAntoine Tenart <antoine.tenart@free-electrons.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • KY Srinivasan's avatar
      hyperv: Fix a bug in netvsc_send() · 3a67c9cc
      KY Srinivasan authored
      After the packet is successfully sent, we should not touch the packet
      as it may have been freed. This patch is based on the work done by
      Long Li <longli@microsoft.com>.
      David, please queue this up for stable.
      Signed-off-by: default avatarK. Y. Srinivasan <kys@microsoft.com>
      Reported-by: default avatarSitsofe Wheeler <sitsofe@yahoo.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  4. 04 Oct, 2014 4 commits
  5. 03 Oct, 2014 8 commits
    • hayeswang's avatar
      r8152: autoresume before setting MAC address · ea6a7112
      hayeswang authored
      Resume the device before setting the MAC address.
      Signed-off-by: default avatarHayes Wang <hayeswang@realtek.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Michel Stam's avatar
      asix: Don't reset PHY on if_up for ASIX 88772 · 3cc81d85
      Michel Stam authored
      I've noticed every time the interface is set to 'up,', the kernel
      reports that the link speed is set to 100 Mbps/Full Duplex, even
      when ethtool is used to set autonegotiation to 'off', half
      duplex, 10 Mbps.
      It can be tested by:
       ifconfig eth0 down
       ethtool -s eth0 autoneg off speed 10 duplex half
       ifconfig eth0 up
      Then checking 'dmesg' for the link speed.
      Signed-off-by: default avatarMichel Stam <m.stam@fugro.nl>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • David S. Miller's avatar
      Merge branch 'rds-net' · fba75163
      David S. Miller authored
      Herton R. Krzesinski says:
      Small fixes/changes for RDS
      I got a report of one issue within RDS (after investigation it was a double
      free), and I'm sending the fix (patch 3/3) which reporter said it works (no more
      WARNING triggered on a specially instrumented kernel). The report/test was done
      on a very old kernel (RHEL 5, 2.6.18 based with backports), but the problem the
      patch handles still exists and should not change. Besides that, while
      reviewing some of the code but being unable to reproduce with rds_tcp, I
      noticed two small improvements/fixes which are in patches 1 and 2.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Herton R. Krzesinski's avatar
      net/rds: fix possible double free on sock tear down · 593cbb3e
      Herton R. Krzesinski authored
      I got a report of a double free happening at RDS slab cache. One
      suspicion was that may be somewhere we were doing a sock_hold/sock_put
      on an already freed sock. Thus after providing a kernel with the
      following change:
       static inline void sock_hold(struct sock *sk)
      -       atomic_inc(&sk->sk_refcnt);
      +       if (!atomic_inc_not_zero(&sk->sk_refcnt))
      +               WARN(1, "Trying to hold sock already gone: %p (family: %hd)\n",
      +                       sk, sk->sk_family);
      The warning successfuly triggered:
      Trying to hold sock already gone: ffff81f6dda61280 (family: 21)
      WARNING: at include/net/sock.h:350 sock_hold()
      Call Trace:
      <IRQ>  [<ffffffff8adac135>] :rds:rds_send_remove_from_sock+0xf0/0x21b
      [<ffffffff8adad35c>] :rds:rds_send_drop_acked+0xbf/0xcf
      [<ffffffff8addf546>] :rds_rdma:rds_ib_recv_tasklet_fn+0x256/0x2dc
      [<ffffffff8009899a>] tasklet_action+0x8f/0x12b
      [<ffffffff800125a2>] __do_softirq+0x89/0x133
      [<ffffffff8005f30c>] call_softirq+0x1c/0x28
      [<ffffffff8006e644>] do_softirq+0x2c/0x7d
      [<ffffffff8006e4d4>] do_IRQ+0xee/0xf7
      [<ffffffff8005e625>] ret_from_intr+0x0/0xa
      Looking at the call chain above, the only way I think this would be
      possible is if somewhere we already released the same socket->sock which
      is assigned to the rds_message at rds_send_remove_from_sock. Which seems
      only possible to happen after the tear down done on rds_release.
      rds_release properly calls rds_send_drop_to to drop the socket from any
      rds_message, and some proper synchronization is in place to avoid race
      with rds_send_drop_acked/rds_send_remove_from_sock. However, I still see
      a very narrow window where it may be possible we touch a sock already
      released: when rds_release races with rds_send_drop_acked, we check
      RDS_MSG_ON_CONN to avoid cleanup on the same rds_message, but in this
      specific case we don't clear rm->m_rs. In this case, it seems we could
      then go on at rds_send_drop_to and after it returns, the sock is freed
      by last sock_put on rds_release, with concurrently we being at
      rds_send_remove_from_sock; then at some point in the loop at
      rds_send_remove_from_sock we process an rds_message which didn't have
      rm->m_rs unset for a freed sock, and a possible sock_hold on an sock
      already gone at rds_release happens.
      This hopefully address the described condition above and avoids a double
      free on "second last" sock_put. In addition, I removed the comment about
      socket destruction on top of rds_send_drop_acked: we call rds_send_drop_to
      in rds_release and we should have things properly serialized there, thus
      I can't see the comment being accurate there.
      Signed-off-by: default avatarHerton R. Krzesinski <herton@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Herton R. Krzesinski's avatar
      net/rds: do proper house keeping if connection fails in rds_tcp_conn_connect · eb74cc97
      Herton R. Krzesinski authored
      I see two problems if we consider the sock->ops->connect attempt to fail in
      rds_tcp_conn_connect. The first issue is that for example we don't remove the
      previously added rds_tcp_connection item to rds_tcp_tc_list at
      rds_tcp_set_callbacks, which means that on a next reconnect attempt for the
      same rds_connection, when rds_tcp_conn_connect is called we can again call
      rds_tcp_set_callbacks, resulting in duplicated items on rds_tcp_tc_list,
      leading to list corruption: to avoid this just make sure we call
      properly rds_tcp_restore_callbacks before we exit. The second issue
      is that we should also release the sock properly, by setting sock = NULL
      only if we are returning without error.
      Signed-off-by: default avatarHerton R. Krzesinski <herton@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Herton R. Krzesinski's avatar
    • Linus Torvalds's avatar
      Merge tag 'md/3.17-final-fix' of git://neil.brown.name/md · ee042ec8
      Linus Torvalds authored
      Pull raid5 discard fix from Neil Brown:
       "One fix for raid5 discard issue"
      * tag 'md/3.17-final-fix' of git://neil.brown.name/md:
        md/raid5: disable 'DISCARD' by default due to safety concerns.
    • Linus Torvalds's avatar
      Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux · 80ad99da
      Linus Torvalds authored
      Pull drm fixes from Dave Airlie:
       "Nothing too major or scary.
        One i915 regression fix, nouveau has a tmds regression fix, along with
        a regression fix for the runtime pm code for optimus laptops not
        restoring the display hw correctly"
      * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
        drm/nouveau: make sure display hardware is reinitialised on runtime resume
        drm/nouveau: punt fbcon resume out to a workqueue
        drm/nouveau: fix regression on original nv50 board
        drm/nv50/disp: fix dpms regression on certain boards
        drm/i915: Flush the PTEs after updating them before suspend
  6. 02 Oct, 2014 15 commits
  7. 01 Oct, 2014 4 commits
    • Dave Airlie's avatar
      Merge branch 'linux-3.17' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes · 19318c06
      Dave Airlie authored
      A few regression fixes, the runpm ones dating back to 3.15.  Also a fairly severe TMDS regression that effected a lot of GF8/9/GT2xx users.
      * 'linux-3.17' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
        drm/nouveau: make sure display hardware is reinitialised on runtime resume
        drm/nouveau: punt fbcon resume out to a workqueue
        drm/nouveau: fix regression on original nv50 board
        drm/nv50/disp: fix dpms regression on certain boards
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net · 50dddff3
      Linus Torvalds authored
      Pull networking fixes from David Miller:
       1) Don't halt the firmware in r8152 driver, from Hayes Wang.
       2) Handle full sized 802.1ad frames in bnx2 and tg3 drivers properly,
          from Vlad Yasevich.
       3) Don't sleep while holding tx_clean_lock in netxen driver, fix from
          Manish Chopra.
       4) Certain kinds of ipv6 routes can end up endlessly failing the route
          validation test, causing it to be re-looked up over and over again.
          This particularly kills input route caching in TCP sockets.  Fix
          from Hannes Frederic Sowa.
       5) netvsc_start_xmit() has a use-after-free access to skb->len, fix
          from K Y Srinivasan.
       6) Fix matching of inverted containers in ematch module, from Ignacy
       7) Aggregation of GRO frames via SKB ->frag_list for linear skbs isn't
          handled properly, regression fix from Eric Dumazet.
       8) Don't test return value of ipv4_neigh_lookup(), which returns an
          error pointer, against NULL.  From WANG Cong.
       9) Fix an old regression where we mistakenly allow a double add of the
          same tunnel.  Fixes from Steffen Klassert.
      10) macvtap device delete and open can run in parallel and corrupt lists
          etc., fix from Vlad Yasevich.
      11) Fix build error with IPV6=m NETFILTER_XT_TARGET_TPROXY=y, from Pablo
          Neira Ayuso.
      12) rhashtable_destroy() triggers lockdep splats, fix also from Pablo.
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (32 commits)
        bna: Update Maintainer Email
        r8152: disable power cut for RTL8153
        r8152: remove clearing bp
        bnx2: Correctly receive full sized 802.1ad fragmes
        tg3: Allow for recieve of full-size 8021AD frames
        r8152: fix setting RTL8152_UNPLUG
        netxen: Fix bug in Tx completion path.
        netxen: Fix BUG "sleeping function called from invalid context"
        ipv6: remove rt6i_genid
        hyperv: Fix a bug in netvsc_start_xmit()
        net: stmmac: fix stmmac_pci_probe failed when CONFIG_HAVE_CLK is selected
        ematch: Fix matching of inverted containers.
        gro: fix aggregation for skb using frag_list
        neigh: check error pointer instead of NULL for ipv4_neigh_lookup()
        ip6_gre: Return an error when adding an existing tunnel.
        ip6_vti: Return an error when adding an existing tunnel.
        ip6_tunnel: Return an error when adding an existing tunnel.
        ip6gre: add a rtnl link alias for ip6gretap
        net/mlx4_core: Allow not to specify probe_vf in SRIOV IB mode
        r8152: fix the carrier off when autoresuming
    • NeilBrown's avatar
      md/raid5: disable 'DISCARD' by default due to safety concerns. · 8e0e99ba
      NeilBrown authored
      It has come to my attention (thanks Martin) that 'discard_zeroes_data'
      is only a hint.  Some devices in some cases don't do what it
      says on the label.
      The use of DISCARD in RAID5 depends on reads from discarded regions
      being predictably zero.  If a write to a previously discarded region
      performs a read-modify-write cycle it assumes that the parity block
      was consistent with the data blocks.  If all were zero, this would
      be the case.  If some are and some aren't this would not be the case.
      This could lead to data corruption after a device failure when
      data needs to be reconstructed from the parity.
      As we cannot trust 'discard_zeroes_data', ignore it by default
      and so disallow DISCARD on all raid4/5/6 arrays.
      As many devices are trustworthy, and as there are benefits to using
      DISCARD, add a module parameter to over-ride this caution and cause
      DISCARD to work if discard_zeroes_data is set.
      If a site want to enable DISCARD on some arrays but not on others they
      should select DISCARD support at the filesystem level, and set the
      raid456 module parameter.
      As this is a data-safety issue, I believe this patch is suitable for
      DISCARD support for RAID456 was added in 3.7
      Cc: Shaohua Li <shli@kernel.org>
      Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
      Cc: Mike Snitzer <snitzer@redhat.com>
      Cc: Heinz Mauelshagen <heinzm@redhat.com>
      Cc: stable@vger.kernel.org (3.7+)
      Acked-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Acked-by: default avatarMike Snitzer <snitzer@redhat.com>
      Fixes: 620125f2
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
    • Ben Skeggs's avatar
      drm/nouveau: make sure display hardware is reinitialised on runtime resume · 6fbb702e
      Ben Skeggs authored
      Linus commit 05c63c2f
       modified the
      runtime suspend/resume paths to skip over display-related tasks to
      avoid locking issues on resume.
      Unfortunately, this resulted in the display hardware being left in
      a partially initialised state, preventing subsequent modesets from
      This commit unifies the (many) suspend/resume paths, bringing back
      display (and fbcon) handling in the runtime paths.
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>