aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-08-25io_uring: ensure read requests go through -ERESTART* transformationJens Axboe1-1/+2
We need to call kiocb_done() for any ret < 0 to ensure that we always get the proper -ERESTARTSYS (and friends) transformation done. At some point this should be tied into general error handling, so we can get rid of the various (mostly network) related commands that check and perform this substitution. Signed-off-by: Jens Axboe <[email protected]>
2020-08-25Merge tag 'libnvdimm-fix-v5.9-rc3' of ↵Linus Torvalds2-0/+7
git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm Pull libnvdimm fixes from Vishal Verma: "A couple of minor fixes for things merged in 5.9-rc1. One is an out-of-bounds access caught by KASAN, and the second is a tweak to some overzealous logging about dax support even for traditional block devices which was unnecessary" * tag 'libnvdimm-fix-v5.9-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm: dax: do not print error message for non-persistent memory block device libnvdimm: KASAN: global-out-of-bounds Read in internal_create_group
2020-08-25io_uring: don't use poll handler if file can't be nonblocking read/writtenJens Axboe1-1/+9
There's no point in using the poll handler if we can't do a nonblocking IO attempt of the operation, since we'll need to go async anyway. In fact this is actively harmful, as reading from eg pipes won't return 0 to indicate EOF. Cc: [email protected] # v5.7+ Reported-by: Benedikt Ames <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2020-08-25Merge branch 'for-linus' of ↵Linus Torvalds8-42/+49
git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid Pull HID fixes from Jiri Kosina: - regression fix / revert of a commit that intended to reduce probing delay by ~50ms, but introduced a race that causes quite a few devices not to enumerate, or get stuck on first IRQ - buffer overflow fix in hiddev, from Peilin Ye * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid: Revert "HID: usbhid: do not sleep when opening device" HID: hiddev: Fix slab-out-of-bounds write in hiddev_ioctl_usage() HID: quirks: Always poll three more Lenovo PixArt mice HID: i2c-hid: Always sleep 60ms after I2C_HID_PWR_ON commands HID: macally: Constify macally_id_table HID: cougar: Constify cougar_id_table
2020-08-25io_uring: fix imbalanced sqo_mm accountingJens Axboe1-7/+3
We do the initial accounting of locked_vm and pinned_vm before we have setup ctx->sqo_mm, which means we can end up having not accounted the memory at setup time, but still decrement it when we exit. This causes an imbalance in the accounting. Setup ctx->sqo_mm earlier in io_uring_create(), before we do the first accounting of mm->{locked,pinned}_vm. This also unifies the state grabbing for the ctx, and eliminates a failure case in io_sq_offload_start(). Fixes: f74441e6311a ("io_uring: account locked memory before potential error case") Reported-by: Robert M. Muncrief <[email protected]> Reported-by: Niklas Schnelle <[email protected]> Tested-by: Niklas Schnelle <[email protected]> Tested-by: Robert M. Muncrief <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2020-08-25PM: sleep: core: Fix the handling of pending runtime resume requestsRafael J. Wysocki1-6/+10
It has been reported that system-wide suspend may be aborted in the absence of any wakeup events due to unforseen interactions of it with the runtume PM framework. One failing scenario is when there are multiple devices sharing an ACPI power resource and runtime-resume needs to be carried out for one of them during system-wide suspend (for example, because it needs to be reconfigured before the whole system goes to sleep). In that case, the runtime-resume of that device involves turning the ACPI power resource "on" which in turn causes runtime-resume requests to be queued up for all of the other devices sharing it. Those requests go to the runtime PM workqueue which is frozen during system-wide suspend, so they are not actually taken care of until the resume of the whole system, but the pm_runtime_barrier() call in __device_suspend() sees them and triggers system wakeup events for them which then cause the system-wide suspend to be aborted if wakeup source objects are in active use. Of course, the logic that leads to triggering those wakeup events is questionable in the first place, because clearly there are cases in which a pending runtime resume request for a device is not connected to any real wakeup events in any way (like the one above). Moreover, it is racy, because the device may be resuming already by the time the pm_runtime_barrier() runs and so if the driver doesn't take care of signaling the wakeup event as appropriate, it will be lost. However, if the driver does take care of that, the extra pm_wakeup_event() call in the core is redundant. Accordingly, drop the conditional pm_wakeup_event() call fron __device_suspend() and make the latter call pm_runtime_barrier() alone. Also modify the comment next to that call to reflect the new code and extend it to mention the need to avoid unwanted interactions between runtime PM and system-wide device suspend callbacks. Fixes: 1e2ef05bb8cf8 ("PM: Limit race conditions between runtime PM and system sleep (v2)") Signed-off-by: Rafael J. Wysocki <[email protected]> Acked-by: Alan Stern <[email protected]> Reported-by: Utkarsh H Patel <[email protected]> Tested-by: Utkarsh H Patel <[email protected]> Tested-by: Pengfei Xu <[email protected]> Cc: All applicable <[email protected]>
2020-08-25ACPI: OSL: Prevent acpi_release_memory() from returning too earlyRafael J. Wysocki1-2/+17
After commit 1757659d022b ("ACPI: OSL: Implement deferred unmapping of ACPI memory") in some cases acpi_release_memory() may return before the target memory mappings actually go away, because they are released asynchronously now. Prevent it from returning prematurely by making it wait for the next RCU grace period to elapse, for all of the RCU callbacks to complete and for all of the scheduled work items to be flushed before returning. Fixes: 1757659d022b ("ACPI: OSL: Implement deferred unmapping of ACPI memory") Reported-by: Kenneth R. Crudup <[email protected]> Tested-by: Kenneth R. Crudup <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Reviewed-by: Heikki Krogerus <[email protected]> Reviewed-by: Mika Westerberg <[email protected]>
2020-08-25usb: typec: tcpm: Fix Fix source hard reset response for TDA 2.3.1.1 and TDA ↵Badhri Jagan Sridharan1-3/+25
2.3.1.2 failures The patch addresses the compliance test failures while running TDA 2.3.1.1 and TDA 2.3.1.2 of the "PD Communications Engine USB PD Compliance MOI" test plan published in https://www.usb.org/usbc. For a product to be Type-C compliant, it's expected that these tests are run on usb.org certified Type-C compliance tester as mentioned in https://www.usb.org/usbc. While the purpose of TDA 2.3.1.1 and TDA 2.3.1.2 is to verify that the static and dynamic electrical capabilities of a Source meet the requirements for each PDO offered, while doing so, the tests also monitor that the timing of the VBUS waveform versus the messages meets the requirements for Hard Reset defined in PROT-PROC-HR-TSTR as mentioned in step 11 of TDA.2.3.1.1 and step 15 of TDA.2.3.1.2. TDB.2.2.13.1: PROT-PROC-HR-TSTR Procedure and Checks for Tester Originated Hard Reset Purpose: To perform the appropriate protocol checks relating to any circumstance in which the Hard Reset signal is sent by the Tester. UUT is behaving as source: The Tester sends a Hard Reset signal. 1. Check VBUS stays within present valid voltage range for tPSHardReset min (25ms) after last bit of Hard Reset signal. [PROT_PROC_HR_TSTR_1] 2. Check that VBUS starts to fall below present valid voltage range by tPSHardReset max (35ms). [PROT_PROC_HR_TSTR_2] 3. Check that VBUS reaches vSafe0V within tSafe0v max (650 ms). [PROT_PROC_HR_TSTR_3] 4. Check that VBUS starts rising to vSafe5V after a delay of tSrcRecover (0.66s - 1s) from reaching vSafe0V. [PROT_PROC_HR_TSTR_4] 5. Check that VBUS reaches vSafe5V within tSrcTurnOn max (275ms) of rising above vSafe0v max (0.8V). [PROT_PROC_HR_TSTR_5] Power Delivery Compliance Plan 139 6. Check that Source Capabilities are finished sending within tFirstSourceCap max (250ms) of VBUS reaching vSafe5v min. [PROT_PROC_HR_TSTR_6]. This is in line with 7.1.5 Response to Hard Resets of the USB Power Delivery Specification Revision 3.0, Version 1.2, "Hard Reset Signaling indicates a communication failure has occurred and the Source Shall stop driving VCONN, Shall remove Rp from the VCONN pin and Shall drive VBUS to vSafe0V as shown in Figure 7-9. The USB connection May reset during a Hard Reset since the VBUS voltage will be less than vSafe5V for an extended period of time. After establishing the vSafe0V voltage condition on VBUS, the Source Shall wait tSrcRecover before re-applying VCONN and restoring VBUS to vSafe5V. A Source Shall conform to the VCONN timing as specified in [USB Type-C 1.3]." With the above guidelines from the spec in mind, TCPM does not turn off VCONN while entering SRC_HARD_RESET_VBUS_OFF. The patch makes TCPM turn off VCONN while entering SRC_HARD_RESET_VBUS_OFF and turn it back on while entering SRC_HARD_RESET_VBUS_ON along with vbus instead of having VCONN on through hardreset. Also, the spec clearly states that "After establishing the vSafe0V voltage condition on VBUS", the Source Shall wait tSrcRecover before re-applying VCONN and restoring VBUS to vSafe5V. TCPM does not conform to this requirement. If the TCPC driver calls tcpm_vbus_change with vbus off signal, TCPM right away enters SRC_HARD_RESET_VBUS_ON without waiting for tSrcRecover. For TCPC's which are buggy/does not call tcpm_vbus_change, TCPM assumes that the vsafe0v is instantaneous as TCPM only waits tSrcRecover instead of waiting for tSafe0v + tSrcRecover. This patch also fixes this behavior by making sure that TCPM waits for tSrcRecover before transitioning into SRC_HARD_RESET_VBUS_ON when tcpm_vbus_change is called by TCPC. When TCPC does not call tcpm_vbus_change, TCPM assumes the worst case i.e. tSafe0v + tSrcRecover before transitioning into SRC_HARD_RESET_VBUS_ON. Signed-off-by: Badhri Jagan Sridharan <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Reviewed-by: Heikki Krogerus <[email protected]> Cc: stable <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-08-25USB: PHY: JZ4770: Fix static checker warning.周琰杰 (Zhou Yanjie)1-0/+1
The commit 2a6c0b82e651 ("USB: PHY: JZ4770: Add support for new Ingenic SoCs.") introduced the initialization function for different chips, but left the relevant code involved in the resetting process in the original function, resulting in uninitialized variable calls. Fixes: 2a6c0b82e651 ("USB: PHY: JZ4770: Add support for new Ingenic SoCs."). Signed-off-by: 周琰杰 (Zhou Yanjie) <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-08-25USB: gadget: f_ncm: add bounds checks to ncm_unwrap_ntb()Brooke Basile1-12/+69
Some values extracted by ncm_unwrap_ntb() could possibly lead to several different out of bounds reads of memory. Specifically the values passed to netdev_alloc_skb_ip_align() need to be checked so that memory is not overflowed. Resolve this by applying bounds checking to a number of different indexes and lengths of the structure parsing logic. Reported-by: Ilja Van Sprundel <[email protected]> Signed-off-by: Brooke Basile <[email protected]> Acked-by: Felipe Balbi <[email protected]> Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-08-25USB: gadget: u_f: add overflow checks to VLA macrosBrooke Basile1-11/+27
size can potentially hold an overflowed value if its assigned expression is left unchecked, leading to a smaller than needed allocation when vla_group_size() is used by callers to allocate memory. To fix this, add a test for saturation before declaring variables and an overflow check to (n) * sizeof(type). If the expression results in overflow, vla_group_size() will return SIZE_MAX. Reported-by: Ilja Van Sprundel <[email protected]> Suggested-by: Kees Cook <[email protected]> Signed-off-by: Brooke Basile <[email protected]> Acked-by: Felipe Balbi <[email protected]> Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-08-25io_uring: revert consumed iov_iter bytes on errorJens Axboe1-0/+4
Some consumers of the iov_iter will return an error, but still have bytes consumed in the iterator. This is an issue for -EAGAIN, since we rely on a sane iov_iter state across retries. Fix this by ensuring that we revert consumed bytes, if any, if the file operations have consumed any bytes from iterator. This is similar to what generic_file_read_iter() does, and is always safe as we have the previous bytes count handy already. Fixes: ff6165b2d7f6 ("io_uring: retain iov_iter state over io_read/io_write calls") Reported-by: Dmitry Shulyak <[email protected]> Reviewed-by: Stefano Garzarella <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2020-08-25irqchip/ingenic: Leave parent IRQ unmasked on suspendPaul Cercueil1-1/+1
All the wakeup sources we possibly want will go through the interrupt controller, so the parent IRQ must not be masked during suspend, or there won't be any way to wake up the system. Signed-off-by: Paul Cercueil <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-08-25irqchip/stm32-exti: Avoid losing interrupts due to clearing pending bits by ↵qiuguorui11-2/+12
mistake In the current code, when the eoi callback of the exti clears the pending bit of the current interrupt, it will first read the values of fpr and rpr, then logically OR the corresponding bit of the interrupt number, and finally write back to fpr and rpr. We found through experiments that if two exti interrupts, we call them int1/int2, arrive almost at the same time. in our scenario, the time difference is 30 microseconds, assuming int1 is triggered first. there will be an extreme scenario: both int's pending bit are set to 1, the irq handle of int1 is executed first, and eoi handle is then executed, at this moment, all pending bits are cleared, but the int 2 has not finally been reported to the cpu yet, which eventually lost int2. According to stm32's TRM description about rpr and fpr: Writing a 1 to this bit will trigger a rising edge event on event x, Writing 0 has no effect. Therefore, when clearing the pending bit, we only need to clear the pending bit of the irq. Fixes: 927abfc4461e7 ("irqchip/stm32: Add stm32mp1 support with hierarchy domain") Signed-off-by: qiuguorui1 <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Cc: [email protected] # v4.18+ Link: https://lore.kernel.org/r/[email protected]
2020-08-25irqchip: Revert modular support for drivers using IRQCHIP_PLATFORM_DRIVER ↵Marc Zyngier4-14/+4
helperse It has become obvious that switching a number of irqchip drivers to being platform drivers without considering the platform was a mistake. We have multiple reports of end-point drivers not probing because the irqchip driver isn't there yet, breaking the expectations of the users. This patch reverts: 920ecb8c35cb ("irqchip/mtk-cirq: Convert to a platform driver") f97dbf48ca43 ("irqchip/mtk-sysirq: Convert to a platform driver") 5be57099d445 ("irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros") 95bf9305d2e3 ("irqchip/qcom-pdc: Allow QCOM_PDC to be loadable as a permanent module") and leave QCOM PDC, MTK sysrq and cirq drivers as built-in, special purpose drivers for the time being until we have worked out a better solution. Reported-by: Enric Balletbo i Serra <[email protected]> Reported-by: Frank Wunderlich <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-08-25dt-bindings: mmc: Add missing description for clk_in/out_sd1Michal Simek1-3/+7
The commit a8fdb80f4d47 ("arm64: zynqmp: Add ZynqMP SDHCI compatible string") added clock-output-names for both SDHCIs before DT binding yaml conversion. But only clk_in/out_sd0 clock names have been covered by DT binding which ends up with dt yaml checking warnings as: From schema: .../Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml ... mmc@ff170000: clock-output-names:0: 'clk_out_sd0' was expected ... mmc@ff170000: clock-output-names:1: 'clk_in_sd0' was expected Fixes: 16ecd8f33c6e ("dt-bindings: mmc: convert arasan sdhci bindings to yaml") Signed-off-by: Michal Simek <[email protected]> Reviewed-by: Manish Narani <[email protected]> Link: https://lore.kernel.org/r/aef586778921c93377ec2f31c86e151b6e93f6c7.1598257520.git.michal.simek@xilinx.com Signed-off-by: Ulf Hansson <[email protected]>
2020-08-25drm/omap: fix incorrect lock stateTomi Valkeinen1-1/+2
After commit 92cc68e35863c1c61c449efa2b2daef6e9926048 ("drm/vblank: Use spin_(un)lock_irq() in drm_crtc_vblank_on()") omapdrm locking is broken: WARNING: inconsistent lock state 5.8.0-rc2-00483-g92cc68e35863 #13 Tainted: G W -------------------------------- inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. swapper/0/0 [HC1[1]:SC0[0]:HE0:SE1] takes: ea98222c (&dev->event_lock#2){?.+.}-{2:2}, at: drm_handle_vblank+0x4c/0x520 [drm] {HARDIRQ-ON-W} state was registered at: trace_hardirqs_on+0x9c/0x1ec _raw_spin_unlock_irq+0x20/0x58 omap_crtc_atomic_enable+0x54/0xa0 [omapdrm] drm_atomic_helper_commit_modeset_enables+0x218/0x270 [drm_kms_helper] omap_atomic_commit_tail+0x48/0xc4 [omapdrm] commit_tail+0x9c/0x190 [drm_kms_helper] drm_atomic_helper_commit+0x154/0x188 [drm_kms_helper] drm_client_modeset_commit_atomic+0x228/0x268 [drm] drm_client_modeset_commit_locked+0x60/0x1d0 [drm] drm_client_modeset_commit+0x24/0x40 [drm] drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0xa8 [drm_kms_helper] drm_fb_helper_set_par+0x2c/0x5c [drm_kms_helper] drm_fb_helper_hotplug_event.part.0+0xa0/0xbc [drm_kms_helper] drm_kms_helper_hotplug_event+0x24/0x30 [drm_kms_helper] output_poll_execute+0x1a8/0x1c0 [drm_kms_helper] process_one_work+0x268/0x800 worker_thread+0x30/0x4e0 kthread+0x164/0x190 ret_from_fork+0x14/0x20 The reason for this is that omapdrm calls drm_crtc_vblank_on() while holding event_lock taken with spin_lock_irq(). It is not clear why drm_crtc_vblank_on() and drm_crtc_vblank_get() are called while holding event_lock. I don't see any problem with moving those calls outside the lock, which is what this patch does. Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Laurent Pinchart <[email protected]>
2020-08-25Merge tag 'v5.9-rc2' into drm-misc-fixesMaarten Lankhorst13284-225283/+684468
Backmerge requested by Tomi for a fix to omap inconsistent locking state issue, and because we need at least v5.9-rc2 now. Signed-off-by: Maarten Lankhorst <[email protected]>
2020-08-25drm/i915: Fix cmd parser desc matching with masksMika Kuoppala1-4/+10
Our variety of defined gpu commands have the actual command id field and possibly length and flags applied. We did start to apply the mask during initialization of the cmd descriptors but forgot to also apply it on comparisons. Fix comparisons in order to properly deny access with associated commands. v2: fix lri with correct mask (Chris) References: 926abff21a8f ("drm/i915/cmdparser: Ignore Length operands during command matching") Reported-by: Nicolai Stange <[email protected]> Cc: [email protected] # v5.4+ Cc: Miroslav Benes <[email protected]> Cc: Takashi Iwai <[email protected]> Cc: Tyler Hicks <[email protected]> Cc: Jon Bloomfield <[email protected]> Cc: Chris Wilson <[email protected]> Signed-off-by: Mika Kuoppala <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 3b4efa148da36f158cce3f662e831af2834b8e0f) Signed-off-by: Jani Nikula <[email protected]>
2020-08-25i2c: iproc: Fix shifting 31 bitsRay Jui1-2/+2
Fix undefined behaviour in the iProc I2C driver by using 'BIT' marcro. Reported-by: Wolfram Sang <[email protected]> Signed-off-by: Ray Jui <[email protected]> Acked-by: Florian Fainelli <[email protected]> [wsa: in commit msg, don't say 'checkpatch' but name the issue] Signed-off-by: Wolfram Sang <[email protected]>
2020-08-25i2c: rcar: in slave mode, clear NACK earlierWolfram Sang1-0/+1
Currently, a NACK in slave mode is set/cleared when SCL is held low by the IP core right before the bit is about to be pushed out. This is too late for clearing and then a NACK from the previous byte is still used for the current one. Now, let's clear the NACK right after we detected the STOP condition following the NACK. Fixes: de20d1857dd6 ("i2c: rcar: add slave support") Signed-off-by: Wolfram Sang <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2020-08-25i2c: acpi: Remove dead code, i.e. i2c_acpi_match_device()Andy Shevchenko2-19/+0
We have no users of i2c_acpi_match_device() anymore and seems will not have them in the future, thus remove dead code. Signed-off-by: Andy Shevchenko <[email protected]> Reviewed-by: Mika Westerberg <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2020-08-25i2c: core: Don't fail PRP0001 enumeration when no ID table existAndy Shevchenko1-1/+1
When commit c64ffff7a9d1 ("i2c: core: Allow empty id_table in ACPI case as well") fixed the enumeration of I²C devices on ACPI enabled platforms when driver has no ID table, it missed the PRP0001 support. i2c_device_match() and i2c_acpi_match_device() differently match driver against given device. Use acpi_driver_match_device(), that is used in the former, in i2c_device_probe() and don't fail PRP0001 enumeration when no ID table exist. Fixes: c64ffff7a9d1 ("i2c: core: Allow empty id_table in ACPI case as well") BugLink: https://stackoverflow.com/q/63519678/2511795 Signed-off-by: Andy Shevchenko <[email protected]> Reviewed-by: Mika Westerberg <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2020-08-24scsi: scsi_debug: Remove superfluous close zone in resp_open_zone()Niklas Cassel1-2/+0
resp_open_zone() always calls zbc_open_zone() with parameter explicit set to true. If zbc_open_zone() is called with parameter explicit set to true, and the current zone state is implicit open, it will call zbc_close_zone() on the zone before proceeding. Therefore, there is no need for resp_open_zone() to call zbc_close_zone() on an implicitly open zone before calling zbc_open_zone(). Remove superfluous close zone in resp_open_zone(). Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Damien Le Moal <[email protected]> Signed-off-by: Niklas Cassel <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2020-08-24scsi: libcxgbi: Fix a use after free in cxgbi_conn_xmit_pdu()Dan Carpenter1-1/+1
We accidentally move this logging printk after the free, but that leads to a use after free. Link: https://lore.kernel.org/r/20200824085933.GD208317@mwanda Fixes: e33c2482289b ("scsi: cxgb4i: Add support for iSCSI segmentation offload") Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2020-08-24scsi: qedf: Fix null ptr reference in qedf_stag_change_workYe Bin1-1/+1
Link: https://lore.kernel.org/r/[email protected] Acked-by: Saurav Kashyap <[email protected]> Signed-off-by: Ye Bin <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2020-08-24Documentation: laptops: thinkpad-acpi: fix underline length build warningRandy Dunlap1-1/+1
Fix underline length build warning in thinkpad-acpi.rst documentation: Documentation/admin-guide/laptops/thinkpad-acpi.rst:1437: WARNING: Title underline too short. DYTC Lapmode sensor ------------------ Fixes: acf7f4a59114 ("platform/x86: thinkpad_acpi: lap or desk mode interface") Signed-off-by: Randy Dunlap <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Corbet <[email protected]>
2020-08-24Documentation: fix typo for abituguru documentationBrandon Jiang3-7/+7
Typo fix for abituguru,abituguru3 and abituguru-datasheet Signed-off-by: Brandon Jiang <[email protected]> Link: https://lore.kernel.org/r/DM5PR22MB0892E4FEFCA9ED055B0A8E71AC580@DM5PR22MB0892.namprd22.prod.outlook.com Signed-off-by: Jonathan Corbet <[email protected]>
2020-08-24docs: Fix function name trailing double-()sKees Cook3-3/+3
I noticed a double-() in the deprecated.rst rendering today. Fix that one and two others in the Documentation/ tree. Acked-by: "Paul E. McKenney" <[email protected]> # For RCU Signed-off-by: Kees Cook <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Corbet <[email protected]>
2020-08-24devices.txt: fix typo of "ubd" as "udb"Theodore Dubois1-1/+1
Signed-off-by: Theodore Dubois <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Corbet <[email protected]>
2020-08-24Documentation: add riscv entry in list of existing profilesLukas Bulwahn1-0/+1
As long as there are only a few maintainer entry profiles, i.e., three in v5.8, continue to maintain a complete a list of entries in the maintainer handbook. Complete the list by adding the RISC-V ARCHITECTURE maintainer entry profile found in MAINTAINERS. Signed-off-by: Lukas Bulwahn <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Corbet <[email protected]>
2020-08-24MAINTAINERS: mention documentation maintainer entry profileLukas Bulwahn1-0/+1
Since commit 53b7f3aa411b ("Add a maintainer entry profile for documentation"), the documentation "subsystem" has a maintainer entry profile, and it deserves to be mentioned in MAINTAINERS with a suitable P: entry. Signed-off-by: Lukas Bulwahn <[email protected]> Reviewed-by: Kees Cook <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Corbet <[email protected]>
2020-08-24Fpga: Documentation: Replace deprecated :c:func: UsagePuranjay Mohan4-23/+23
Replace :c:func: with func() as the previous usage is deprecated. Signed-off-by: Puranjay Mohan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Corbet <[email protected]>
2020-08-24IIO: Documentation: Replace deprecated :c:func: UsagePuranjay Mohan1-8/+8
Replace :c:func: with func() as the previous usage is deprecated. Signed-off-by: Puranjay Mohan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Corbet <[email protected]>
2020-08-24Documentation/locking/locktypes: fix local_locks documentationMarta Rybczynska1-12/+12
Fix issues with local_locks documentation: - fix function names, local_lock.h has local_unlock_irqrestore(), not local_lock_irqrestore() - fix mapping table, local_unlock_irqrestore() maps to local_irq_restore(), not _save() Signed-off-by: Marta Rybczynska <[email protected]> Acked-by: Will Deacon <[email protected]> Link: https://lore.kernel.org/r/CAApg2=SKxQ3Sqwj6TZnV-0x0cKLXFKDaPvXT4N15MPDMKq724g@mail.gmail.com Signed-off-by: Jonathan Corbet <[email protected]>
2020-08-24lib: Revert use of fallthrough pseudo-keyword in lib/Gustavo A. R. Silva16-64/+64
The following build error for powerpc64 was reported by Nathan Chancellor: "$ scripts/config --file arch/powerpc/configs/powernv_defconfig -e KERNEL_XZ $ make -skj"$(nproc)" ARCH=powerpc CROSS_COMPILE=powerpc64le-linux- distclean powernv_defconfig zImage ... In file included from arch/powerpc/boot/../../../lib/decompress_unxz.c:234, from arch/powerpc/boot/decompress.c:38: arch/powerpc/boot/../../../lib/xz/xz_dec_stream.c: In function 'dec_main': arch/powerpc/boot/../../../lib/xz/xz_dec_stream.c:586:4: error: 'fallthrough' undeclared (first use in this function) 586 | fallthrough; | ^~~~~~~~~~~ This will end up affecting distribution configurations such as Debian and OpenSUSE according to my testing. I am not sure what the solution is, the PowerPC wrapper does not set -D__KERNEL__ so I am not sure that compiler_attributes.h can be safely included." In order to avoid these sort of problems, it seems that the best solution is to use /* fall through */ comments instead of the fallthrough pseudo-keyword macro in lib/, for now. Reported-by: Nathan Chancellor <[email protected]> Fixes: df561f6688fe ("treewide: Use fallthrough pseudo-keyword") Signed-off-by: Gustavo A. R. Silva <[email protected]> Reviewed-and-tested-by: Nathan Chancellor <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-08-24Merge tag 'for-5.9-rc2-tag' of ↵Linus Torvalds9-31/+39
git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux Pull btrfs fixes from David Sterba: - fix swapfile activation on subvolumes with deleted snapshots - error value mixup when removing directory entries from tree log - fix lzo compression level reset after previous level setting - fix space cache memory leak after transaction abort - fix const function attribute - more error handling improvements * tag 'for-5.9-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux: btrfs: detect nocow for swap after snapshot delete btrfs: check the right error variable in btrfs_del_dir_entries_in_log btrfs: fix space cache memory leak after transaction abort btrfs: use the correct const function attribute for btrfs_get_num_csums btrfs: reset compression level for lzo on remount btrfs: handle errors from async submission
2020-08-24Merge tag 'io_uring-5.9-2020-08-23' of git://git.kernel.dk/linux-blockLinus Torvalds26-153/+238
Pull block fixes from Jens Axboe: - NVMe pull request from Sagi: - nvme completion rework from Christoph and Chao that mostly came from a bit of divergence of how we classify errors related to pathing/retry etc. - nvmet passthru fixes from Chaitanya - minor nvmet fixes from Amit and I - mpath round-robin path selection fix from Martin - ignore noiob for zoned devices from Keith - minor nvme-fc fix from Tianjia" - BFQ cgroup leak fix (Dmitry) - block layer MAINTAINERS addition (Geert) - fix null_blk FUA checking (Hou) - get_max_io_size() size fix (Keith) - fix block page_is_mergeable() for compound pages (Matthew) - discard granularity fixes (Ming) - IO scheduler ordering fix (Ming) - misc fixes * tag 'io_uring-5.9-2020-08-23' of git://git.kernel.dk/linux-block: (31 commits) null_blk: fix passing of REQ_FUA flag in null_handle_rq nvmet: Disable keep-alive timer when kato is cleared to 0h nvme: redirect commands on dying queue nvme: just check the status code type in nvme_is_path_error nvme: refactor command completion nvme: rename and document nvme_end_request nvme: skip noiob for zoned devices nvme-pci: fix PRP pool size nvme-pci: Use u32 for nvme_dev.q_depth and nvme_queue.q_depth nvme: Use spin_lock_irq() when taking the ctrl->lock nvmet: call blk_mq_free_request() directly nvmet: fix oops in pt cmd execution nvmet: add ns tear down label for pt-cmd handling nvme: multipath: round-robin: eliminate "fallback" variable nvme: multipath: round-robin: fix single non-optimized path case nvme-fc: Fix wrong return value in __nvme_fc_init_request() nvmet-passthru: Reject commands with non-sgl flags set nvmet: fix a memory leak blkcg: fix memleak for iolatency MAINTAINERS: Add missing header files to BLOCK LAYER section ...
2020-08-24Merge tag 'fallthrough-pseudo-keyword-5.9-rc3' of ↵Linus Torvalds1148-2737/+2667
git://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux Pull 'fallthrough' keyword conversion from Gustavo A. R. Silva: "A tree-wide patch that replaces tons (2484) of /* fall through */ comments, and its variants, with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case. There are currently 1167 intances of this fallthrough pseudo-keyword macro in mainline (5.9-rc2), that have been introduced over the last couple of development cycles: $ git grep -nw 'fallthrough;' | wc -l 1167 The global adoption of the fallthrough pseudo-keyword is something certain to happen; so, better sooner than later. :) This will also save everybody's time and thousands of lines of unnecessarily repetitive changelog text. After applying this patch on top of 5.9-rc2, we'll have a total of 3651 instances of this macro: $ git grep -nw 'fallthrough;' | wc -l 3651 This treewide patch doesn't address ALL fall-through markings in all subsystems at once because I have previously sent out patches for some of such subsystems separately, and I will follow up on them; however, this definitely contributes most of the work needed to replace all the fall-through markings with the fallthrough pseudo-keyword macro in the whole codebase. I have build-tested this patch on 10 different architectures: x86_64, i386, arm64, powerpc, s390, sparc64, sh, m68k, powerpc64 and alpha (allyesconfig for all of them). This is in linux-next already and kernel test robot has also helped me to successfully build-test early versions of this patch[2][3][4][5]" [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through [2] https://lore.kernel.org/lkml/5f3cc99a.HgvOW3rH0mD0RmkM%[email protected]/ [3] https://lore.kernel.org/lkml/5f3dd1d2.l1axczH+t4hMBZ63%[email protected]/ [4] https://lore.kernel.org/lkml/5f3e977a.mwYHUIObbR4SHr0B%[email protected]/ [5] https://lore.kernel.org/lkml/5f3f9e1c.qsyb%2FaySkiXNpkO4%[email protected]/ * tag 'fallthrough-pseudo-keyword-5.9-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux: treewide: Use fallthrough pseudo-keyword
2020-08-24ceph: don't allow setlease on cephfsJeff Layton1-0/+1
Leases don't currently work correctly on kcephfs, as they are not broken when caps are revoked. They could eventually be implemented similarly to how we did them in libcephfs, but for now don't allow them. [ idryomov: no need for simple_nosetlease() in ceph_dir_fops and ceph_snapdir_fops ] Signed-off-by: Jeff Layton <[email protected]> Reviewed-by: Ilya Dryomov <[email protected]> Signed-off-by: Ilya Dryomov <[email protected]>
2020-08-24ceph: fix inode number handling on arches with 32-bit ino_tJeff Layton8-77/+74
Tuan and Ulrich mentioned that they were hitting a problem on s390x, which has a 32-bit ino_t value, even though it's a 64-bit arch (for historical reasons). I think the current handling of inode numbers in the ceph driver is wrong. It tries to use 32-bit inode numbers on 32-bit arches, but that's actually not a problem. 32-bit arches can deal with 64-bit inode numbers just fine when userland code is compiled with LFS support (the common case these days). What we really want to do is just use 64-bit numbers everywhere, unless someone has mounted with the ino32 mount option. In that case, we want to ensure that we hash the inode number down to something that will fit in 32 bits before presenting the value to userland. Add new helper functions that do this, and only do the conversion before presenting these values to userland in getattr and readdir. The inode table hashvalue is changed to just cast the inode number to unsigned long, as low-order bits are the most likely to vary anyway. While it's not strictly required, we do want to put something in inode->i_ino. Instead of basing it on BITS_PER_LONG, however, base it on the size of the ino_t type. NOTE: This is a user-visible change on 32-bit arches: 1/ inode numbers will be seen to have changed between kernel versions. 32-bit arches will see large inode numbers now instead of the hashed ones they saw before. 2/ any really old software not built with LFS support may start failing stat() calls with -EOVERFLOW on inode numbers >2^32. Nothing much we can do about these, but hopefully the intersection of people running such code on ceph will be very small. The workaround for both problems is to mount with "-o ino32". [ idryomov: changelog tweak ] URL: https://tracker.ceph.com/issues/46828 Reported-by: Ulrich Weigand <[email protected]> Reported-and-Tested-by: Tuan Hoang1 <[email protected]> Signed-off-by: Jeff Layton <[email protected]> Reviewed-by: "Yan, Zheng" <[email protected]> Signed-off-by: Ilya Dryomov <[email protected]>
2020-08-24drm/etnaviv: always start/stop scheduler in timeout processingLucas Stach1-5/+6
The drm scheduler currently expects that the stop/start sequence is always executed in the timeout handling, as the job at the head of the hardware execution list is always removed from the ring mirror before the driver function is called and only inserted back into the list when starting the scheduler. This adds some unnecessary overhead if the timeout handler determines that the GPU is still executing jobs normally and just wished to extend the timeout, but a better solution requires a major rearchitecture of the scheduler, which is not applicable as a fix. Fixes: 135517d3565b ("drm/scheduler: Avoid accessing freed bad job.") Signed-off-by: Lucas Stach <[email protected]> Tested-by: Russell King <[email protected]>
2020-08-24drm/etnaviv: fix external abort seen on GC600 rev 0x19Christian Gmeiner1-2/+9
It looks like that this GPU core triggers an abort when reading VIVS_HI_CHIP_PRODUCT_ID and/or VIVS_HI_CHIP_ECO_ID. I looked at different versions of Vivante's kernel driver and did not found anything about this issue or what feature flag can be used. So go the simplest route and do not read these two registers on the affected GPU core. Signed-off-by: Christian Gmeiner <[email protected]> Reported-by: Josua Mayer <[email protected]> Fixes: 815e45bbd4d3 ("drm/etnaviv: determine product, customer and eco id") Cc: [email protected] Tested-by: Josua Mayer <[email protected]> Signed-off-by: Lucas Stach <[email protected]>
2020-08-24hv_utils: drain the timesync packets on onchannelcallbackVineeth Pillai1-3/+16
There could be instances where a system stall prevents the timesync packets to be consumed. And this might lead to more than one packet pending in the ring buffer. Current code empties one packet per callback and it might be a stale one. So drain all the packets from ring buffer on each callback. Signed-off-by: Vineeth Pillai <[email protected]> Reviewed-by: Michael Kelley <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Wei Liu <[email protected]>
2020-08-24hv_utils: return error if host timesysnc update is staleVineeth Pillai1-11/+35
If for any reason, host timesync messages were not processed by the guest, hv_ptp_gettime() returns a stale value and the caller (clock_gettime, PTP ioctl etc) has no means to know this now. Return an error so that the caller knows about this. Signed-off-by: Vineeth Pillai <[email protected]> Reviewed-by: Michael Kelley <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Wei Liu <[email protected]>
2020-08-24mfd: core: Fix double-free in mfd_remove_devices_fn()Dmitry Osipenko1-2/+0
The pdev.mfd_cell is released by platform_device_release(), which is invoked by platform_device_unregister(). Hence mfd_remove_devices_fn() shouldn't release the cell variable. The double-free bug is reported KASAN during of MFD driver module removal. Fixes: 466a62d7642f ("mfd: core: Make a best effort attempt to match devices with the correct of_nodes") Reported-by: Marek Szyprowski <[email protected]> Signed-off-by: Dmitry Osipenko <[email protected]> Signed-off-by: Lee Jones <[email protected]>
2020-08-24gfs2: add some much needed cleanup for log flushes that failBob Peterson2-0/+32
When a log flush fails due to io errors, it signals the failure but does not clean up after itself very well. This is because buffers are added to the transaction tr_buf and tr_databuf queue, but the io error causes gfs2_log_flush to bypass the "after_commit" functions responsible for dequeueing the bd elements. If the bd elements are added to the ail list before the error, function ail_drain takes care of dequeueing them. But if they haven't gotten that far, the elements are forgotten and make the transactions unable to be freed. This patch introduces new function trans_drain which drains the bd elements from the transaction so they can be freed properly. Signed-off-by: Bob Peterson <[email protected]> Signed-off-by: Andreas Gruenbacher <[email protected]>
2020-08-24Documentation: fix pm/intel_pstate build warning and wordingRandy Dunlap1-2/+2
Fix documentation build warning and sentence wording: Documentation/admin-guide/pm/intel_pstate.rst:568: WARNING: Unexpected indentation. Fixes: f473bf398bf1 ("cpufreq: intel_pstate: Allow raw energy performance preference value") Signed-off-by: Randy Dunlap <[email protected]> Cc: Srinivas Pandruvada <[email protected]> Cc: Rafael J. Wysocki <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2020-08-24libceph: add __maybe_unused to DEFINE_CEPH_FEATUREIlya Dryomov1-4/+4
Avoid -Wunused-const-variable warnings for "make W=1". Reported-by: Leon Romanovsky <[email protected]> Signed-off-by: Ilya Dryomov <[email protected]> Reviewed-by: Leon Romanovsky <[email protected]>
2020-08-24mmc: mediatek: add optional module reset propertyWenbin Mei1-0/+13
This patch fixs eMMC-Access on mt7622/Bpi-64. Before we got these Errors on mounting eMMC ion R64: [ 48.664925] blk_update_request: I/O error, dev mmcblk0, sector 204800 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0 [ 48.676019] Buffer I/O error on dev mmcblk0p1, logical block 0, lost sync page write This patch adds a optional reset management for msdc. Sometimes the bootloader does not bring msdc register to default state, so need reset the msdc controller. Cc: <[email protected]> # v5.4+ Fixes: 966580ad236e ("mmc: mediatek: add support for MT7622 SoC") Signed-off-by: Wenbin Mei <[email protected]> Reviewed-by: Philipp Zabel <[email protected]> Tested-by: Frank Wunderlich <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.