- 08 Feb, 2015 13 commits
-
-
hayeswang authored
vlan_get_protocol() has been defined and use it to replace get_protocol(). Signed-off-by:
Hayes Wang <hayeswang@realtek.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
hayeswang authored
Keep NETIF_F_HW_VLAN_CTAG_RX and NETIF_F_HW_VLAN_CTAG_TX at the same line. Signed-off-by:
-
hayeswang authored
It is unnecessary to accress the hw register if the device is unplugged. Signed-off-by:
-
hayeswang authored
Replace (tp->speed & LINK_STATUS) with netif_carrier_ok(). Signed-off-by:
-
hayeswang authored
Set LPM timer to 500us, except for RTL_VER_04 which doesn't link at USB 3.0. Signed-off-by:
-
hayeswang authored
If a error occurs when submitting rx, skip the remaining submissions and try to submit them again next time. Signed-off-by:
-
Sowmini Varadhan authored
Commit 083735f4 ("rds: switch rds_message_copy_from_user() to iov_iter") breaks rds_message_copy_from_user() semantics on success, and causes it to return nbytes copied, when it should return 0. This commit fixes that bug. Signed-off-by:
Sowmini Varadhan <sowmini.varadhan@oracle.com> Signed-off-by:
-
Rasmus Villemoes authored
The macro rdsdebug is defined as pr_debug("%s(): " fmt, __func__ , ##args) Hence it doesn't make sense to include the name of the calling function explicitly in the format string passed to rdsdebug. Signed-off-by:Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by:
-
Jarno Rajahalme authored
OVS userspace already probes the openvswitch kernel module for OVS_ACTION_ATTR_SET_MASKED support. This patch adds the kernel module implementation of masked set actions. The existing set action sets many fields at once. When only a subset of the IP header fields, for example, should be modified, all the IP fields need to be exact matched so that the other field values can be copied to the set action. A masked set action allows modification of an arbitrary subset of the supported header bits without requiring the rest to be matched. Masked set action is now supported for all writeable key types, except for the tunnel key. The set tunnel action is an exception as any input tunnel info is cleared before action processing starts, so there is no tunnel info to mask. The kernel module converts all (non-tunnel) set actions to masked set actions. This makes action processing more uniform, and results in less branching and duplicating the action processing code. When returning actions to userspace, the fully masked set actions are converted back to normal set actions. We use a kernel internal action code to be able to tell the userspace provided and converted masked set actions apart. Signed-off-by:
Jarno Rajahalme <jrajahalme@nicira.com> Acked-by:
Pravin B Shelar <pshelar@nicira.com> Signed-off-by:
-
David S. Miller authored
Florian Fainelli says: ==================== net: dsa: bcm_sf2: GPHY power down This patch series implement GPHY power up and down in the SF2 switch driver in order to conserve power whenever possible (e.g: port is brought down or unused during Wake-on-LAN). ==================== Signed-off-by: -
Florian Fainelli authored
Implement the power on/off recommended procedure for the Single GPHY we have on our Starfighter 2 switch. In order to make sure we get proper LED link/activity signaling during suspend, switch the link indication from the Switch/MAC to the PHY. Finally, since the GPHY needs to be reset to be put in low power mode, we will loose any context applied to it: workarounds, EEE etc.. so we need to call phy_init_hw() to get our fixups re-applied successfully. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Florian Fainelli authored
Move the code that touches the single GPHY register from bcm_sf2_sw_resume() to a separate function since we will have to enable/disable the GPHY from different locations, and we want the code to be self-contained. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-nextDavid S. Miller authored
NFC: 3.20 second pull request This is the second NFC pull request for 3.20. It brings: - NCI NFCEE (NFC Execution Environment, typically an embedded or external secure element) discovery and enabling/disabling support. In order to communicate with an NFCEE, we also added NCI's logical connections support to the NCI stack. - HCI over NCI protocol support. Some secure elements only understand HCI and thus we need to send them HCI frames when they're part of an NCI chipset. - NFC_EVT_TRANSACTION userspace API addition. Whenever an application running on a secure element needs to notify its host counterpart, we send an NFC_EVENT_SE_TRANSACTION event to userspace through the NFC netlink socket. - Secure element and HCI transaction event support for the st21nfcb chipset. Signed-off-by:
-
- 06 Feb, 2015 27 commits
-
-
Thomas Graf authored
The remove logic properly searched the remaining chain for a matching entry with an identical hash but it did this while searching from both the old and new table. Instead in order to not leave stale references behind we need to: 1. When growing and searching from the new table: Search remaining chain for entry with same hash to avoid having the new table directly point to a entry with a different hash. 2. When shrinking and searching from the old table: Check if the element after the removed would create a cross reference and avoid it if so. These bugs were present from the beginning in nft_hash. Also, both insert functions calculated the hash based on the mask of the new table. This worked while growing. Wwhile shrinking, the mask of the inew table is smaller than the mask of the old table. This lead to a bit not being taken into account when selecting the bucket lock and thus caused the wrong bucket to be locked eventually. Fixes: 7e1e7763 ("lib: Resizable, Scalable, Concurrent Hash Table") Fixes: 97defe1e ("rhashtable: Per bucket locks & deferred expansion/shrinking") Reported-by:Ying Xue <ying.xue@windriver.com> Signed-off-by:
Thomas Graf <tgraf@suug.ch> Signed-off-by:
-
David S. Miller authored
Thomas Graf says: ==================== rhashtable fixes This series fixes all remaining known issues with rhashtable that have been reported. In particular the race condition reported by Ying Xue. ==================== Signed-off-by: -
Thomas Graf authored
During a resize, when two buckets in the larger table map to a single bucket in the smaller table and the new table has already been (partially) linked to the old table. Removal of an element may result the bucket in the larger table to point to entries which all hash to a different value than the bucket index. Thus causing two buckets to point to the same sub chain after unzipping. This is not illegal *during* the resize phase but after it has completed. Keep the old table around until all of the unzipping is done to allow the removal code to only search for matching hashed entries during this special period. Reported-by:
-
Thomas Graf authored
Catch hash miscalculations which result in hard to track down race conditions. Signed-off-by:
-
Thomas Graf authored
This simplifies debugging of locking violations if compiled with CONFIG_PROVE_LOCKING. Signed-off-by:
-
Thomas Graf authored
We need to wait for all RCU readers to complete after the last bit of unzipping has been completed. Otherwise the old table is freed up prematurely. Fixes: 7e1e7763 ("lib: Resizable, Scalable, Concurrent Hash Table") Signed-off-by:
-
Thomas Graf authored
rhashtable currently allows to use a bucket lock per bucket. This requires multiple levels of complicated nested locking because when resizing, a single bucket of the smaller table will map to two buckets in the larger table. So far rhashtable has explicitly locked both buckets in the larger table. By excluding the highest bit of the hash from the bucket lock map and thus only allowing locks to buckets in a ratio of 1:2, the locking can be simplified a lot without losing the benefits of multiple locks. Larger tables which benefit from multiple locks will not have a single lock per bucket anyway. Signed-off-by:
-
Thomas Graf authored
The value computed by key_hashfn() is used by rhashtable_lookup_compare() to traverse both tables during a resize. key_hashfn() must therefore return the hash value without the buckets mask applied so it can be masked to the size of each individual table. Fixes: 97defe1e ("rhashtable: Per bucket locks & deferred expansion/shrinking") Signed-off-by:
-
Lad, Prabhakar authored
this patch fixes following sparse warning: vxge-config.c:4640:30: warning: Using plain integer as NULL pointer Signed-off-by:
Lad, Prabhakar <prabhakar.csengg@gmail.com> Signed-off-by:
-
Lad, Prabhakar authored
this patch fixes following sparse warning: interface.c:83:5: warning: symbol 'xenvif_poll' was not declared. Should it be static? Signed-off-by:
Wei Liu <wei.liu2@citrix.com> Signed-off-by:
-
Lad, Prabhakar authored
this patch fixes following sparse warning: macb.c:2038:26: warning: symbol 'gem_ethtool_ops' was not declared. Should it be static? Alongside drops exporting of gem_ethtool_ops as there is no need. Signed-off-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by:
-
Lad, Prabhakar authored
this patch fixes following sparse warnings: bnx2x_main.c:9172:6: warning: symbol 'bnx2x_stop_ptp' was not declared. Should it be static? bnx2x_main.c:13321:6: warning: symbol 'bnx2x_register_phc' was not declared. Should it be static? bnx2x_main.c:14638:5: warning: symbol 'bnx2x_enable_ptp_packets' was not declared. Should it be static? Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Lad, Prabhakar authored
this patch fixes following sparse warnings: enic_main.c:92:28: warning: symbol 'mod_table' was not declared. Should it be static? enic_main.c:109:28: warning: symbol 'mod_range' was not declared. Should it be static? enic_main.c:1306:5: warning: symbol 'enic_busy_poll' was not declared. Should it be static? Signed-off-by:
-
Lad, Prabhakar authored
this patch fixes following sparse warning: enic_ethtool.c:95:6: warning: symbol 'enic_intr_coal_set_rx' was not declared. Should it be static? Signed-off-by:
-
Lad, Prabhakar authored
this patch fixes following sparse warning: be_cmds.c:2750:5: warning: symbol 'be_cmd_set_qos' was not declared. Should it be static? Signed-off-by:
-
Lad, Prabhakar authored
this patch fixes following sparse warning: cxgb4_dcb.c:25:6: warning: symbol 'dcb_ver_array' was not declared. Should it be static? Alongside making it const. Signed-off-by:
-
Lad, Prabhakar authored
this patch fixes following sparse warnings: netvsc.c:688:5: warning: symbol 'netvsc_copy_to_send_buf' was not declared. Should it be static? rndis_filter.c:627:5: warning: symbol 'rndis_filter_set_offload_params' was not declared. Should it be static? rndis_filter.c:702:5: warning: symbol 'rndis_filter_set_rss_param' was not declared. Should it be static? Signed-off-by:
Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by:
-
David S. Miller authored
Jon Maloy says: ==================== tipc: resolve message disordering problem When TIPC receives messages from multi-threaded device drivers it may occasionally deliver messages to their destination sockets in the wrong order. This happens despite correct resequencing at the link layer, because the upcall path from link to socket is not protected by any locks. These commits solve this problem by introducing an 'input' message queue in each link, through which messages must be delivered to the upper layers. ==================== Signed-off-by: -
Jon Paul Maloy authored
In a previous commit in this series we resolved a race problem during unicast message reception. Here, we resolve the same problem at multicast reception. We apply the same technique: an input queue serializing the delivery of arriving buffers. The main difference is that here we do it in two steps. First, the broadcast link feeds arriving buffers into the tail of an arrival queue, which head is consumed at the socket level, and where destination lookup is performed. Second, if the lookup is successful, the resulting buffer clones are fed into a second queue, the input queue. This queue is consumed at reception in the socket just like in the unicast case. Both queues are protected by the same lock, -the one of the input queue. Reviewed-by:
Jon Maloy <jon.maloy@ericsson.com> Signed-off-by:
-
Jon Paul Maloy authored
The structure 'tipc_port_list' is used to collect port numbers representing multicast destination socket on a receiving node. The list is not based on a standard linked list, and is in reality optimized for the uncommon case that there are more than one multicast destinations per node. This makes the list handling unecessarily complex, and as a consequence, even the socket multicast reception becomes more complex. In this commit, we replace 'tipc_port_list' with a new 'struct tipc_plist', which is based on a standard list. We give the new list stack (push/pop) semantics, someting that simplifies the implementation of the function tipc_sk_mcast_rcv(). Reviewed-by:
-
Jon Paul Maloy authored
The new input message queue in struct tipc_link can be used for delivering connection abort messages to subscribing sockets. This makes it possible to simplify the code for such cases. This commit removes the temporary list in tipc_node_unlock() used for transforming abort subscriptions to messages. Instead, the abort messages are now created at the moment of lost contact, and then added to the last failed link's generic input queue for delivery to the sockets concerned. Reviewed-by:
-
Jon Paul Maloy authored
TIPC handles message cardinality and sequencing at the link layer, before passing messages upwards to the destination sockets. During the upcall from link to socket no locks are held. It is therefore possible, and we see it happen occasionally, that messages arriving in different threads and delivered in sequence still bypass each other before they reach the destination socket. This must not happen, since it violates the sequentiality guarantee. We solve this by adding a new input buffer queue to the link structure. Arriving messages are added safely to the tail of that queue by the link, while the head of the queue is consumed, also safely, by the receiving socket. Sequentiality is secured per socket by only allowing buffers to be dequeued inside the socket lock. Since there may be multiple simultaneous readers of the queue, we use a 'filter' parameter to reduce the risk that they peek the same buffer from the queue, hence also reducing the risk of contention on the receiving socket locks. This solves the sequentiality problem, and seems to cause no measurable performance degradation. A nice side effect of this change is that lock handling in the functions tipc_rcv() and tipc_bcast_rcv() now becomes uniform, something that will enable future simplifications of those functions. Reviewed-by:
-
Jon Paul Maloy authored
The list for outgoing traffic buffers from a socket is currently allocated on the stack. This forces us to initialize the queue for each sent message, something costing extra CPU cycles in the most critical data path. Later in this series we will introduce a new safe input buffer queue, something that would force us to initialize even the spinlock of the outgoing queue. A closer analysis reveals that the queue always is filled and emptied within the same lock_sock() session. It is therefore safe to use a queue aggregated in the socket itself for this purpose. Since there already exists a queue for this in struct sock, sk_write_queue, we introduce use of that queue in this commit. Reviewed-by:
-
Jon Paul Maloy authored
The function tipc_msg_eval() is in reality doing two related, but different tasks. First it tries to find a new destination for named messages, in case there was no first lookup, or if the first lookup failed. Second, it does what its name suggests, evaluating the validity of the message and its destination, and returning an appropriate error code depending on the result. This is confusing, and in this commit we choose to break it up into two functions. A new function, tipc_msg_lookup_dest(), first attempts to find a new destination, if the message is of the right type. If this lookup fails, or if the message should not be subject to a second lookup, the already existing tipc_msg_reverse() is called. This function performs prepares the message for rejection, if applicable. Reviewed-by:
-
Jon Paul Maloy authored
The code for enqueuing arriving buffers in the function tipc_sk_rcv() contains long code lines and currently goes to two indentation levels. As a cosmetic preparaton for the next commits, we break it out into a separate function. Reviewed-by:
-
Jon Paul Maloy authored
Despite recent improvements, the handling of error codes and return values at reception of messages in the socket layer is still confusing. In this commit, we try to make it more comprehensible. First, we separate between the return values coming from the functions called by tipc_sk_rcv(), -those are TIPC specific error codes, and the return values returned by tipc_sk_rcv() itself. Second, we don't use the returned TIPC error code as indication for whether a buffer should be forwarded/rejected or not; instead we use the buffer pointer passed along with filter_msg(). This separation is necessary because we sometimes want to forward messages even when there is no error (i.e., protocol messages and successfully secondary looked up data messages). Reviewed-by:
-
Jon Paul Maloy authored
The most common usage of namespace information is when we fetch the own node addess from the net structure. This leads to a lot of passing around of a parameter of type 'struct net *' between functions just to make them able to obtain this address. However, in many cases this is unnecessary. The own node address is readily available as a member of both struct tipc_sock and tipc_link, and can be fetched from there instead. The fact that the vast majority of functions in socket.c and link.c anyway are maintaining a pointer to their respective base structures makes this option even more compelling. In this commit, we introduce the inline functions tsk_own_node() and link_own_node() to make it easy for functions to fetch the node address from those structs instead of having to pass along and dereference the namespace struct. In particular, we make calls to the msg_xx() functions in msg.{h,c} context independent by directly passing them the own node address as parameter when needed. Those functions should be regarded as leaves in the code dependency tree, and it is hence desirable to keep them namspace unaware. Apart from a potential positive effect on cache behavior, these changes make it easier to introduce the changes that will follow later in this series. Reviewed-by:
-
