1. 29 Jun, 2016 32 commits
  2. 28 Jun, 2016 8 commits
    • Willem de Bruijn's avatar
      sock_diag: do not broadcast raw socket destruction · 9a0fee2b
      Willem de Bruijn authored
      Diag intends to broadcast tcp_sk and udp_sk socket destruction.
      Testing sk->sk_protocol for IPPROTO_TCP/IPPROTO_UDP alone is not
      sufficient for this. Raw sockets can have the same type.
      
      Add a test for sk->sk_type.
      
      Fixes: eb4cb008 ("sock_diag: define destruction multicast groups")
      Signed-off-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9a0fee2b
    • Aaron Campbell's avatar
      connector: fix out-of-order cn_proc netlink message delivery · ab8ed951
      Aaron Campbell authored
      The proc connector messages include a sequence number, allowing userspace
      programs to detect lost messages.  However, performing this detection is
      currently more difficult than necessary, since netlink messages can be
      delivered to the application out-of-order.  To fix this, leave pre-emption
      disabled during cn_netlink_send(), and use GFP_NOWAIT.
      
      The following was written as a test case.  Building the kernel w/ make -j32
      proved a reliable way to generate out-of-order cn_proc messages.
      
      int
      main(int argc, char *argv[])
      {
      	static uint32_t last_seq[CPU_SETSIZE], seq;
      	int cpu, fd;
      	struct sockaddr_nl sa;
      	struct __attribute__((aligned(NLMSG_ALIGNTO))) {
      		struct nlmsghdr nl_hdr;
      		struct __attribute__((__packed__)) {
      			struct cn_msg cn_msg;
      			struct proc_event cn_proc;
      		};
      	} rmsg;
      	struct __attribute__((aligned(NLMSG_ALIGNTO))) {
      		struct nlmsghdr nl_hdr;
      		struct __attribute__((__packed__)) {
      			struct cn_msg cn_msg;
      			enum proc_cn_mcast_op cn_mcast;
      		};
      	} smsg;
      
      	fd = socket(PF_NETLINK, SOCK_DGRAM, NETLINK_CONNECTOR);
      	if (fd < 0) {
      		perror("socket");
      	}
      
      	sa.nl_family = AF_NETLINK;
      	sa.nl_groups = CN_IDX_PROC;
      	sa.nl_pid = getpid();
      	if (bind(fd, (struct sockaddr *)&sa, sizeof(sa)) < 0) {
      		perror("bind");
      	}
      
      	memset(&smsg, 0, sizeof(smsg));
      	smsg.nl_hdr.nlmsg_len = sizeof(smsg);
      	smsg.nl_hdr.nlmsg_pid = getpid();
      	smsg.nl_hdr.nlmsg_type = NLMSG_DONE;
      	smsg.cn_msg.id.idx = CN_IDX_PROC;
      	smsg.cn_msg.id.val = CN_VAL_PROC;
      	smsg.cn_msg.len = sizeof(enum proc_cn_mcast_op);
      	smsg.cn_mcast = PROC_CN_MCAST_LISTEN;
      	if (send(fd, &smsg, sizeof(smsg), 0) != sizeof(smsg)) {
      		perror("send");
      	}
      
      	while (recv(fd, &rmsg, sizeof(rmsg), 0) == sizeof(rmsg)) {
      		cpu = rmsg.cn_proc.cpu;
      		if (cpu < 0) {
      			continue;
      		}
      		seq = rmsg.cn_msg.seq;
      		if ((last_seq[cpu] != 0) && (seq != last_seq[cpu] + 1)) {
      			printf("out-of-order seq=%d on cpu=%d\n", seq, cpu);
      		}
      		last_seq[cpu] = seq;
      	}
      
      	/* NOTREACHED */
      
      	perror("recv");
      
      	return -1;
      }
      Signed-off-by: default avatarAaron Campbell <aaron@monkey.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ab8ed951
    • daniel's avatar
      Bridge: Fix ipv6 mc snooping if bridge has no ipv6 address · 0888d5f3
      daniel authored
      The bridge is falsly dropping ipv6 mulitcast packets if there is:
       1. No ipv6 address assigned on the brigde.
       2. No external mld querier present.
       3. The internal querier enabled.
      
      When the bridge fails to build mld queries, because it has no
      ipv6 address, it slilently returns, but keeps the local querier enabled.
      This specific case causes confusing packet loss.
      
      Ipv6 multicast snooping can only work if:
       a) An external querier is present
       OR
       b) The bridge has an ipv6 address an is capable of sending own queries
      
      Otherwise it has to forward/flood the ipv6 multicast traffic,
      because snooping cannot work.
      
      This patch fixes the issue by adding a flag to the bridge struct that
      indicates that there is currently no ipv6 address assinged to the bridge
      and returns a false state for the local querier in
      __br_multicast_querier_exists().
      
      Special thanks to Linus Lüssing.
      
      Fixes: d1d81d4c ("bridge: check return value of ipv6_dev_get_saddr()")
      Signed-off-by: default avatarDaniel Danzberger <daniel@dd-wrt.com>
      Acked-by: default avatarLinus Lüssing <linus.luessing@c0d3.blue>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0888d5f3
    • Jouni Malinen's avatar
      mac80211: Fix mesh estab_plinks counting in STA removal case · 126e7557
      Jouni Malinen authored
      If a user space program (e.g., wpa_supplicant) deletes a STA entry that
      is currently in NL80211_PLINK_ESTAB state, the number of established
      plinks counter was not decremented and this could result in rejecting
      new plink establishment before really hitting the real maximum plink
      limit. For !user_mpm case, this decrementation is handled by
      mesh_plink_deactive().
      
      Fix this by decrementing estab_plinks on STA deletion
      (mesh_sta_cleanup() gets called from there) so that the counter has a
      correct value and the Beacon frame advertisement in Mesh Configuration
      element shows the proper value for capability to accept additional
      peers.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJouni Malinen <j@w1.fi>
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      126e7557
    • Wang Sheng-Hui's avatar
      net/mlx5: use mlx5_buf_alloc_node instead of mlx5_buf_alloc in mlx5_wq_ll_create · f299a02d
      Wang Sheng-Hui authored
      Commit 311c7c71 ("net/mlx5e: Allocate DMA coherent memory on
      reader NUMA node") introduced mlx5_*_alloc_node() but missed changing
      some calling and warn messages. This patch introduces 2 changes:
      	* Use mlx5_buf_alloc_node() instead of mlx5_buf_alloc() in
      	  mlx5_wq_ll_create()
      	* Update the failure warn messages with _node postfix for
      	  mlx5_*_alloc function names
      
      Fixes: 311c7c71 ("net/mlx5e: Allocate DMA coherent memory on reader NUMA node")
      Signed-off-by: default avatarWang Sheng-Hui <shhuiw@foxmail.com>
      Acked-By: default avatarSaeed Mahameed <saeedm@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f299a02d
    • David S. Miller's avatar
      Merge branch 'bgmac-fixes' · d1b5a8da
      David S. Miller authored
      Florian Fainelli says:
      
      ====================
      net: bgmac: Random fixes
      
      This patch series fixes a few issues spotted by code inspection and
      actual testing.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d1b5a8da
    • Florian Fainelli's avatar
      net: bgmac: Remove superflous netif_carrier_on() · 3894396e
      Florian Fainelli authored
      bgmac_open() calls phy_start() to initialize the PHY state machine,
      which will set the interface's carrier state accordingly, no need to
      force that as this could be conflicting with the PHY state determined by
      PHYLIB.
      
      Fixes: dd4544f0 ("bgmac: driver for GBit MAC core on BCMA bus")
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3894396e
    • Florian Fainelli's avatar
      net: bgmac: Start transmit queue in bgmac_open · c3897f2a
      Florian Fainelli authored
      The driver does not start the transmit queue in bgmac_open(). If the
      queue was stopped prior to closing then re-opening the interface, we
      would never be able to wake-up again.
      
      Fixes: dd4544f0 ("bgmac: driver for GBit MAC core on BCMA bus")
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c3897f2a