aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-05-13drm/i915: Handle idling during i915_gem_evict_something busy loopsChris Wilson1-14/+12
i915_gem_evict_something() is charged with finding a slot within the GTT that we may reuse. Since our goal is not to stall, we first look for a slot that only overlaps idle vma. To this end, on the first pass we move any active vma to the end of the search list. However, we only stopped moving active vma after we see the first active vma twice. If during the search, that first active vma completed, we would not notice and keep on extending the search list. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1746 Fixes: 2850748ef876 ("drm/i915: Pull i915_vma_pin under the vm->mutex") Fixes: b1e3177bd1d8 ("drm/i915: Coordinate i915_active with its own mutex") Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: <[email protected]> # v5.5+ Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 73e28cc40bf00b5d168cb8f5cff1ae63e9097446) Signed-off-by: Rodrigo Vivi <[email protected]>
2020-05-13net: broadcom: Select BROADCOM_PHY for BCMGENETFlorian Fainelli1-0/+1
The GENET controller on the Raspberry Pi 4 (2711) is typically interfaced with an external Broadcom PHY via a RGMII electrical interface. To make sure that delays are properly configured at the PHY side, ensure that we the dedicated Broadcom PHY driver (CONFIG_BROADCOM_PHY) is enabled for this to happen. Fixes: 402482a6a78e ("net: bcmgenet: Clear ID_MODE_DIS in EXT_RGMII_OOB_CTRL when not needed") Reported-by: Marek Szyprowski <[email protected]> Signed-off-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-05-13Merge branch 'tipc-fixes'David S. Miller3-16/+49
Tuong Lien says: ==================== tipc: add some patches This series adds patches to fix some issues in TIPC streaming & service subscription. ==================== Signed-off-by: David S. Miller <[email protected]>
2020-05-13tipc: fix failed service subscription deletionTuong Lien2-4/+15
When a service subscription is expired or canceled by user, it needs to be deleted from the subscription list, so that new subscriptions can be registered (max = 65535 per net). However, there are two issues in code that can cause such an unused subscription to persist: 1) The 'tipc_conn_delete_sub()' has a loop on the subscription list but it makes a break shortly when the 1st subscription differs from the one specified, so the subscription will not be deleted. 2) In case a subscription is canceled, the code to remove the 'TIPC_SUB_CANCEL' flag from the subscription filter does not work if it is a local subscription (i.e. the little endian isn't involved). So, it will be no matches when looking for the subscription to delete later. The subscription(s) will be removed eventually when the user terminates its topology connection but that could be a long time later. Meanwhile, the number of available subscriptions may be exhausted. This commit fixes the two issues above, so as needed a subscription can be deleted correctly. Acked-by: Ying Xue <[email protected]> Acked-by: Jon Maloy <[email protected]> Signed-off-by: Tuong Lien <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-05-13tipc: fix memory leak in service subscriptingTuong Lien1-1/+3
Upon receipt of a service subscription request from user via a topology connection, one 'sub' object will be allocated in kernel, so it will be able to send an event of the service if any to the user correspondingly then. Also, in case of any failure, the connection will be shutdown and all the pertaining 'sub' objects will be freed. However, there is a race condition as follows resulting in memory leak: receive-work connection send-work | | | sub-1 |<------//-------| | sub-2 |<------//-------| | | |<---------------| evt for sub-x sub-3 |<------//-------| | : : : : : : | /--------| | | | * peer closed | | | | | | | |<-------X-------| evt for sub-y | | |<===============| sub-n |<------/ X shutdown | -> orphan | | That is, the 'receive-work' may get the last subscription request while the 'send-work' is shutting down the connection due to peer close. We had a 'lock' on the connection, so the two actions cannot be carried out simultaneously. If the last subscription is allocated e.g. 'sub-n', before the 'send-work' closes the connection, there will be no issue at all, the 'sub' objects will be freed. In contrast the last subscription will become orphan since the connection was closed, and we released all references. This commit fixes the issue by simply adding one test if the connection remains in 'connected' state right after we obtain the connection lock, then a subscription object can be created as usual, otherwise we ignore it. Acked-by: Ying Xue <[email protected]> Acked-by: Jon Maloy <[email protected]> Reported-by: Thang Ngo <[email protected]> Signed-off-by: Tuong Lien <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-05-13tipc: fix large latency in smart Nagle streamingTuong Lien1-11/+31
Currently when a connection is in Nagle mode, we set the 'ack_required' bit in the last sending buffer and wait for the corresponding ACK prior to pushing more data. However, on the receiving side, the ACK is issued only when application really reads the whole data. Even if part of the last buffer is received, we will not do the ACK as required. This might cause an unnecessary delay since the receiver does not always fetch the message as fast as the sender, resulting in a large latency in the user message sending, which is: [one RTT + the receiver processing time]. The commit makes Nagle ACK as soon as possible i.e. when a message with the 'ack_required' arrives in the receiving side's stack even before it is processed or put in the socket receive queue... This way, we can limit the streaming latency to one RTT as committed in Nagle mode. Acked-by: Ying Xue <[email protected]> Acked-by: Jon Maloy <[email protected]> Signed-off-by: Tuong Lien <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-05-13Merge branch 's390-fixes'David S. Miller2-1/+4
Ursula Braun says: ==================== s390/net: updates 2020-05-13 please apply the fix from Wei Yongjun to netdev's net tree and add Karsten Graul as co-maintainer for drivers/s390/net. ==================== Signed-off-by: David S. Miller <[email protected]>
2020-05-13MAINTAINERS: add Karsten Graul as S390 NETWORK DRIVERS maintainerUrsula Braun1-0/+1
Add Karsten as additional maintainer for drivers/s390/net . One of his focal points is the ism driver. Cc: Julian Wiedmann <[email protected]> Acked-by: Julian Wiedmann <[email protected]> Signed-off-by: Ursula Braun <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-05-13s390/ism: fix error return code in ism_probe()Wei Yongjun1-1/+3
Fix to return negative error code -ENOMEM from the smcd_alloc_dev() error handling case instead of 0, as done elsewhere in this function. Fixes: 684b89bc39ce ("s390/ism: add device driver for internal shared memory") Reported-by: Hulk Robot <[email protected]> Signed-off-by: Wei Yongjun <[email protected]> Signed-off-by: Ursula Braun <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-05-13io_uring: polled fixed file must go through free iterationJens Axboe1-5/+1
When we changed the file registration handling, it became important to iterate the bulk request freeing list for fixed files as well, or we miss dropping the fixed file reference. If not, we're leaking references, and we'll get a kworker stuck waiting for file references to disappear. This also means we can remove the special casing of fixed vs non-fixed files, we need to iterate for both and we can just rely on __io_req_aux_free() doing io_put_file() instead of doing it manually. Fixes: 055895537302 ("io_uring: refactor file register/unregister/update handling") Signed-off-by: Jens Axboe <[email protected]>
2020-05-13hwmon: (da9052) Synchronize access with mfdSamu Nuutamo1-2/+2
When tsi-as-adc is configured it is possible for in7[0123]_input read to return an incorrect value if a concurrent read to in[456]_input is performed. This is caused by a concurrent manipulation of the mux channel without proper locking as hwmon and mfd use different locks for synchronization. Switch hwmon to use the same lock as mfd when accessing the TSI channel. Fixes: 4f16cab19a3d5 ("hwmon: da9052: Add support for TSI channel") Signed-off-by: Samu Nuutamo <[email protected]> [rebase to current master, reword commit message slightly] Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Guenter Roeck <[email protected]>
2020-05-13KVM: x86: Fix pkru save/restore when guest CR4.PKE=0, move it to x86.cBabu Moger3-18/+18
Though rdpkru and wrpkru are contingent upon CR4.PKE, the PKRU resource isn't. It can be read with XSAVE and written with XRSTOR. So, if we don't set the guest PKRU value here(kvm_load_guest_xsave_state), the guest can read the host value. In case of kvm_load_host_xsave_state, guest with CR4.PKE clear could potentially use XRSTOR to change the host PKRU value. While at it, move pkru state save/restore to common code and the host_pkru field to kvm_vcpu_arch. This will let SVM support protection keys. Cc: [email protected] Reported-by: Jim Mattson <[email protected]> Signed-off-by: Babu Moger <[email protected]> Message-Id: <158932794619.44260.14508381096663848853.stgit@naples-babu.amd.com> Signed-off-by: Paolo Bonzini <[email protected]>
2020-05-13x86/hyperv: Properly suspend/resume reenlightenment notificationsVitaly Kuznetsov1-2/+17
Errors during hibernation with reenlightenment notifications enabled were reported: [ 51.730435] PM: hibernation entry [ 51.737435] PM: Syncing filesystems ... ... [ 54.102216] Disabling non-boot CPUs ... [ 54.106633] smpboot: CPU 1 is now offline [ 54.110006] unchecked MSR access error: WRMSR to 0x40000106 (tried to write 0x47c72780000100ee) at rIP: 0xffffffff90062f24 native_write_msr+0x4/0x20) [ 54.110006] Call Trace: [ 54.110006] hv_cpu_die+0xd9/0xf0 ... Normally, hv_cpu_die() just reassigns reenlightenment notifications to some other CPU when the CPU receiving them goes offline. Upon hibernation, there is no other CPU which is still online so cpumask_any_but(cpu_online_mask) returns >= nr_cpu_ids and using it as hv_vp_index index is incorrect. Disable the feature when cpumask_any_but() fails. Also, as we now disable reenlightenment notifications upon hibernation we need to restore them on resume. Check if hv_reenlightenment_cb was previously set and restore from hv_resume(). Signed-off-by: Vitaly Kuznetsov <[email protected]> Reviewed-by: Dexuan Cui <[email protected]> Reviewed-by: Tianyu Lan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Wei Liu <[email protected]>
2020-05-13hwmon: (nct7904) Fix incorrect range of temperature limit registersAmy Shih1-1/+3
The format of temperature limitation registers are 8-bit 2's complement and the range is -128~127. Converts the reading value to signed char to fix the incorrect range of temperature limitation registers. Signed-off-by: Amy Shih <[email protected]> Signed-off-by: Guenter Roeck <[email protected]>
2020-05-13hwmon: (nct7904) Read all SMI status registers in probe functionAmy Shih1-0/+8
When nct7904 power up, it compares current sensor readings against the default threshold immediately. This results in false alarms on startup. Read all SMI status registers in probe function to clear the alarms. Signed-off-by: Amy Shih <[email protected]> [groeck: Reworded description] Signed-off-by: Guenter Roeck <[email protected]>
2020-05-13NFS/pnfs: Don't use RPC_TASK_CRED_NOREF with pnfsTrond Myklebust3-5/+7
When we're doing pnfs then the credential being used for the RPC call is not necessarily the same as the one used in the open context, so don't use RPC_TASK_CRED_NOREF. Fixes: 612965072020 ("NFSv4: Avoid referencing the cred unnecessarily during NFSv4 I/O") Signed-off-by: Trond Myklebust <[email protected]>
2020-05-13usb: typec: mux: intel: Fix DP_HPD_LVL bit fieldPrashant Malani1-3/+3
According to the PMC Type C Subsystem (TCSS) Mux programming guide rev 0.6, the PMC HPD request LVL bit field is bit 4. Fix the definition here to match the programming guide. Since this bit field is changing, explicitly define a field for the HPD_HIGH mode data bit. Signed-off-by: Prashant Malani <[email protected]> Fixes: 6701adfa9693 ("usb: typec: driver for Intel PMC mux control") Reviewed-by: Benson Leung <[email protected]> Acked-by: Heikki Krogerus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-05-13Merge tag 'fixes-for-v5.7-rc5' of ↵Greg Kroah-Hartman12-18/+34
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus Felipe writes: USB: fixes for v5.7-rc5 Fixing raw-gadget's IOCTL return value. Enabling EXTCON for Intel Merrifield. Couple leaks have been plugged in net2272 and twl6030-usb. Returning an error code when things fail in cdc and ncm legacy gadgets. An old bug on dwc3 regarding HWO bit handling has been fixed. Apart from these, some minor fixes. Signed-off-by: Felipe Balbi <[email protected]> * tag 'fixes-for-v5.7-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb: usb: raw-gadget: fix return value of ep read ioctls usb: dwc3: select USB_ROLE_SWITCH usb: gadget: legacy: fix error return code in gncm_bind() usb: gadget: legacy: fix error return code in cdc_bind() usb: gadget: legacy: fix redundant initialization warnings usb: gadget: tegra-xudc: Fix idle suspend/resume usb: gadget: net2272: Fix a memory leak in an error handling path in 'net2272_plat_probe()' usb: phy: twl6030-usb: Fix a resource leak in an error handling path in 'twl6030_usb_probe()' usb: cdns3: gadget: prev_req->trb is NULL for ep0 usb: gadget: audio: Fix a missing error return value in audio_bind() usb: dwc3: pci: Enable extcon driver for Intel Merrifield dwc3: Remove check for HWO flag in dwc3_gadget_ep_reclaim_trb_sg()
2020-05-13staging: wfx: unlock on error pathDan Carpenter1-1/+3
We need to release the tx_lock on the error path before returning. Fixes: d1c015b4ef6f ("staging: wfx: rewrite wfx_hw_scan()") Signed-off-by: Dan Carpenter <[email protected]> Cc: stable <[email protected]> Reviewed-by: Jérôme Pouiller <[email protected]> Link: https://lore.kernel.org/r/20200512083656.GA251760@mwanda Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-05-13staging: greybus: Fix uninitialized scalar variableOscar Carter1-2/+2
In the "gb_tty_set_termios" function the "newline" variable is declared but not initialized. So the "flow_control" member is not initialized and the OR / AND operations with itself results in an undefined value in this member. The purpose of the code is to set the flow control type, so remove the OR / AND self operator and set the value directly. Addresses-Coverity-ID: 1374016 ("Uninitialized scalar variable") Fixes: e55c25206d5c9 ("greybus: uart: Handle CRTSCTS flag in termios") Signed-off-by: Oscar Carter <[email protected]> Cc: stable <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-05-13staging: kpc2000: fix error return code in kp2000_pcie_probe()Wei Yongjun1-5/+4
Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Also removed var 'rv' since we can use 'err' instead. Fixes: 7dc7967fc39a ("staging: kpc2000: add initial set of Daktronics drivers") Signed-off-by: Wei Yongjun <[email protected]> Cc: stable <[email protected]> Reviewed-by: Dan Carpenter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-05-13dmaengine: dmatest: Restore default for channelVladimir Murzin1-4/+5
In case of dmatest is built-in and no channel was configured test doesn't run with: dmatest: Could not start test, no channels configured Even though description to "channel" parameter claims that default is any. Add default channel back as it used to be rather than reject test with no channel configuration. Fixes: d53513d5dc285d9a95a534fc41c5c08af6b60eac ("dmaengine: dmatest: Add support for multi channel testing) Reported-by: Dijil Mohan <[email protected]> Signed-off-by: Vladimir Murzin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]>
2020-05-13drm/meson: pm resume add return errno branchBernard Zhao1-3/+1
pm_resump api did not handle drm_mode_config_helper_resume error. This change add handle to return drm_mode_config_helper_resume`s error number. This code logic is aligned with api pm_suspend. After this change, the code maybe a bit readable. Signed-off-by: Bernard Zhao <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-05-13csky: Fixup remove unnecessary save/restore PSR codeGuo Ren3-11/+2
All processes' PSR could success from SETUP_MMU, so need set it in INIT_THREAD again. And use a3 instead of r7 in __switch_to for code convention. Signed-off-by: Guo Ren <[email protected]>
2020-05-13csky: Fixup remove duplicate irq_disableLiu Yibin1-2/+0
Interrupt has been disabled in __schedule() with local_irq_disable() and enabled in finish_task_switch->finish_lock_switch() with local_irq_enabled(), So needn't to disable irq here. Signed-off-by: Liu Yibin <[email protected]> Signed-off-by: Guo Ren <[email protected]>
2020-05-13csky: Fixup calltrace panicGuo Ren8-119/+159
The implementation of show_stack will panic with wrong fp: addr = *fp++; because the fp isn't checked properly. The current implementations of show_stack, wchan and stack_trace haven't been designed properly, so just deprecate them. This patch is a reference to riscv's way, all codes are modified from arm's. The patch is passed with: - cat /proc/<pid>/stack - cat /proc/<pid>/wchan - echo c > /proc/sysrq-trigger Signed-off-by: Guo Ren <[email protected]>
2020-05-13csky: Fixup perf callchain unwindMao Han1-2/+7
[ 5221.974084] Unable to handle kernel paging request at virtual address 0xfffff000, pc: 0x8002c18e [ 5221.985929] Oops: 00000000 [ 5221.989488] [ 5221.989488] CURRENT PROCESS: [ 5221.989488] [ 5221.992877] COMM=callchain_test PID=11962 [ 5221.995213] TEXT=00008000-000087e0 DATA=00009f1c-0000a018 BSS=0000a018-0000b000 [ 5221.999037] USER-STACK=7fc18e20 KERNEL-STACK=be204680 [ 5221.999037] [ 5222.003292] PC: 0x8002c18e (perf_callchain_kernel+0x3e/0xd4) [ 5222.007957] LR: 0x8002c198 (perf_callchain_kernel+0x48/0xd4) [ 5222.074873] Call Trace: [ 5222.074873] [<800a248e>] get_perf_callchain+0x20a/0x29c [ 5222.074873] [<8009d964>] perf_callchain+0x64/0x80 [ 5222.074873] [<8009dc1c>] perf_prepare_sample+0x29c/0x4b8 [ 5222.074873] [<8009de6e>] perf_event_output_forward+0x36/0x98 [ 5222.074873] [<800497e0>] search_exception_tables+0x20/0x44 [ 5222.074873] [<8002cbb6>] do_page_fault+0x92/0x378 [ 5222.074873] [<80098608>] __perf_event_overflow+0x54/0xdc [ 5222.074873] [<80098778>] perf_swevent_hrtimer+0xe8/0x164 [ 5222.074873] [<8002ddd0>] update_mmu_cache+0x0/0xd8 [ 5222.074873] [<8002c014>] user_backtrace+0x58/0xc4 [ 5222.074873] [<8002c0b4>] perf_callchain_user+0x34/0xd0 [ 5222.074873] [<800a2442>] get_perf_callchain+0x1be/0x29c [ 5222.074873] [<8009d964>] perf_callchain+0x64/0x80 [ 5222.074873] [<8009d834>] perf_output_sample+0x78c/0x858 [ 5222.074873] [<8009dc1c>] perf_prepare_sample+0x29c/0x4b8 [ 5222.074873] [<8009de94>] perf_event_output_forward+0x5c/0x98 [ 5222.097846] [ 5222.097846] [<800a0300>] perf_event_exit_task+0x58/0x43c [ 5222.097846] [<8006c874>] hrtimer_interrupt+0x104/0x2ec [ 5222.097846] [<800a0300>] perf_event_exit_task+0x58/0x43c [ 5222.097846] [<80437bb6>] dw_apb_clockevent_irq+0x2a/0x4c [ 5222.097846] [<8006c770>] hrtimer_interrupt+0x0/0x2ec [ 5222.097846] [<8005f2e4>] __handle_irq_event_percpu+0xac/0x19c [ 5222.097846] [<80437bb6>] dw_apb_clockevent_irq+0x2a/0x4c [ 5222.097846] [<8005f408>] handle_irq_event_percpu+0x34/0x88 [ 5222.097846] [<8005f480>] handle_irq_event+0x24/0x64 [ 5222.097846] [<8006218c>] handle_level_irq+0x68/0xdc [ 5222.097846] [<8005ec76>] __handle_domain_irq+0x56/0xa8 [ 5222.097846] [<80450e90>] ck_irq_handler+0xac/0xe4 [ 5222.097846] [<80029012>] csky_do_IRQ+0x12/0x24 [ 5222.097846] [<8002a3a0>] csky_irq+0x70/0x80 [ 5222.097846] [<800ca612>] alloc_set_pte+0xd2/0x238 [ 5222.097846] [<8002ddd0>] update_mmu_cache+0x0/0xd8 [ 5222.097846] [<800a0340>] perf_event_exit_task+0x98/0x43c The original fp check doesn't base on the real kernal stack region. Invalid fp address may cause kernel panic. Signed-off-by: Mao Han <[email protected]> Signed-off-by: Guo Ren <[email protected]>
2020-05-13csky: Fixup msa highest 3 bits maskLiu Yibin2-4/+4
Just as comment mentioned, the msa format: cr<30/31, 15> MSA register format: 31 - 29 | 28 - 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 BA Reserved SH WA B SO SEC C D V So we should shift 29 bits not 28 bits for mask Signed-off-by: Liu Yibin <[email protected]> Signed-off-by: Guo Ren <[email protected]>
2020-05-13csky: Fixup perf probe -x hungupGuo Ren2-0/+11
case: # perf probe -x /lib/libc-2.28.9000.so memcpy # perf record -e probe_libc:memcpy -aR sleep 1 System hangup and cpu get in trap_c loop, because our hardware singlestep state could still get interrupt signal. When we get in uprobe_xol singlestep slot, we should disable irq in pt_regs->psr. And is_swbp_insn() need a csky arch implementation with a low 16bit mask. Signed-off-by: Guo Ren <[email protected]> Cc: Steven Rostedt (VMware) <[email protected]>
2020-05-13csky: Fixup compile error for abiv1 entry.SGuo Ren1-4/+4
This bug is from uprobe signal definition in thread_info.h. The instruction (andi) of abiv1 immediate is smaller than abiv2, then it will cause: AS arch/csky/kernel/entry.o arch/csky/kernel/entry.S: Assembler messages: arch/csky/kernel/entry.S:224: Error: Operand 2 immediate is overflow. Signed-off-by: Guo Ren <[email protected]>
2020-05-13csky/ftrace: Fixup error when disable CONFIG_DYNAMIC_FTRACEGuo Ren2-0/+4
When CONFIG_DYNAMIC_FTRACE is enabled, static ftrace will fail to boot up and compile. It's a carelessness when developing "dynamic ftrace" and "ftrace with regs". Signed-off-by: Guo Ren <[email protected]>
2020-05-13iommu/amd: Fix get_acpihid_device_id()Raul E Rangel1-1/+2
acpi_dev_hid_uid_match() expects a null pointer for UID if it doesn't exist. The acpihid_map_entry contains a char buffer for holding the UID. If no UID was provided in the IVRS table, this buffer will be zeroed. If we pass in a null string, acpi_dev_hid_uid_match() will return false because it will try and match an empty string to the ACPI UID of the device. Fixes: ae5e6c6439c3 ("iommu/amd: Switch to use acpi_dev_hid_uid_match()") Suggested-by: Andy Shevchenko <[email protected]> Signed-off-by: Raul E Rangel <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/20200511103229.v2.1.I6f1b6f973ee6c8af1348611370c73a0ec0ea53f1@changeid Signed-off-by: Joerg Roedel <[email protected]>
2020-05-13iommu/amd: Fix over-read of ACPI UID from IVRS tableAlexander Monakov1-4/+5
IVRS parsing code always tries to read 255 bytes from memory when retrieving ACPI device path, and makes an assumption that firmware provides a zero-terminated string. Both of those are bugs: the entry is likely to be shorter than 255 bytes, and zero-termination is not guaranteed. With Acer SF314-42 firmware these issues manifest visibly in dmesg: AMD-Vi: ivrs, add hid:AMDI0020, uid:\_SB.FUR0\xf0\xa5, rdevid:160 AMD-Vi: ivrs, add hid:AMDI0020, uid:\_SB.FUR1\xf0\xa5, rdevid:160 AMD-Vi: ivrs, add hid:AMDI0020, uid:\_SB.FUR2\xf0\xa5, rdevid:160 AMD-Vi: ivrs, add hid:AMDI0020, uid:\_SB.FUR3>\x83e\x8d\x9a\xd1... The first three lines show how the code over-reads adjacent table entries into the UID, and in the last line it even reads garbage data beyond the end of the IVRS table itself. Since each entry has the length of the UID (uidl member of ivhd_entry struct), use that for memcpy, and manually add a zero terminator. Avoid zero-filling hid and uid arrays up front, and instead ensure the uid array is always zero-terminated. No change needed for the hid array, as it was already properly zero-terminated. Fixes: 2a0cb4e2d423c ("iommu/amd: Add new map for storing IVHD dev entry type HID") Signed-off-by: Alexander Monakov <[email protected]> Cc: Joerg Roedel <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]>
2020-05-13ovl: potential crash in ovl_fid_to_fh()Dan Carpenter1-0/+3
The "buflen" value comes from the user and there is a potential that it could be zero. In do_handle_to_path() we know that "handle->handle_bytes" is non-zero and we do: handle_dwords = handle->handle_bytes >> 2; So values 1-3 become zero. Then in ovl_fh_to_dentry() we do: int len = fh_len << 2; So now len is in the "0,4-128" range and a multiple of 4. But if "buflen" is zero it will try to copy negative bytes when we do the memcpy in ovl_fid_to_fh(). memcpy(&fh->fb, fid, buflen - OVL_FH_WIRE_OFFSET); And that will lead to a crash. Thanks to Amir Goldstein for his help with this patch. Fixes: cbe7fba8edfc ("ovl: make sure that real fid is 32bit aligned in memory") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Amir Goldstein <[email protected]> Cc: <[email protected]> # v5.5 Signed-off-by: Miklos Szeredi <[email protected]>
2020-05-12clk: ti: clkctrl: convert subclocks to use proper names alsoTero Kristo1-50/+48
Addition of the new internal API to get the clkctrl names missed adding the same conversion in place for the subclocks. This leads into missed parent/child relationships (i.e. orphaned clocks) with mixed node name handling, for example with omap4/omap5 where the l4_per clocks are using new naming, but rest are using old. Fix by converting the subclock registration to pick correct names for the clocks also. Fixes: 6c3090520554 ("clk: ti: clkctrl: Fix hidden dependency to node name") Signed-off-by: Tero Kristo <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Acked-by: Tony Lindgren <[email protected]> Signed-off-by: Stephen Boyd <[email protected]>
2020-05-12clk: ti: am33xx: fix RTC clock parentTero Kristo1-1/+1
Right now, trying to use RTC purely with the ti-sysc / clkctrl framework fails to enable the RTC module properly. Based on experimentation, this appears to be because RTC is sourced from the clkdiv32k optional clock. TRM is not very clear on this topic, but fix the RTC to use the proper source clock nevertheless. Reported-by: Tony Lindgren <[email protected]> Signed-off-by: Tero Kristo <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Acked-by: Tony Lindgren <[email protected]> Signed-off-by: Stephen Boyd <[email protected]>
2020-05-12clk: ti: clkctrl: Fix Bad of_node_put within clkctrl_get_nameTero Kristo1-1/+0
clkctrl_get_name incorrectly calls of_node_put when it is not really doing of_node_get. This causes a boot time warning later on: [ 0.000000] OF: ERROR: Bad of_node_put() on /ocp/interconnect@4a000000/segmen t@0/target-module@5000/cm_core_aon@0/ipu-cm@500/ipu1-clkctrl@20 Fix by dropping the of_node_put from the function. Reported-by: Naresh Kamboju <[email protected]> Fixes: 6c3090520554 ("clk: ti: clkctrl: Fix hidden dependency to node name") Signed-off-by: Tero Kristo <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Acked-by: Tony Lindgren <[email protected]> Signed-off-by: Stephen Boyd <[email protected]>
2020-05-12netlabel: cope with NULL catmapPaolo Abeni3-3/+12
The cipso and calipso code can set the MLS_CAT attribute on successful parsing, even if the corresponding catmap has not been allocated, as per current configuration and external input. Later, selinux code tries to access the catmap if the MLS_CAT flag is present via netlbl_catmap_getlong(). That may cause null ptr dereference while processing incoming network traffic. Address the issue setting the MLS_CAT flag only if the catmap is really allocated. Additionally let netlbl_catmap_getlong() cope with NULL catmap. Reported-by: Matthew Sheets <[email protected]> Fixes: 4b8feff251da ("netlabel: fix the horribly broken catmap functions") Fixes: ceba1832b1b2 ("calipso: Set the calipso socket label to match the secattr.") Signed-off-by: Paolo Abeni <[email protected]> Acked-by: Paul Moore <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-05-12riscv: Make SYS_SUPPORTS_HUGETLBFS depends on MMUKefeng Wang1-0/+1
HUGETLBFS only used when MMU enabled, add the dependency. Reported-by: Hulk Robot <[email protected]> Signed-off-by: Kefeng Wang <[email protected]> Signed-off-by: Palmer Dabbelt <[email protected]>
2020-05-12riscv: Disable ARCH_HAS_DEBUG_VIRTUAL if NOMMUKefeng Wang1-1/+1
DEBUG_VIRTUAL should only used when MMU enabled, add the dependence. Signed-off-by: Kefeng Wang <[email protected]> Signed-off-by: Palmer Dabbelt <[email protected]>
2020-05-12riscv: Add pgprot_writecombine/device and PAGE_SHARED defination if NOMMUKefeng Wang2-0/+3
Some drivers use PAGE_SHARED, pgprot_writecombine()/pgprot_device(), add the defination to fix build error if NOMMU. Reported-by: Hulk Robot <[email protected]> Signed-off-by: Kefeng Wang <[email protected]> Signed-off-by: Palmer Dabbelt <[email protected]>
2020-05-12riscv: stacktrace: Fix undefined reference to `walk_stackframe'Kefeng Wang1-1/+1
Drop static declaration to fix following build error if FRAME_POINTER disabled, riscv64-linux-ld: arch/riscv/kernel/perf_callchain.o: in function `.L0': perf_callchain.c:(.text+0x2b8): undefined reference to `walk_stackframe' Reported-by: Hulk Robot <[email protected]> Signed-off-by: Kefeng Wang <[email protected]> Signed-off-by: Palmer Dabbelt <[email protected]>
2020-05-12Merge tag 'v5.7-rockchip-clk-fixes1' of ↵Stephen Boyd1-13/+4
git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into clk-fixes Pull one Rockchip clk fix from Heiko Stuebner: - Fix for wrongly defines rk3228 aclk_gpu* * tag 'v5.7-rockchip-clk-fixes1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip: clk: rockchip: fix incorrect configuration of rk3228 aclk_gpu* clocks
2020-05-12riscv: Fix unmet direct dependencies built based on SOC_VIRTKefeng Wang1-8/+9
Fix unmet direct dependencies Warning and fix Kconfig indent. WARNING: unmet direct dependencies detected for POWER_RESET_SYSCON Depends on [n]: POWER_RESET [=n] && OF [=y] && HAS_IOMEM [=y] Selected by [y]: - SOC_VIRT [=y] WARNING: unmet direct dependencies detected for POWER_RESET_SYSCON_POWEROFF Depends on [n]: POWER_RESET [=n] && OF [=y] && HAS_IOMEM [=y] Selected by [y]: - SOC_VIRT [=y] WARNING: unmet direct dependencies detected for RTC_DRV_GOLDFISH Depends on [n]: RTC_CLASS [=n] && OF [=y] && HAS_IOMEM [=y] && (GOLDFISH [=y] || COMPILE_TEST [=n]) Selected by [y]: - SOC_VIRT [=y] Reported-by: Hulk Robot <[email protected]> Signed-off-by: Kefeng Wang <[email protected]> Signed-off-by: Palmer Dabbelt <[email protected]>
2020-05-12clk: tegra: Fix initial rate for pll_a on Tegra124Thierry Reding1-1/+1
pll_a_out0 and the I2S clocks are already configured to default to rates corresponding to a 44.1 kHz sampling rate, but the pll_a configuration was set to a default that is not listed in the frequency table, which caused the PLL code to compute an invalid configuration. As a result of this invalid configuration, Jetson TK1 fails to resume from suspend. This used to get papered over because the ASoC driver would force audio clocks to a 44.1 kHz configuration on boot. However, that's not really necessary and was hence removed in commit ff5d18cb04f4 ("ASoC: tegra: Enable audio mclk during tegra_asoc_utils_init()"). Fix the initial rate for pll_a so that it matches the 44.1 kHz entry in the pll_a frequency table. Fixes: ff5d18cb04f4 ("ASoC: tegra: Enable audio mclk during tegra_asoc_utils_init()") Signed-off-by: Thierry Reding <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Stephen Boyd <[email protected]>
2020-05-12riscv: perf: RISCV_BASE_PMU should be independentKefeng Wang2-7/+3
Selecting PERF_EVENTS without selecting RISCV_BASE_PMU results in a build error. Signed-off-by: Kefeng Wang <[email protected]> [Palmer: commit text] Fixes: 178e9fc47aae("perf: riscv: preliminary RISC-V support") Signed-off-by: Palmer Dabbelt <[email protected]>
2020-05-12x86/ftrace: Have ftrace trampolines turn read-only at the end of system boot upSteven Rostedt (VMware)5-23/+60
Booting one of my machines, it triggered the following crash: Kernel/User page tables isolation: enabled ftrace: allocating 36577 entries in 143 pages Starting tracer 'function' BUG: unable to handle page fault for address: ffffffffa000005c #PF: supervisor write access in kernel mode #PF: error_code(0x0003) - permissions violation PGD 2014067 P4D 2014067 PUD 2015063 PMD 7b253067 PTE 7b252061 Oops: 0003 [#1] PREEMPT SMP PTI CPU: 0 PID: 0 Comm: swapper Not tainted 5.4.0-test+ #24 Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS SDBLI944.86P 05/08/2007 RIP: 0010:text_poke_early+0x4a/0x58 Code: 34 24 48 89 54 24 08 e8 bf 72 0b 00 48 8b 34 24 48 8b 4c 24 08 84 c0 74 0b 48 89 df f3 a4 48 83 c4 10 5b c3 9c 58 fa 48 89 df <f3> a4 50 9d 48 83 c4 10 5b e9 d6 f9 ff ff 0 41 57 49 RSP: 0000:ffffffff82003d38 EFLAGS: 00010046 RAX: 0000000000000046 RBX: ffffffffa000005c RCX: 0000000000000005 RDX: 0000000000000005 RSI: ffffffff825b9a90 RDI: ffffffffa000005c RBP: ffffffffa000005c R08: 0000000000000000 R09: ffffffff8206e6e0 R10: ffff88807b01f4c0 R11: ffffffff8176c106 R12: ffffffff8206e6e0 R13: ffffffff824f2440 R14: 0000000000000000 R15: ffffffff8206eac0 FS: 0000000000000000(0000) GS:ffff88807d400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffa000005c CR3: 0000000002012000 CR4: 00000000000006b0 Call Trace: text_poke_bp+0x27/0x64 ? mutex_lock+0x36/0x5d arch_ftrace_update_trampoline+0x287/0x2d5 ? ftrace_replace_code+0x14b/0x160 ? ftrace_update_ftrace_func+0x65/0x6c __register_ftrace_function+0x6d/0x81 ftrace_startup+0x23/0xc1 register_ftrace_function+0x20/0x37 func_set_flag+0x59/0x77 __set_tracer_option.isra.19+0x20/0x3e trace_set_options+0xd6/0x13e apply_trace_boot_options+0x44/0x6d register_tracer+0x19e/0x1ac early_trace_init+0x21b/0x2c9 start_kernel+0x241/0x518 ? load_ucode_intel_bsp+0x21/0x52 secondary_startup_64+0xa4/0xb0 I was able to trigger it on other machines, when I added to the kernel command line of both "ftrace=function" and "trace_options=func_stack_trace". The cause is the "ftrace=function" would register the function tracer and create a trampoline, and it will set it as executable and read-only. Then the "trace_options=func_stack_trace" would then update the same trampoline to include the stack tracer version of the function tracer. But since the trampoline already exists, it updates it with text_poke_bp(). The problem is that text_poke_bp() called while system_state == SYSTEM_BOOTING, it will simply do a memcpy() and not the page mapping, as it would think that the text is still read-write. But in this case it is not, and we take a fault and crash. Instead, lets keep the ftrace trampolines read-write during boot up, and then when the kernel executable text is set to read-only, the ftrace trampolines get set to read-only as well. Link: https://lkml.kernel.org/r/[email protected] Cc: Ingo Molnar <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Josh Poimboeuf <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Cc: [email protected] Fixes: 768ae4406a5c ("x86/ftrace: Use text_poke()") Acked-by: Peter Zijlstra <[email protected]> Signed-off-by: Steven Rostedt (VMware) <[email protected]>
2020-05-12RDMA/uverbs: Move IB_EVENT_DEVICE_FATAL to destroy_uobjJason Gunthorpe3-7/+10
When multiple async FDs were allowed to exist the idea was for all broadcast events to be delivered to all async FDs, however IB_EVENT_DEVICE_FATAL was missed. Instead of having ib_uverbs_free_hw_resources() special case the global async_fd, have it cause the event during the uobject destruction. Every async fd is now a uobject so simply generate the IB_EVENT_DEVICE_FATAL while destroying the async fd uobject. This ensures every async FD gets a copy of the event. Fixes: d680e88e2013 ("RDMA/core: Add UVERBS_METHOD_ASYNC_EVENT_ALLOC") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Yishai Hadas <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2020-05-12RDMA/uverbs: Do not discard the IB_EVENT_DEVICE_FATAL eventJason Gunthorpe4-3/+29
The commit below moved all of the destruction to the disassociate step and cleaned up the event channel during destroy_uobj. However, when ib_uverbs_free_hw_resources() pushes IB_EVENT_DEVICE_FATAL and then immediately goes to destroy all uobjects this causes ib_uverbs_free_event_queue() to discard the queued event if userspace hasn't already read() it. Unlike all other event queues async FD needs to defer the ib_uverbs_free_event_queue() until FD release. This still unregisters the handler from the IB device during disassociation. Fixes: 3e032c0e92aa ("RDMA/core: Make ib_uverbs_async_event_file into a uobject") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Yishai Hadas <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2020-05-12tcp: fix SO_RCVLOWAT hangs with fat skbsEric Dumazet3-4/+26
We autotune rcvbuf whenever SO_RCVLOWAT is set to account for 100% overhead in tcp_set_rcvlowat() This works well when skb->len/skb->truesize ratio is bigger than 0.5 But if we receive packets with small MSS, we can end up in a situation where not enough bytes are available in the receive queue to satisfy RCVLOWAT setting. As our sk_rcvbuf limit is hit, we send zero windows in ACK packets, preventing remote peer from sending more data. Even autotuning does not help, because it only triggers at the time user process drains the queue. If no EPOLLIN is generated, this can not happen. Note poll() has a similar issue, after commit c7004482e8dc ("tcp: Respect SO_RCVLOWAT in tcp_poll().") Fixes: 03f45c883c6f ("tcp: avoid extra wakeups for SO_RCVLOWAT users") Signed-off-by: Eric Dumazet <[email protected]> Acked-by: Soheil Hassas Yeganeh <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.