aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2019-12-11bpf, riscv: Limit to 33 tail callsPaul Chaignon1-2/+2
All BPF JIT compilers except RISC-V's and MIPS' enforce a 33-tail calls limit at runtime. In addition, a test was recently added, in tailcalls2, to check this limit. This patch updates the tail call limit in RISC-V's JIT compiler to allow 33 tail calls. I tested it using the above selftest on an emulated RISCV64. Fixes: 2353ecc6f91f ("bpf, riscv: add BPF JIT for RV64G") Reported-by: Mahshid Khezri <[email protected]> Signed-off-by: Paul Chaignon <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Acked-by: Björn Töpel <[email protected]> Acked-by: Martin KaFai Lau <[email protected]> Link: https://lore.kernel.org/bpf/966fe384383bf23a0ee1efe8d7291c78a3fb832b.1575916815.git.paul.chaignon@gmail.com
2019-12-11gpio: pca953x: Switch to bitops in IRQ callbacksAndy Shevchenko1-16/+10
Since we have driver converted to use bitmap API we must use traditional bit operations (set_bit(), clear_bit(), etc.) against it. Currently IRQ callbacks are missed in the conversion and thus broken. Let's fix it right here right now. Fixes: 35d13d94893f ("gpio: pca953x: convert to use bitmap API") Signed-off-by: Andy Shevchenko <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
2019-12-11gpiolib: fix up emulated open drain outputsRussell King1-0/+8
gpiolib has a corner case with open drain outputs that are emulated. When such outputs are outputting a logic 1, emulation will set the hardware to input mode, which will cause gpiod_get_direction() to report that it is in input mode. This is different from the behaviour with a true open-drain output. Unify the semantics here. Cc: <[email protected]> Suggested-by: Linus Walleij <[email protected]> Signed-off-by: Russell King <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
2019-12-11MAINTAINERS: Append missed file to the databaseAndy Shevchenko1-0/+1
When gpiolib.h internal header had been split to few, the commit 77cb907abe6c ("gpiolib: acpi: Split ACPI stuff to gpiolib-acpi.h") in particular missed the MAINTAINERS database update. Do it here. Fixes: 77cb907abe6c ("gpiolib: acpi: Split ACPI stuff to gpiolib-acpi.h") Signed-off-by: Andy Shevchenko <[email protected]> Acked-by: Mika Westerberg <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
2019-12-11arm64: dts: ls1028a: fix typo in TMU calibration dataMichael Walle1-1/+1
The temperature sensor may jump backwards because there is a wrong calibration value. Both values have to be monotonically increasing. Fix it. This was tested on a custom board. Fixes: 571cebfe8e2b ("arm64: dts: ls1028a: Add Thermal Monitor Unit node") Signed-off-by: Michael Walle <[email protected]> Acked-by: Tang Yuantian <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2019-12-11gpio: xgs-iproc: remove __exit annotation for iproc_gpio_removeArnd Bergmann1-1/+1
When built into the kernel, the driver causes a link problem: `iproc_gpio_remove' referenced in section `.data' of drivers/gpio/gpio-xgs-iproc.o: defined in discarded section `.exit.text' of drivers/gpio/gpio-xgs-iproc.o Remove the incorrect annotation. Fixes: 6a41b6c5fc20 ("gpio: Add xgs-iproc driver") Signed-off-by: Arnd Bergmann <[email protected]> Reviewed-by: Chris Packham <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
2019-12-11gpio: aspeed: avoid return type warningArnd Bergmann1-1/+1
gcc has a hard time tracking whether BUG_ON(1) ends execution or not: drivers/gpio/gpio-aspeed-sgpio.c: In function 'bank_reg': drivers/gpio/gpio-aspeed-sgpio.c:112:1: error: control reaches end of non-void function [-Werror=return-type] Use the simpler BUG() that gcc knows cannot continue. Fixes: f8b410e3695a ("gpio: aspeed-sgpio: Rename and add Kconfig/Makefile") Signed-off-by: Arnd Bergmann <[email protected]> Acked-by: Andrew Jeffery <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
2019-12-11gpio: mockup: Fix usage of new GPIO_LINE_DIRECTIONKent Gibson1-2/+5
Restore the external behavior of gpio-mockup to what it was prior to the change to using GPIO_LINE_DIRECTION. Fixes: e42615ec233b ("gpio: Use new GPIO_LINE_DIRECTION") Signed-off-by: Kent Gibson <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
2019-12-11drm/i915/gvt: use vgpu lock for active state settingZhenyu Wang1-2/+2
Need to align with deactivate, should only use vgpu's lock for active state setting instead of gvt lock. Fixes: f25a49ab8ab9 ("drm/i915/gvt: Use vgpu_lock to protect per vgpu access") Cc: Colin Xu <[email protected]> Reviewed-by: Colin Xu <[email protected]> Signed-off-by: Zhenyu Wang <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-12-11USB: Fix incorrect DMA allocations for local memory pool driversFredrik Noring2-22/+23
Fix commit 7b81cb6bddd2 ("usb: add a HCD_DMA flag instead of guestimating DMA capabilities") where local memory USB drivers erroneously allocate DMA memory instead of pool memory, causing OHCI Unrecoverable Error, disabled HC died; cleaning up The order between hcd_uses_dma() and hcd->localmem_pool is now arranged as in hcd_buffer_alloc() and hcd_buffer_free(), with the test for hcd->localmem_pool placed first. As an alternative, one might consider adjusting hcd_uses_dma() with static inline bool hcd_uses_dma(struct usb_hcd *hcd) { - return IS_ENABLED(CONFIG_HAS_DMA) && (hcd->driver->flags & HCD_DMA); + return IS_ENABLED(CONFIG_HAS_DMA) && + (hcd->driver->flags & HCD_DMA) && + (hcd->localmem_pool == NULL); } One can also consider unsetting HCD_DMA for local memory pool drivers. Fixes: 7b81cb6bddd2 ("usb: add a HCD_DMA flag instead of guestimating DMA capabilities") Cc: stable <[email protected]> Signed-off-by: Fredrik Noring <[email protected]> Link: https://lore.kernel.org/r/20191210172905.GA52526@sx9 Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-12-11i2c: add helper to check if a client has a driver attachedWolfram Sang1-0/+5
As a preparation for an API conversion, factor out something frequently used in the media subsystem. As an improvement, it bails out on both, NULL and ERRPTR to handle the old and new API. Signed-off-by: Wolfram Sang <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2019-12-11clk: imx: pll14xx: fix clk_pll14xx_wait_lockPeng Fan1-1/+1
The usage of readl_poll_timeout is wrong, the 3rd parameter(cond) should be "val & LOCK_STATUS" not "val & LOCK_TIMEOUT_US", It is not check whether the pll locked, LOCK_STATUS reflects the mask, not LOCK_TIMEOUT_US. Fixes: 8646d4dcc7fb ("clk: imx: Add PLLs driver for imx8mm soc") Cc: <[email protected]> Reviewed-by: Abel Vesa <[email protected]> Signed-off-by: Peng Fan <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2019-12-11ARM: imx: Correct ocotp id for serial number support of i.MX6ULL/ULZ SoCsChristoph Niedermaier1-2/+2
After the commit 8267ff89b713 ("ARM: imx: Add serial number support for i.MX6/7 SoCs") the kernel doesn't start on i.MX6ULL/ULZ SoC. Tested on next-20191205. For i.MX6ULL/ULZ the variable "ocotp_compat" is set to "fsl,imx6ul-ocotp", but with commit ffbc34bf0e9c ("nvmem: imx-ocotp: Implement i.MX6ULL/ULZ support") and commit f243bc821ee3 ("ARM: dts: imx6ull: Fix i.MX6ULL/ULZ ocotp compatible") the value "fsl,imx6ull-ocotp" is already defined and set in device tree... By setting "ocotp_compat" to "fsl,imx6ull-ocotp" the kernel does boot. Fixes: 8267ff89b713 ("ARM: imx: Add serial number support for i.MX6/7 SoCs") Signed-off-by: Christoph Niedermaier <[email protected]> Reviewed-by: Fabio Estevam <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2019-12-11sched/cputime, proc/stat: Fix incorrect guest nice cpustat valueFlavio Leitner1-2/+2
The value being used for guest_nice should be CPUTIME_GUEST_NICE and not CPUTIME_USER. Fixes: 26dae145a76c ("procfs: Use all-in-one vtime aware kcpustat accessor") Signed-off-by: Flavio Leitner <[email protected]> Signed-off-by: Frederic Weisbecker <[email protected]> Cc: Peter Zijlstra <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-12-11ALSA: hda/realtek - Line-out jack doesn't work on a Dell AIOHui Wang1-5/+3
After applying the fixup ALC274_FIXUP_DELL_AIO_LINEOUT_VERB, the Line-out jack works well. And instead of adding a new set of pin definition in the pin_fixup_tbl, we put a more generic matching entry in the fallback_pin_fixup_tbl. Cc: <[email protected]> Signed-off-by: Hui Wang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2019-12-10net: ena: fix napi handler misbehavior when the napi budget is zeroNetanel Belgazal1-3/+7
In netpoll the napi handler could be called with budget equal to zero. Current ENA napi handler doesn't take that into consideration. The napi handler handles Rx packets in a do-while loop. Currently, the budget check happens only after decrementing the budget, therefore the napi handler, in rare cases, could run over MAX_INT packets. In addition to that, this moves all budget related variables to int calculation and stop mixing u32 to avoid ambiguity Fixes: 1738cd3ed342 ("net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)") Signed-off-by: Netanel Belgazal <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-12-10Merge branch 'tipc-fix-some-issues'David S. Miller4-126/+215
Tuong Lien says: ==================== tipc: fix some issues This series consists of some bug-fixes for TIPC. ==================== Signed-off-by: David S. Miller <[email protected]>
2019-12-10tipc: fix use-after-free in tipc_disc_rcv()Tuong Lien1-3/+3
In the function 'tipc_disc_rcv()', the 'msg_peer_net_hash()' is called to read the header data field but after the message skb has been freed, that might result in a garbage value... This commit fixes it by defining a new local variable to store the data first, just like the other header fields' handling. Fixes: f73b12812a3d ("tipc: improve throughput between nodes in netns") Acked-by: Jon Maloy <[email protected]> Signed-off-by: Tuong Lien <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-12-10tipc: fix retrans failure due to wrong destinationTuong Lien1-14/+18
When a user message is sent, TIPC will check if the socket has faced a congestion at link layer. If that happens, it will make a sleep to wait for the congestion to disappear. This leaves a gap for other users to take over the socket (e.g. multi threads) since the socket is released as well. Also, in case of connectionless (e.g. SOCK_RDM), user is free to send messages to various destinations (e.g. via 'sendto()'), then the socket's preformatted header has to be updated correspondingly prior to the actual payload message building. Unfortunately, the latter action is done before the first action which causes a condition issue that the destination of a certain message can be modified incorrectly in the middle, leading to wrong destination when that message is built. Consequently, when the message is sent to the link layer, it gets stuck there forever because the peer node will simply reject it. After a number of retransmission attempts, the link is eventually taken down and the retransmission failure is reported. This commit fixes the problem by rearranging the order of actions to prevent the race condition from occurring, so the message building is 'atomic' and its header will not be modified by anyone. Fixes: 365ad353c256 ("tipc: reduce risk of user starvation during link congestion") Acked-by: Jon Maloy <[email protected]> Signed-off-by: Tuong Lien <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-12-10tipc: fix potential hanging after b/rcast changingTuong Lien1-9/+15
In commit c55c8edafa91 ("tipc: smooth change between replicast and broadcast"), we allow instant switching between replicast and broadcast by sending a dummy 'SYN' packet on the last used link to synchronize packets on the links. The 'SYN' message is an object of link congestion also, so if that happens, a 'SOCK_WAKEUP' will be scheduled to be sent back to the socket... However, in that commit, we simply use the same socket 'cong_link_cnt' counter for both the 'SYN' & normal payload message sending. Therefore, if both the replicast & broadcast links are congested, the counter will be not updated correctly but overwritten by the latter congestion. Later on, when the 'SOCK_WAKEUP' messages are processed, the counter is reduced one by one and eventually overflowed. Consequently, further activities on the socket will only wait for the false congestion signal to disappear but never been met. Because sending the 'SYN' message is vital for the mechanism, it should be done anyway. This commit fixes the issue by marking the message with an error code e.g. 'TIPC_ERR_NO_PORT', so its sending should not face a link congestion, there is no need to touch the socket 'cong_link_cnt' either. In addition, in the event of any error (e.g. -ENOBUFS), we will purge the entire payload message queue and make a return immediately. Fixes: c55c8edafa91 ("tipc: smooth change between replicast and broadcast") Acked-by: Jon Maloy <[email protected]> Signed-off-by: Tuong Lien <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-12-10tipc: fix name table rbtree issuesTuong Lien1-100/+179
The current rbtree for service ranges in the name table is built based on the 'lower' & 'upper' range values resulting in a flaw in the rbtree searching. Some issues have been observed in case of range overlapping: Case #1: unable to withdraw a name entry: After some name services are bound, all of them are withdrawn by user but one remains in the name table forever. This corrupts the table and that service becomes dummy i.e. no real port. E.g. / {22, 22} / / ---> {10, 50} / \ / \ {10, 30} {20, 60} The node {10, 30} cannot be removed since the rbtree searching stops at the node's ancestor i.e. {10, 50}, so starting from it will never reach the finding node. Case #2: failed to send data in some cases: E.g. Two service ranges: {20, 60}, {10, 50} are bound. The rbtree for this service will be one of the two cases below depending on the order of the bindings: {20, 60} {10, 50} <-- / \ / \ / \ / \ {10, 50} NIL <-- NIL {20, 60} (a) (b) Now, try to send some data to service {30}, there will be two results: (a): Failed, no route to host. (b): Ok. The reason is that the rbtree searching will stop at the pointing node as shown above. Case #3: Same as case #2b above but if the data sending's scope is local and the {10, 50} is published by a peer node, then it will result in 'no route to host' even though the other {20, 60} is for example on the local node which should be able to get the data. The issues are actually due to the way we built the rbtree. This commit fixes it by introducing an additional field to each node - named 'max', which is the largest 'upper' of that node subtree. The 'max' value for each subtrees will be propagated correctly whenever a node is inserted/ removed or the tree is rebalanced by the augmented rbtree callbacks. By this way, we can change the rbtree searching appoarch to solve the issues above. Another benefit from this is that we can now improve the searching for a next range matching e.g. in case of multicast, so get rid of the unneeded looping over all nodes in the tree. Acked-by: Jon Maloy <[email protected]> Signed-off-by: Tuong Lien <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-12-10Merge branch 'bnxt_en-Error-recovery-fixes'David S. Miller6-60/+146
Michael Chan says: ==================== bnxt_en: Error recovery fixes. This patch series contains fixes mostly for the error recovery feature and related areas. Please queue the series for -stable also. Thanks. ==================== Signed-off-by: David S. Miller <[email protected]>
2019-12-10bnxt_en: Add missing devlink health reporters for VFs.Vasundhara Volam2-14/+22
The VF driver also needs to create the health reporters since VFs are also involved in firmware reset and recovery. Modify bnxt_dl_register() and bnxt_dl_unregister() so that they can be called by the VFs to register/unregister devlink. Only the PF will register the devlink parameters. With devlink registered, we can now create the health reporters on the VFs. Fixes: 6763c779c2d8 ("bnxt_en: Add new FW devlink_health_reporter") Signed-off-by: Vasundhara Volam <[email protected]> Signed-off-by: Michael Chan <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-12-10bnxt_en: Fix the logic that creates the health reporters.Vasundhara Volam3-21/+56
Fix the logic to properly check the fw capabilities and create the devlink health reporters only when needed. The current code creates the reporters unconditionally as long as bp->fw_health is valid, and that's not correct. Call bnxt_dl_fw_reporters_create() directly from the init and reset code path instead of from bnxt_dl_register(). This allows the reporters to be adjusted when capabilities change. The same applies to bnxt_dl_fw_reporters_destroy(). Fixes: 6763c779c2d8 ("bnxt_en: Add new FW devlink_health_reporter") Signed-off-by: Vasundhara Volam <[email protected]> Signed-off-by: Michael Chan <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-12-10bnxt_en: Remove unnecessary NULL checks for fw_healthVasundhara Volam2-9/+3
After fixing the allocation of bp->fw_health in the previous patch, the driver will not go through the fw reset and recovery code paths if bp->fw_health allocation fails. So we can now remove the unnecessary NULL checks. Signed-off-by: Vasundhara Volam <[email protected]> Signed-off-by: Michael Chan <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-12-10bnxt_en: Fix bp->fw_health allocation and free logic.Vasundhara Volam1-10/+26
bp->fw_health needs to be allocated for either the firmware initiated reset feature or the driver initiated error recovery feature. The current code is not allocating bp->fw_health for all the necessary cases. This patch corrects the logic to allocate bp->fw_health correctly when needed. If allocation fails, we clear the feature flags. We also add the the missing kfree(bp->fw_health) when the driver is unloaded. If we get an async reset message from the firmware, we also need to make sure that we have a valid bp->fw_health before proceeding. Fixes: 07f83d72d238 ("bnxt_en: Discover firmware error recovery capabilities.") Signed-off-by: Vasundhara Volam <[email protected]> Signed-off-by: Michael Chan <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-12-10bnxt_en: Return error if FW returns more data than dump lengthVasundhara Volam2-8/+34
If any change happened in the configuration of VF in VM while collecting live dump, there could be a race and firmware can return more data than allocated dump length. Fix it by keeping track of the accumulated core dump length copied so far and abort the copy with error code if the next chunk of core dump will exceed the original dump length. Fixes: 6c5657d085ae ("bnxt_en: Add support for ethtool get dump.") Signed-off-by: Vasundhara Volam <[email protected]> Signed-off-by: Michael Chan <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-12-10bnxt_en: Free context memory in the open path if firmware has been reset.Michael Chan1-0/+3
This will trigger new context memory to be rediscovered and allocated during the re-probe process after a firmware reset. Without this, the newly reset firmware does not have valid context memory and the driver will eventually fail to allocate some resources. Fixes: ec5d31e3c15d ("bnxt_en: Handle firmware reset status during IF_UP.") Signed-off-by: Michael Chan <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-12-10bnxt_en: Fix MSIX request logic for RDMA driver.Michael Chan1-2/+6
The logic needs to check both bp->total_irqs and the reserved IRQs in hw_resc->resv_irqs if applicable and see if both are enough to cover the L2 and RDMA requested vectors. The current code is only checking bp->total_irqs and can fail in some code paths, such as the TX timeout code path with the RDMA driver requesting vectors after recovery. In this code path, we have not reserved enough MSIX resources for the RDMA driver yet. Fixes: 75720e6323a1 ("bnxt_en: Keep track of reserved IRQs.") Signed-off-by: Michael Chan <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-12-10io_uring: add sockets to list of files that support non-blocking issueJens Axboe1-2/+4
In chasing a performance issue between using IORING_OP_RECVMSG and IORING_OP_READV on sockets, tracing showed that we always punt the socket reads to async offload. This is due to io_file_supports_async() not checking for S_ISSOCK on the inode. Since sockets supports the O_NONBLOCK (or MSG_DONTWAIT) flag just fine, add sockets to the list of file types that we can do a non-blocking issue to. Signed-off-by: Jens Axboe <[email protected]>
2019-12-10net: make socket read/write_iter() honor IOCB_NOWAITJens Axboe1-2/+2
The socket read/write helpers only look at the file O_NONBLOCK. not the iocb IOCB_NOWAIT flag. This breaks users like preadv2/pwritev2 and io_uring that rely on not having the file itself marked nonblocking, but rather the iocb itself. Cc: [email protected] Acked-by: David Miller <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2019-12-10io_uring: only hash regular files for async work executionJens Axboe1-1/+3
We hash regular files to avoid having multiple threads hammer on the inode mutex, but it should not be needed on other types of files (like sockets). Signed-off-by: Jens Axboe <[email protected]>
2019-12-10io_uring: run next sqe inline if possibleJens Axboe1-4/+11
One major use case of linked commands is the ability to run the next link inline, if at all possible. This is done correctly for async offload, but somewhere along the line we lost the ability to do so when we were able to complete a request without having to punt it. Ensure that we do so correctly. Signed-off-by: Jens Axboe <[email protected]>
2019-12-10io_uring: don't dynamically allocate poll dataJens Axboe1-16/+11
This essentially reverts commit e944475e6984. For high poll ops workloads, like TAO, the dynamic allocation of the wait_queue entry for IORING_OP_POLL_ADD adds considerable extra overhead. Go back to embedding the wait_queue_entry, but keep the usage of wait->private for the pointer stashing. Signed-off-by: Jens Axboe <[email protected]>
2019-12-10io_uring: deferred send/recvmsg should assign iovJens Axboe1-2/+2
Don't just assign it from the main call path, that can miss the case when we're called from issue deferral. Signed-off-by: Jens Axboe <[email protected]>
2019-12-10io_uring: sqthread should grab ctx->uring_lock for submissionsJens Axboe1-5/+2
We use the mutex to guard against registered file updates, for instance. Ensure we're safe in accessing that state against concurrent updates. Signed-off-by: Jens Axboe <[email protected]>
2019-12-10io-wq: briefly spin for new work after finishing workJens Axboe2-5/+26
To avoid going to sleep only to get woken shortly thereafter, spin briefly for new work upon completion of work. Signed-off-by: Jens Axboe <[email protected]>
2019-12-10io-wq: remove worker->wait waitqueueJens Axboe1-8/+2
We only have one cases of using the waitqueue to wake the worker, the rest are using wake_up_process(). Since we can save some cycles not fiddling with the waitqueue io_wqe_worker(), switch the work activation to task wakeup and get rid of the now unused wait_queue_head_t in struct io_worker. Signed-off-by: Jens Axboe <[email protected]>
2019-12-10io_uring: allow unbreakable linksJens Axboe2-38/+47
Some commands will invariably end in a failure in the sense that the completion result will be less than zero. One such example is timeouts that don't have a completion count set, they will always complete with -ETIME unless cancelled. For linked commands, we sever links and fail the rest of the chain if the result is less than zero. Since we have commands where we know that will happen, add IOSQE_IO_HARDLINK as a stronger link that doesn't sever regardless of the completion result. Note that the link will still sever if we fail submitting the parent request, hard links are only resilient in the presence of completion results for requests that did submit correctly. Cc: [email protected] # v5.4 Reviewed-by: Pavel Begunkov <[email protected]> Reported-by: 李通洲 <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2019-12-11Revert "locking/mutex: Complain upon mutex API misuse in IRQ contexts"Davidlohr Bueso1-4/+0
This ended up causing some noise in places such as rxrpc running in softirq. The warning is misleading in this case as the mutex trylock and unlock operations are done within the same context; and therefore we need not worry about the PI-boosting issues that comes along with no single-owner lock guarantees. While we don't want to support this in mutexes, there is no way out of this yet; so lets get rid of the WARNs for now, as it is only fair to code that has historically relied on non-preemptible softirq guarantees. In addition, changing the lock type is also unviable: exclusive rwsems have the same issue (just not the WARN_ON) and counting semaphores would introduce a performance hit as mutexes are a lot more optimized. This reverts: a0855d24fc22: ("locking/mutex: Complain upon mutex API misuse in IRQ contexts") Fixes: a0855d24fc22: ("locking/mutex: Complain upon mutex API misuse in IRQ contexts") Signed-off-by: Davidlohr Bueso <[email protected]> Tested-by: David Howells <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-12-10cpuidle: Fix cpuidle_driver_state_disabled()Rafael J. Wysocki1-0/+10
It turns out that cpuidle_driver_state_disabled() can be called before registering the cpufreq driver on some platforms, which was not expected when it was introduced and which leads to a NULL pointer dereference when trying to walk the CPUs associated with the given cpuidle driver. Fix the problem by making cpuidle_driver_state_disabled() check if the driver's mask of CPUs associated with it is present and to set CPUIDLE_FLAG_UNUSABLE for the given idle state in the driver's states list if that is not the case to cause __cpuidle_register_device() to set CPUIDLE_STATE_DISABLED_BY_DRIVER for that state for all cpuidle devices registered by it later. Fixes: cbda56d5fefc ("cpuidle: Introduce cpuidle_driver_state_disabled() for driver quirks") Reported-by: Daniel Lezcano <[email protected]> Tested-by: Daniel Lezcano <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2019-12-10drm/amd/display: include linux/slab.h where neededArnd Bergmann1-0/+2
Calling kzalloc() and related functions requires the linux/slab.h header to be included: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_resource.c: In function 'dcn21_ipp_create': drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_resource.c:679:3: error: implicit declaration of function 'kzalloc'; did you mean 'd_alloc'? [-Werror=implicit-function-declaration] kzalloc(sizeof(struct dcn10_ipp), GFP_KERNEL); A lot of other headers also miss a direct include in this file, but this is the only one that causes a problem for now. Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-12-10i2c: fix header file kernel-doc warningRandy Dunlap1-0/+1
Fix kernel-doc warning in <linux/i2c.h>. ../include/linux/i2c.h:337: warning: Function parameter or member 'init_irq' not described in 'i2c_client' Signed-off-by: Randy Dunlap <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2019-12-10i2c: remove i2c_new_dummy() APIWolfram Sang2-29/+0
All in-kernel users have been converted to {devm_}i2c_new_dummy_device(). Remove the old API. Signed-off-by: Wolfram Sang <[email protected]> Reviewed-by: Niklas Söderlund <[email protected]> Tested-by: Luca Ceresoli <[email protected]> Reviewed-by: Luca Ceresoli <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2019-12-10drm/amd/display: fix undefined struct member referenceArnd Bergmann1-0/+2
An initialization was added for two optional struct members. One of these is always present in the dcn20_resource file, but the other one depends on CONFIG_DRM_AMD_DC_DSC_SUPPORT and causes a build failure if that is missing: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_resource.c:926:14: error: excess elements in struct initializer [-Werror] .num_dsc = 5, Add another #ifdef around the assignment. Fixes: c3d03c5a196f ("drm/amd/display: Include num_vmid and num_dsc within NV14's resource caps") Reviewed-by: Zhan Liu <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2019-12-10sh: kgdb: Mark expected switch fall-throughsKuninori Morimoto1-0/+1
Mark switch cases where we are expecting to fall through. This patch fixes the following error: LINUX/arch/sh/kernel/kgdb.c: In function 'kgdb_arch_handle_exception': LINUX/arch/sh/kernel/kgdb.c:267:6: error: this statement may fall through [-Werror=implicit-fallthrough=] if (kgdb_hex2long(&ptr, &addr)) ^ LINUX/arch/sh/kernel/kgdb.c:269:2: note: here case 'D': ^~~~ Signed-off-by: Kuninori Morimoto <[email protected]> Acked-by: Daniel Thompson <[email protected]> Signed-off-by: Gustavo A. R. Silva <[email protected]>
2019-12-10ARM: dts: bcm283x: Fix critical trip pointStefan Wahren1-1/+1
During definition of the CPU thermal zone of BCM283x SoC family there was a misunderstanding of the meaning "criticial trip point" and the thermal throttling range of the VideoCore firmware. The latter one takes effect when the core temperature is at least 85 degree celsius or higher So the current critical trip point doesn't make sense, because the thermal shutdown appears before the firmware has a chance to throttle the ARM core(s). Fix these unwanted shutdowns by increasing the critical trip point to a value which shouldn't be reached with working thermal throttling. Fixes: 0fe4d2181cc4 ("ARM: dts: bcm283x: Add CPU thermal zone with 1 trip point") Signed-off-by: Stefan Wahren <[email protected]> Signed-off-by: Florian Fainelli <[email protected]>
2019-12-10ftrace: Fix function_graph tracer interaction with BPF trampolineAlexei Starovoitov4-26/+21
Depending on type of BPF programs served by BPF trampoline it can call original function. In such case the trampoline will skip one stack frame while returning. That will confuse function_graph tracer and will cause crashes with bad RIP. Teach graph tracer to skip functions that have BPF trampoline attached. Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Steven Rostedt (VMware) <[email protected]>
2019-12-10tracing: remove set but not used variable 'buffer'YueHaibing1-2/+0
kernel/trace/trace_events_inject.c: In function trace_inject_entry: kernel/trace/trace_events_inject.c:20:22: warning: variable buffer set but not used [-Wunused-but-set-variable] It is never used, so remove it. Link: http://lkml.kernel.org/r/[email protected] Reported-by: Hulk Robot <[email protected]> Acked-by: Cong Wang <[email protected]> Signed-off-by: YueHaibing <[email protected]> Signed-off-by: Steven Rostedt (VMware) <[email protected]>
2019-12-10module: Remove accidental change of module_enable_x()Steven Rostedt (VMware)1-5/+1
When pulling in Divya Indi's patch, I made a minor fix to remove unneeded braces. I commited my fix up via "git commit -a --amend". Unfortunately, I didn't realize I had some changes I was testing in the module code, and those changes were applied to Divya's patch as well. This reverts the accidental updates to the module code. Cc: Jessica Yu <[email protected]> Cc: Divya Indi <[email protected]> Reported-by: Peter Zijlstra <[email protected]> Fixes: e585e6469d6f ("tracing: Verify if trace array exists before destroying it.") Signed-off-by: Steven Rostedt (VMware) <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.