- 13 Nov, 2019 38 commits
-
-
Connor Kuehl authored
BugLink: https://bugs.launchpad.net/bugs/1852306 Properties: no-test-build Signed-off-by:
Connor Kuehl <connor.kuehl@canonical.com>
-
Connor Kuehl authored
Ignore: yes Signed-off-by: -
Colin Ian King authored
BugLink: https://bugs.launchpad.net/bugs/1850175 There memset is indented incorrectly, remove the extraneous tabs. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry picked from commit 4208966f) Signed-off-by:
Kamal Mostafa <kamal@canonical.com> Acked-by:
Stefan Bader <stefan.bader@canonical.com> Acked-by:
Khaled Elmously <khalid.elmously@canonical.com> Signed-off-by:
-
Sameeh Jubran authored
BugLink: https://bugs.launchpad.net/bugs/1850175 There is a race condition that can occur when calling ena_down(). The ena_clean_tx_irq() - which is a part of the napi handler - function might wake up the tx queue when the queue is supposed to be down (during recovery or changing the size of the queues for example) This causes the ena_start_xmit() function to trigger and possibly try to access the destroyed queues. The race is illustrated below: Flow A: Flow B(napi handler) ena_down() netif_carrier_off() netif_tx_disable() ena_clean_tx_irq() netif_tx_wake_queue() ena_napi_disable_all() ena_destroy_all_io_queues() After these flows the tx queue is active and ena_start_xmit() accesses the destroyed queue which leads to a kernel panic. fixes: 1738cd3e (net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)) Signed-off-by:
Sameeh Jubran <sameehj@amazon.com> Signed-off-by:
-
Jakub Kicinski authored
BugLink: https://bugs.launchpad.net/bugs/1850175 This reverts commit 315c28d2 ("net: ena: ethtool: add extra properties retrieval via get_priv_flags"). As discussed at netconf and on the mailing list we can't allow for the the abuse of private flags for exposing arbitrary device labels. Signed-off-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by:
-
Sameeh Jubran authored
BugLink: https://bugs.launchpad.net/bugs/1850175 The current code of create_queues_with_size_backoff() allows the ring size to become as small as ENA_MIN_RING_SIZE/2. This is a bug since we don't want the queue ring to be smaller than ENA_MIN_RING_SIZE In this commit we change the loop's termination condition to look at the queue size of the next iteration instead of that of the current one, so that the minimal queue size again becomes ENA_MIN_RING_SIZE. Fixes: eece4d2a ("net: ena: add ethtool function for changing io queue sizes") Signed-off-by:
Arthur Kiyanovski <akiyano@amazon.com> Signed-off-by:
-
Sameeh Jubran authored
BugLink: https://bugs.launchpad.net/bugs/1850175 Update driver version to match device specification. Signed-off-by:
-
Sameeh Jubran authored
BugLink: https://bugs.launchpad.net/bugs/1850175 Let the compiler decide if the function should be inline in *.c files Signed-off-by:
-
Sameeh Jubran authored
BugLink: https://bugs.launchpad.net/bugs/1850175 Implement the set_ringparam() function of the ethtool interface to enable the changing of io queue sizes. Signed-off-by:
-
Sameeh Jubran authored
BugLink: https://bugs.launchpad.net/bugs/1850175 If there is not enough memory to allocate io queues the driver will try to allocate smaller queues. The backoff algorithm is as follows: 1. Try to allocate TX and RX and if successful. 1.1. return success 2. Divide by 2 the size of the larger of RX and TX queues (or both if their size is the same). 3. If TX or RX is smaller than 256 3.1. return failure. 4. else 4.1. go back to 1. Also change the tx_queue_size, rx_queue_size field names in struct adapter to requested_tx_queue_size and requested_rx_queue_size, and use RX and TX queue 0 for actual queue sizes. Explanation: The original fields were useless as they were simply used to assign values once from them to each of the queues in the adapter in ena_probe(). They could simply be deleted. However now that we have a backoff feature, we have use for them. In case of backoff there is a difference between the requested queue sizes and the actual sizes. Therefore there is a need to save the requested queue size for future retries of queue allocation (for example if allocation failed and then ifdown + ifup was called we want to start the allocation from the original requested size of the queues). Signed-off-by:
-
Sameeh Jubran authored
BugLink: https://bugs.launchpad.net/bugs/1850175 Currently ethtool -g shows the same size for current and max queue sizes. Signed-off-by:
-
Sameeh Jubran authored
BugLink: https://bugs.launchpad.net/bugs/1850175 Use MAX_QUEUES_EXT get feature capability to query the device. Signed-off-by:
Netanel Belgazal <netanel@amazon.com> Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: https://bugs.launchpad.net/bugs/1850175 Add a new admin command to support different queue size for Tx/Rx queues (the change also support different SQ/CQ sizes) Signed-off-by:
-
Sameeh Jubran authored
BugLink: https://bugs.launchpad.net/bugs/1850175Signed-off-by:
-
Sameeh Jubran authored
BugLink: https://bugs.launchpad.net/bugs/1850175 Add a new statistics to ETHTOOL to specify if the device calculated and validated the Rx csum. Signed-off-by:
Evgeny Shmeilin <evgeny@annapurnaLabs.com> Signed-off-by:
-
Sameeh Jubran authored
BugLink: https://bugs.launchpad.net/bugs/1850175 This patch initially checks if CQ doorbell is needed before proceeding with the calculations. Signed-off-by:
Igor Chauskin <igorch@amazon.com> Signed-off-by:
-
Sameeh Jubran authored
BugLink: https://bugs.launchpad.net/bugs/1850175 Up until now the driver always used a single setting for the sizes of the different parts of the llq entry - 128 for entry size, 2 for descriptors before header and 96 for maximum header size. The current code makes sure that the parts of the llq entry are compatible with each other and with the initial llq entry size given by the device. This commit changes this code to support any llq entry size Signed-off-by:
-
Sameeh Jubran authored
BugLink: https://bugs.launchpad.net/bugs/1850175 Enable fallback to polling mode for Admin queue when identified a command response arrival without an accompanying MSI-X interrupt Signed-off-by:
-
Sameeh Jubran authored
BugLink: https://bugs.launchpad.net/bugs/1850175 Some pr_err prints lacked '\n' in the end. Added where missing. Signed-off-by:
-
Sameeh Jubran authored
BugLink: https://bugs.launchpad.net/bugs/1850175 Reverse christmas tree arrangement is when strings are written from longer to shorter with each line. Most of our functions are abiding this arrangement but this function does not. In this commit we arrange the variables of ena_probe() in reverse christmas tree. Signed-off-by:
-
Sameeh Jubran authored
BugLink: https://bugs.launchpad.net/bugs/1850175 struct ena_ring holds a union of free_rx_ids and free_tx_ids. Both of the above fields mean the exact same thing and are used exactly the same way. Furthermore, these fields are always used with a prefix of the type of ring. So for tx it will be tx_ring->free_tx_ids, and for rx it will be rx_ring->free_rx_ids, which shows how redundant the "_tx" and "_rx" parts are. Furthermore still, this may lead to confusing code like where tx_ring->free_rx_ids which works correctly but looks like a mess. This commit removes the aforementioned redundancy by replacing the free_rx/tx_ids union with a single free_ids field. It also changes a single goto label name from err_free_tx_ids: to err_tx_free_ids: for consistency with the above new notation. Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: https://bugs.launchpad.net/bugs/1850175 This commit adds a mechanism for exposing different device properties via ethtool's priv_flags. The strings are provided by the device and copied to user space through the driver. In this commit we: Add commands, structs and defines necessary for handling extra properties Add functions for: Allocation/destruction of a buffer for extra properties strings. Retreival of extra properties strings and flags from the network device. Handle the allocation of a buffer for extra properties strings. * Initialize buffer with extra properties strings from the network device at driver startup. Use ethtool's get_priv_flags to expose extra properties of the ENA device Signed-off-by:
-
Sameeh Jubran authored
BugLink: https://bugs.launchpad.net/bugs/1850175 There is a maximum TX burst size that the ENA device can handle. It is exposed by the device to the driver and the driver needs to comply with it to avoid bugs. In this commit we: 1. Add ena_com_is_doorbell_needed(), which calculates the number of llq entries that will be used to hold a packet, and will return true if they exceed the number of allowed entries in a burst. If the function returns true, a doorbell needs to be invoked to send this packet in the next burst. 2. Follow the available entries in the current burst: - Every doorbell a new burst begins - With each write of an llq entry, the available entries in the current burst are decreased by 1. Signed-off-by:
-
Sameeh Jubran authored
BugLink: https://bugs.launchpad.net/bugs/1850175 ena_com_fill_hash_function() didn't configure the rss->hash_func. Fixes: 1738cd3e ("net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)") Signed-off-by:
-
Sameeh Jubran authored
BugLink: https://bugs.launchpad.net/bugs/1850175 Adaptive interrupt moderation was erroneously enabled by default in the driver. In case the device supports adaptive interrupt moderation it will be automatically used, which may potentially increase latency. The adaptive moderation can be enabled from ethtool command in case the feature is supported by the device. Fixes: 1738cd3e ("net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)") Signed-off-by:
Guy Tzalik <gtzalik@amazon.com> Signed-off-by:
-
Sameeh Jubran authored
BugLink: https://bugs.launchpad.net/bugs/1850175 ena_com_config_llq_info() returns 0 even if ena_com_set_llq() fails. Return the failure code of ena_com_set_llq() in case it fails. fixes: 689b2bda ("net: ena: add functions for handling Low Latency Queues in ena_com") Signed-off-by:
-
Sameeh Jubran authored
BugLink: https://bugs.launchpad.net/bugs/1850175 ena_com_set_hash_function() tests if a hash function is supported by the device before setting it. The test returns the opposite result than needed. Reverse the condition to return the correct value. Also use the BIT macro instead of inline shift. Fixes: 1738cd3e ("net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)") Signed-off-by:
-
Sameeh Jubran authored
BugLink: https://bugs.launchpad.net/bugs/1850175 ena_up() calls ena_init_napi() but does not call ena_del_napi() in case of failure. This causes a segmentation fault upon rmmod when netif_napi_del() is called. Fix this bug by calling ena_del_napi() before returning error from ena_up(). Fixes: 1738cd3e ("net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)") Signed-off-by:
-
Sameeh Jubran authored
BugLink: https://bugs.launchpad.net/bugs/1850175 second parameter should be the index of the table rather than the value. Fixes: 1738cd3e ("net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)") Signed-off-by:
Saeed Bshara <saeedb@amazon.com> Signed-off-by:
-
Sameeh Jubran authored
BugLink: https://bugs.launchpad.net/bugs/1850175 In some cases when a queue related allocation fails, successful past allocations are freed but the pointer that pointed to them is not set to NULL. This is a problem for 2 reasons: 1. This is generally a bad practice since this pointer might be accidentally accessed in the future. 2. Future allocations using the same pointer check if the pointer is NULL and fail if it is not. Fixed this by setting such pointers to NULL in the allocation of queue related objects. Also refactored the code of ena_setup_tx_resources() to goto-style error handling to avoid code duplication of resource freeing. Fixes: 1738cd3e ("net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)") Signed-off-by:
-
Sameeh Jubran authored
BugLink: https://bugs.launchpad.net/bugs/1850175 BugLink: https://bugs.launchpad.net/bugs/1838700 [ Upstream commit f9133088 ] GCC 8 contains a number of new warnings as well as enhancements to existing checkers. The warning - Wstringop-truncation - warns for calls to bounded string manipulation functions such as strncat, strncpy, and stpncpy that may either truncate the copied string or leave the destination unchanged. In our case the destination string length (32 bytes) is much shorter than the source string (64 bytes) which causes this warning to show up. In general the destination has to be at least a byte larger than the length of the source string with strncpy for this warning not to showup. This can be easily fixed by using strlcpy instead which already does the truncation to the string. Documentation for this function can be found here: https://elixir.bootlin.com/linux/latest/source/lib/string.c#L141 Fixes: 1738cd3e ("net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)") Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
-
Baoyou Xie authored
BugLink: https://bugs.launchpad.net/bugs/1849871 Some cameras post inaccurate frame where next frame data overlap it. this results in screen flicker, and it need to be prevented. So this patch marks the buffer error to discard the frame where buffer overflow. Signed-off-by:
Baoyou Xie <baoyou.xie@linaro.org> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com> (cherry picked from commit dfc1648c) Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Acked-by:
-
Vincent Guittot authored
CVE-2018-20784 This re-applies the commit reverted here: commit c40f7d74 ("sched/fair: Fix infinite loop in update_blocked_averages() by reverting a9e7f654") I.e. now that cfs_rq can be safely removed/added in the list, we can re-apply: commit a9e7f654 ("sched/fair: Fix O(nr_cgroups) in load balance path") Signed-off-by:
Vincent Guittot <vincent.guittot@linaro.org> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: sargun@sargun.me Cc: tj@kernel.org Cc: xiexiuqi@huawei.com Cc: xiezhipeng1@huawei.com Link: https://lkml.kernel.org/r/1549469662-13614-3-git-send-email-vincent.guittot@linaro.orgSigned-off-by:
Ingo Molnar <mingo@kernel.org> (backported from commit 039ae8bc) [ Connor Kuehl: In 'cfs_rq_is_decayed' the data member 'runnable_load_sum' belongs to struct cfs_rq and not sched_avg, so update that. Some instances of 'for_each_leaf_cfs_rq' required manual updating to the new 'for_each_leaf_cfs_rq_safe' and the last hunk for 'update_blocked_averages' required manual placement. ] Signed-off-by:
Sultan Alsawaf <sultan.alsawaf@canonical.com> Acked-by:
-
Vincent Guittot authored
CVE-2018-20784 Removing a cfs_rq from rq->leaf_cfs_rq_list can break the parent/child ordering of the list when it will be added back. In order to remove an empty and fully decayed cfs_rq, we must remove its children too, so they will be added back in the right order next time. With a normal decay of PELT, a parent will be empty and fully decayed if all children are empty and fully decayed too. In such a case, we just have to ensure that the whole branch will be added when a new task is enqueued. This is default behavior since : commit f6783319 ("sched/fair: Fix insertion in rq->leaf_cfs_rq_list") In case of throttling, the PELT of throttled cfs_rq will not be updated whereas the parent will. This breaks the assumption made above unless we remove the children of a cfs_rq that is throttled. Then, they will be added back when unthrottled and a sched_entity will be enqueued. As throttled cfs_rq are now removed from the list, we can remove the associated test in update_blocked_averages(). Signed-off-by:
-
Vincent Guittot authored
CVE-2018-20784 Sargun reported a crash: "I picked up c40f7d74 sched/fair: Fix infinite loop in update_blocked_averages() by reverting a9e7f654 and put it on top of 4.19.13. In addition to this, I uninlined list_add_leaf_cfs_rq for debugging. This revealed a new bug that we didn't get to because we kept getting crashes from the previous issue. When we are running with cgroups that are rapidly changing, with CFS bandwidth control, and in addition using the cpusets cgroup, we see this crash. Specifically, it seems to occur with cgroups that are throttled and we change the allowed cpuset." The algorithm used to order cfs_rq in rq->leaf_cfs_rq_list assumes that it will walk down to root the 1st time a cfs_rq is used and we will finish to add either a cfs_rq without parent or a cfs_rq with a parent that is already on the list. But this is not always true in presence of throttling. Because a cfs_rq can be throttled even if it has never been used but other CPUs of the cgroup have already used all the bandwdith, we are not sure to go down to the root and add all cfs_rq in the list. Ensure that all cfs_rq will be added in the list even if they are throttled. [ mingo: Fix !CGROUPS build. ] Reported-by:
Sargun Dhillon <sargun@sargun.me> Signed-off-by:
-
Peter Zijlstra authored
CVE-2018-20784 The magic in list_add_leaf_cfs_rq() requires that at the end of enqueue_task_fair(): rq->tmp_alone_branch == &rq->lead_cfs_rq_list If this is violated, list integrity is compromised for list entries and the tmp_alone_branch pointer might dangle. Also, reflow list_add_leaf_cfs_rq() while there. This looses one indentation level and generates a form that's convenient for the next patch. Signed-off-by:
-
Vincent Guittot authored
CVE-2018-20784 Fix the insertion of cfs_rq in rq->leaf_cfs_rq_list to ensure that a child will always be called before its parent. The hierarchical order in shares update list has been introduced by commit: 67e86250 ("sched: Introduce hierarchal order on shares update list") With the current implementation a child can be still put after its parent. Lets take the example of: root \ b /\ c d* | e* with root -> b -> c already enqueued but not d -> e so the leaf_cfs_rq_list looks like: head -> c -> b -> root -> tail The branch d -> e will be added the first time that they are enqueued, starting with e then d. When e is added, its parents is not already on the list so e is put at the tail : head -> c -> b -> root -> e -> tail Then, d is added at the head because its parent is already on the list: head -> d -> c -> b -> root -> e -> tail e is not placed at the right position and will be called the last whereas it should be called at the beginning. Because it follows the bottom-up enqueue sequence, we are sure that we will finished to add either a cfs_rq without parent or a cfs_rq with a parent that is already on the list. We can use this event to detect when we have finished to add a new branch. For the others, whose parents are not already added, we have to ensure that they will be added after their children that have just been inserted the steps before, and after any potential parents that are already in the list. The easiest way is to put the cfs_rq just after the last inserted one and to keep track of it untl the branch is fully added. Signed-off-by:
Dietmar Eggemann <dietmar.eggemann@arm.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Morten.Rasmussen@arm.com Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: bsegall@google.com Cc: kernellwp@gmail.com Cc: pjt@google.com Cc: yuyang.du@intel.com Link: http://lkml.kernel.org/r/1478598827-32372-3-git-send-email-vincent.guittot@linaro.orgSigned-off-by:
-
Linus Torvalds authored
CVE-2018-20784 Zhipeng Xie, Xie XiuQi and Sargun Dhillon reported lockups in the scheduler under high loads, starting at around the v4.18 time frame, and Zhipeng Xie tracked it down to bugs in the rq->leaf_cfs_rq_list manipulation. Do a (manual) revert of: a9e7f654 ("sched/fair: Fix O(nr_cgroups) in load balance path") It turns out that the list_del_leaf_cfs_rq() introduced by this commit is a surprising property that was not considered in followup commits such as: 9c2791f9 ("sched/fair: Fix hierarchical order in rq->leaf_cfs_rq_list") As Vincent Guittot explains: "I think that there is a bigger problem with commit a9e7f654 and cfs_rq throttling: Let take the example of the following topology TG2 --> TG1 --> root: 1) The 1st time a task is enqueued, we will add TG2 cfs_rq then TG1 cfs_rq to leaf_cfs_rq_list and we are sure to do the whole branch in one path because it has never been used and can't be throttled so tmp_alone_branch will point to leaf_cfs_rq_list at the end. 2) Then TG1 is throttled 3) and we add TG3 as a new child of TG1. 4) The 1st enqueue of a task on TG3 will add TG3 cfs_rq just before TG1 cfs_rq and tmp_alone_branch will stay on rq->leaf_cfs_rq_list. With commit a9e7f654, we can del a cfs_rq from rq->leaf_cfs_rq_list. So if the load of TG1 cfs_rq becomes NULL before step 2) above, TG1 cfs_rq is removed from the list. Then at step 4), TG3 cfs_rq is added at the beginning of rq->leaf_cfs_rq_list but tmp_alone_branch still points to TG3 cfs_rq because its throttled parent can't be enqueued when the lock is released. tmp_alone_branch doesn't point to rq->leaf_cfs_rq_list whereas it should. So if TG3 cfs_rq is removed or destroyed before tmp_alone_branch points on another TG cfs_rq, the next TG cfs_rq that will be added, will be linked outside rq->leaf_cfs_rq_list - which is bad. In addition, we can break the ordering of the cfs_rq in rq->leaf_cfs_rq_list but this ordering is used to update and propagate the update from leaf down to root." Instead of trying to work through all these cases and trying to reproduce the very high loads that produced the lockup to begin with, simplify the code temporarily by reverting a9e7f654 - which change was clearly not thought through completely. This (hopefully) gives us a kernel that doesn't lock up so people can continue to enjoy their holidays without worrying about regressions. ;-) [ mingo: Wrote changelog, fixed weird spelling in code comment while at it. ] Analyzed-by:
Xie XiuQi <xiexiuqi@huawei.com> Analyzed-by:
Zhipeng Xie <xiezhipeng1@huawei.com> Reported-by:
Linus Torvalds <torvalds@linux-foundation.org> Acked-by:
-
- 12 Nov, 2019 2 commits
-
-
Connor Kuehl authored
BugLink: https://bugs.launchpad.net/bugs/1852110 Ignore: yes Signed-off-by:
-
Connor Kuehl authored
BugLink: https://bugs.launchpad.net/bugs/1852110 Ubuntu commit 6a1909898c14 ("ARM: 8479/2: add implementation for arm-smccc") updated selectable config options. Accept the defaults. Signed-off-by:
-
