aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2019-11-30s390/head64: correct init_task stack setupVasily Gorbik1-1/+1
Add missing allocation of pt_regs at the bottom of the stack. This makes it consistent with other stack setup cases and also what stack unwinder expects. Reviewed-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2019-11-30s390/unwind: make reuse_sp default when unwinding pt_regsVasily Gorbik2-15/+7
Currently unwinder yields 2 entries when pt_regs are met: sp="address of pt_regs itself" ip=pt_regs->psw sp=pt_regs->gprs[15] ip="r14 from stack frame pointed by pt_regs->gprs[15]" And neither of those 2 states (combination of sp and ip) ever happened. reuse_sp has been introduced by commit a1d863ac3e10 ("s390/unwind: fix mixing regs and sp"). reuse_sp=true makes unwinder keen to produce the following result, when pt_regs are given (as an arg to unwind_start): sp=pt_regs->gprs[15] ip=pt_regs->psw sp=pt_regs->gprs[15] ip="r14 from stack frame pointed by pt_regs->gprs[15]" The first state is an actual state in which a task was when pt_regs were collected. The second state is marked unreliable and is for debugging purposes to cover the case when a task has been interrupted in between stack frame allocation and writing back_chain - in this case r14 might show an actual caller. Make unwinder behaviour enabled via reuse_sp=true default and drop the special case handling. Reviewed-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2019-11-30s390/unwind: report an error if pt_regs are not on stackVasily Gorbik1-1/+1
If unwinder is looking at pt_regs which is not on stack then something went wrong and an error has to be reported rather than successful unwinding termination. Reviewed-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2019-11-30s390: avoid misusing CALL_ON_STACK for task stack setupVasily Gorbik3-9/+13
CALL_ON_STACK is intended to be used for temporary stack switching with potential return to the caller. When CALL_ON_STACK is misused to switch from nodat stack to task stack back_chain information would later lead stack unwinder from task stack into (per cpu) nodat stack which is reused for other purposes. This would yield confusing unwinding result or errors. To avoid that introduce CALL_ON_STACK_NORETURN to be used instead. It makes sure that back_chain is zeroed and unwinder finishes gracefully ending up at task pt_regs. Reviewed-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2019-11-30s390: correct CALL_ON_STACK back_chain savingVasily Gorbik1-1/+14
Currently CALL_ON_STACK saves r15 as back_chain in the first stack frame of the stack we about to switch to. But if a function which uses CALL_ON_STACK calls other function it allocates a stack frame for a callee. In this case r15 is pointing to a callee stack frame and not a stack frame of function itself. This results in dummy unwinding entry with random sp and ip values. Introduce and utilize current_frame_address macro to get an address of actual function stack frame. Reviewed-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2019-11-30s390/unwind: unify task is current checksVasily Gorbik3-6/+3
Avoid mixture of task == NULL and task == current meaning the same thing and simply always initialize task with current in unwind_start. Reviewed-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2019-11-30s390: disable preemption when switching to nodat stack with CALL_ON_STACKVasily Gorbik2-3/+11
Make sure preemption is disabled when temporary switching to nodat stack with CALL_ON_STACK helper, because nodat stack is per cpu. Reviewed-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2019-11-30s390: always inline disabled_waitVasily Gorbik1-1/+1
disabled_wait uses _THIS_IP_ and assumes that compiler would inline it. Make sure this assumption is always correct by utilizing __always_inline. Reviewed-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2019-11-30s390/vdso: fix getcpuHeiko Carstens4-10/+14
getcpu reads the required values for cpu and node with two instructions. This might lead to an inconsistent result if user space gets preempted and migrated to a different CPU between the two instructions. Fix this by using just a single instruction to read both values at once. This is currently rather a theoretical bug, since there is no real NUMA support available (except for NUMA emulation). Reviewed-by: Christian Borntraeger <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2019-11-30s390/smp,vdso: fix ASCE handlingHeiko Carstens1-0/+5
When a secondary CPU is brought up it must initialize its control registers. CPU A which triggers that a secondary CPU B is brought up stores its control register contents into the lowcore of new CPU B, which then loads these values on startup. This is problematic in various ways: the control register which contains the home space ASCE will correctly contain the kernel ASCE; however control registers for primary and secondary ASCEs are initialized with whatever values were present in CPU A. Typically: - the primary ASCE will contain the user process ASCE of the process that triggered onlining of CPU B. - the secondary ASCE will contain the percpu VDSO ASCE of CPU A. Due to lazy ASCE handling we may also end up with other combinations. When then CPU B switches to a different process (!= idle) it will fixup the primary ASCE. However the problem is that the (wrong) ASCE from CPU A was loaded into control register 1: as soon as an ASCE is attached (aka loaded) a CPU is free to generate TLB entries using that address space. Even though it is very unlikey that CPU B will actually generate such entries, this could result in TLB entries of the address space of the process that ran on CPU A. These entries shouldn't exist at all and could cause problems later on. Furthermore the secondary ASCE of CPU B will not be updated correctly. This means that processes may see wrong results or even crash if they access VDSO data on CPU B. The correct VDSO ASCE will eventually be loaded on return to user space as soon as the kernel executed a call to strnlen_user or an atomic futex operation on CPU B. Fix both issues by intializing the to be loaded control register contents with the correct ASCEs and also enforce (re-)loading of the ASCEs upon first context switch and return to user space. Fixes: 0aaba41b58bc ("s390: remove all code using the access register mode") Cc: [email protected] # v4.15+ Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2019-11-30s390/zcrypt: handle new reply code FILTERED_BY_HYPERVISORHarald Freudenberger1-0/+2
This patch introduces support for a new architectured reply code 0x8B indicating that a hypervisor layer (if any) has rejected an ap message. Linux may run as a guest on top of a hypervisor like zVM or KVM. So the crypto hardware seen by the ap bus may be restricted by the hypervisor for example only a subset like only clear key crypto requests may be supported. Other requests will be filtered out - rejected by the hypervisor. The new reply code 0x8B will appear in such cases and needs to get recognized by the ap bus and zcrypt device driver zoo. Signed-off-by: Harald Freudenberger <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2019-11-30s390: implement perf_arch_fetch_caller_regsIlya Leoshkevich1-0/+7
On s390 bpf_get_stack_raw_tp() returns 0 entries for both kernel and user stacks. While there is no practical unwinding solution for userspace on s390 at this moment, there certainly is a kernel unwinder. However, it is not properly integrated with BPF. In order to start unwinding, bpf_get_stack_raw_tp() obtains the current kernel register values using perf_fetch_caller_regs(), which is not implemented for s390. The actual unwinding then happens by passing those registers to perf_callchain_kernel(). Implement perf_arch_fetch_caller_regs() for s390, where __builtin_frame_address(0) points to back_chain. Signed-off-by: Ilya Leoshkevich <[email protected]> Acked-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2019-11-29xtensa: clean up system_call/xtensa_rt_sigreturn interactionMax Filippov3-10/+6
system_call assembly code always pushes pointer to struct pt_regs as the last additional parameter for all system calls. The only user of this feature is xtensa_rt_sigreturn. Avoid this special case. Define xtensa_rt_sigreturn as accepting no argiments. Use current_pt_regs to get pointer to struct pt_regs in xtensa_rt_sigreturn. Don't pass additional parameter from system_call code. Signed-off-by: Max Filippov <[email protected]>
2019-11-29xtensa: fix system_call interaction with ptraceMax Filippov2-4/+18
Don't overwrite return value if system call was cancelled at entry by ptrace. Return status code from do_syscall_trace_enter so that pt_regs::syscall doesn't need to be changed to skip syscall. Signed-off-by: Max Filippov <[email protected]>
2019-11-29xtensa: rearrange syscall tracingMax Filippov3-7/+4
system_call saves and restores syscall number across system call to make clone and execv entry and exit tracing match. This complicates things when syscall code may be changed by ptrace. Preserve syscall code in copy_thread and start_thread directly instead of doing tricks in system_call. Signed-off-by: Max Filippov <[email protected]>
2019-11-29selftests: pmtu: use -oneline for ip route list cacheThadeu Lima de Souza Cascardo1-3/+2
Some versions of iproute2 will output more than one line per entry, which will cause the test to fail, like: TEST: ipv6: list and flush cached exceptions [FAIL] can't list cached exceptions That happens, for example, with iproute2 4.15.0. When using the -oneline option, this will work just fine: TEST: ipv6: list and flush cached exceptions [ OK ] This also works just fine with a more recent version of iproute2, like 5.4.0. For some reason, two lines are printed for the IPv4 test no matter what version of iproute2 is used. Use the same -oneline parameter there instead of counting the lines twice. Fixes: b964641e9925 ("selftests: pmtu: Make list_flush_ipv6_exception test more demanding") Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]> Acked-by: Stefano Brivio <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-11-29Merge branch 'for-5.5/whiskers' into for-linusJiri Kosina1-43/+103
- robustification of tablet mode support in google-whiskers driver (Dmitry Torokhov)
2019-11-29Merge branch 'for-5.5/logitech' into for-linusJiri Kosina7-0/+990
- Support for Logitech G15 (Hans de Goede) - silencing of non-informative error flow in dmesg from logitechi-hiddpp (Hans de Goede)
2019-11-29Merge branch 'for-5.5/ish' into for-linusJiri Kosina1-1/+1
- typo fix (Geert Uytterhoeven)
2019-11-29Merge branch 'for-5.5/i2c' into for-linusJiri Kosina1-2/+0
- removal of superfluous delay (You-Sheng Yang)
2019-11-29Merge branch 'for-5.5/hidraw' into for-linusJiri Kosina1-5/+5
- printk() -> pr_*() cleanup (Rishi Gupta)
2019-11-29Merge branch 'for-5.5/core' into for-linusJiri Kosina2806-29808/+47847
- hid_have_special_driver[] cleanup for LED devices (Heiner Kallweit) - HID parser improvements (Blaž Hrastnik, Candle Sun)
2019-11-29Merge tag 'kvm-ppc-uvmem-5.5-2' of ↵Paolo Bonzini15-0/+1137
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc into HEAD KVM: Add support for secure guests under the Protected Execution Framework (PEF) Ultravisor on POWER. This enables secure memory to be represented as device memory, which provides a way for the host to keep track of which pages of a secure guest have been moved into secure memory managed by the ultravisor and are no longer accessible by the host, and manage movement of pages between secure and normal memory.
2019-11-29Documentation: kvm: Fix mention to number of ioctls classesWainer dos Santos Moschetta1-1/+1
In api.txt it is said that KVM ioctls belong to three classes but in reality it is four. Fixed this, but do not count categories anymore to avoid such as outdated information in the future. Signed-off-by: Wainer dos Santos Moschetta <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2019-11-29io_uring: fix missing kmap() declaration on powerpcJens Axboe1-0/+1
Christophe reports that current master fails building on powerpc with this error: CC fs/io_uring.o fs/io_uring.c: In function ‘loop_rw_iter’: fs/io_uring.c:1628:21: error: implicit declaration of function ‘kmap’ [-Werror=implicit-function-declaration] iovec.iov_base = kmap(iter->bvec->bv_page) ^ fs/io_uring.c:1628:19: warning: assignment makes pointer from integer without a cast [-Wint-conversion] iovec.iov_base = kmap(iter->bvec->bv_page) ^ fs/io_uring.c:1643:4: error: implicit declaration of function ‘kunmap’ [-Werror=implicit-function-declaration] kunmap(iter->bvec->bv_page); ^ which is caused by a missing highmem.h include. Fix it by including it. Fixes: 311ae9e159d8 ("io_uring: fix dead-hung for non-iter fixed rw") Reported-by: Christophe Leroy <[email protected]> Tested-by: Christophe Leroy <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2019-11-29ALSA: hda - fixup for the bass speaker on Lenovo Carbon X1 7th genJaroslav Kysela1-0/+17
The auto-parser assigns the bass speaker to DAC3 (NID 0x06) which is without the volume control. I do not see a reason to use DAC2, because the shared output to all speakers produces the sufficient and well balanced sound. The stereo support is enough for this purpose (laptop). Signed-off-by: Jaroslav Kysela <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2019-11-29ALSA: hda: hdmi - preserve non-MST PCM routing for Intel platformsKai Vehmanen1-0/+5
Commit 5398e94fb753 ("ALSA: hda - Add DP-MST support for NVIDIA codecs") introduced a slight change of behaviour how non-MST monitors are assigned to PCMs on Intel platforms. In the drm_audio_component.h interface, the third parameter to pin_eld_notify() is pipe number. On Intel platforms, this value is -1 for MST. On other platforms, a non-zero pipe id is used to signal MST use. This difference leads to some subtle differences in hdmi_find_pcm_slot() with regards to how non-MST monitors are assigned to PCMs. This patch restores the original behaviour on Intel platforms while keeping the new allocation policy on other platforms. Signed-off-by: Kai Vehmanen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2019-11-29ALSA: hda: hdmi - fix kernel oops caused by invalid PCM idxKai Vehmanen1-11/+11
Add additional check in hdmi_find_pcm_slot() to not return a pcm index that points to unallocated pcm. This could happen if codec driver is set up in codec->mst_no_extra_pcms mode. On some platforms, this leads to a kernel oops in snd_ctl_notify(), called via update_eld(). BugLink: https://github.com/thesofproject/linux/issues/1536 Fixes: 5398e94fb753 ALSA: hda - Add DP-MST support for NVIDIA codecs Signed-off-by: Kai Vehmanen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2019-11-29PM / devfreq: Add missing locking while setting suspend_freqMarek Szyprowski1-0/+4
Commit 2abb0d5268ae ("PM / devfreq: Lock devfreq in trans_stat_show") revealed a missing locking while calling devfreq_update_status() function during suspend/resume cycle. Code analysis revealed that devfreq_set_target() function was called without needed locks held for setting device specific suspend_freq if such has been defined. This patch fixes that by adding the needed locking, what fixes following kernel warning on Exynos4412-based OdroidU3 board during system suspend: PM: suspend entry (deep) Filesystems sync: 0.002 seconds Freezing user space processes ... (elapsed 0.001 seconds) done. OOM killer disabled. Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. ------------[ cut here ]------------ WARNING: CPU: 2 PID: 1385 at drivers/devfreq/devfreq.c:204 devfreq_update_status+0xc0/0x188 Modules linked in: CPU: 2 PID: 1385 Comm: rtcwake Not tainted 5.4.0-rc6-next-20191111 #6848 Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [<c0112588>] (unwind_backtrace) from [<c010e070>] (show_stack+0x10/0x14) [<c010e070>] (show_stack) from [<c0afb010>] (dump_stack+0xb4/0xe0) [<c0afb010>] (dump_stack) from [<c01272e0>] (__warn+0xf4/0x10c) [<c01272e0>] (__warn) from [<c01273a8>] (warn_slowpath_fmt+0xb0/0xb8) [<c01273a8>] (warn_slowpath_fmt) from [<c07d105c>] (devfreq_update_status+0xc0/0x188) [<c07d105c>] (devfreq_update_status) from [<c07d2d70>] (devfreq_set_target+0xb0/0x15c) [<c07d2d70>] (devfreq_set_target) from [<c07d3598>] (devfreq_suspend+0x2c/0x64) [<c07d3598>] (devfreq_suspend) from [<c05de0b0>] (dpm_suspend+0xa4/0x57c) [<c05de0b0>] (dpm_suspend) from [<c05def74>] (dpm_suspend_start+0x98/0xa0) [<c05def74>] (dpm_suspend_start) from [<c0195b58>] (suspend_devices_and_enter+0xec/0xc74) [<c0195b58>] (suspend_devices_and_enter) from [<c0196a20>] (pm_suspend+0x340/0x410) [<c0196a20>] (pm_suspend) from [<c019480c>] (state_store+0x6c/0xc8) [<c019480c>] (state_store) from [<c033fc50>] (kernfs_fop_write+0x10c/0x228) [<c033fc50>] (kernfs_fop_write) from [<c02a6d3c>] (__vfs_write+0x30/0x1d0) [<c02a6d3c>] (__vfs_write) from [<c02a9afc>] (vfs_write+0xa4/0x180) [<c02a9afc>] (vfs_write) from [<c02a9d58>] (ksys_write+0x60/0xd8) [<c02a9d58>] (ksys_write) from [<c0101000>] (ret_fast_syscall+0x0/0x28) Exception stack(0xed3d7fa8 to 0xed3d7ff0) ... irq event stamp: 9667 hardirqs last enabled at (9679): [<c0b1e7c4>] _raw_spin_unlock_irq+0x20/0x58 hardirqs last disabled at (9698): [<c0b16a20>] __schedule+0xd8/0x818 softirqs last enabled at (9694): [<c01026fc>] __do_softirq+0x4fc/0x5fc softirqs last disabled at (9719): [<c012fe68>] irq_exit+0x16c/0x170 ---[ end trace 41ac5b57d046bdbc ]--- ------------[ cut here ]------------ Signed-off-by: Marek Szyprowski <[email protected]> Acked-by: Chanwoo Choi <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2019-11-29powerpc/fixmap: fix crash with HIGHMEMChristophe Leroy1-0/+6
Commit f2bb86937d86 ("powerpc/fixmap: don't clear fixmap area in paging_init()") removed the clearing of fixmap area in order to avoid clearing fixmapped areas set earlier. However unlike all other users of fixmap which use __set_fixmap(), HIGHMEM functions directly use __set_pte_at(). This means the page table must pre-exist, otherwise the following crash can be encoutered due to the lack of entry in the PGD. Oops: Kernel access of bad area, sig: 11 [#1] BE PAGE_SIZE=4K MMU=Hash PowerMac Modules linked in: CPU: 0 PID: 1 Comm: swapper Not tainted 5.4.0+ #2528 NIP: c0144ce8 LR: c0144ccc CTR: 00000080 REGS: ef0b5aa0 TRAP: 0300 Not tainted (5.4.0+) MSR: 00009032 <EE,ME,IR,DR,RI> CR: 44282842 XER: 00000000 DAR: fffdf000 DSISR: 42000000 GPR00: c0144ccc ef0b5b58 ef0b0000 fffdf000 fffdf000 00000000 c0000f7c 00000000 GPR08: c0833000 fffdf000 00000000 ef1c53c9 24042842 00000000 00000000 00000000 GPR16: 00000000 00000000 ef7e7358 effe8160 00000000 c08a9660 c0851644 00000004 GPR24: c08c70a8 00002dc2 00000000 00000001 00000201 effe8160 effe8160 00000000 NIP [c0144ce8] prep_new_page+0x138/0x178 LR [c0144ccc] prep_new_page+0x11c/0x178 Call Trace: [ef0b5b58] [c0144ccc] prep_new_page+0x11c/0x178 (unreliable) [ef0b5b88] [c0147218] get_page_from_freelist+0x1fc/0xd88 [ef0b5c38] [c0148328] __alloc_pages_nodemask+0xd4/0xbb4 [ef0b5cf8] [c0142ba8] __vmalloc_node_range+0x1b4/0x2e0 [ef0b5d38] [c0142dd0] vzalloc+0x48/0x58 [ef0b5d58] [c0301c8c] check_partition+0x58/0x244 [ef0b5d78] [c02ffe80] blk_add_partitions+0x44/0x2cc [ef0b5db8] [c01a32d8] bdev_disk_changed+0x68/0xfc [ef0b5de8] [c01a4494] __blkdev_get+0x290/0x460 [ef0b5e28] [c02fdd40] __device_add_disk+0x480/0x4d8 [ef0b5e68] [c0810688] brd_init+0xc0/0x188 [ef0b5e88] [c0005194] do_one_initcall+0x40/0x19c [ef0b5ee8] [c07dd4dc] kernel_init_freeable+0x164/0x230 [ef0b5f28] [c0005408] kernel_init+0x18/0x10c [ef0b5f38] [c0014274] ret_from_kernel_thread+0x14/0x1c Partially revert that commit to still clear the fixmap area dedicated to HIGHMEM. Fixes: f2bb86937d86 ("powerpc/fixmap: don't clear fixmap area in paging_init()") Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/d42fa9747df5afa41e67b08e374c98d3b40529c9.1574927918.git.christophe.leroy@c-s.fr
2019-11-29x86/efi: remove unused variablesYueHaibing1-5/+0
commit ad723674d675 ("x86/efi: move common keyring handler functions to new file") leave this unused. Fixes: ad723674d675 ("x86/efi: move common keyring handler functions to new file") Reported-by: Hulk Robot <[email protected]> Signed-off-by: YueHaibing <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2019-11-29PM / QoS: Restore DEV_PM_QOS_MIN/MAX_FREQUENCYLeonard Crestez3-7/+82
Support for adding per-device frequency limits was removed in commit 2aac8bdf7a0f ("PM: QoS: Drop frequency QoS types from device PM QoS") after cpufreq switched to use a new "freq_constraints" construct. Restore support for per-device freq limits but base this upon freq_constraints. This is primarily meant to be used by the devfreq subsystem. This removes the "static" marking on freq_qos_apply but does not export it for modules. Signed-off-by: Leonard Crestez <[email protected]> Reviewed-by: Matthias Kaehlcke <[email protected]> Tested-by: Matthias Kaehlcke <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2019-11-29PM / QoS: Reorder pm_qos/freq_qos/dev_pm_qos structsLeonard Crestez1-36/+38
This allows dev_pm_qos to embed freq_qos structs, which is done in the next patch. Separate commit to make it easier to review. Signed-off-by: Leonard Crestez <[email protected]> Reviewed-by: Matthias Kaehlcke <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2019-11-29PM / QoS: Initial kunit testLeonard Crestez3-0/+122
The pm_qos family of APIs are used in relatively difficult to reproduce scenarios such as thermal throttling so they benefit from unit testing. Start by adding basic tests from the the freq_qos APIs. It includes tests for issues that were brought up on mailing lists: https://patchwork.kernel.org/patch/11252425/#23017005 https://patchwork.kernel.org/patch/11253421/ Signed-off-by: Leonard Crestez <[email protected]> Reviewed-by: Matthias Kaehlcke <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2019-11-29PM / QoS: Redefine FREQ_QOS_MAX_DEFAULT_VALUE to S32_MAXLeonard Crestez1-1/+1
QOS requests for DEFAULT_VALUE are supposed to be ignored but this is not the case for FREQ_QOS_MAX. Adding one request for MAX_DEFAULT_VALUE and one for a real value will cause freq_qos_read_value to unexpectedly return MAX_DEFAULT_VALUE (-1). This happens because freq_qos max value is aggregated with PM_QOS_MIN but FREQ_QOS_MAX_DEFAULT_VALUE is (-1) so it's smaller than other values. Fix this by redefining FREQ_QOS_MAX_DEFAULT_VALUE to S32_MAX. Looking at current users for freq_qos it seems that none of them create requests for FREQ_QOS_MAX_DEFAULT_VALUE. Fixes: 77751a466ebd ("PM: QoS: Introduce frequency QoS") Signed-off-by: Leonard Crestez <[email protected]> Reported-by: Matthias Kaehlcke <[email protected]> Reviewed-by: Matthias Kaehlcke <[email protected]> Cc: 5.4+ <[email protected]> # 5.4+ Signed-off-by: Rafael J. Wysocki <[email protected]>
2019-11-29power: avs: Fix Kconfig indentationKrzysztof Kozlowski1-6/+6
Adjust indentation from spaces to tab (+optional two spaces) as in coding style with command like: $ sed -e 's/^ /\t/' -i */Kconfig Signed-off-by: Krzysztof Kozlowski <[email protected]> Acked-by: Kevin Hilman <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2019-11-29cpufreq: Fix Kconfig indentationKrzysztof Kozlowski2-12/+12
Adjust indentation from spaces to tab (+optional two spaces) as in coding style with command like: $ sed -e 's/^ /\t/' -i */Kconfig Signed-off-by: Krzysztof Kozlowski <[email protected]> Acked-by: Viresh Kumar <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2019-11-29cpuidle: minor Kconfig help text fixesRandy Dunlap1-3/+3
End sentences in help text with a period (aka full stop). Signed-off-by: Randy Dunlap <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2019-11-29cpuidle: Drop disabled field from struct cpuidle_stateRafael J. Wysocki5-10/+9
After recent cpuidle updates the "disabled" field in struct cpuidle_state is only used by two drivers (intel_idle and shmobile cpuidle) for marking unusable idle states, but that may as well be achieved with the help of a state flag, so define an "unusable" idle state flag, CPUIDLE_FLAG_UNUSABLE, make the drivers in question use it instead of the "disabled" field and make the core set CPUIDLE_STATE_DISABLED_BY_DRIVER for the idle states with that flag set. After the above changes, the "disabled" field in struct cpuidle_state is not used any more, so drop it. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <[email protected]>
2019-11-29cpuidle: Fix Kconfig indentationKrzysztof Kozlowski2-16/+16
Adjust indentation from spaces to tab (+optional two spaces) as in coding style with command like: $ sed -e 's/^ /\t/' -i */Kconfig Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2019-11-29ACPI: bus: Fix NULL pointer check in acpi_bus_get_private_data()Vamshi K Sthambamkadi1-1/+1
kmemleak reported backtrace: [<bbee0454>] kmem_cache_alloc_trace+0x128/0x260 [<6677f215>] i2c_acpi_install_space_handler+0x4b/0xe0 [<1180f4fc>] i2c_register_adapter+0x186/0x400 [<6083baf7>] i2c_add_adapter+0x4e/0x70 [<a3ddf966>] intel_gmbus_setup+0x1a2/0x2c0 [i915] [<84cb69ae>] i915_driver_probe+0x8d8/0x13a0 [i915] [<81911d4b>] i915_pci_probe+0x48/0x160 [i915] [<4b159af1>] pci_device_probe+0xdc/0x160 [<b3c64704>] really_probe+0x1ee/0x450 [<bc029f5a>] driver_probe_device+0x142/0x1b0 [<d8829d20>] device_driver_attach+0x49/0x50 [<de71f045>] __driver_attach+0xc9/0x150 [<df33ac83>] bus_for_each_dev+0x56/0xa0 [<80089bba>] driver_attach+0x19/0x20 [<cc73f583>] bus_add_driver+0x177/0x220 [<7b29d8c7>] driver_register+0x56/0xf0 In i2c_acpi_remove_space_handler(), a leak occurs whenever the "data" parameter is initialized to 0 before being passed to acpi_bus_get_private_data(). This is because the NULL pointer check in acpi_bus_get_private_data() (condition->if(!*data)) returns EINVAL and, in consequence, memory is never freed in i2c_acpi_remove_space_handler(). Fix the NULL pointer check in acpi_bus_get_private_data() to follow the analogous check in acpi_get_data_full(). Signed-off-by: Vamshi K Sthambamkadi <[email protected]> [ rjw: Subject & changelog ] Cc: All applicable <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2019-11-29Revert "jffs2: Fix possible null-pointer dereferences in ↵Joel Stanley1-1/+1
jffs2_add_frag_to_fragtree()" This reverts commit f2538f999345405f7d2e1194c0c8efa4e11f7b3a. The patch stopped JFFS2 from being able to mount an existing filesystem with the following errors: jffs2: error: (77) jffs2_build_inode_fragtree: Add node to tree failed -22 jffs2: error: (77) jffs2_do_read_inode_internal: Failed to build final fragtree for inode #5377: error -22 Fixes: f2538f999345 ("jffs2: Fix possible null-pointer dereferences...") Cc: [email protected] Suggested-by: Hou Tao <[email protected]> Signed-off-by: Joel Stanley <[email protected]> Signed-off-by: Richard Weinberger <[email protected]>
2019-11-29ACPI: Fix Kconfig indentationKrzysztof Kozlowski1-4/+4
Adjust indentation from spaces to tab (+optional two spaces) as in coding style with command like: $ sed -e 's/^ /\t/' -i */Kconfig Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2019-11-29ACPI: OSL: only free map once in osl.cFrancesco Ruggeri1-11/+17
acpi_os_map_cleanup checks map->refcount outside of acpi_ioremap_lock before freeing the map. This creates a race condition the can result in the map being freed more than once. A panic can be caused by running for ((i=0; i<10; i++)) do for ((j=0; j<100000; j++)) do cat /sys/firmware/acpi/tables/data/BERT >/dev/null done & done This patch makes sure that only the process that drops the reference to 0 does the freeing. Fixes: b7c1fadd6c2e ("ACPI: Do not use krefs under a mutex in osl.c") Signed-off-by: Francesco Ruggeri <[email protected]> Reviewed-by: Dmitry Safonov <[email protected]> Cc: All applicable <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2019-11-29ACPI: button: Add DMI quirk for Acer Switch 10 SW5-032 lid-switchHans de Goede1-0/+13
The Acer Switch 10 SW5-032 _LID method is quite broken, it looks like this: Method (_LID, 0, NotSerialized) // _LID: Lid Status { If ((STAS & One)) { Local0 = One PBCG |= 0x05000000 HMCG |= 0x05000000 } Else { Local0 = Zero PBCG &= 0xF0FFFFFF HMCG &= 0xF0FFFFFF } ^^PCI0.GFX0.CLID = Local0 Return (Local0) } The problem here is the accesses to the PBCG and HMCG, these are the pinconf0 registers for the power, resp. the home button GPIO, e.g. PBCG is declared as: OperationRegion (PWBT, SystemMemory, 0xFED0E080, 0x10) Field (PWBT, DWordAcc, NoLock, Preserve) { PBCG, 32, PBV1, 32, PBSA, 32, PBV2, 32 } Where 0xFED0E000 is the base address of the GPO2 device and 0x80 is the offset for the pin used for the powerbutton. The problem here is this line in _LID: PBCG |= 0x05000000 This changes the trigger flags of the GPIO, changing when it generates interrupts. Note it does not clear the original flags. Linux uses an edge triggered interrupt on both positive and negative edges. This |= adds the BYT_TRIG_LVL flag to this, so now it is turned into a level interrupt which fires both when low and high, iow it simply always fires leading to an interrupt storm, the tablet immediately waking up from suspend again, etc. There is nothing we can do to fix this, except for a DSDT override, which the user needs to do manually. The only thing we can do is never call _LID, which requires disabling the lid-switch functionality altogether. This commit adds a quirk for this, as no lid-switch function is better then the interrupt storm. A user manually applying a DSDT override can also override the quirk on the kernel cmdline. Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Mika Westerberg <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2019-11-29bpf: Force .BTF section start to zero when dumping from vmlinuxStanislav Fomichev1-2/+3
While trying to figure out why fentry_fexit selftest doesn't pass for me (old pahole, broken BTF), I found out that my latest patch can break vmlinux .BTF generation. objcopy preserves section start when doing --only-section, so there is a chance (depending on where pahole inserts .BTF section) to have leading empty zeroes. Let's explicitly force section offset to zero. Before: $ objcopy --set-section-flags .BTF=alloc -O binary \ --only-section=.BTF vmlinux .btf.vmlinux.bin $ xxd .btf.vmlinux.bin | head -n1 00000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................ After: $ objcopy --change-section-address .BTF=0 \ --set-section-flags .BTF=alloc -O binary \ --only-section=.BTF vmlinux .btf.vmlinux.bin $ xxd .btf.vmlinux.bin | head -n1 00000000: 9feb 0100 1800 0000 0000 0000 80e1 1c00 ................ ^BTF magic As part of this change, I'm also dropping '2>/dev/null' from objcopy invocation to be able to catch possible other issues (objcopy doesn't produce any warnings for me anymore, it did before with --dump-section). Fixes: da5fb18225b4 ("bpf: Support pre-2.25-binutils objcopy for vmlinux BTF") Signed-off-by: Stanislav Fomichev <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Acked-by: John Fastabend <[email protected]> Cc: Andrii Nakryiko <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2019-11-29x86/mce/therm_throt: Mask out read-only and reserved MSR bitsSrinivas Pandruvada1-5/+12
While writing to MSR IA32_THERM_STATUS/IA32_PKG_THERM_STATUS, avoid writing 1 to read only and reserved fields because updating some fields generates exception. [ bp: Vertically align for better readability. ] Fixes: f6656208f04e ("x86/mce/therm_throt: Optimize notifications of thermal throttle") Reported-by: Dominik Brodowski <[email protected]> Tested-by: Dominik Brodowski <[email protected]> Signed-off-by: Srinivas Pandruvada <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: linux-edac <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Tony Luck <[email protected]> Cc: x86-ml <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2019-11-28Merge branch 'tipc-Fix-some-bugs-at-socket-layer'David S. Miller1-9/+15
Tung Nguyen says: ==================== tipc: Fix some bugs at socket layer This series fixes some bugs at socket layer. ==================== Signed-off-by: David S. Miller <[email protected]>
2019-11-28tipc: fix duplicate SYN messages under link congestionTung Nguyen1-7/+10
Scenario: 1. A client socket initiates a SYN message to a listening socket. 2. The send link is congested, the SYN message is put in the send link and a wakeup message is put in wakeup queue. 3. The congestion situation is abated, the wakeup message is pulled out of the wakeup queue. Function tipc_sk_push_backlog() is called to send out delayed messages by Nagle. However, the client socket is still in CONNECTING state. So, it sends the SYN message in the socket write queue to the listening socket again. 4. The listening socket receives the first SYN message and creates first server socket. The client socket receives ACK- and establishes a connection to the first server socket. The client socket closes its connection with the first server socket. 5. The listening socket receives the second SYN message and creates second server socket. The second server socket sends ACK- to the client socket, but it has been closed. It results in connection reset error when reading from the server socket in user space. Solution: return from function tipc_sk_push_backlog() immediately if there is pending SYN message in the socket write queue. Fixes: c0bceb97db9e ("tipc: add smart nagle feature") Signed-off-by: Tung Nguyen <[email protected]> Acked-by: Jon Maloy <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-11-28tipc: fix wrong timeout input for tipc_wait_for_cond()Tung Nguyen1-1/+1
In function __tipc_shutdown(), the timeout value passed to tipc_wait_for_cond() is not jiffies. This commit fixes it by converting that value from milliseconds to jiffies. Fixes: 365ad353c256 ("tipc: reduce risk of user starvation during link congestion") Signed-off-by: Tung Nguyen <[email protected]> Acked-by: Jon Maloy <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.