- 29 Sep, 2020 40 commits
-
-
Thomas Gleixner authored
The usage of in_interrupt() in drivers is phased out and Linus clearly requested that code which changes behaviour depending on context should either be seperated or the context be conveyed in an argument passed by the caller, which usually knows the context. sonic_quiesce() uses 'in_interrupt() || irqs_disabled()' to chose either udelay() or usleep_range() in the wait loop. In all callchains leading to it the context is well defined and known. Add a 'may_sleep' argument and pass it through the various callchains leading to this function. Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Sebastian Andrzej Siewior authored
in_interrupt() is ill defined and does not provide what the name suggests. The usage especially in driver code is deprecated and a tree wide effort to clean up and consolidate the (ab)usage of in_interrupt() and related checks is happening. In this case the check covers only parts of the contexts in which these functions cannot be called. It fails to detect preemption or interrupt disabled invocations. As the functions which contain these warnings invoke mutex_lock() which contains a broad variety of checks (always enabled or debug option dependent) and therefore covers all invalid conditions already, there is no point in having inconsistent warnings in those drivers. The conditional return is not really valuable in practice either. Just remove them. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Sebastian Andrzej Siewior authored
in_interrupt() is ill defined and does not provide what the name suggests. The usage especially in driver code is deprecated and a tree wide effort to clean up and consolidate the (ab)usage of in_interrupt() and related checks is happening. In this case the check covers only parts of the contexts in which these functions cannot be called. It fails to detect preemption or interrupt disabled invocations. As the functions which are invoked from ionic_adminq_post() and ionic_dev_cmd_wait() contain a broad variety of checks (always enabled or debug option dependent) which cover all invalid conditions already, there is no point in having inconsistent warnings in those drivers. Just remove them. Signed-off-by:
Shannon Nelson <snelson@pensando.io> Signed-off-by:
-
Sebastian Andrzej Siewior authored
The in_interrupt() usage in this driver tries to figure out which context may sleep and which context may not sleep. in_interrupt() is not really suitable as it misses both preemption disabled and interrupt disabled invocations from task context. Conditionals like that in driver code are frowned upon in general because invocations of functions from invalid contexts might not be detected as the conditional papers over it. ionic_lif_addr() and _ionoc_lif_rx_mode() can be called from: 1) ->ndo_set_rx_mode() which is under netif_addr_lock_bh()) so it must not sleep. 2) Init and setup functions which are in fully preemptible task context. ionic_link_status_check_request() has two call paths: 1) NAPI which obviously cannot sleep 2) Setup which is again fully preemptible task context Add arguments which convey the execution context to the affected functions and let the callers provide the context instead of letting the functions deduce it. Signed-off-by: -
Sebastian Andrzej Siewior authored
in_interrupt() is ill defined and does not provide what the name suggests. The usage especially in driver code is deprecated and a tree wide effort to clean up and consolidate the (ab)usage of in_interrupt() and related checks is happening. In this case the checks cover only parts of the contexts in which these functions cannot be called. They fail to detect preemption or interrupt disabled invocations. As the functions which are invoked from the various places contain already a broad variety of checks (always enabled or debug option dependent) cover all invalid conditions already, there is no point in having inconsistent warnings in those drivers. Just remove them. Signed-off-by:
Alexander Duyck <alexander.h.duyck@linux.intel.com> Signed-off-by:
-
Sebastian Andrzej Siewior authored
The usage of in_interrupt() in drivers is phased out and Linus clearly requested that code which changes behaviour depending on context should either be seperated or the context be conveyed in an argument passed by the caller, which usually knows the context. mpc52xx_fec_stop() uses in_interrupt() to check if it is safe to sleep. All callers run in well defined contexts. Pass an argument from the callers indicating whether it is safe to sleep. Signed-off-by:
-
Sebastian Andrzej Siewior authored
e100_hw_init() invokes e100_self_test() only if in_interrupt() returns false as e100_self_test() uses msleep() which requires sleepable task context. The in_interrupt() check is incomplete because in_interrupt() cannot catch callers from contexts which have just preemption or interrupts disabled. e100_hw_init() is invoked from: - e100_loopback_test() which clearly is sleepable task context as the function uses msleep() itself. - e100_up() which clearly is sleepable task context as well because it invokes e100_alloc_cbs() abd request_irq() which both require sleepable task context due to GFP_KERNEL allocations and mutex_lock() operations. Remove the pointless in_interrupt() check. As a side effect of this analysis it turned out that e100_rx_alloc_list() which is only invoked from e100_loopback_test() and e100_up() pointlessly uses a GFP_ATOMIC allocation. The next invoked function e100_alloc_cbs() is using GFP_KERNEL already. Change the allocation mode in e100_rx_alloc_list() to GFP_KERNEL as well. Signed-off-by: -
Thomas Gleixner authored
t4_sge_stop() is only ever called from task context and the in_interrupt() check is presumably a leftover from copying t3_sge_stop(). Aside of in_interrupt() being deprecated because it's not providing what it claims to provide, this check would paper over illegitimate callers. The functions invoked from t4_sge_stop() contain already warnings to catch invocations from invalid contexts. Remove it. Signed-off-by:
-
Thomas Gleixner authored
t3_sge_stop() is called from task context and from error handlers in interrupt context. It relies on in_interrupt() to differentiate the contexts. in_interrupt() is deprecated as it is ill defined and does not provide what it suggests. Instead of replacing it with some other construct, simply split the function into t3_sge_stop_dma(), which can be called from any context, and t3_sge_stop() which can be only called from task context. This has the advantage that any bogus invocation of t3_sge_stop() from wrong contexts can be caught by debug kernels instead of being papered over by the conditional. Signed-off-by:
-
Thomas Gleixner authored
in_interrupt() is ill defined and does not provide what the name suggests. The usage especially in driver code is deprecated and a tree wide effort to clean up and consolidate the (ab)usage of in_interrupt() and related checks is happening. In this case the check covers only parts of the contexts in which these functions cannot be called. It fails to detect preemption or interrupt disabled invocations. As the functions which are invoked from at*_reinit_locked() contain a broad variety of checks (always enabled or debug option dependent) which cover all invalid conditions already, there is no point in having inconsistent warnings in those drivers. Just remove them. Signed-off-by:
-
Sebastian Andrzej Siewior authored
The usage of in_interrupt() in non-core code is phased out. Ideally the information of the calling context should be passed by the callers or the functions be split as appropriate. cfhsi_rx_desc() and cfhsi_rx_pld() use in_interrupt() to distinguish if they should use netif_rx() or netif_rx_ni() for receiving packets. The attempt to consolidate the code by passing an arguemnt or by distangling it failed due lack of knowledge about this driver and because the call chains are hard to follow. As a stop gap use netif_rx_any_context() which invokes the correct code path depending on context and confines the in_interrupt() usage to core code. Signed-off-by:
-
Sebastian Andrzej Siewior authored
Quite some drivers make conditional decisions based on in_interrupt() to invoke either netif_rx() or netif_rx_ni(). Conditionals based on in_interrupt() or other variants of preempt count checks in drivers should not exist for various reasons and Linus clearly requested to either split the code pathes or pass an argument to the common functions which provides the context. This is obviously the correct solution, but for some of the affected drivers this needs a major rewrite due to their convoluted structure. As in_interrupt() usage in drivers needs to be phased out, provide netif_rx_any_context() as a stop gap for these drivers. This confines the in_interrupt() conditional to core code which in turn allows to remove the access to this check for driver code and provides one central place to do further modifications once the driver maze is cleaned up. Suggested-by:
-
Thomas Gleixner authored
While chasing in_interrupt() (ab)use in drivers it turned out that the caif_spi driver has never been in use since the driver was merged 10 years ago. There never was any matching code which provides a platform device. The driver has not seen any update (asided of treewide changes and cleanups) since 8 years and the maintainers vanished from the planet. So analysing the potential contexts and the (in)correctness of in_interrupt() usage is just a pointless exercise. Remove the cruft. Signed-off-by:
-
Thomas Gleixner authored
enic_dev_wait() has a BUG_ON(in_interrupt()). Chasing the callers of enic_dev_wait() revealed the gems of enic_reset() and enic_tx_hang_reset() which are both invoked through work queues in order to be able to call rtnl_lock(). So far so good. After locking rtnl both functions acquire enic::enic_api_lock which serializes against the (ab)use from infiniband. This is where the trainwreck starts. enic::enic_api_lock is a spin_lock() which implicitly disables preemption, but both functions invoke a ton of functions under that lock which can sleep. The BUG_ON(in_interrupt()) does not trigger in that case because it can't detect the preempt disabled condition. This clearly has never been tested with any of the mandatory debug options for 7+ years, which would have caught that for sure. Cure it by adding a enic_api_busy member to struct enic, which is modified and evaluated with enic::enic_api_lock held. If enic_api_devcmd_proxy_by_index() observes enic::enic_api_busy as true, it drops enic::enic_api_lock and busy waits for enic::enic_api_busy to become false. It would be smarter to wait for a completion of that busy period, but enic_api_devcmd_proxy_by_index() is called with other spin locks held which obviously can't sleep. Remove the BUG_ON(in_interrupt()) check as well because it's incomplete and with proper debugging enabled the problem would have been caught from the debug checks in schedule_timeout(). Fixes: 0b038566 ("drivers/net: enic: Add an interface for USNIC to interact with firmware") Signed-off-by:
-
Jacob Keller authored
Commit 5d5b4128 ("devlink: introduce flash update overwrite mask") added a usage of _BITUL to the UAPI <linux/devlink.h> header, but failed to include the header file where it was defined. It happens that this does not break any existing kernel include chains because it gets included through other sources. However, when including the UAPI headers in a userspace application (such as devlink in iproute2), _BITUL is not defined. Fixes: 5d5b4128 ("devlink: introduce flash update overwrite mask") Signed-off-by:
Jacob Keller <jacob.e.keller@intel.com> Signed-off-by:
-
David S. Miller authored
Rohit Maheshwari says: ==================== cxgb4/ch_ktls: updates in net-next This series of patches improves connections setup and statistics. This series is broken down as follows: Patch 1 fixes the handling of connection setup failure in HW. Driver shouldn't return success to tls_dev_add, until HW returns success. Patch 2 avoids the log flood. Patch 3 adds ktls statistics at port level. v1->v2: - removed conn_up from all places. v2->v3: - Corrected timeout handling. ==================== Signed-off-by: -
Rohit Maheshwari authored
All the ktls stats were at adapter level, but now changing it to port level. Fixes: 62370a4f ("cxgb4/chcr: Add ipv6 support and statistics") Signed-off-by:
Rohit Maheshwari <rohitm@chelsio.com> Signed-off-by:
-
Rohit Maheshwari authored
Changing these logs to dynamic debugs. If issue is seen, these logs can be enabled at run time. Signed-off-by:
-
Rohit Maheshwari authored
Since driver first return success to tls_dev_add, if req to HW is successful, but later if HW returns failure, that connection traffic fails permanently and connection status remains unknown to stack. v1->v2: - removed conn_up from all places. v2->v3: - Corrected timeout handling. Fixes: 34aba2c4 ("cxgb4/chcr : Register to tls add and del callback") Signed-off-by:
-
Gustavo A. R. Silva authored
One-element arrays are being deprecated[1]. Replace the one-element array with a simple object of type u_char: 'u_char rm_pad1'[2], once it seems this is just a placeholder for padding. [1] https://www.kernel.org/doc/html/v5.9-rc1/process/deprecated.html#zero-length-and-one-element-arrays [2] https://github.com/KSPP/linux/issues/86Built-tested-by:
kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/lkml/5f72c23f.%2FkPBWcZBu+W6HKH4%25lkp@intel.com/Signed-off-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by:
-
Tom Parkin authored
When an L2TPv3 session receives a data frame with an incorrect cookie l2tp_core logs a warning message and bumps a stats counter to reflect the fact that the packet has been dropped. However, the stats counter in question is missing from the l2tp_netlink get message for tunnel and session instances. Include the statistic in the netlink get response. Signed-off-by:
Tom Parkin <tparkin@katalix.com> Signed-off-by:
-
David S. Miller authored
Merge branch 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next Johan Hedberg says: ==================== pull request: bluetooth-next 2020-09-29 Here's the main bluetooth-next pull request for 5.10: - Multiple fixes to suspend/resume handling - Added mgmt events for controller suspend/resume state - Improved extended advertising support - btintel: Enhanced support for next generation controllers - Added Qualcomm Bluetooth SoC WCN6855 support - Several other smaller fixes & improvements ==================== Signed-off-by:
-
David S. Miller authored
Huazhong Tan says: ==================== net: hns3: updates for -next There are some misc updates for the HNS3 ethernet driver. ==================== Signed-off-by: -
Guangbin Huang authored
Adds debugfs to dump tqp enable status. Signed-off-by:
Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
-
Guangbin Huang authored
In order to query specifications of the device, add a new debugfs command "dev spec" to do that. Signed-off-by:
-
Guojia Liao authored
NETIF_F_HW_VLAN_CTAG_FILTER is not set in netdev->hw_feature, but set in netdev->features. So the handler of NETIF_F_HW_VLAN_CTAG_FILTER in hns3_self_test() is always true, remove it. Signed-off-by:
Guojia Liao <liaoguojia@huawei.com> Signed-off-by:
-
Huazhong Tan authored
Add RoCE VF client reset support by notifying the RoCE VF client when hns3 VF is resetting and adding a interface to query whether CMDQ is ready to work. Signed-off-by:
-
Huazhong Tan authored
Add support for UDP segmentation offload to the HNS3 driver when the device can do it. Signed-off-by:
-
Huazhong Tan authored
Since the maximun BD number may not be 8 now, so rename hns3_over_8bd() to hns3_over_max_bd(). Signed-off-by:
-
Huazhong Tan authored
Currently, the driver is able to query the device's specifications, which includes the maximum BD number of non TSO packet, so replace macro HNS3_MAX_NON_TSO_BD_NUM with the queried value, and rewrite macro HNS3_MAX_NON_TSO_SIZE whose value depends on the the maximum BD number of non TSO packet. Also, add a new parameter max_non_tso_bd_num to function hns3_tx_bd_num() and hns3_skb_need_linearized(), then they can get the maximum BD number of non TSO packet from the caller instead of calculating by themself, The note of hns3_skb_need_linearized() should be update as well. Signed-off-by:
-
David S. Miller authored
Stanislaw Kardach says: ==================== octeontx2-af: cleanup and extend parser config Current KPU configuration data is spread over multiple files which makes it hard to read. Clean this up by gathering all configuration data in a single structure and also in a single file (npc_profile.h). This should increase the readability of KPU handling code (since it always references same structure), simplify updates to the CAM key extraction code and allow abstracting out the configuration source. Additionally extend and fix the parser config to support additional DSA types, NAT-T-ESP and IPv6 fields. Patch 1 ensures that CUSTOMx LTYPEs are not aliased with meaningful LTYPEs where possible. Patch 2 gathers all KPU profile related data into a single struct and creates an adapter structure which provides an interface to the KPU profile for the octeontx2-af driver. Patches 3-4 add support for Extended DSA, eDSA and Forward DSA. Patches 5-6 adds IPv6 fields to CAM key extraction and optimize the parser performance for fragmented IPv6 packets. Patch 7 refactors ESP handling in the parser to support NAT-T-ESP. ==================== Signed-off-by: -
Kiran Kumar K authored
Add support for NAT-T-ESP to KPU parser configuration. NAT ESP is a UDP based protocol. So move ESP to LE so that both UDP and ESP can be extracted. Signed-off-by:
Kiran Kumar K <kirankumark@marvell.com> Acked-by:
Sunil Goutham <sgoutham@marvell.com> Signed-off-by:
-
Abhijit Ayarekar authored
IPv6 fragmented packet may not contain completed layer 4 information. So stop KPU parsing after setting ipv6 fragmentation flag. Signed-off-by:
Abhijit Ayarekar <aayarekar@marvell.com> Acked-by:
-
Vidhya Vidhyaraman authored
Added some IPv6 protocol fields to the default MKEX profile. They include everything from the beginning of IP header and up to source address. The pattern occupies full KW2 in MCAM entry. Only one out of two LD registers for this protocol is used. Signed-off-by:
Vidhya Vidhyaraman <vraman@marvell.com> Acked-by:
-
Satha Rao authored
KPU profile interpret Extended DSA and eDSA by looking source dev. This was incorrect and it restricts to use few source device ids and also created confusion while parsing regular DSA tag. With below patch lookup was based on bit 12 of Word0. This is always zero for DSA tag and it should be one for Extended DSA and eDSA. Signed-off-by:
Satha Rao <skoteshwar@marvell.com> Acked-by:
-
Hariprasad Kelam authored
Marvell Prestera switches supports distributed switch architecture by inserting Forward DSA tag of 4 bytes right after ethernet SMAC. This tag don't have a tpid field. This patch provides parser and extraction support for the same. Default ldata extraction profile added for FDSA such that Src_port is extracted and placed inplace of vlanid field. Like extended DSA and eDSA tags,a special PKIND of 62 is used for this tag. Signed-off-by:
Hariprasad Kelam <hkelam@marvell.com> Acked-by:
-
Stanislaw Kardach authored
Refactor KPU related NPC code gathering all configuration data in a structured format and putting it in one place (npc_profile.h). This increases readability and makes it easier to extend the profile configuration (as opposed to jumping between multiple header and source files). To do this: * Gather all KPU profile related data into a single adapter struct. * Convert the built-in MKEX definition to a structured one to streamline the MKEX loading. * Convert LT default register configuration into a structure, keeping default protocol settings in same file where identifiers for those protocols are defined. * Add a single point for KPU profile loading, so that its source may change in the future once proper interfaces for loading such config are in place. Signed-off-by:
Stanislaw Kardach <skardach@marvell.com> Acked-by:
-
Stanislaw Kardach authored
Since LD contains LTYPE definitions tweaked toward efficient NIX_AF_RX_FLOW_KEY_ALG(0..31)_FIELD(0..4) usage, the original location of NPC_LT_LD_CUSTOM0/1 was aliased with MPLS_IN_* definitions. Moving custom frame to value 6 and 7 removes the aliasing at the cost of custom frames being also considered when TCP/UDP RSS algo is configured. However since the goal of CUSTOM frames is to classify them to a separate set of RQs, this cost is acceptable. Signed-off-by:
-
Gustavo A. R. Silva authored
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Refactor the code according to the use of a flexible-array member in struct tc_u_hnode and use the struct_size() helper to calculate the size for the allocations. Commit 5778d39d ("net_sched: fix struct tc_u_hnode layout in u32") makes it clear that the code is expected to dynamically allocate divisor + 1 entries for ->ht[] in tc_uhnode. Also, based on other observations, as the piece of code below: 1232 for (h = 0; h <= ht->divisor; h++) { 1233 for (n = rtnl_dereference(ht->ht[h]); 1234 n; 1235 n = rtnl_dereference(n->next)) { 1236 if (tc_skip_hw(n->flags)) 1237 continue; 1238 1239 err = u32_reoffload_knode(tp, n, add, cb, 1240 cb_priv, extack); 1241 if (err) 1242 return err; 1243 } 1244 } we can assume that, in general, the code is actually expecting to allocate that extra space for the one-element array in tc_uhnode, everytime it allocates memory for instances of tc_uhnode or tc_u_common structures. That's the reason for passing '1' as the last argument for struct_size() in the allocation for _root_ht_ and _tp_c_, and 'divisor + 1' in the allocation code for _ht_. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9-rc1/process/deprecated.html#zero-length-and-one-element-arraysTested-by:
-
Gustavo A. R. Silva authored
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Refactor the code according to the use of a flexible-array member in struct qed_ll2_tx_packet, instead of a one-element array and use the struct_size() helper to calculate the size for the allocations. Commit f5823fe6 ("qed: Add ll2 option to limit the number of bds per packet") was used as a reference point for these changes. Also, it's important to notice that flexible-array members should occur last in any structure, and structures containing such arrays and that are members of other structures, must also occur last in the containing structure. That's why _cur_completing_packet_ is now moved to the bottom in struct qed_ll2_tx_queue. _descq_mem_ and _cur_send_packet_ are also moved for unification. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9-rc1/process/deprecated.html#zero-length-and-one-element-arraysTested-by:
-
