1. 08 5月, 2016 2 次提交
  2. 07 5月, 2016 7 次提交
  3. 06 5月, 2016 3 次提交
    • N
      net: bridge: fix old ioctl unlocked net device walk · 31ca0458
      Nikolay Aleksandrov 提交于
      get_bridge_ifindices() is used from the old "deviceless" bridge ioctl
      calls which aren't called with rtnl held. The comment above says that it is
      called with rtnl but that is not really the case.
      Here's a sample output from a test ASSERT_RTNL() which I put in
      get_bridge_ifindices and executed "brctl show":
      [  957.422726] RTNL: assertion failed at net/bridge//br_ioctl.c (30)
      [  957.422925] CPU: 0 PID: 1862 Comm: brctl Tainted: G        W  O
      4.6.0-rc4+ #157
      [  957.423009] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
      BIOS 1.8.1-20150318_183358- 04/01/2014
      [  957.423009]  0000000000000000 ffff880058adfdf0 ffffffff8138dec5
      0000000000000400
      [  957.423009]  ffffffff81ce8380 ffff880058adfe58 ffffffffa05ead32
      0000000000000001
      [  957.423009]  00007ffec1a444b0 0000000000000400 ffff880053c19130
      0000000000008940
      [  957.423009] Call Trace:
      [  957.423009]  [<ffffffff8138dec5>] dump_stack+0x85/0xc0
      [  957.423009]  [<ffffffffa05ead32>]
      br_ioctl_deviceless_stub+0x212/0x2e0 [bridge]
      [  957.423009]  [<ffffffff81515beb>] sock_ioctl+0x22b/0x290
      [  957.423009]  [<ffffffff8126ba75>] do_vfs_ioctl+0x95/0x700
      [  957.423009]  [<ffffffff8126c159>] SyS_ioctl+0x79/0x90
      [  957.423009]  [<ffffffff8163a4c0>] entry_SYSCALL_64_fastpath+0x23/0xc1
      
      Since it only reads bridge ifindices, we can use rcu to safely walk the net
      device list. Also remove the wrong rtnl comment above.
      Signed-off-by: NNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      31ca0458
    • I
      VSOCK: do not disconnect socket when peer has shutdown SEND only · dedc58e0
      Ian Campbell 提交于
      The peer may be expecting a reply having sent a request and then done a
      shutdown(SHUT_WR), so tearing down the whole socket at this point seems
      wrong and breaks for me with a client which does a SHUT_WR.
      
      Looking at other socket family's stream_recvmsg callbacks doing a shutdown
      here does not seem to be the norm and removing it does not seem to have
      had any adverse effects that I can see.
      
      I'm using Stefan's RFC virtio transport patches, I'm unsure of the impact
      on the vmci transport.
      Signed-off-by: NIan Campbell <ian.campbell@docker.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Stefan Hajnoczi <stefanha@redhat.com>
      Cc: Claudio Imbrenda <imbrenda@linux.vnet.ibm.com>
      Cc: Andy King <acking@vmware.com>
      Cc: Dmitry Torokhov <dtor@vmware.com>
      Cc: Jorgen Hansen <jhansen@vmware.com>
      Cc: Adit Ranadive <aditr@vmware.com>
      Cc: netdev@vger.kernel.org
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      dedc58e0
    • D
      net/mlx4_en: Fix endianness bug in IPV6 csum calculation · 82d69203
      Daniel Jurgens 提交于
      Use htons instead of unconditionally byte swapping nexthdr.  On a little
      endian systems shifting the byte is correct behavior, but it results in
      incorrect csums on big endian architectures.
      
      Fixes: f8c6455b ('net/mlx4_en: Extend checksum offloading by CHECKSUM COMPLETE')
      Signed-off-by: NDaniel Jurgens <danielj@mellanox.com>
      Reviewed-by: NCarol Soto <clsoto@us.ibm.com>
      Tested-by: NCarol Soto <clsoto@us.ibm.com>
      Signed-off-by: NTariq Toukan <tariqt@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      82d69203
  4. 05 5月, 2016 8 次提交
  5. 04 5月, 2016 20 次提交