aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2018-06-15mm/memblock: add missing include <linux/bootmem.h>Mathieu Malaterre1-0/+1
Commit 26f09e9b3a06 ("mm/memblock: add memblock memory allocation apis") introduced two new function definitions: memblock_virt_alloc_try_nid_nopanic() memblock_virt_alloc_try_nid() Commit ea1f5f3712af ("mm: define memblock_virt_alloc_try_nid_raw") introduced the following function definition: memblock_virt_alloc_try_nid_raw() This commit adds an includeof header file <linux/bootmem.h> to provide the missing function prototypes. Silence the following gcc warning (W=1): mm/memblock.c:1334:15: warning: no previous prototype for `memblock_virt_alloc_try_nid_raw' [-Wmissing-prototypes] mm/memblock.c:1371:15: warning: no previous prototype for `memblock_virt_alloc_try_nid_nopanic' [-Wmissing-prototypes] mm/memblock.c:1407:15: warning: no previous prototype for `memblock_virt_alloc_try_nid' [-Wmissing-prototypes] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Mathieu Malaterre <[email protected]> Reviewed-by: Andrew Morton <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-06-15mm: check for SIGKILL inside dup_mmap() loopTetsuo Handa1-0/+8
As a theoretical problem, dup_mmap() of an mm_struct with 60000+ vmas can loop while potentially allocating memory, with mm->mmap_sem held for write by current thread. This is bad if current thread was selected as an OOM victim, for current thread will continue allocations using memory reserves while OOM reaper is unable to reclaim memory. As an actually observable problem, it is not difficult to make OOM reaper unable to reclaim memory if the OOM victim is blocked at i_mmap_lock_write() in this loop. Unfortunately, since nobody can explain whether it is safe to use killable wait there, let's check for SIGKILL before trying to allocate memory. Even without an OOM event, there is no point with continuing the loop from the beginning if current thread is killed. I tested with debug printk(). This patch should be safe because we already fail if security_vm_enough_memory_mm() or kmem_cache_alloc(GFP_KERNEL) fails and exit_mmap() handles it. ***** Aborting dup_mmap() due to SIGKILL ***** ***** Aborting dup_mmap() due to SIGKILL ***** ***** Aborting dup_mmap() due to SIGKILL ***** ***** Aborting dup_mmap() due to SIGKILL ***** ***** Aborting exit_mmap() due to NULL mmap ***** [[email protected]: add comment] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Tetsuo Handa <[email protected]> Cc: Alexander Viro <[email protected]> Cc: Rik van Riel <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Kirill A. Shutemov <[email protected]> Cc: David Rientjes <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-06-15kexec: yield to scheduler when loading kimage segmentsJarrett Farnitano1-0/+4
Without yielding while loading kimage segments, a large initrd will block all other work on the CPU performing the load until it is completed. For example loading an initrd of 200MB on a low power single core system will lock up the system for a few seconds. To increase system responsiveness to other tasks at that time, call cond_resched() in both the crash kernel and normal kernel segment loading loops. I did run into a practical problem. Hardware watchdogs on embedded systems can have short timers on the order of seconds. If the system is locked up for a few seconds with only a single core available, the watchdog may not be pet in a timely fashion. If this happens, the hardware watchdog will fire and reset the system. This really only becomes a problem when you are working with a single core, a decently sized initrd, and have a constrained hardware watchdog. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Jarrett Farnitano <[email protected]> Reviewed-by: "Eric W. Biederman" <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-06-15mm: fix race between kmem_cache destroy, create and deactivateShakeel Butt2-1/+33
The memcg kmem cache creation and deactivation (SLUB only) is asynchronous. If a root kmem cache is destroyed whose memcg cache is in the process of creation or deactivation, the kernel may crash. Example of one such crash: general protection fault: 0000 [#1] SMP PTI CPU: 1 PID: 1721 Comm: kworker/14:1 Not tainted 4.17.0-smp ... Workqueue: memcg_kmem_cache kmemcg_deactivate_workfn RIP: 0010:has_cpu_slab ... Call Trace: ? on_each_cpu_cond __kmem_cache_shrink kmemcg_cache_deact_after_rcu kmemcg_deactivate_workfn process_one_work worker_thread kthread ret_from_fork+0x35/0x40 To fix this race, on root kmem cache destruction, mark the cache as dying and flush the workqueue used for memcg kmem cache creation and deactivation. SLUB's memcg kmem cache deactivation also includes RCU callback and thus make sure all previous registered RCU callbacks have completed as well. [[email protected]: handle the RCU callbacks for SLUB deactivation] Link: http://lkml.kernel.org/r/[email protected] [[email protected]: add more documentation, rename fields for readability] Link: http://lkml.kernel.org/r/[email protected] [[email protected]: fix build, per Shakeel] [[email protected]: v3. Instead of refcount, flush the workqueue] Link: http://lkml.kernel.org/r/[email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Shakeel Butt <[email protected]> Acked-by: Vladimir Davydov <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Greg Thelen <[email protected]> Cc: Christoph Lameter <[email protected]> Cc: Pekka Enberg <[email protected]> Cc: David Rientjes <[email protected]> Cc: Joonsoo Kim <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: Tejun Heo <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-06-15mm: fix devmem_is_allowed() for sub-page System RAM intersectionsDan Williams1-1/+3
Hussam reports: I was poking around and for no real reason, I did cat /dev/mem and strings /dev/mem. Then I saw the following warning in dmesg. I saved it and rebooted immediately. memremap attempted on mixed range 0x000000000009c000 size: 0x1000 ------------[ cut here ]------------ WARNING: CPU: 0 PID: 11810 at kernel/memremap.c:98 memremap+0x104/0x170 [..] Call Trace: xlate_dev_mem_ptr+0x25/0x40 read_mem+0x89/0x1a0 __vfs_read+0x36/0x170 The memremap() implementation checks for attempts to remap System RAM with MEMREMAP_WB and instead redirects those mapping attempts to the linear map. However, that only works if the physical address range being remapped is page aligned. In low memory we have situations like the following: 00000000-00000fff : Reserved 00001000-0009fbff : System RAM 0009fc00-0009ffff : Reserved ...where System RAM intersects Reserved ranges on a sub-page page granularity. Given that devmem_is_allowed() special cases any attempt to map System RAM in the first 1MB of memory, replace page_is_ram() with the more precise region_intersects() to trap attempts to map disallowed ranges. Link: https://bugzilla.kernel.org/show_bug.cgi?id=199999 Link: http://lkml.kernel.org/r/152856436164.18127.2847888121707136898.stgit@dwillia2-desk3.amr.corp.intel.com Fixes: 92281dee825f ("arch: introduce memremap()") Signed-off-by: Dan Williams <[email protected]> Reported-by: Hussam Al-Tayeb <[email protected]> Tested-by: Hussam Al-Tayeb <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-06-15mm/swapfile.c: fix swap_count comment about nonexistent SWAP_HAS_CONTDaniel Jordan1-1/+1
Commit 570a335b8e22 ("swap_info: swap count continuations") introduces COUNT_CONTINUED but refers to it incorrectly as SWAP_HAS_CONT in a comment in swap_count. Fix it. Link: http://lkml.kernel.org/r/[email protected] Fixes: 570a335b8e22 ("swap_info: swap count continuations") Signed-off-by: Daniel Jordan <[email protected]> Reviewed-by: Andrew Morton <[email protected]> Cc: "Huang, Ying" <[email protected]> Cc: Hugh Dickins <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-06-15mm: fix null pointer dereference in mem_cgroup_protectedRoman Gushchin1-0/+4
Shakeel reported a crash in mem_cgroup_protected(), which can be triggered by memcg reclaim if the legacy cgroup v1 use_hierarchy=0 mode is used: BUG: unable to handle kernel NULL pointer dereference at 0000000000000120 PGD 8000001ff55da067 P4D 8000001ff55da067 PUD 1fdc7df067 PMD 0 Oops: 0000 [#4] SMP PTI CPU: 0 PID: 15581 Comm: bash Tainted: G D 4.17.0-smp-clean #5 Hardware name: ... RIP: 0010:mem_cgroup_protected+0x54/0x130 Code: 4c 8b 8e 00 01 00 00 4c 8b 86 08 01 00 00 48 8d 8a 08 ff ff ff 48 85 d2 ba 00 00 00 00 48 0f 44 ca 48 39 c8 0f 84 cf 00 00 00 <48> 8b 81 20 01 00 00 4d 89 ca 4c 39 c8 4c 0f 46 d0 4d 85 d2 74 05 RSP: 0000:ffffabe64dfafa58 EFLAGS: 00010286 RAX: ffff9fb6ff03d000 RBX: ffff9fb6f5b1b000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff9fb6f5b1b000 RDI: ffff9fb6f5b1b000 RBP: ffffabe64dfafb08 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 000000000000c800 R12: ffffabe64dfafb88 R13: ffff9fb6f5b1b000 R14: ffffabe64dfafb88 R15: ffff9fb77fffe000 FS: 00007fed1f8ac700(0000) GS:ffff9fb6ff400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000120 CR3: 0000001fdcf86003 CR4: 00000000001606f0 Call Trace: ? shrink_node+0x194/0x510 do_try_to_free_pages+0xfd/0x390 try_to_free_mem_cgroup_pages+0x123/0x210 try_charge+0x19e/0x700 mem_cgroup_try_charge+0x10b/0x1a0 wp_page_copy+0x134/0x5b0 do_wp_page+0x90/0x460 __handle_mm_fault+0x8e3/0xf30 handle_mm_fault+0xfe/0x220 __do_page_fault+0x262/0x500 do_page_fault+0x28/0xd0 ? page_fault+0x8/0x30 page_fault+0x1e/0x30 RIP: 0033:0x485b72 The problem happens because parent_mem_cgroup() returns a NULL pointer, which is dereferenced later without a check. As cgroup v1 has no memory guarantee support, let's make mem_cgroup_protected() immediately return MEMCG_PROT_NONE, if the given cgroup has no parent (non-hierarchical mode is used). Link: http://lkml.kernel.org/r/[email protected] Fixes: bf8d5d52ffe8 ("memcg: introduce memory.min") Signed-off-by: Roman Gushchin <[email protected]> Reported-by: Shakeel Butt <[email protected]> Tested-by: Shakeel Butt <[email protected]> Tested-by: John Stultz <[email protected]> Acked-by: Johannes Weiner <[email protected]> Acked-by: Michal Hocko <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-06-15mm/ksm.c: ignore STABLE_FLAG of rmap_item->address in rmap_walk_ksm()Jia He1-4/+10
In our armv8a server(QDF2400), I noticed lots of WARN_ON caused by PAGE_SIZE unaligned for rmap_item->address under memory pressure tests(start 20 guests and run memhog in the host). WARNING: CPU: 4 PID: 4641 at virt/kvm/arm/mmu.c:1826 kvm_age_hva_handler+0xc0/0xc8 CPU: 4 PID: 4641 Comm: memhog Tainted: G W 4.17.0-rc3+ #8 Call trace: kvm_age_hva_handler+0xc0/0xc8 handle_hva_to_gpa+0xa8/0xe0 kvm_age_hva+0x4c/0xe8 kvm_mmu_notifier_clear_flush_young+0x54/0x98 __mmu_notifier_clear_flush_young+0x6c/0xa0 page_referenced_one+0x154/0x1d8 rmap_walk_ksm+0x12c/0x1d0 rmap_walk+0x94/0xa0 page_referenced+0x194/0x1b0 shrink_page_list+0x674/0xc28 shrink_inactive_list+0x26c/0x5b8 shrink_node_memcg+0x35c/0x620 shrink_node+0x100/0x430 do_try_to_free_pages+0xe0/0x3a8 try_to_free_pages+0xe4/0x230 __alloc_pages_nodemask+0x564/0xdc0 alloc_pages_vma+0x90/0x228 do_anonymous_page+0xc8/0x4d0 __handle_mm_fault+0x4a0/0x508 handle_mm_fault+0xf8/0x1b0 do_page_fault+0x218/0x4b8 do_translation_fault+0x90/0xa0 do_mem_abort+0x68/0xf0 el0_da+0x24/0x28 In rmap_walk_ksm, the rmap_item->address might still have the STABLE_FLAG, then the start and end in handle_hva_to_gpa might not be PAGE_SIZE aligned. Thus it will cause exceptions in handle_hva_to_gpa on arm64. This patch fixes it by ignoring (not removing) the low bits of address when doing rmap_walk_ksm. IMO, it should be backported to stable tree. the storm of WARN_ONs is very easy for me to reproduce. More than that, I watched a panic (not reproducible) as follows: page:ffff7fe003742d80 count:-4871 mapcount:-2126053375 mapping: (null) index:0x0 flags: 0x1fffc00000000000() raw: 1fffc00000000000 0000000000000000 0000000000000000 ffffecf981470000 raw: dead000000000100 dead000000000200 ffff8017c001c000 0000000000000000 page dumped because: nonzero _refcount CPU: 29 PID: 18323 Comm: qemu-kvm Tainted: G W 4.14.15-5.hxt.aarch64 #1 Hardware name: <snip for confidential issues> Call trace: dump_backtrace+0x0/0x22c show_stack+0x24/0x2c dump_stack+0x8c/0xb0 bad_page+0xf4/0x154 free_pages_check_bad+0x90/0x9c free_pcppages_bulk+0x464/0x518 free_hot_cold_page+0x22c/0x300 __put_page+0x54/0x60 unmap_stage2_range+0x170/0x2b4 kvm_unmap_hva_handler+0x30/0x40 handle_hva_to_gpa+0xb0/0xec kvm_unmap_hva_range+0x5c/0xd0 I even injected a fault on purpose in kvm_unmap_hva_range by seting size=size-0x200, the call trace is similar as above. So I thought the panic is similarly caused by the root cause of WARN_ON. Andrea said: : It looks a straightforward safe fix, on x86 hva_to_gfn_memslot would : zap those bits and hide the misalignment caused by the low metadata : bits being erroneously left set in the address, but the arm code : notices when that's the last page in the memslot and the hva_end is : getting aligned and the size is below one page. : : I think the problem triggers in the addr += PAGE_SIZE of : unmap_stage2_ptes that never matches end because end is aligned but : addr is not. : : } while (pte++, addr += PAGE_SIZE, addr != end); : : x86 again only works on hva_start/hva_end after converting it to : gfn_start/end and that being in pfn units the bits are zapped before : they risk to cause trouble. Jia He said: : I've tested by myself in arm64 server (QDF2400,46 cpus,96G mem) Without : this patch, the WARN_ON is very easy for reproducing. After this patch, I : have run the same benchmarch for a whole day without any WARN_ONs Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Jia He <[email protected]> Reviewed-by: Andrea Arcangeli <[email protected]> Tested-by: Jia He <[email protected]> Cc: Suzuki K Poulose <[email protected]> Cc: Minchan Kim <[email protected]> Cc: Claudio Imbrenda <[email protected]> Cc: Arvind Yadav <[email protected]> Cc: Mike Rapoport <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-06-15Merge tag 'vfs-timespec64' of ↵Linus Torvalds85-424/+539
git://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground Pull inode timestamps conversion to timespec64 from Arnd Bergmann: "This is a late set of changes from Deepa Dinamani doing an automated treewide conversion of the inode and iattr structures from 'timespec' to 'timespec64', to push the conversion from the VFS layer into the individual file systems. As Deepa writes: 'The series aims to switch vfs timestamps to use struct timespec64. Currently vfs uses struct timespec, which is not y2038 safe. The series involves the following: 1. Add vfs helper functions for supporting struct timepec64 timestamps. 2. Cast prints of vfs timestamps to avoid warnings after the switch. 3. Simplify code using vfs timestamps so that the actual replacement becomes easy. 4. Convert vfs timestamps to use struct timespec64 using a script. This is a flag day patch. Next steps: 1. Convert APIs that can handle timespec64, instead of converting timestamps at the boundaries. 2. Update internal data structures to avoid timestamp conversions' Thomas Gleixner adds: 'I think there is no point to drag that out for the next merge window. The whole thing needs to be done in one go for the core changes which means that you're going to play that catchup game forever. Let's get over with it towards the end of the merge window'" * tag 'vfs-timespec64' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground: pstore: Remove bogus format string definition vfs: change inode times to use struct timespec64 pstore: Convert internal records to timespec64 udf: Simplify calls to udf_disk_stamp_to_time fs: nfs: get rid of memcpys for inode times ceph: make inode time prints to be long long lustre: Use long long type to print inode time fs: add timespec64_truncate()
2018-06-15Merge tag 'ceph-for-4.18-rc1' of git://github.com/ceph/ceph-clientLinus Torvalds15-256/+372
Pull ceph updates from Ilya Dryomov: "The main piece is a set of libceph changes that revamps how OSD requests are aborted, improving CephFS ENOSPC handling and making "umount -f" actually work (Zheng and myself). The rest is mostly mount option handling cleanups from Chengguang and assorted fixes from Zheng, Luis and Dongsheng. * tag 'ceph-for-4.18-rc1' of git://github.com/ceph/ceph-client: (31 commits) rbd: flush rbd_dev->watch_dwork after watch is unregistered ceph: update description of some mount options ceph: show ino32 if the value is different with default ceph: strengthen rsize/wsize/readdir_max_bytes validation ceph: fix alignment of rasize ceph: fix use-after-free in ceph_statfs() ceph: prevent i_version from going back ceph: fix wrong check for the case of updating link count libceph: allocate the locator string with GFP_NOFAIL libceph: make abort_on_full a per-osdc setting libceph: don't abort reads in ceph_osdc_abort_on_full() libceph: avoid a use-after-free during map check libceph: don't warn if req->r_abort_on_full is set libceph: use for_each_request() in ceph_osdc_abort_on_full() libceph: defer __complete_request() to a workqueue libceph: move more code into __complete_request() libceph: no need to call flush_workqueue() before destruction ceph: flush pending works before shutdown super ceph: abort osd requests on force umount libceph: introduce ceph_osdc_abort_requests() ...
2018-06-15Merge tag 'for-4.18-part2-tag' of ↵Linus Torvalds5-19/+19
git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux Pull btrfs fixes from David Sterba: - error handling fixup for one of the new ioctls from 1st pull - fix for device-replace that incorrectly uses inode pages and can mess up compressed extents in some cases - fiemap fix for reporting incorrect number of extents - vm_fault_t type conversion * tag 'for-4.18-part2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux: btrfs: scrub: Don't use inode pages for device replace btrfs: change return type of btrfs_page_mkwrite to vm_fault_t Btrfs: fiemap: pass correct bytenr when fm_extent_count is zero btrfs: Check error of btrfs_iget in btrfs_search_path_in_tree_user
2018-06-15Kbuild: rename HAVE_CC_STACKPROTECTOR config variableMasahiro Yamada8-9/+9
HAVE_CC_STACKPROTECTOR should be selected by architectures with stack canary implementation. It is not about the compiler support. For the consistency with commit 050e9baa9dc9 ("Kbuild: rename CC_STACKPROTECTOR[_STRONG] config variables"), remove 'CC_' from the config symbol. I moved the 'select' lines to keep the alphabetical sorting. Signed-off-by: Masahiro Yamada <[email protected]> Acked-by: Kees Cook <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-06-15kconfig: tinyconfig: remove stale stack protector fixupsMasahiro Yamada1-4/+0
Prior to commit 2a61f4747eea ("stack-protector: test compiler capability in Kconfig and drop AUTO mode"), the stack protector was configured by the choice of NONE, REGULAR, STRONG, AUTO. tiny.config needed to explicitly set NONE because the default value of choice, AUTO, did not produce the tiniest kernel. Now that there are only two boolean symbols, STACKPROTECTOR and STACKPROTECTOR_STRONG, they are naturally disabled by "make allnoconfig", which "make tinyconfig" is based on. Remove unnecessary lines from the tiny.config fragment file. Signed-off-by: Masahiro Yamada <[email protected]> Acked-by: Kees Cook <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-06-15x86: fix dependency of X86_32_LAZY_GSMasahiro Yamada1-1/+1
Commit 2a61f4747eea ("stack-protector: test compiler capability in Kconfig and drop AUTO mode") replaced the 'choice' with two boolean symbols, so CC_STACKPROTECTOR_NONE no longer exists. Prior to commit 2bc2f688fdf8 ("Makefile: move stack-protector availability out of Kconfig"), this line was like this: depends on X86_32 && !CC_STACKPROTECTOR The CC_ prefix was dropped by commit 050e9baa9dc9 ("Kbuild: rename CC_STACKPROTECTOR[_STRONG] config variables"), so the dependency now should be: depends on X86_32 && !STACKPROTECTOR Signed-off-by: Masahiro Yamada <[email protected]> Acked-by: Kees Cook <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-06-14sctp: define sctp_packet_gso_append to build GSO framesXin Long2-10/+23
Now sctp GSO uses skb_gro_receive() to append the data into head skb frag_list. However it actually only needs very few code from skb_gro_receive(). Besides, NAPI_GRO_CB has to be set while most of its members are not needed here. This patch is to add sctp_packet_gso_append() to build GSO frames instead of skb_gro_receive(), and it would avoid many unnecessary checks and make the code clearer. Note that sctp will use page frags instead of frag_list to build GSO frames in another patch. But it may take time, as sctp's GSO frames may have different size. skb_segment() can only split it into the frags with the same size, which would break the border of sctp chunks. Signed-off-by: Xin Long <[email protected]> Reviewed-by: Marcelo Ricardo Leitner <[email protected]> Acked-by: Neil Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-06-14KVM: x86: VMX: redo fix for link error without CONFIG_HYPERVArnd Bergmann1-4/+2
Arnd had sent this patch to the KVM mailing list, but it slipped through the cracks of maintainers hand-off, and therefore wasn't included in the pull request. The same issue had been fixed by Linus in commit dbee3d0 ("KVM: x86: VMX: fix build without hyper-v", 2018-06-12) as a self-described "quick-and-hacky build fix". However, checking the compile-time configuration symbol with IS_ENABLED is cleaner and it is enough to avoid the link error, so switch to Arnd's solution. Signed-off-by: Arnd Bergmann <[email protected]> [Rewritten commit message. - Paolo] Signed-off-by: Paolo Bonzini <[email protected]>
2018-06-14ALSA: usb-audio: Always create the interrupt pipe for the mixerJorge Sanjuan1-3/+5
An UAC3 BADD device may also include an interrupt status pipe to report changes on the HEADSET ADAPTER terminals. The creation of the status pipe is dependent on the device reporting that it has it. Signed-off-by: Jorge Sanjuan <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2018-06-14ALSA: usb-audio: Add insertion control for UAC3 BADDJorge Sanjuan1-0/+17
The HEADSET ADAPTER profile for BADD devices is meant to support Insertion Control for the Input and Output Terminals of the headset. This patch defines the BADD inferred input and output terminals and builds the connector controls. Signed-off-by: Jorge Sanjuan <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2018-06-14ALSA: usb-audio: Change in connectors control creation interfaceJorge Sanjuan1-10/+10
Change build_connector_control() and get_connector_control_name() so they take `struct usb_mixer_interface` as input argument instead of `struct mixer_build`. This is preliminary work to add support for connectors control for UAC3 BADD devices. No functional change. Signed-off-by: Jorge Sanjuan <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2018-06-14ALSA: usb-audio: Add bi-directional terminal typesJorge Sanjuan1-0/+8
Define the bi-directional USB terminal types for audio devices. Signed-off-by: Jorge Sanjuan <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2018-06-14ALSA: lx6464es: add error handling for pci_ioremap_barZhouyang Jia1-0/+7
When pci_ioremap_bar fails, the lack of error-handling code may cause unexpected results. This patch adds error-handling code after calling pci_ioremap_bar. Signed-off-by: Zhouyang Jia <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2018-06-14ALSA: sonicvibes: add error handling for snd_ctl_addZhouyang Jia1-2/+10
When snd_ctl_add fails, the lack of error-handling code may cause unexpected results. This patch adds error-handling code after calling snd_ctl_add. Signed-off-by: Zhouyang Jia <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2018-06-14Merge tag 'kvm-ppc-next-4.18-2' of ↵Paolo Bonzini38-1228/+2310
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc into HEAD
2018-06-14KVM: x86: fix typo at kvm_arch_hardware_setup commentMarcelo Tosatti1-1/+1
Fix typo in sentence about min value calculation. Signed-off-by: Marcelo Tosatti <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2018-06-14blk-mq: remove blk_mq_tagset_iterChristoph Hellwig2-31/+0
Unused now that nvme stopped using it. Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Jens Axboe <[email protected]>
2018-06-14nvme: remove nvme_reinit_tagsetChristoph Hellwig2-12/+0
Unused now that all transports stopped using it. Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Jens Axboe <[email protected]>
2018-06-14nvme-fc: fix nulling of queue data on reconnectJames Smart1-6/+5
The reconnect path is calling the init routines to clear a queue structure. But the queue structure has state that perhaps needs to persist as long as the controller is live. Remove the nvme_fc_init_queue() calls on reconnect. The nvme_fc_free_queue() calls will clear state bits and reset any relevant queue state for a new connection. Signed-off-by: James Smart <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]>
2018-06-14nvme-fc: remove reinit_request routineJames Smart1-20/+0
The reinit_request routine is not necessary. Remove support for the op callback. As all that nvme_reinit_tagset() does is itterate and call the reinit routine, it too has no purpose. Remove the call. Signed-off-by: James Smart <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]>
2018-06-14blk-mq: don't time out requests again that are in the timeout handlerChristoph Hellwig2-0/+7
We can currently call the timeout handler again on a request that has already been handed over to the timeout handler. Prevent that with a new flag. Fixes: 12f5b931 ("blk-mq: Remove generation seqeunce") Reported-by: Andrew Randrianasulu <[email protected]> Tested-by: Andrew Randrianasulu <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2018-06-14pstore: Remove bogus format string definitionArnd Bergmann1-11/+6
The pstore conversion to timespec64 introduces its own method of passing seconds into sscanf() and sprintf() type functions to work around the timespec64 definition on 64-bit systems that redefine it to 'timespec'. That hack is now finally getting removed, but that means we get a (harmless) warning once both patches are merged: fs/pstore/ram.c: In function 'ramoops_read_kmsg_hdr': fs/pstore/ram.c:39:29: error: format '%ld' expects argument of type 'long int *', but argument 3 has type 'time64_t *' {aka 'long long int *'} [-Werror=format=] #define RAMOOPS_KERNMSG_HDR "====" ^~~~~~ fs/pstore/ram.c:167:21: note: in expansion of macro 'RAMOOPS_KERNMSG_HDR' This removes the pstore specific workaround and uses the same method that we have in place for all other functions that print a timespec64. Related to this, I found that the kasprintf() output contains an incorrect nanosecond values for any number starting with zeroes, and I adapt the format string accordingly. Link: https://lkml.org/lkml/2018/5/19/115 Link: https://lkml.org/lkml/2018/5/16/1080 Fixes: 0f0d83b99ef7 ("pstore: Convert internal records to timespec64") Acked-by: Kees Cook <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2018-06-14Merge branch 'vfs_timespec64' of https://github.com/deepa-hub/vfs into ↵Arnd Bergmann90-439/+563
vfs-timespec64 Pull the timespec64 conversion from Deepa Dinamani: "The series aims to switch vfs timestamps to use struct timespec64. Currently vfs uses struct timespec, which is not y2038 safe. The flag patch applies cleanly. I've not seen the timestamps update logic change often. The series applies cleanly on 4.17-rc6 and linux-next tip (top commit: next-20180517). I'm not sure how to merge this kind of a series with a flag patch. We are targeting 4.18 for this. Let me know if you have other suggestions. The series involves the following: 1. Add vfs helper functions for supporting struct timepec64 timestamps. 2. Cast prints of vfs timestamps to avoid warnings after the switch. 3. Simplify code using vfs timestamps so that the actual replacement becomes easy. 4. Convert vfs timestamps to use struct timespec64 using a script. This is a flag day patch. I've tried to keep the conversions with the script simple, to aid in the reviews. I've kept all the internal filesystem data structures and function signatures the same. Next steps: 1. Convert APIs that can handle timespec64, instead of converting timestamps at the boundaries. 2. Update internal data structures to avoid timestamp conversions." I've pulled it into a branch based on top of the NFS changes that are now in mainline, so I could resolve the non-obvious conflict between the two while merging. Signed-off-by: Arnd Bergmann <[email protected]>
2018-06-14drm/amd/powerplay: Set higher SCLK&MCLK frequency than dpm7 in OD (v2)Kenneth Feng1-2/+5
Fix the issue that SCLK&MCLK can't be set higher than dpm7 when OD is enabled in SMU7. v2: fix warning (Alex) Signed-off-by: Kenneth Feng <[email protected]> Acked-by: Rex Zhu<[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2018-06-14nvme-fc: change controllers first connect to use reconnect pathJames Smart1-57/+47
Current code follows the framework that has been in the transports from the beginning where initial link-side controller connect occurs as part of "creating the controller". Thus that first connect fully talks to the controller and obtains values that can then be used in for blk-mq setup, etc. It also means that everything about the controller is fully know before the "create controller" call returns. This has several weaknesses: - The initial create_ctrl call made by the cli will block for a long time as wire transactions are performed synchronously. This delay becomes longer if errors occur or connectivity is lost and retries need to be performed. - Code wise, it means there is a separate connect path for initial controller connect vs the (same) steps used in the reconnect path. - And as there's separate paths, it means there's separate error handling and retry logic. It also plays havoc with the NEW state (should transition out of it after successful initial connect) vs the RESETTING and CONNECTING (reconnect) states that want to be transitioned to on error. - As there's separate paths, to recover from errors and disruptions, it requires separate recovery/retry paths as well and can severely convolute the controller state. This patch reworks the fc transport to use the same connect paths for the initial connection as it uses for reconnect. This makes a single path for error recovery and handling. This patch: - Removes the driving of the initial connect and replaces it with a state transition to CONNECTING and initiating the reconnect thread. A dummy state transition of RESETTING had to be traversed as a direct transtion of NEW->CONNECTING is not allowed. Given that the controller is "new", the RESETTING transition is a simple no-op. Once in the reconnecting thread, the normal behaviors of ctrl_loss_tmo (max_retries * connect_delay) and dev_loss_tmo will apply before the controller is torn down. - Only if the state transitions couldn't be traversed and the reconnect thread not scheduled, will the controller be torn down while in create_ctrl. - The prior code used the controller state of NEW to indicate whether request queues had been initialized or not. For the admin queue, the request queue is always created, so there's no need to check a state. For IO queues, change to tracking whether a successful io request queue create has occurred (e.g. 1st successful connect). - The initial controller id is initialized to the dynamic controller id used in the initial connect message. It will be overwritten by the real controller id once the controller is connected on the wire. Signed-off-by: James Smart <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]>
2018-06-14Merge tag 'scsi-fixes' of ↵Linus Torvalds8-12/+32
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "This is a set of minor (and safe changes) that didn't make the initial pull request plus some bug fixes" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: qla2xxx: Mask off Scope bits in retry delay scsi: qla2xxx: Fix crash on qla2x00_mailbox_command scsi: aic7xxx: aic79xx: fix potential null pointer dereference on ahd scsi: mpt3sas: Add an I/O barrier scsi: qla2xxx: Fix setting lower transfer speed if GPSC fails scsi: hpsa: disable device during shutdown scsi: sd_zbc: Fix sd_zbc_check_zone_size() error path scsi: aacraid: remove bogus GFP_DMA32 specifies
2018-06-14Merge tag 'platform-drivers-x86-v4.18-1' of ↵Linus Torvalds20-77/+585
git://git.infradead.org/linux-platform-drivers-x86 Pull x86 platform driver updates from Darren Hart: "Several incremental improvements including new keycodes, new models, new quirks, and related documentation. Adds LED platform driver activation for Mellanox systems. Some minor optimizations and cleanups. Includes several bug fixes, message silencing, mostly minor Automated summary: acer-wmi: - add another KEY_POWER keycode apple-gmux: - fix gmux_get_client_id()'s return type asus-laptop: - Simplify getting .drvdata asus-wireless: - Fix format specifier dell-laptop: - Fix keyboard backlight timeout on XPS 13 9370 dell-smbios: - Match on www.dell.com in OEM strings too dell-wmi: - Ignore new rfkill and fn-lock events - Set correct keycode for Fn + left arrow fujitsu-laptop: - Simplify soft key handling ideapad-laptop: - Add E42-80 to no_hw_rfkill - Add fn-lock setting - Add MIIX 720-12IKB to no_hw_rfkill lib/string_helpers: - Add missed declaration of struct task_struct intel_scu_ipc: - Replace mdelay with usleep_range in intel_scu_ipc_i2c_cntrl mlx-platform: - Add LED platform driver activation platform/mellanox: - Add new ODM system types to mlx-platform - mlxreg-hotplug: add extra cycle for hotplug work queue - mlxreg-hotplug: Document fixes for hotplug private data platform_data/mlxreg: - Document fixes for hotplug device silead_dmi: - Add entry for Chuwi Hi8 tablet touchscreen - Add touchscreen info for the Onda V891w tablet - Add info for the PoV mobii TAB-P800W (v2.0) - Add touchscreen info for the Jumper EZpad 6 Pro thinkpad_acpi: - silence false-positive-prone pr_warn - do not report thermal sensor state for tablet mode switch - silence HKEY 0x6032, 0x60f0, 0x6030" * tag 'platform-drivers-x86-v4.18-1' of git://git.infradead.org/linux-platform-drivers-x86: (30 commits) platform/x86: silead_dmi: Add entry for Chuwi Hi8 tablet touchscreen platform/x86: dell-laptop: Fix keyboard backlight timeout on XPS 13 9370 platform/x86: dell-wmi: Ignore new rfkill and fn-lock events platform/x86: mlx-platform: Add LED platform driver activation platform/mellanox: Add new ODM system types to mlx-platform platform/mellanox: mlxreg-hotplug: add extra cycle for hotplug work queue platform/x86: ideapad-laptop: Add E42-80 to no_hw_rfkill platform/x86: silead_dmi: Add touchscreen info for the Onda V891w tablet platform/x86: silead_dmi: Add info for the PoV mobii TAB-P800W (v2.0) platform/x86: silead_dmi: Add touchscreen info for the Jumper EZpad 6 Pro platform/x86: asus-wireless: Fix format specifier platform/x86: asus-wmi: Fix NULL pointer dereference platform/x86: dell-wmi: Set correct keycode for Fn + left arrow platform/x86: acer-wmi: add another KEY_POWER keycode platform/x86: ideapad-laptop: Add fn-lock setting platform/x86: ideapad-laptop: Add MIIX 720-12IKB to no_hw_rfkill lib/string_helpers: Add missed declaration of struct task_struct platform/x86: DELL_WMI use depends on instead of select for DELL_SMBIOS platform/mellanox: mlxreg-hotplug: Document fixes for hotplug private data platform_data/mlxreg: Document fixes for hotplug device ...
2018-06-14Merge tag 'pwm/for-4.18-rc1' of ↵Linus Torvalds10-12/+66
git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm Pull pwm updates from Thierry Reding: "This contains a couple of fixes and cleanups for the Meson and ACPI/LPSS drivers as well as capture support for STM32. Note that given the cross- subsystem changes, the STM32 patches were merged through the MFD and PWM trees, both sharing an immutable branch" * tag 'pwm/for-4.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm: pwm: stm32: Fix build warning with CONFIG_DMA_ENGINE disabled pwm: stm32: Enforce dependency on CONFIG_MFD_STM32_TIMERS ACPI / LPSS: Add missing prv_offset setting for byt/cht PWM devices pwm: lpss: platform: Save/restore the ctrl register over a suspend/resume dt-bindings: mfd: stm32-timers: Add support for dmas pwm: simplify getting .drvdata pwm: meson: Fix allocation of PWM channel array
2018-06-14Merge branch 'i2c/for-4.18' of ↵Linus Torvalds94-483/+1683
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull i2c updates from Wolfram Sang: - mainly feature additions to drivers (stm32f7, qup, xlp9xx, mlxcpld, ...) - conversion to use the i2c_8bit_addr_from_msg macro consistently - move includes to platform_data - core updates to allow the (still in review) I3C subsystem to connect - and the regular share of smaller driver updates * 'i2c/for-4.18' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: (68 commits) i2c: qup: fix building without CONFIG_ACPI i2c: tegra: Remove suspend-resume i2c: imx-lpi2c: Switch to SPDX identifier i2c: mxs: Switch to SPDX identifier i2c: busses: make use of i2c_8bit_addr_from_msg i2c: algos: make use of i2c_8bit_addr_from_msg i2c: rcar: document R8A77980 bindings i2c: qup: Add command-line parameter to override SCL frequency i2c: qup: Correct duty cycle for FM and FM+ i2c: qup: Add support for Fast Mode Plus i2c: qup: add probe path for Centriq ACPI devices i2c: robotfuzz-osif: drop pointless test i2c: robotfuzz-osif: remove pointless local variable i2c: rk3x: Don't print visible virtual mapping MMIO address i2c: opal: don't check number of messages in the driver i2c: ibm_iic: don't check number of messages in the driver i2c: imx: Switch to SPDX identifier i2c: mux: pca954x: merge calls to of_match_device and of_device_get_match_data i2c: mux: demux-pinctrl: use proper parent device for demux adapter i2c: mux: improve error message for failed symlink ...
2018-06-14Merge tag 'apparmor-pr-2018-06-13' of ↵Linus Torvalds15-74/+313
git://git.kernel.org/pub/scm/linux/kernel/git/jj/linux-apparmor Pull AppArmor updates from John Johansen: "Features - add support for mapping secids and using secctxes - add the ability to get a task's secid - add support for audit rule filtering Cleanups: - multiple typo fixes - Convert to use match_string() helper - update git and wiki locations in AppArmor docs - improve get_buffers macro by using get_cpu_ptr - Use an IDR to allocate apparmor secids Bug fixes: - fix '*seclen' is never less than zero - fix mediation of prlimit - fix memory leak when deduping profile load - fix ptrace read check - fix memory leak of rule on error exit path" * tag 'apparmor-pr-2018-06-13' of git://git.kernel.org/pub/scm/linux/kernel/git/jj/linux-apparmor: (21 commits) apparmor: fix ptrace read check apparmor: fix memory leak when deduping profile load apparmor: fix mediation of prlimit apparmor: fixup secid map conversion to using IDR apparmor: Use an IDR to allocate apparmor secids apparmor: Fix memory leak of rule on error exit path apparmor: modify audit rule support to support profile stacks apparmor: Add support for audit rule filtering apparmor: update git and wiki locations in AppArmor docs apparmor: Convert to use match_string() helper apparmor: improve get_buffers macro by using get_cpu_ptr apparmor: fix '*seclen' is never less than zero apparmor: fix typo "preconfinement" apparmor: fix typo "independent" apparmor: fix typo "traverse" apparmor: fix typo "type" apparmor: fix typo "replace" apparmor: fix typo "comparison" apparmor: fix typo "loosen" apparmor: add the ability to get a task's secid ...
2018-06-14Kbuild: rename CC_STACKPROTECTOR[_STRONG] config variablesLinus Torvalds33-39/+39
The changes to automatically test for working stack protector compiler support in the Kconfig files removed the special STACKPROTECTOR_AUTO option that picked the strongest stack protector that the compiler supported. That was all a nice cleanup - it makes no sense to have the AUTO case now that the Kconfig phase can just determine the compiler support directly. HOWEVER. It also meant that doing "make oldconfig" would now _disable_ the strong stackprotector if you had AUTO enabled, because in a legacy config file, the sane stack protector configuration would look like CONFIG_HAVE_CC_STACKPROTECTOR=y # CONFIG_CC_STACKPROTECTOR_NONE is not set # CONFIG_CC_STACKPROTECTOR_REGULAR is not set # CONFIG_CC_STACKPROTECTOR_STRONG is not set CONFIG_CC_STACKPROTECTOR_AUTO=y and when you ran this through "make oldconfig" with the Kbuild changes, it would ask you about the regular CONFIG_CC_STACKPROTECTOR (that had been renamed from CONFIG_CC_STACKPROTECTOR_REGULAR to just CONFIG_CC_STACKPROTECTOR), but it would think that the STRONG version used to be disabled (because it was really enabled by AUTO), and would disable it in the new config, resulting in: CONFIG_HAVE_CC_STACKPROTECTOR=y CONFIG_CC_HAS_STACKPROTECTOR_NONE=y CONFIG_CC_STACKPROTECTOR=y # CONFIG_CC_STACKPROTECTOR_STRONG is not set CONFIG_CC_HAS_SANE_STACKPROTECTOR=y That's dangerously subtle - people could suddenly find themselves with the weaker stack protector setup without even realizing. The solution here is to just rename not just the old RECULAR stack protector option, but also the strong one. This does that by just removing the CC_ prefix entirely for the user choices, because it really is not about the compiler support (the compiler support now instead automatially impacts _visibility_ of the options to users). This results in "make oldconfig" actually asking the user for their choice, so that we don't have any silent subtle security model changes. The end result would generally look like this: CONFIG_HAVE_CC_STACKPROTECTOR=y CONFIG_CC_HAS_STACKPROTECTOR_NONE=y CONFIG_STACKPROTECTOR=y CONFIG_STACKPROTECTOR_STRONG=y CONFIG_CC_HAS_SANE_STACKPROTECTOR=y where the "CC_" versions really are about internal compiler infrastructure, not the user selections. Acked-by: Masahiro Yamada <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-06-13Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nfDavid S. Miller13-23/+52
Pablo Neira Ayuso says: ==================== Netfilter fixes for net The following patchset contains Netfilter patches for your net tree: 1) Fix NULL pointer dereference from nf_nat_decode_session() if NAT is not loaded, from Prashant Bhole. 2) Fix socket extension module autoload. 3) Don't bogusly reject sets with the NFT_SET_EVAL flag set on from the dynset extension. 4) Fix races with nf_tables module removal and netns exit path, patches from Florian Westphal. 5) Don't hit BUG_ON if jumpstack goes too deep, instead hit WARN_ON_ONCE, from Taehee Yoo. 6) Another NULL pointer dereference from ctnetlink, again if NAT is not loaded, from Florian Westphal. 7) Fix x_tables match list corruption in xt_connmark module removal path, also from Florian. 8) nf_conncount doesn't properly deal with conntrack zones, hence garbage collector may get rid of entries in a different zone. From Yi-Hung Wei. ==================== Signed-off-by: David S. Miller <[email protected]>
2018-06-13drm/amd/powerplay: remove uncessary extra gfxoff control callEvan Quan1-9/+0
Gfxoff is already enabled in amdgpu_device_ip_set_powergating_state. So, no need to enable it again in pp_late_init. Signed-off-by: Evan Quan <[email protected]> Reviewed-by: Huang Rui <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2018-06-13drm/amdgpu: fix parsing indirect register list v2Evan Quan1-6/+9
WARN_ON possible buffer overflow and avoid unnecessary dereference. v2: change BUG_ON to WARN_ON Signed-off-by: Evan Quan <[email protected]> Reviewed-by: Huang Rui <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2018-06-13drm/amd/include: Update df 3.6 mask and shift definitionShaoyun Liu1-4/+4
The register field hsas been changed in df 3.6, update to correct setting Signed-off-by: Shaoyun Liu <[email protected]> Acked-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2018-06-13drm/amd/pp: Fix OD feature enable failed on Vega10 workstation cardsRex Zhu1-2/+7
As hw required, soc clock must large than mclk, So we set max soc clock to OD Max Memory clk. But on workstation, vbios do not support OD feature, the OD max memory clock is equal to 0. In this case, driver can support underclocking. and set od max memory clock to the value in highest memory dpm level. So the od max memory clock should be less than highest soc clock. and driver should not change the soc clock. caused by commit ca57b9b0a156 ("drm/amd/pp: Allow underclocking when od table is empty in vbios") Reviewed-by: Evan Quan <[email protected]> Signed-off-by: Rex Zhu <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2018-06-13drm/amd/display: Fix stale buffer object (bo) usePratik Vishwakarma1-11/+0
Fixes stale buffer object (bo) usage for cursor plane Cursor plane's bo operations are handled in DC code. Currently, atomic_commit() does not handle bo operations for cursor plane, as a result the bo assigned for cursor plane in dm_plane_helper_prepare_fb() is not coherent with the updates to the same made in dc code.This mismatch leads to "bo" corruption and hence crashes during S3 entry. This patch cleans up the code which was added as a hack for 4.9 version only. Reviewed-by: Andrey Grodzovsky <[email protected]> Signed-off-by: Pratik Vishwakarma <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2018-06-13drm/amd/pp: initialize result to before or'ing in dataColin Ian King1-1/+1
The current use of result is or'ing in values and checking for a non-zero result, however, result is not initialized to zero so it potentially contains garbage to start with. Fix this by initializing it to the first return from the call to vega10_program_didt_config_registers. Detected by cppcheck: "(error) Uninitialized variable: result" Fixes: 9b7b8154cdb8 ("drm/amd/powerplay: added didt support for vega10") Signed-off-by: Colin Ian King <[email protected]> Acked-by: Huang Rui <[email protected]> [Fix the subject as Colin's comment] Signed-off-by: Huang Rui <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2018-06-13drm/amd/powerplay: fix wrong clock adjust sequenceEvan Quan1-7/+6
The clocks should be adjusted after display configuration changed. Otherwise, the socclk and memclk may be forced on an unnecessary higher level. Signed-off-by: Evan Quan <[email protected]> Reviewed-by: Rex Zhu <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2018-06-13drm/amdgpu: Grab/put runtime PM references in atomic_commit_tail()Lyude Paul1-0/+13
So, unfortunately I recently made the discovery that in the upstream kernel, the only reason that amdgpu is not currently suffering from issues with runtime PM putting the GPU into suspend while it's driving displays is due to the fact that on most prime systems, we have sound devices associated with the GPU that hold their own runtime PM ref for the GPU. What this means however, is that in the event that there isn't any kind of sound device active (which can easily be reproduced by building a kernel with sound drivers disabled), the GPU will fall asleep even when there's displays active. This appears to be in part due to the fact that amdgpu has not actually ever relied on it's rpm_idle() function to be the only thing keeping it running, and normally grabs it's own power references whenever there are displays active (as can be seen with the original pre-DC codepath in amdgpu_display_crtc_set_config() in amdgpu_display.c). This means it's very likely that this bug was introduced during the switch over the DC. So to fix this, we start grabbing runtime PM references every time we enable a previously disabled CRTC in atomic_commit_tail(). This appears to be the correct solution, as it matches up with what i915 does in i915/intel_runtime_pm.c. The one sideaffect of this is that we ignore the variable that the pre-DC code used to use for tracking when it needed runtime PM refs, adev->have_disp_power_ref. This is mainly because there's no way for a driver to tell whether or not all of it's CRTCs are enabled or disabled when we've begun committing an atomic state, as there may be CRTC commits happening in parallel that aren't contained within the atomic state being committed. So, it's safer to just get/put a reference for each CRTC being enabled or disabled in the new atomic state. Signed-off-by: Lyude Paul <[email protected]> Acked-by: Christian König <[email protected]>. Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2018-06-13drm/amd/powerplay: fix missed hwmgr check warning before call ↵Huang Rui1-1/+2
gfx_off_control handler Patch 9667849bbb8d: "drm/amd/powerplay: add control gfxoff enabling in late init" from Mar 13, 2018, leads to the following static checker warning: drivers/gpu/drm/amd/amdgpu/../powerplay/amd_powerplay.c:194 pp_late_init() error: we previously assumed 'hwmgr' could be null (see line 185) drivers/gpu/drm/amd/amdgpu/../powerplay/amd_powerplay.c This patch fixes the warning to add hwmgr checking. Reported-by: Dan Carpenter <[email protected]> Signed-off-by: Huang Rui <[email protected]> Reviewed-by: Evan Quan <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2018-06-13drm/amdgpu: fix CG enabling hang with gfxoff enabledHuang Rui4-8/+15
After defer the execution of clockgating enabling, at that time, gfx already enter into "off" state. Howerver, clockgating enabling will use MMIO to access the gfx registers, then get the gfx hung. So here we should move the gfx powergating and gfxoff enabling behavior at the end of initialization behind clockgating. Signed-off-by: Huang Rui <[email protected]> Reviewed-by: Hawking Zhang <[email protected]> Acked-by: Christian König <[email protected]> Cc: Felix Kuehling <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.