- 24 Aug, 2017 15 commits
-
-
Sam Mendoza-Jonas authored
BugLink: http://bugs.launchpad.net/bugs/1711401 Commit 2def86a7 ("hvc: Convert to using interrupts instead of opal events") enabled the use of interrupts in the hvc_driver for OPAL platforms. However on machines with more than one hvc console, any console after the first will fail to register an interrupt handler in notifier_add_irq() since all consoles share the same IRQ number but do not set the IRQF_SHARED flag: genirq: Flags mismatch irq 31. 00000000 (hvc_console) vs. 00000000 (hvc_console) hvc_open: request_irq failed with rc -16. This error propagates up to hvc_open() and the console is closed, but OPAL will still generate interrupts that are not handled, leading to rcu_sched stall warnings. Set IRQF_SHARED when calling request_irq(), allowing additional consoles to start properly. This is only set for consoles handled by hvc_opal_probe(), leaving other types unaffected. Signed-off-by:
Samuel Mendoza-Jonas <sam@mendozajonas.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> (cherry picked from commit bbc3dfe8) Signed-off-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
Stefan Bader <stefan.bader@canonical.com> Acked-by:
Po-Hsu Lin <po-hsu.lin@canonical.com> Signed-off-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com>
-
Po-Hsu Lin authored
BugLink: http://bugs.launchpad.net/bugs/1710868 In the memory offline test, the $ration was used with RANDOM as the possibility to get it offlined, correct it to become the portion of available removable memory blocks. Also ask the tool to try to offline the next available memory block if the attempt is unsuccessful. It will only fail if all removable memory blocks are busy. A nice example: $ sudo ./test.sh Test scope: 10% hotplug memory online all hot-pluggable memory in offline state: SKIPPED - no hot-pluggable memory in offline state offline 10% hot-pluggable memory in online state trying to offline 3 out of 28 memory block(s): online->offline memory1 online->offline memory10 ./test.sh: line 74: echo: write error: Resource temporarily unavailable offline_memory_expect_success 10: unexpected fail online->offline memory100 online->offline memory101 online all hot-pluggable memory in offline state: offline->online memory1 offline->online memory100 offline->online memory101 skip extra tests: debugfs is not mounted $ echo $? 0 Signed-off-by:
Shuah Khan <shuahkh@osg.samsung.com> (cherry picked from commit 5ff0c60b) Signed-off-by:
-
Po-Hsu Lin authored
BugLink: http://bugs.launchpad.net/bugs/1710868 There is no prompt for testing memory notifier error injection, added with the same echo format of other tests above. Signed-off-by:
-
Po-Hsu Lin authored
BugLink: http://bugs.launchpad.net/bugs/1710868 Check the precentage range for -r flag in memory-hotplug test. Signed-off-by:
-
Po-Hsu Lin authored
BugLink: http://bugs.launchpad.net/bugs/1710868 Check for hot-pluggable memory availability in prerequisite() of the memory-hotplug test. Signed-off-by:
-
Po-Hsu Lin authored
BugLink: http://bugs.launchpad.net/bugs/1710868 Typo fixed for hotpluggable_offline_memory() in memory-hotplug test. Signed-off-by:
-
Tore Anderson authored
BugLink: https://bugs.launchpad.net/bugs/1707643 The HP lt4132 LTE/HSPA+ 4G Module (03f0:a31d) is a rebranded Huawei ME906s-158 device. It, like the ME906s-158, requires the "NDP to end" quirk for correct operation. Signed-off-by:
Tore Anderson <tore@fud.no> Signed-off-by:
David S. Miller <davem@davemloft.net> (backported from commit a68491f8) Signed-off-by:
Aurimas Fišeras <aurimas@members.fsf.org> Tested-by:
-
Andrea Arcangeli authored
BugLink: http://bugs.launchpad.net/bugs/1680513 If a candidate stable_node_dup has been found and it can accept further merges it can be refiled to the head of the list to speedup next searches without altering which dup is found and how the dups accumulate in the chain. We already refiled it back to the head in the prune_stale_stable_nodes case, but we didn't refile it if not pruning (which is more common). And we also refiled it when it was already at the head which is unnecessary (in the prune_stale_stable_nodes case, nr > 1 means there's more than one dup in the chain, it doesn't mean it's not already at the head of the chain). The stable_node_chain list is single threaded and there's no SMP locking contention so it should be faster to refile it to the head of the list also if prune_stale_stable_nodes is false. Profiling shows the refile happens 1.9% of the time when a dup is found with a max_page_sharing limit setting of 3 (with max_page_sharing of 2 the refile never happens of course as there's never space for one more merge) which is reasonably low. At higher max_page_sharing values it should be much less frequent. This is just an optimization. Link: http://lkml.kernel.org/r/20170518173721.22316-4-aarcange@redhat.comSigned-off-by:
Andrea Arcangeli <aarcange@redhat.com> Cc: Evgheni Dereveanchin <ederevea@redhat.com> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Petr Holasek <pholasek@redhat.com> Cc: Hugh Dickins <hughd@google.com> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Davidlohr Bueso <dave@stgolabs.net> Cc: Gavin Guo <gavin.guo@canonical.com> Cc: Jay Vosburgh <jay.vosburgh@canonical.com> Cc: Mel Gorman <mgorman@techsingularity.net> Cc: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> (cherry picked from commit 80b18dfa) Signed-off-by:
Gavin Guo <gavin.guo@canonical.com> Acked-by:
Seth Forshee <seth.forshee@canonical.com> Signed-off-by:
-
Andrea Arcangeli authored
BugLink: http://bugs.launchpad.net/bugs/1680513 Some static checker complains if chain/chain_prune returns a potentially stale pointer. There are two output parameters to chain/chain_prune, one is tree_page the other is stable_node_dup. Like in get_ksm_page the caller has to check tree_page is NULL before touching the stable_node. Similarly in chain/chain_prune the caller has to check tree_page before touching the stable_node_dup returned or the original stable_node passed as parameter. Because the tree_page is never returned as a stale pointer, it may be more intuitive to return tree_page and to pass stable_node_dup for reference instead of the reverse. This patch purely swaps the two output parameters of chain/chain_prune as a cleanup for the static checker and to mimic the get_ksm_page behavior more closely. There's no change to the caller at all except the swap, it's purely a cleanup and it is a noop from the caller point of view. Link: http://lkml.kernel.org/r/20170518173721.22316-3-aarcange@redhat.comSigned-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Tested-by:
-
Andrea Arcangeli authored
BugLink: http://bugs.launchpad.net/bugs/1680513 Patch series "KSMscale cleanup/optimizations". There are no fixes here it's just minor cleanups and optimizations. 1/3 removes makes the "fix" for the stale stable_node fall in the standard case without introducing new cases. Setting stable_node to NULL was marginally safer, but stale pointer is still wiped from the caller, this looks cleaner. 2/3 should fix the false positive from Dan's static checker. 3/3 is a microoptimization to apply the the refile of future merge candidate dups at the head of the chain in all cases and to skip it in one case where we did it and but it was a noop (to avoid checking if it was already at the head but now we've to check it anyway so it got optimized away). This patch (of 3): When the stable_node chain is collapsed we can as well set the caller stable_node to match the returned stable_node_dup in chain_prune(). This way the collapse case becomes indistinguishable from the regular stable_node case and we can remove two branches from the KSM page migration handling slow paths. While it was all correct this looks cleaner (and faster) as the caller has to deal with fewer special cases. Link: http://lkml.kernel.org/r/20170518173721.22316-2-aarcange@redhat.comSigned-off-by:
-
Andrea Arcangeli authored
BugLink: http://bugs.launchpad.net/bugs/1680513 If merge_across_nodes was manually set to 0 (not the default value) by the admin or a tuned profile on NUMA systems triggering cross-NODE page migrations, a stable_node use after free could materialize. If the chain is collapsed stable_node would point to the old chain that was already freed. stable_node_dup would be the stable_node dup now converted to a regular stable_node and indexed in the rbtree in replacement of the freed stable_node chain (not anymore a dup). This special case where the chain is collapsed in the NUMA replacement path, is now detected by setting stable_node to NULL by the chain_prune callee if it decides to collapse the chain. This tells the NUMA replacement code that even if stable_node and stable_node_dup are different, this is not a chain if stable_node is NULL, as the stable_node_dup was converted to a regular stable_node and the chain was collapsed. It is generally safer for the callee to force the caller stable_node to NULL the moment it become stale so any other mistake like this would result in an instant Oops easier to debug than an use after free. Otherwise the replace logic would act like if stable_node was a valid chain, when in fact it was freed. Notably stable_node_chain_add_dup(page_node, stable_node) would run on a stable stable_node. Andrey Ryabinin found the source of the use after free in chain_prune(). Link: http://lkml.kernel.org/r/20170512193805.8807-2-aarcange@redhat.comSigned-off-by:
Andrey Ryabinin <aryabinin@virtuozzo.com> Reported-by:
Evgheni Dereveanchin <ederevea@redhat.com> Tested-by:
-
Andrea Arcangeli authored
BugLink: http://bugs.launchpad.net/bugs/1680513 Without a max deduplication limit for each KSM page, the list of the rmap_items associated to each stable_node can grow infinitely large. During the rmap walk each entry can take up to ~10usec to process because of IPIs for the TLB flushing (both for the primary MMU and the secondary MMUs with the MMU notifier). With only 16GB of address space shared in the same KSM page, that would amount to dozens of seconds of kernel runtime. A ~256 max deduplication factor will reduce the latencies of the rmap walks on KSM pages to order of a few msec. Just doing the cond_resched() during the rmap walks is not enough, the list size must have a limit too, otherwise the caller could get blocked in (schedule friendly) kernel computations for seconds, unexpectedly. There's room for optimization to significantly reduce the IPI delivery cost during the page_referenced(), but at least for page_migration in the KSM case (used by hard NUMA bindings, compaction and NUMA balancing) it may be inevitable to send lots of IPIs if each rmap_item->mm is active on a different CPU and there are lots of CPUs. Even if we ignore the IPI delivery cost, we've still to walk the whole KSM rmap list, so we can't allow millions or billions (ulimited) number of entries in the KSM stable_node rmap_item lists. The limit is enforced efficiently by adding a second dimension to the stable rbtree. So there are three types of stable_nodes: the regular ones (identical as before, living in the first flat dimension of the stable rbtree), the "chains" and the "dups". Every "chain" and all "dups" linked into a "chain" enforce the invariant that they represent the same write protected memory content, even if each "dup" will be pointed by a different KSM page copy of that content. This way the stable rbtree lookup computational complexity is unaffected if compared to an unlimited max_sharing_limit. It is still enforced that there cannot be KSM page content duplicates in the stable rbtree itself. Adding the second dimension to the stable rbtree only after the max_page_sharing limit hits, provides for a zero memory footprint increase on 64bit archs. The memory overhead of the per-KSM page stable_tree and per virtual mapping rmap_item is unchanged. Only after the max_page_sharing limit hits, we need to allocate a stable_tree "chain" and rb_replace() the "regular" stable_node with the newly allocated stable_node "chain". After that we simply add the "regular" stable_node to the chain as a stable_node "dup" by linking hlist_dup in the stable_node_chain->hlist. This way the "regular" (flat) stable_node is converted to a stable_node "dup" living in the second dimension of the stable rbtree. During stable rbtree lookups the stable_node "chain" is identified as stable_node->rmap_hlist_len == STABLE_NODE_CHAIN (aka is_stable_node_chain()). When dropping stable_nodes, the stable_node "dup" is identified as stable_node->head == STABLE_NODE_DUP_HEAD (aka is_stable_node_dup()). The STABLE_NODE_DUP_HEAD must be an unique valid pointer never used elsewhere in any stable_node->head/node to avoid a clashes with the stable_node->node.rb_parent_color pointer, and different from &migrate_nodes. So the second field of &migrate_nodes is picked and verified as always safe with a BUILD_BUG_ON in case the list_head implementation changes in the future. The STABLE_NODE_DUP is picked as a random negative value in stable_node->rmap_hlist_len. rmap_hlist_len cannot become negative when it's a "regular" stable_node or a stable_node "dup". The stable_node_chain->nid is irrelevant. The stable_node_chain->kpfn is aliased in a union with a time field used to rate limit the stable_node_chain->hlist prunes. The garbage collection of the stable_node_chain happens lazily during stable rbtree lookups (as for all other kind of stable_nodes), or while disabling KSM with "echo 2 >/sys/kernel/mm/ksm/run" while collecting the entire stable rbtree. While the "regular" stable_nodes and the stable_node "dups" must wait for their underlying tree_page to be freed before they can be freed themselves, the stable_node "chains" can be freed immediately if the stable_node->hlist turns empty. This is because the "chains" are never pointed by any page->mapping and they're effectively stable rbtree KSM self contained metadata. [akpm@linux-foundation.org: fix non-NUMA build] Signed-off-by:
Petr Holasek <pholasek@redhat.com> Cc: Hugh Dickins <hughd@google.com> Cc: Davidlohr Bueso <dave@stgolabs.net> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Evgheni Dereveanchin <ederevea@redhat.com> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Gavin Guo <gavin.guo@canonical.com> Cc: Jay Vosburgh <jay.vosburgh@canonical.com> Cc: Mel Gorman <mgorman@techsingularity.net> Signed-off-by:
-
Thadeu Lima de Souza Cascardo authored
BugLink: https://bugs.launchpad.net/bugs/1712345 Whenever we update the ABI files, the files may be sorted in a different order, even though their contents are the same. That happens because the system updating the ABI files may use a different locale than the one that was used previously. Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Acked-by:
Marcelo Cerri <marcelo.cerri@canonical.com> Acked-by:
-
Wen-chien Jesse Sung authored
BugLink: https://launchpad.net/bugs/1665783Signed-off-by:
Wen-chien Jesse Sung <jesse.sung@canonical.com> Acked-by:
Brad Figg <brad.figg@canonical.com> Acked-by:
-
Tim Gardner authored
BugLink: https://launchpad.net/bugs/1665783Signed-off-by:
Tim Gardner <tim.gardner@canonical.com> Signed-off-by:
-
- 23 Aug, 2017 3 commits
-
-
Tim Gardner authored
BugLink: https://launchpad.net/bugs/1665783Signed-off-by:
-
Wen-chien Jesse Sung authored
BugLink: https://launchpad.net/bugs/1665783Signed-off-by:
-
Wen-chien Jesse Sung authored
BugLink: https://launchpad.net/bugs/1665783 Based on files developed by Lool <lool@sd-70125.dedibox.fr> and Tim Gardner <tim.gardner@canonical.com> Signed-off-by:
-
- 22 Aug, 2017 22 commits
-
-
Greg Kroah-Hartman authored
BugLink: http://bugs.launchpad.net/bugs/1711557Signed-off-by:
-
Thomas Gleixner authored
BugLink: http://bugs.launchpad.net/bugs/1711557 commit 3fa53ec2 upstream. The irq chip callbacks irq_request/release_resources() have absolutely no business with masking and unmasking the irq. The core code unmasks the interrupt after complete setup and masks it before invoking irq_release_resources(). The unmask is actually harmful as it happens before the interrupt is completely initialized in __setup_irq(). Remove it. Fixes: f6a8249f ("pinctrl: exynos: Lock GPIOs as interrupts when used as EINTs") Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Krzysztof Kozlowski <krzk@kernel.org> Cc: Sylwester Nawrocki <s.nawrocki@samsung.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Kukjin Kim <kgene@kernel.org> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-samsung-soc@vger.kernel.org Cc: linux-gpio@vger.kernel.org Acked-by:
Tomasz Figa <tomasz.figa@gmail.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Icenowy Zheng authored
BugLink: http://bugs.launchpad.net/bugs/1711557 commit d81ece74 upstream. The PH16 pin has a function with mux id 0x5, which is the DET pin of the "sim" (smart card reader) IP block. This function is missing in old versions of A10/A20 SoCs' datasheets and user manuals, so it's also missing in the old drivers. The newest A10 Datasheet V1.70 and A20 Datasheet V1.41 contain this pin function, and it's discovered during implementing R40 pinctrl driver. Add it to the driver. As we now merged A20 pinctrl driver to the A10 one, we need to only fix the A10 driver now. Fixes: f2821b1c ("pinctrl: sunxi: Move Allwinner A10 pinctrl driver to a driver of its own") Signed-off-by:
Icenowy Zheng <icenowy@aosc.io> Reviewed-by:
Chen-Yu Tsai <wens@csie.org> Signed-off-by:
-
Christoph Hellwig authored
BugLink: http://bugs.launchpad.net/bugs/1711557 commit 8a9d6e96 upstream. The blocklayout code does not compile cleanly for a 32-bit sector_t, and also has no reliable checks for devices sizes, which makes it unsafe to use with a kernel that doesn't support large block devices. Signed-off-by:
Christoph Hellwig <hch@lst.de> Reported-by:
Arnd Bergmann <arnd@arndb.de> Fixes: 5c83746a ("pnfs/blocklayout: in-kernel GETDEVICEINFO XDR parsing") Signed-off-by:
Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by:
-
Stefan-Gabriel Mirea authored
BugLink: http://bugs.launchpad.net/bugs/1711557 commit d466d3c1 upstream. In order to select the alternate voltage reference pair (VALTH/VALTL), the right value for the REFSEL field in the ADCx_CFG register is "01", leading to 0x800 as register mask. See section 8.2.6.4 in the reference manual[1]. [1] http://www.nxp.com/docs/en/reference-manual/VFXXXRM.pdf Fixes: a7754276 ("iio:adc:imx: add Freescale Vybrid vf610 adc driver") Signed-off-by:
Stefan-Gabriel Mirea <stefan-gabriel.mirea@nxp.com> Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
-
Sandeep Singh authored
BugLink: http://bugs.launchpad.net/bugs/1711557 commit e788787e upstream. Certain HP keyboards would keep inputting a character automatically which is the wake-up key after S3 resume On some AMD platforms USB host fails to respond (by holding resume-K) to USB device (an HP keyboard) resume request within 1ms (TURSM) and ensures that resume is signaled for at least 20 ms (TDRSMDN), which is defined in USB 2.0 spec. The result is that the keyboard is out of function. In SNPS USB design, the host responds to the resume request only after system gets back to S0 and the host gets to functional after the internal HW restore operation that is more than 1 second after the initial resume request from the USB device. As a workaround for specific keyboard ID(HP Keyboards), applying port reset after resume when the keyboard is plugged in. Signed-off-by:
Sandeep Singh <Sandeep.Singh@amd.com> Signed-off-by:
Shyam Sundar S K <Shyam-sundar.S-k@amd.com> cc: Nehal Shah <Nehal-bakulchandra.Shah@amd.com> Reviewed-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by:
-
Kai-Heng Feng authored
BugLink: http://bugs.launchpad.net/bugs/1711557 commit 7496cfe5 upstream. Moshi USB to Ethernet Adapter internally uses a Genesys Logic hub to connect to Realtek r8153. The Realtek r8153 ethernet does not work on the internal hub, no-lpm quirk can make it work. Since another r8153 dongle at my hand does not have the issue, so add the quirk to the Genesys Logic hub instead. Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by:
-
Bin Liu authored
BugLink: http://bugs.launchpad.net/bugs/1711557 commit 2eac1362 upstream. While unlink an urb, if the urb has been programmed in the controller, the controller driver might do some hw related actions to tear down the urb. Currently usb_hcd_flush_endpoint() passes each urb from the head of the endpoint's urb_list to the controller driver, which could make the controller driver think each urb has been programmed and take the unnecessary actions for each urb. This patch changes the behavior in usb_hcd_flush_endpoint() to pass the urbs from the tail of the list, to avoid any unnecessary actions in an controller driver. Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Bin Liu <b-liu@ti.com> Signed-off-by:
-
Alan Stern authored
BugLink: http://bugs.launchpad.net/bugs/1711557 commit 94c43b98 upstream. Some buggy USB disk adapters disconnect and reconnect multiple times during the enumeration procedure. This may lead to a device connecting at full speed instead of high speed, because when the USB stack sees that a device isn't able to enumerate at high speed, it tries to hand the connection over to a full-speed companion controller. The logic for doing this is careful to check that the device is still connected. But this check is inadequate if the device disconnects and reconnects before the check is done. The symptom is that a device works, but much more slowly than it is capable of operating. The situation was made worse recently by commit 22547c4c ("usb: hub: Wait for connection to be reestablished after port reset"), which increases the delay following a reset before a disconnect is recognized, thus giving the device more time to reconnect. This patch makes the check more robust. If the device was disconnected at any time during enumeration, we will now skip the full-speed handover. Signed-off-by:
Zdenek Kabelac <zkabelac@redhat.com> Reviewed-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Alan Swanson authored
BugLink: http://bugs.launchpad.net/bugs/1711557 commit 89f23d51 upstream. Similar to commit d595259f ("usb-storage: Add ignore-residue quirk for Initio INIC-3619") for INIC-3169 in unusual_devs.h but INIC-3069 already present in unusual_uas.h. Both in same controller IC family. Issue is that MakeMKV fails during key exchange with installed bluray drive with following error: 002004:0000 Error 'Scsi error - ILLEGAL REQUEST:COPY PROTECTION KEY EXCHANGE FAILURE - KEY NOT ESTABLISHED' occurred while issuing SCSI command AD010..080002400 to device 'SG:dev_11:0' Signed-off-by:
Alan Swanson <reiver@improbability.net> Acked-by:
Oliver Neukum <oneukum@suse.com> Signed-off-by:
-
Akinobu Mita authored
BugLink: http://bugs.launchpad.net/bugs/1711557 commit a3507e48 upstream. The TSL2563 driver provides three iio channels, two of which are raw ADC channels (channel 0 and channel 1) in the device and the remaining one is calculated by the two. The ADC channel 0 only supports programmable interrupt with threshold settings and this driver supports the event but the generated event code does not contain the corresponding iio channel type. This is going to change userspace ABI. Hopefully fixing this to be what it should always have been won't break any userspace code. Cc: Jonathan Cameron <jic23@kernel.org> Signed-off-by:
Akinobu Mita <akinobu.mita@gmail.com> Signed-off-by:
Jonathan Cameron <jic23@kernel.org> Signed-off-by:
-
Hans de Goede authored
BugLink: http://bugs.launchpad.net/bugs/1711557 commit e59e1898 upstream. After probe we would put the device in normal mode, after a runtime suspend-resume we would put it back in normal mode. But for a regular suspend-resume we would only put it back in normal mode if triggers or events have been requested. This is not consistent and breaks reading raw values after a suspend-resume. This commit changes the regular resume path to also unconditionally put the device back in normal mode, fixing reading of raw values not working after a regular suspend-resume cycle. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by:
-
Arnd Bergmann authored
BugLink: http://bugs.launchpad.net/bugs/1711557 commit 105967ad upstream. gcc-7 points out an older regression: drivers/staging/iio/resolver/ad2s1210.c: In function 'ad2s1210_read_raw': drivers/staging/iio/resolver/ad2s1210.c:515:42: error: '<<' in boolean context, did you mean '<' ? [-Werror=int-in-bool-context] The original code had 'unsigned short' here, but incorrectly got converted to 'bool'. This reverts the regression and uses a normal type instead. Fixes: 29148543 ("staging:iio:resolver:ad2s1210 minimal chan spec conversion.") Signed-off-by:
-
Rafael J. Wysocki authored
BugLink: http://bugs.launchpad.net/bugs/1711557 commit cd5a6a4f upstream. Make usb_hc_died() clear the HCD_FLAG_RH_RUNNING flag for the shared HCD and set HCD_FLAG_DEAD for it, in analogy with what is done for the primary one. Among other thigs, this prevents check_root_hub_suspended() from returning -EBUSY for dead HCDs which helps to work around system suspend issues in some situations. This actually fixes occasional suspend failures on one of my test machines. Suggested-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by:
-
Bin Liu authored
BugLink: http://bugs.launchpad.net/bugs/1711557 commit 45d73860 upstream. commit 68fe05e2 ("usb: musb: fix tx fifo flush handling") drops the 1ms delay trying to solve the long disconnect time issue when application queued many tx urbs. However, the 1ms delay is needed for some use cases, for example, without the delay, reconnecting AR9271 WIFI dongle no longer works if the connection is dropped from the AP. So let's add back the 1ms delay in musb_h_tx_flush_fifo(), and solve the long disconnect time problem with a separate patch for usb_hcd_flush_endpoint(). Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: http://bugs.launchpad.net/bugs/1711557 commit 3b6bcd3d upstream. This adds a new ATEN device id for a new pl2303-based device. Reported-by:
Peter Kuo <PeterKuo@aten.com.tw> Cc: Johan Hovold <johan@kernel.org> Signed-off-by:
-
Stefan Triller authored
BugLink: http://bugs.launchpad.net/bugs/1711557 commit 9585e340 upstream. The German Telekom offers a ZigBee USB Stick under the brand name Qivicon for their SmartHome Home Base in its 1. Generation. The productId is not known by the according kernel module, this patch adds support for it. Signed-off-by:
Stefan Triller <github@stefantriller.de> Reviewed-by:
Frans Klaver <fransklaver@gmail.com> Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Hector Martin authored
BugLink: http://bugs.launchpad.net/bugs/1711557 commit fd1b8668 upstream. Add device id for D-Link DWM-222. Signed-off-by:
Hector Martin <marcan@marcan.st> Signed-off-by:
-
Weston Andros Adamson authored
BugLink: http://bugs.launchpad.net/bugs/1711557 commit 1feb2616 upstream. The client was freeing the nfs4_ff_layout_ds, but not the contained nfs4_ff_ds_version array. Signed-off-by:
Weston Andros Adamson <dros@primarydata.com> Signed-off-by:
-
Mateusz Jurczyk authored
BugLink: http://bugs.launchpad.net/bugs/1711557 commit 68227c03 upstream. Before the patch, the flock flag could remain uninitialized for the lifespan of the fuse_file allocation. Unless set to true in fuse_file_flock(), it would remain in an indeterminate state until read in an if statement in fuse_release_common(). This could consequently lead to taking an unexpected branch in the code. The bug was discovered by a runtime instrumentation designed to detect use of uninitialized memory in the kernel. Signed-off-by:
Mateusz Jurczyk <mjurczyk@google.com> Fixes: 37fb3a30 ("fuse: fix flock") Signed-off-by:
Miklos Szeredi <mszeredi@redhat.com> Signed-off-by:
-
Nicholas Bellinger authored
BugLink: http://bugs.launchpad.net/bugs/1711557 commit 978d13d6 upstream. This patch fixes a bug associated with iscsit_reset_np_thread() that can occur during parallel configfs rmdir of a single iscsi_np used across multiple iscsi-target instances, that would result in hung task(s) similar to below where configfs rmdir process context was blocked indefinately waiting for iscsi_np->np_restart_comp to finish: [ 6726.112076] INFO: task dcp_proxy_node_:15550 blocked for more than 120 seconds. [ 6726.119440] Tainted: G W O 4.1.26-3321 #2 [ 6726.125045] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 6726.132927] dcp_proxy_node_ D ffff8803f202bc88 0 15550 1 0x00000000 [ 6726.140058] ffff8803f202bc88 ffff88085c64d960 ffff88083b3b1ad0 ffff88087fffeb08 [ 6726.147593] ffff8803f202c000 7fffffffffffffff ffff88083f459c28 ffff88083b3b1ad0 [ 6726.155132] ffff88035373c100 ffff8803f202bca8 ffffffff8168ced2 ffff8803f202bcb8 [ 6726.162667] Call Trace: [ 6726.165150] [<ffffffff8168ced2>] schedule+0x32/0x80 [ 6726.170156] [<ffffffff8168f5b4>] schedule_timeout+0x214/0x290 [ 6726.176030] [<ffffffff810caef2>] ? __send_signal+0x52/0x4a0 [ 6726.181728] [<ffffffff8168d7d6>] wait_for_completion+0x96/0x100 [ 6726.187774] [<ffffffff810e7c80>] ? wake_up_state+0x10/0x10 [ 6726.193395] [<ffffffffa035d6e2>] iscsit_reset_np_thread+0x62/0xe0 [iscsi_target_mod] [ 6726.201278] [<ffffffffa0355d86>] iscsit_tpg_disable_portal_group+0x96/0x190 [iscsi_target_mod] [ 6726.210033] [<ffffffffa0363f7f>] lio_target_tpg_store_enable+0x4f/0xc0 [iscsi_target_mod] [ 6726.218351] [<ffffffff81260c5a>] configfs_write_file+0xaa/0x110 [ 6726.224392] [<ffffffff811ea364>] vfs_write+0xa4/0x1b0 [ 6726.229576] [<ffffffff811eb111>] SyS_write+0x41/0xb0 [ 6726.234659] [<ffffffff8169042e>] system_call_fastpath+0x12/0x71 It would happen because each iscsit_reset_np_thread() sets state to ISCSI_NP_THREAD_RESET, sends SIGINT, and then blocks waiting for completion on iscsi_np->np_restart_comp. However, if iscsi_np was active processing a login request and more than a single iscsit_reset_np_thread() caller to the same iscsi_np was blocked on iscsi_np->np_restart_comp, iscsi_np kthread process context in __iscsi_target_login_thread() would flush pending signals and only perform a single completion of np->np_restart_comp before going back to sleep within transport specific iscsit_transport->iscsi_accept_np code. To address this bug, add a iscsi_np->np_reset_count and update __iscsi_target_login_thread() to keep completing np->np_restart_comp until ->np_reset_count has reached zero. Reported-by:
Gary Guo <ghg@datera.io> Tested-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
-
Varun Prakash authored
BugLink: http://bugs.launchpad.net/bugs/1711557 commit ea8dc5b4 upstream. On receiving text request iscsi-target allocates buffer for payload in iscsit_handle_text_cmd() and assigns buffer pointer to cmd->text_in_ptr, this buffer is currently freed in iscsit_release_cmd(), if iscsi-target sets 'C' bit in text response then it will receive another text request from the initiator with ttt != 0xffffffff in this case iscsi-target will find cmd using itt and call iscsit_setup_text_cmd() which will set cmd->text_in_ptr to NULL without freeing previously allocated buffer. This patch fixes this issue by calling kfree(cmd->text_in_ptr) in iscsit_setup_text_cmd() before assigning NULL to it. For the first text request cmd->text_in_ptr is NULL as cmd is memset to 0 in iscsit_allocate_cmd(). Signed-off-by:
Varun Prakash <varun@chelsio.com> Signed-off-by:
-
