summaryrefslogtreecommitdiff
path: root/net
AgeCommit message (Collapse)Author
2014-11-28NFC: NCI: Handle Target mode activationJulien Lefrique
Changes: * Extract the Listen mode activation parameters from RF_INTF_ACTIVATED_NTF. * Store the General Bytes of ATR_REQ. * Signal that Target mode is activated in case of an activation in NFC-DEP. * Update the NCI state accordingly. * Use the various constants defined in nfc.h. * Fix the ATR_REQ and ATR_RES maximum size. As per NCI 1.0 and NCI 1.1, the Activation Parameters for both Poll and Listen mode contain all the bytes of ATR_REQ/ATR_RES starting and including Byte 3 as defined in [DIGITAL]. In [DIGITAL], the maximum size of ATR_REQ/ATR_RES is 64 bytes and they are numbered starting from Byte 1. Signed-off-by: Julien Lefrique <lefrique@marvell.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2014-11-28NFC: NCI: Enable NFC-DEP in Listen A and Listen FJulien Lefrique
Send LA_SEL_INFO and LF_PROTOCOL_TYPE with NFC-DEP protocol enabled. Configure 212 Kbit/s and 412 Kbit/s bit rates for Listen F. Signed-off-by: Julien Lefrique <lefrique@marvell.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2014-11-28NFC: NCI: Add passive Listen modes in discover requestJulien Lefrique
The Target mode protocols are given to the nci_start_poll() function but were previously ignored. To enable P2P Target, when NFC-DEP is requested as a Target mode protocol, add NFC-A and NFC-F Passive Listen modes in RF_DISCOVER_CMD command. Signed-off-by: Julien Lefrique <lefrique@marvell.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2014-11-28NFC: llcp: Use list_for_each_entry in llcp_accept_pollAxel Lin
list_for_each_entry_safe() is necessary if list objects are deleted from the list while traversing it. Not the case here, so we can use the base list_for_each_entry variant. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2014-11-28NFC: digital: Add NFC-DEP Target-side ATN SupportMark A. Greer
When an NFC-DEP target receives an ATN PDU, its supposed to respond with a similar ATN PDU. When the Target receives an I PDU with the PNI one less than the current PNI and the last PDU sent was an ATN PDU, the Target is to resend the last non-ATN PDU that it has sent. This is described in section 14.12.3.4 of the NFC Digital Protocol Spec. The digital layer's NFC-DEP code doesn't implement this so add that support. Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com> Tested-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2014-11-28NFC: digital: Add NFC-DEP Initiator-side ATN SupportMark A. Greer
When an NFC-DEP Initiator times out when waiting for a DEP_RES from the Target, its supposed to send an ATN to the Target. The Target should respond to the ATN with a similar ATN PDU and the Initiator can then resend the last non-ATN PDU that it sent. No more than 'N(retry,atn)' are to be send where 2 <= 'N(retry,atn)' <= 5. If the Initiator had just sent a NACK PDU when the timeout occurred, it is to continue sending NACKs until 'N(retry,nack)' NACKs have been send. This is described in section 14.12.5.6 of the NFC-DEP Digital Protocol Spec. The digital layer's NFC-DEP code doesn't implement this so add that support. The value chosen for 'N(retry,atn)' is 2. Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com> Tested-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2014-11-28NFC: digital: Add NFC-DEP Target-side NACK SupportMark A. Greer
When an NFC-DEP Target receives a NACK PDU with a PNI equal to 1 less than the current PNI, it is supposed to re-send the last PDU. This is implied in section 14.12.5.4 of the NFC Digital Protocol Spec. The digital layer's NFC-DEP code doesn't implement Target-side NACK handing so add it. The last PDU that was sent is saved in the 'nfc_digital_dev' structure's 'saved_skb' member. The skb will have an additional reference taken to ensure that the skb isn't freed when the driver performs a kfree_skb() on the skb. The length of the skb/PDU is also saved so the length can be restored when re-sending the PDU in the skb (the driver will perform an skb_pull() so an skb_push() needs to be done to restore the skb's data pointer/length). Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com> Tested-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2014-11-28NFC: digital: Add NFC-DEP Initiator-side NACK SupportMark A. Greer
When an NFC-DEP Initiator receives a frame with an incorrect CRC or with a parity error, and the frame is at least 4 bytes long, its supposed to send a NACK to the Target. The Initiator can send up to 'N(retry,nack)' consecutive NACKs where 2 <= 'N(retry,nack)' <= 5. When the limit is exceeded, a PROTOCOL EXCEPTION is raised. Any other type of transmission error is to be ignored and the Initiator should continue waiting for a new frame. This is described in section 14.12.5.4 of the NFC Digital Protocol Spec. The digital layer's NFC-DEP code doesn't implement any of this so add it. This support diverges from the spec in two significant ways: a) NACKs will be sent for ANY error reported by the driver except a timeout. This is done because there is currently no way for the digital layer to distinguish a CRC or parity error from any other type of error reported by the driver. b) All other errors will cause a PROTOCOL EXCEPTION even frames with CRC errors that are less than 4 bytes. The value chosen for 'N(retry,nack)' is 2. Targets do not send NACK PDUs. Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com> Tested-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2014-11-28NFC: digital: Add NFC-DEP Receive Chaining SupportMark A. Greer
When the peer in an NFC-DEP exchange has a packet to send that is larger than the local maximum payload, it sets the 'MI' bit in the 'I' PDU. This indicates that NFC-DEP chaining is to occur. When such a PDU is received, the local side responds with an 'ACK' PDU and this continues until the peer sends an 'I' PDU with the 'MI' bit cleared. This indicates that the chaining sequence is complete and the entire packet has been transferred. Receiving chained PDUs is currently not supported by the digital layer so add that support. When a chaining sequence is initiated by the peer, the digital layer will allocate an skb large enough to hold 8 maximum sized frame payloads. The maximum payload can range from 64 to 254 bytes so 8 * 254 = 2032 seems like a reasonable compromise between potentially wasting memory and constantly reallocating new, larger skbs. Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com> Tested-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2014-11-28NFC: digital: Add NFC-DEP Send Chaining SupportMark A. Greer
When the NFC-DEP code is given a packet to send that is larger than the peer's maximum payload, its supposed to set the 'MI' bit in the 'I' PDU's Protocol Frame Byte (PFB). Setting this bit indicates that NFC-DEP chaining is to occur. When NFC-DEP chaining is progress, sender 'I' PDUs are acknowledged with 'ACK' PDUs until the last 'I' PDU in the chain (which has the 'MI' bit cleared) is responded to with a normal 'I' PDU. This can occur while in Initiator mode or in Target mode. Sender NFC-DEP chaining is currently not implemented in the digital layer so add that support. Unfortunately, since sending a frame may require writing the CRC to the end of the data, the relevant data part of the original skb must be copied for each intermediate frame. Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com> Tested-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2014-11-28NFC: digital: Implement NFC-DEP max payload lengthsMark A. Greer
The maximum payload for NFC-DEP exchanges (i.e., the number of bytes between SoD and EoD) is negotiated using the ATR_REQ, ATR_RES, and PSL_REQ commands. The valid maximum lengths are 64, 128, 192, and 254 bytes. Currently, NFC-DEP code assumes that both sides are always using 254 byte maximums and ignores attempts by the peer to change it. Instead, implement the negotiation code, enforce the local maximum when receiving data from the peer, and don't send payloads that exceed the remote's maximum. The default local maximum is 254 bytes. Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com> Tested-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2014-11-28NFC: digital: Enforce NFC-DEP PNI sequencingMark A. Greer
NFC-DEP DEP_REQ and DEP_RES exchanges using 'I' and 'ACK/NACK' PDUs have a sequence number called the Packet Number Information (PNI). The PNI is incremented (modulo 4) after every DEP_REQ/ DEP_RES pair and should be verified by the digital layer code. That verification isn't always done, though, so add code to make sure that it is done. Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com> Tested-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2014-11-28NFC: digital: Ensure no NAD byte in DEP_REQ and DEP_RES framesMark A. Greer
According to chapter 14 of the NFC-DEP Digital Protocol Spec., the NAD byte should never be present in DEP_REQ or DEP_RES frames. However, this is not enforced so add that enforcement code. Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com> Tested-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2014-11-28NFC: digital: Add Target-mode NFC-DEP DID SupportMark A. Greer
When in Target mode, the Initiator specifies whether subsequent DEP_REQ and DEP_RES frames will include a DID byte by the value passed in the ATR_REQ. If the DID value in the ATR_REQ is '0' then no DID byte will be included. If the DID value is between '1' and '14' then a DID byte containing the same value must be included in subsequent DEP_REQ and DEP_RES frames. Any other DID value is invalid. This is specified in sections 14.8.1.2 and 14.8.2.2 of the NFC Digital Protocol Spec. Checking the DID value (if it should be there at all), is not currently supported by the digital layer's NFC-DEP code. Add this support by remembering the DID value in the ATR_REQ, checking the DID value of received DEP_REQ frames (if it should be there at all), and including the remembered DID value in DEP_RES frames when appropriate. Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com> Tested-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2014-11-28NFC: digital: Ensure no DID in NFC-DEP responsesMark A. Greer
When in Initiator mode, the digital layer's NFC-DEP code always sets the Device ID (DID) value in the ATR_REQ to '0'. This means that subsequent DEP_REQ and DEP_RES frames must never include a DID byte. This is specified in sections 14.8.1.1 and 14.8.2.1 of the NFC Digital Protocol Spec. Currently, the digital layer's NFC-DEP code doesn't enforce this rule so add code to ensure that there is no DID byte in DEP_RES frames. Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com> Tested-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2014-11-28NFC: digital: Rearrange NFC-DEP DEP_REQ/DEP_RES CodeMark A. Greer
Rearrange some of the code in digital_in_recv_dep_res() and digital_tg_recv_dep_req() so the initial code looks similar. The real reason is prepare the code for some upcoming patches that require these changes. Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com> Tested-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2014-11-28NFC: digital: Fix potential skb leaks in NFC-DEP codeMark A. Greer
When digital_in_send_cmd() or digital_tg_send_cmd() fail, they do not free the skb that was passed to them so the routine that allocated the skb should free it. Currently, there are several routines in the NFC-DEP code that don't do this so make them. Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com> Tested-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2014-11-28cfg80211: make WEXT compatibility unselectableJohannes Berg
This option has been marked for deprecation and removal for a little more than two years, but it's not been very clearly signalled since it was always possible to just select it. Make it unselectable now to signal anyone who's still using it after all this time more clearly. They can still get it back, but only by patching the kernel. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-11-27Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netLinus Torvalds
Pull networking fixes from David Miller: "Several small fixes here: 1) Don't crash in tg3 driver when the number of tx queues has been configured to be different from the number of rx queues. From Thadeu Lima de Souza Cascardo. 2) VLAN filter not disabled properly in promisc mode in ixgbe driver, from Vlad Yasevich. 3) Fix OOPS on dellink op in VTI tunnel driver, from Xin Long. 4) IPV6 GRE driver WCCP code checks skb->protocol for ETH_P_IP instead of ETH_P_IPV6, whoops. From Yuri Chislov. 5) Socket matching in ping driver is buggy when packet AF does not match socket's AF. Fix from Jane Zhou. 6) Fix checksum calculation errors in VXLAN due to where the udp_tunnel6_xmit_skb() helper gets it's saddr/daddr from. From Alexander Duyck. 7) Fix 5G detection problem in rtlwifi driver, from Larry Finger. 8) Fix NULL deref in tcp_v{4,6}_send_reset, from Eric Dumazet. 9) Various missing netlink attribute verifications in bridging code, from Thomas Graf. 10) tcp_recvmsg() unconditionally calls ipv4 ip_recv_error even for ipv6 sockets, whoops. Fix from Willem de Bruijn" * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (29 commits) net-timestamp: make tcp_recvmsg call ipv6_recv_error for AF_INET6 socks bridge: Sanitize IFLA_EXT_MASK for AF_BRIDGE:RTM_GETLINK bridge: Add missing policy entry for IFLA_BRPORT_FAST_LEAVE net: Check for presence of IFLA_AF_SPEC net: Validate IFLA_BRIDGE_MODE attribute length bridge: Validate IFLA_BRIDGE_FLAGS attribute length stmmac: platform: fix default values of the filter bins setting net/mlx4_core: Limit count field to 24 bits in qp_alloc_res net: dsa: bcm_sf2: reset switch prior to initialization net: dsa: bcm_sf2: fix unmapping registers in case of errors tg3: fix ring init when there are more TX than RX channels tcp: fix possible NULL dereference in tcp_vX_send_reset() rtlwifi: Change order in device startup rtlwifi: rtl8821ae: Fix 5G detection problem Revert "netfilter: conntrack: fix race in __nf_conntrack_confirm against get_next_corpse" vxlan: Fix boolean flip in VXLAN_F_UDP_ZERO_CSUM6_[TX|RX] ip6_udp_tunnel: Fix checksum calculation net-timestamp: Fix a documentation typo net/ping: handle protocol mismatching scenario af_packet: fix sparse warning ...
2014-11-27sunrpc: add a debugfs rpc_xprt directory with an info file in itJeff Layton
Add a new directory heirarchy under the debugfs sunrpc/ directory: sunrpc/ rpc_xprt/ <xprt id>/ Within that directory, we can put files that give info about the xprts. We do have the (minor) problem that there is no succinct, unique identifier for rpc_xprts. So we generate them synthetically with a static atomic_t counter. For now, this directory just holds an "info" file, but we may add other files to it in the future. Signed-off-by: Jeff Layton <jlayton@primarydata.com> Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
2014-11-27sunrpc: add debugfs file for displaying client rpc_task queueJeff Layton
It's possible to get a dump of the RPC task queue by writing a value to /proc/sys/sunrpc/rpc_debug. If you write any value to that file, you get a dump of the RPC client task list into the log buffer. This is a rather inconvenient interface however, and makes it hard to get immediate info about the task queue. Add a new directory hierarchy under debugfs: sunrpc/ rpc_clnt/ <clientid>/ Within each clientid directory we create a new "tasks" file that will dump info similar to what shows up in the log buffer, but with a few small differences -- we avoid printing raw kernel addresses in favor of symbolic names and the XID is also displayed. Signed-off-by: Jeff Layton <jlayton@primarydata.com> Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
2014-11-27mac80211: copy chandef from AP vif to VLANsFelix Fietkau
Instead of keeping track of all those special cases where VLAN interfaces have no bss_conf.chandef, just make sure they have the same as the AP interface they belong to. Among others, this fixes a crash getting a VLAN's channel from userspace since a NULL channel is returned as a good result (return value 0) for VLANs since the commit below. Cc: stable@vger.kernel.org [3.18 only] Fixes: c12bc4885f4b3 ("mac80211: return the vif's chandef in ieee80211_cfg_get_channel()") Signed-off-by: Felix Fietkau <nbd@openwrt.org> [rewrite commit log] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-11-27nl80211: don't crash sending invalid chandefJohannes Berg
One of the cases for an invalid channel definition is that the channel pointer is NULL, in which case the warning is a bit late since we'll dereference the pointer. Bail out of the function upon warning about this. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-11-27netfilter: combine IPv4 and IPv6 nf_nat_redirect code in one modulePablo Neira Ayuso
This resolves linking problems with CONFIG_IPV6=n: net/built-in.o: In function `redirect_tg6': xt_REDIRECT.c:(.text+0x6d021): undefined reference to `nf_nat_redirect_ipv6' Reported-by: Andreas Ruprecht <rupran@einserver.de> Reported-by: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2014-11-27netfilter: nf_tables_bridge: set the pktinfo for IPv4/IPv6 trafficAlvaro Neira
This patch adds the missing bits to allow to match per meta l4proto from the bridge. Example: nft add rule bridge filter input ether type {ip, ip6} meta l4proto udp counter Signed-off-by: Alvaro Neira Ayuso <alvaroneay@gmail.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2014-11-27netfilter: nf_tables_bridge: export nft_reject_ip*hdr_validate functionsAlvaro Neira
This patch exports the functions nft_reject_iphdr_validate and nft_reject_ip6hdr_validate to use it in follow up patches. These functions check if the IPv4/IPv6 header is correct. Signed-off-by: Alvaro Neira Ayuso <alvaroneay@gmail.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2014-11-27netfilter: conntrack: avoid zeroing timerFlorian Westphal
add a __nfct_init_offset annotation member to struct nf_conn to make it clear which members are covered by the memset when the conntrack is allocated. This avoids zeroing timer_list and ct_net; both are already inited explicitly. Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2014-11-27netfilter: xt_recent: relax ip_pkt_list_tot restrictionsFlorian Westphal
The maximum value for the hitcount parameter is given by "ip_pkt_list_tot" parameter (default: 20). Exceeding this value on the command line will cause the rule to be rejected. The parameter is also readonly, i.e. it cannot be changed without module unload or reboot. Store size per table, then base nstamps[] size on the hitcount instead. The module parameter is retained for backwards compatibility. Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2014-11-27Bluetooth: Automatically flushable packets aren't allowed on LE linksSteven Walter
The Bluetooth spec states that automatically flushable packets may not be sent over a LE-U link. Signed-off-by: Steven Walter <stevenrwalter@gmail.com> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2014-11-26Merge tag 'nfs-rdma-for-3.19' of ↵Trond Myklebust
git://git.linux-nfs.org/projects/anna/nfs-rdma into linux-next Pull NFS client RDMA changes for 3.19 from Anna Schumaker: "NFS: Client side changes for RDMA These patches various bugfixes and cleanups for using NFS over RDMA, including better error handling and performance improvements by using pad optimization. Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>" * tag 'nfs-rdma-for-3.19' of git://git.linux-nfs.org/projects/anna/nfs-rdma: xprtrdma: Display async errors xprtrdma: Enable pad optimization xprtrdma: Re-write rpcrdma_flush_cqs() xprtrdma: Refactor tasklet scheduling xprtrdma: unmap all FMRs during transport disconnect xprtrdma: Cap req_cqinit xprtrdma: Return an errno from rpcrdma_register_external()
2014-11-26Merge tag 'nfs-cel-for-3.19' of ↵Trond Myklebust
git://git.linux-nfs.org/projects/anna/nfs-rdma into linux-next Pull pull additional NFS client changes for 3.19 from Anna Schumaker: "NFS: Generic client side changes from Chuck These patches fixes for iostats and SETCLIENTID in addition to cleaning up the nfs4_init_callback() function. Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>" * tag 'nfs-cel-for-3.19' of git://git.linux-nfs.org/projects/anna/nfs-rdma: NFS: Clean up nfs4_init_callback() NFS: SETCLIENTID XDR buffer sizes are incorrect SUNRPC: serialize iostats updates
2014-11-26net-timestamp: make tcp_recvmsg call ipv6_recv_error for AF_INET6 socksWillem de Bruijn
TCP timestamping introduced MSG_ERRQUEUE handling for TCP sockets. If the socket is of family AF_INET6, call ipv6_recv_error instead of ip_recv_error. This change is more complex than a single branch due to the loadable ipv6 module. It reuses a pre-existing indirect function call from ping. The ping code is safe to call, because it is part of the core ipv6 module and always present when AF_INET6 sockets are active. Fixes: 4ed2d765 (net-timestamp: TCP timestamping) Signed-off-by: Willem de Bruijn <willemb@google.com> ---- It may also be worthwhile to add WARN_ON_ONCE(sk->family == AF_INET6) to ip_recv_error. Signed-off-by: David S. Miller <davem@davemloft.net>
2014-11-26bridge: Sanitize IFLA_EXT_MASK for AF_BRIDGE:RTM_GETLINKThomas Graf
Only search for IFLA_EXT_MASK if the message actually carries a ifinfomsg header and validate minimal length requirements for IFLA_EXT_MASK. Fixes: 6cbdceeb ("bridge: Dump vlan information from a bridge port") Cc: Vlad Yasevich <vyasevic@redhat.com> Signed-off-by: Thomas Graf <tgraf@suug.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-11-26bridge: Add missing policy entry for IFLA_BRPORT_FAST_LEAVEThomas Graf
Fixes: c2d3babf ("bridge: implement multicast fast leave") Cc: David S. Miller <davem@davemloft.net> Signed-off-by: Thomas Graf <tgraf@suug.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-11-26bridge: Validate IFLA_BRIDGE_FLAGS attribute lengthThomas Graf
Payload is currently accessed blindly and may exceed valid message boundaries. Fixes: 407af3299 ("bridge: Add netlink interface to configure vlans on bridge ports") Cc: Vlad Yasevich <vyasevic@redhat.com> Signed-off-by: Thomas Graf <tgraf@suug.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-11-26cfg80211: clean up beacon loss CQM eventJohannes Berg
Having it as a sub-event for RSSI thresholds is very ugly, but luckily no userspace actually uses the events yet. Move the event to its own function call internally and to its own event attribute in nl80211. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-11-26tipc: use generic SKB list APIs to manage TIPC outgoing packet chainsYing Xue
Use standard SKB list APIs associated with struct sk_buff_head to manage socket outgoing packet chain and name table outgoing packet chain, having relevant code simpler and more readable. Signed-off-by: Ying Xue <ying.xue@windriver.com> Reviewed-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-11-26tipc: use generic SKB list APIs to manage link receive queueYing Xue
Use standard SKB list APIs associated with struct sk_buff_head to manage link's receive queue to simplify its relevant code cemplexity. Signed-off-by: Ying Xue <ying.xue@windriver.com> Reviewed-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-11-26tipc: use generic SKB list APIs to manage deferred queue of linkYing Xue
Use standard SKB list APIs associated with struct sk_buff_head to manage link's deferred queue, simplifying relevant code. Signed-off-by: Ying Xue <ying.xue@windriver.com> Reviewed-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-11-26tipc: use generic SKB list APIs to manage link transmission queueYing Xue
Use standard SKB list APIs associated with struct sk_buff_head to manage link transmission queue, having relevant code more clean. Signed-off-by: Ying Xue <ying.xue@windriver.com> Reviewed-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-11-26tipc: use skb_queue_walk_safe marco to simplify link_prepare_wakeup routineYing Xue
Signed-off-by: Ying Xue <ying.xue@windriver.com> Reviewed-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-11-26tipc: remove unused between routineYing Xue
Signed-off-by: Ying Xue <ying.xue@windriver.com> Reviewed-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-11-26tipc: eliminate two pseudo message types of BUNDLE_OPEN and BUNDLE_CLOSEDYing Xue
The pseudo message types of BUNDLE_CLOSED as well as BUNDLE_OPEN are used to flag whether or not more messages can be bundled into a data packet in the outgoing transmission queue. Obviously, no more messages can be appended after the packet has been sent and is waiting to be acknowledged and deleted. These message types do in reality represent a send-side local implementation flag, and are not defined as part of the protocol. It is therefore safe to move it to to where it belongs, that is, the control area (TIPC_SKB_CB) of the buffer. Signed-off-by: Ying Xue <ying.xue@windriver.com> Reviewed-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-11-26tipc: clean up the process of link pushing packetsYing Xue
In original tipc_link_push_packet(), it pushes messages from protocol message queue, retransmission queue and next_out queue. But as the two first queues are removed, we can simplify its relevant code through deleting tipc_link_push_queue(). Signed-off-by: Ying Xue <ying.xue@windriver.com> Reviewed-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-11-26tipc: remove retransmission queueYing Xue
TIPC retransmission queue is intended to record which messages should be retransmitted when bearer is not congested. However, as the retransmission queue becomes useless with the removal of bearer congestion mechanism, it should be removed. Signed-off-by: Ying Xue <ying.xue@windriver.com> Reviewed-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-11-26tipc: remove protocol message queueYing Xue
TIPC protocol message queue is intended to save one protocol message when bearer is congested so that the message stored in the queue can be immediately transmitted when bearer congestion is released. However, as now the protocol queue has no mission any more with the removal of bearer congestion mechanism, it should be removed. Signed-off-by: Ying Xue <ying.xue@windriver.com> Reviewed-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-11-26tipc: remove node subscription infrastructureYing Xue
The node subscribe infrastructure represents a virtual base class, so its users, such as struct tipc_port and struct publication, can derive its implemented functionalities. However, after the removal of struct tipc_port, struct publication is left as its only single user now. So defining an abstract infrastructure for one user becomes no longer reasonable. If corresponding new functions associated with the infrastructure are moved to name_table.c file, the node subscription infrastructure can be removed as well. Signed-off-by: Ying Xue <ying.xue@windriver.com> Reviewed-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-11-26ipv6: Remove unnecessary testzhuyj
The "init_net" test in function addrconf_exit_net is introduced in commit 44a6bd29 [Create ipv6 devconf-s for namespaces] to avoid freeing init_net. In commit c900a800 [ipv6: fix bad free of addrconf_init_net], function addrconf_init_net will allocate memory for every net regardless of init_net. In this case, it is unnecessary to make "init_net" test. CC: Hong Zhiguo <honkiko@gmail.com> CC: Octavian Purdila <opurdila@ixiacom.com> CC: Pavel Emelyanov <xemul@openvz.org> CC: Cong Wang <cwang@twopensource.com> Suggested-by: David S. Miller <davem@davemloft.net> Signed-off-by: Zhu Yanjun <Yanjun.Zhu@windriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-11-26gue: Call remcsum_adjustTom Herbert
Change remote checksum offload to call remcsum_adjust. This also eliminates the optimization to skip an IP header as part of the adjustment (really does not seem to be much of a win). Signed-off-by: Tom Herbert <therbert@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-11-26pkt_sched: fq: increase max delay from 125 ms to one secondEric Dumazet
FQ/pacing has a clamp of delay of 125 ms, to avoid some possible harm. It turns out this delay is too small to allow pacing low rates : Some ISP setup very aggressive policers as low as 16kbit. Now TCP stack has spurious rtx prevention, it seems safe to increase this fixed parameter, without adding a qdisc attribute. Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>