-
Notifications
You must be signed in to change notification settings - Fork 133
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merge/sound upstream 20230103 #4122
Merge/sound upstream 20230103 #4122
Conversation
…ench/cifs-2.6 Pull cifs fixes from Steve French: "cifs/smb3 client fixes, mostly related to reconnect and/or DFS: - two important reconnect fixes: cases where status of recently connected IPCs and shares were not being updated leaving them in an incorrect state - fix for older Windows servers that would return STATUS_OBJECT_NAME_INVALID to query info requests on DFS links in a namespace that contained non-ASCII characters, reducing number of wasted roundtrips. - fix for leaked -ENOMEM to userspace when cifs.ko couldn't perform I/O due to a disconnected server, expired or deleted session. - removal of all unneeded DFS related mount option string parsing (now using fs_context for automounts) - improve clarity/readability, moving various DFS related functions out of fs/cifs/connect.c (which was getting too big to be readable) to new file. - Fix problem when large number of DFS connections. Allow sharing of DFS connections and fix how the referral paths are matched - Referral caching fix: Instead of looking up ipc connections to refresh cached referrals, store direct dfs root server's IPC pointer in new sessions so it can simply be accessed to either refresh or create a new referral that such connections belong to. - Fix to allow dfs root server's connections to also failover - Optimized reconnect of nested DFS links - Set correct status of IPC connections marked for reconnect" * tag '6.2-rc-smb3-client-fixes-part2' of git://git.samba.org/sfrench/cifs-2.6: cifs: update internal module number cifs: don't leak -ENOMEM in smb2_open_file() cifs: use origin fullpath for automounts cifs: set correct status of tcon ipc when reconnecting cifs: optimize reconnect of nested links cifs: fix source pathname comparison of dfs supers cifs: fix confusing debug message cifs: don't block in dfs_cache_noreq_update_tgthint() cifs: refresh root referrals cifs: fix refresh of cached referrals cifs: don't refresh cached referrals from unactive mounts cifs: share dfs connections and supers cifs: split out ses and tcon retrieval from mount_get_conns() cifs: set resolved ip in sockaddr cifs: remove unused smb3_fs_context::mount_options cifs: get rid of mount options string parsing cifs: use fs_context for automounts cifs: reduce roundtrips on create/qinfo requests cifs: set correct ipc status after initial tree connect cifs: set correct tcon status after initial tree connect
This patch isn't intended to have any effect on the compiled code. It just removes one level of indirection: calling the *host* compiler to build and then run a program that just printf:s the numerical entries of the syscall-table. In other words, the generated syscalls.c changes from: [46] = "ftruncate", to: [__NR3264_ftruncate] = "ftruncate", The latter is as good as the former to the user of perf, and this can be done directly by the shell-script. The syscalls defined as non-literal values (like "#define __NR_ftruncate __NR3264_ftruncate") are trivially resolved at compile-time without namespace-leaking and/or collision for its sole user, perf/util/syscalltbl.c, that just #includes the generated file. A future "-mabi=32" support would probably have to handle this differently, but that is a pre-existing problem not affected by this simplification. Calling the *host* compiler only complicates things and accidentally can get a completely wrong set of files and syscall numbers, see earlier commits. Note that the script parameter hostcc is now unused. At the time of this patch, powerpc (the origin, see comments), and also e.g. x86 has moved on, from filtering "gcc -dM -E" output to reading separate specific text-file, a table of syscall numbers. IMHO should arm64 consider adopting this. Signed-off-by: Hans-Peter Nilsson <hp@axis.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Reviewed-by: Leo Yan <leo.yan@linaro.org> Tested-by: Leo Yan <leo.yan@linaro.org> Acked-by: Arnd Bergmann <arnd@arndb.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: John Garry <john.garry@huawei.com> Cc: Kim Phillips <kim.phillips@arm.com> Cc: Leo Yan <leo.yan@linaro.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Will Deacon <will@kernel.org> Cc: linux-arm-kernel@lists.infradead.org Link: https://lore.kernel.org/r/20201228024159.2BB66203B5@pchp3.se.axis.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Enable VCN Dynamic Power Gating control for GC IP v11.0.4. Signed-off-by: Saleemkhan Jamadar <saleemkhan.jamadar@amd.com> Reviewed-by: Veerabadhran Gopalakrishnan <veerabadhran.gopalakrishnan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org # 6.0, 6.1
…erations The build was failing on archlinux because it has a newer libtraceevent that added a new entry to the tep_print_arg_type enum: 19.72 archlinux:base : FAIL gcc version 12.2.0 (GCC) util/scripting-engines/trace-event-python.c: In function ‘define_event_symbols’: util/scripting-engines/trace-event-python.c:281:9: error: enumeration value ‘TEP_PRINT_CPUMASK’ not handled in switch [-Werror=switch-enum] 281 | switch (args->type) { | ^~~~~~ cc1: all warnings being treated as errors Since we build with distros that have different versions of libtraceevent and there is no way to easily test if these enum entries are available, just disable -Werror=switch-enum for that specific object. Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
If we have a signal pending during cancelations, it'll cause the task_work run to return an error. Since we didn't run task_work, the current task is left in TASK_INTERRUPTIBLE state when we need to re-grab the ctx mutex, and the kernel will rightfully complain about that. Move the lock grabbing for the error cases outside the loop to avoid that issue. Reported-by: syzbot+7df055631cd1be4586fd@syzkaller.appspotmail.com Link: https://lore.kernel.org/io-uring/0000000000003a14a905f05050b0@google.com/ Signed-off-by: Jens Axboe <axboe@kernel.dk>
That function consumes the reference. Reviewed-by: Luben Tuikov <luben.tuikov@amd.com> Reported-by: Borislav Petkov (AMD) <bp@alien8.de> Tested-by: Borislav Petkov (AMD) <bp@alien8.de> Signed-off-by: Christian König <christian.koenig@amd.com> Fixes: aab9cf7 ("drm/amdgpu: use scheduler dependencies for VM updates") Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Since 6.1 we have noticed random rpm install failures that were tracked to mremap() returning -ENOMEM and to commit ca3d76b ("mm: add merging after mremap resize"). The problem occurs when mremap() expands a VMA in place, but using an starting address that's not vma->vm_start, but somewhere in the middle. The extension_pgoff calculation introduced by the commit is wrong in that case, so vma_merge() fails due to pgoffs not being compatible. Fix the calculation. By the way it seems that the situations, where rpm now expands a vma from the middle, were made possible also due to that commit, thanks to the improved vma merging. Yet it should work just fine, except for the buggy calculation. Link: https://lkml.kernel.org/r/20221216163227.24648-1-vbabka@suse.cz Reported-by: Jiri Slaby <jirislaby@kernel.org> Link: https://bugzilla.suse.com/show_bug.cgi?id=1206359 Fixes: ca3d76b ("mm: add merging after mremap resize") Signed-off-by: Vlastimil Babka <vbabka@suse.cz> Cc: Jakub Matěna <matenajakub@gmail.com> Cc: "Kirill A . Shutemov" <kirill@shutemov.name> Cc: Liam Howlett <liam.howlett@oracle.com> Cc: Matthew Wilcox <willy@infradead.org> Cc: Mel Gorman <mgorman@techsingularity.net> Cc: Michal Hocko <mhocko@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
When encountering any vma in the range with policy other than MPOL_BIND or MPOL_PREFERRED_MANY, an error is returned without issuing a mpol_put on the policy just allocated with mpol_dup(). This allows arbitrary users to leak kernel memory. Link: https://lkml.kernel.org/r/20221215194621.202816-1-mathieu.desnoyers@efficios.com Fixes: c6018b4 ("mm/mempolicy: add set_mempolicy_home_node syscall") Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: "Huang, Ying" <ying.huang@intel.com> Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Acked-by: Michal Hocko <mhocko@suse.com> Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Feng Tang <feng.tang@intel.com> Cc: Michal Hocko <mhocko@kernel.org> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Mel Gorman <mgorman@techsingularity.net> Cc: Mike Kravetz <mike.kravetz@oracle.com> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Andi Kleen <ak@linux.intel.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Huang Ying <ying.huang@intel.com> Cc: <stable@vger.kernel.org> [5.17+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
This is needed for the vmap/vunmap declarations: mm/kmsan/kmsan_test.c:316:9: error: implicit declaration of function 'vmap' is invalid in C99 [-Werror,-Wimplicit-function-declaration] vbuf = vmap(pages, npages, VM_MAP, PAGE_KERNEL); ^ mm/kmsan/kmsan_test.c:316:29: error: use of undeclared identifier 'VM_MAP' vbuf = vmap(pages, npages, VM_MAP, PAGE_KERNEL); ^ mm/kmsan/kmsan_test.c:322:3: error: implicit declaration of function 'vunmap' is invalid in C99 [-Werror,-Wimplicit-function-declaration] vunmap(vbuf); ^ Link: https://lkml.kernel.org/r/20221215163046.4079767-1-arnd@kernel.org Fixes: 8ed691b ("kmsan: add tests for KMSAN") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Alexander Potapenko <glider@google.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Marco Elver <elver@google.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
USB support can be in a loadable module, and this causes a link failure with KMSAN: ERROR: modpost: "kmsan_handle_urb" [drivers/usb/core/usbcore.ko] undefined! Export the symbol so it can be used by this module. Link: https://lkml.kernel.org/r/20221215162710.3802378-1-arnd@kernel.org Fixes: 553a801 ("kmsan: handle memory sent to/from USB") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Alexander Potapenko <glider@google.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Marco Elver <elver@google.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Commit bbff39c ("hugetlb: allocate vma lock for all sharable vmas") removed the pmd sharable checks in the vma lock helper routines. However, it left the functional version of helper routines behind #ifdef CONFIG_ARCH_WANT_HUGE_PMD_SHARE. Therefore, the vma lock is not being used for sharable vmas on architectures that do not support pmd sharing. On these architectures, a potential fault/truncation race is exposed that could leave pages in a hugetlb file past i_size until the file is removed. Move the functional vma lock helpers outside the ifdef, and remove the non-functional stubs. Since the vma lock is not just for pmd sharing, rename the routine __vma_shareable_flags_pmd. Link: https://lkml.kernel.org/r/20221212235042.178355-1-mike.kravetz@oracle.com Fixes: bbff39c ("hugetlb: allocate vma lock for all sharable vmas") Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com> Reviewed-by: Miaohe Lin <linmiaohe@huawei.com> Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> Cc: David Hildenbrand <david@redhat.com> Cc: James Houghton <jthoughton@google.com> Cc: Mina Almasry <almasrymina@google.com> Cc: Muchun Song <songmuchun@bytedance.com> Cc: Naoya Horiguchi <naoya.horiguchi@linux.dev> Cc: Peter Xu <peterx@redhat.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Mike Rapoport contacted me off-list with a regression in running criu. Periodic tests fail with an RCU stall during execution. Although rare, it is possible to hit this with other uses so this patch should be backported to fix the regression. This patchset adds the fix and a test case to the maple tree test suite. This patch (of 2): An insufficient node was causing an out-of-bounds access on the node in mas_leaf_max_gap(). The cause was the faulty detection of the new node being a root node when overwriting many entries at the end of the tree. Fix the detection of a new root and ensure there is sufficient data prior to entering the spanning rebalance loop. Link: https://lkml.kernel.org/r/20221219161922.2708732-1-Liam.Howlett@oracle.com Link: https://lkml.kernel.org/r/20221219161922.2708732-2-Liam.Howlett@oracle.com Fixes: 54a611b ("Maple Tree: add new data structure") Signed-off-by: Liam R. Howlett <Liam.Howlett@oracle.com> Reported-by: Mike Rapoport <rppt@kernel.org> Tested-by: Mike Rapoport <rppt@kernel.org> Cc: Andrei Vagin <avagin@gmail.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Muhammad Usama Anjum <usama.anjum@collabora.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
…t data Add a test to the maple tree test suite for the spanning rebalance insufficient node issue does not go undetected again. Link: https://lkml.kernel.org/r/20221219161922.2708732-3-Liam.Howlett@oracle.com Fixes: 54a611b ("Maple Tree: add new data structure") Signed-off-by: Liam R. Howlett <Liam.Howlett@oracle.com> Cc: Andrei Vagin <avagin@gmail.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Muhammad Usama Anjum <usama.anjum@collabora.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
In GCC version 12.1 a checksum field was added. This patch fixes a kernel crash occurring during boot when using gcov-kernel with GCC version 12.2. The crash occurred on a system running on i.MX6SX. Link: https://lkml.kernel.org/r/20221220102318.3418501-1-rickaran@axis.com Fixes: 977ef30 ("gcov: support GCC 12.1 and newer compilers") Signed-off-by: Rickard x Andersson <rickaran@axis.com> Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com> Tested-by: Peter Oberparleiter <oberpar@linux.ibm.com> Reviewed-by: Martin Liska <mliska@suse.cz> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Pull io_uring fixes from Jens Axboe: - Improve the locking for timeouts. This was originally queued up for the initial pull, but I messed up and it got missed. (Pavel) - Fix an issue with running task_work from the wait path, causing some inefficiencies (me) - Add a clear of ->free_iov upfront in the 32-bit compat data importing, so we ensure that it's always sane at completion time (me) - Use call_rcu_hurry() for the eventfd signaling (Dylan) - Ordering fix for multishot recv completions (Pavel) - Add the io_uring trace header to the MAINTAINERS entry (Ammar) * tag 'io_uring-6.2-2022-12-19' of git://git.kernel.dk/linux: MAINTAINERS: io_uring: Add include/trace/events/io_uring.h io_uring/net: fix cleanup after recycle io_uring/net: ensure compat import handlers clear free_iov io_uring: include task_work run after scheduling in wait for events io_uring: don't use TIF_NOTIFY_SIGNAL to test for availability of task_work io_uring: use call_rcu_hurry if signaling an eventfd io_uring: fix overflow handling regression io_uring: ease timeout flush locking requirements io_uring: revise completion_lock locking io_uring: protect cq_timeouts with timeout_lock
Pull block fixes from Jens Axboe: - Various fixes for BFQ (Yu, Yuwei) - Fix for loop command line parsing (Isaac) - No need to specifically clear REQ_ALLOC_CACHE on IOPOLL downgrade anymore (me) - blk-iocost enum fix for newer gcc (Jiri) - UAF fix for queue release (Ming) - blk-iolatency error handling memory leak fix (Tejun) * tag 'block-6.2-2022-12-19' of git://git.kernel.dk/linux: block: don't clear REQ_ALLOC_CACHE for non-polled requests block: fix use-after-free of q->q_usage_counter block, bfq: only do counting of pending-request for BFQ_GROUP_IOSCHED blk-iolatency: Fix memory leak on add_disk() failures loop: Fix the max_loop commandline argument treatment when it is set to 0 block/blk-iocost (gcc13): keep large values in a new enum block, bfq: replace 0/1 with false/true in bic apis block, bfq: don't return bfqg from __bfq_bic_change_cgroup() block, bfq: fix possible uaf for 'bfqq->bic'
…p.org/agd5f/linux into drm-next amd-drm-fixes-6.2-2022-12-21: amdgpu: - Avoid large variable on the stack - S0ix fixes - SMU 13.x fixes - VCN fix - Add missing fence reference amdkfd: - Fix init vm error handling - Fix double release of compute pasid Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221221205828.6093-1-alexander.deucher@amd.com
Pull RISC-V kvm updates from Paolo Bonzini: - Allow unloading KVM module - Allow KVM user-space to set mvendorid, marchid, and mimpid - Several fixes and cleanups * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: RISC-V: KVM: Add ONE_REG interface for mvendorid, marchid, and mimpid RISC-V: KVM: Save mvendorid, marchid, and mimpid when creating VCPU RISC-V: Export sbi_get_mvendorid() and friends RISC-V: KVM: Move sbi related struct and functions to kvm_vcpu_sbi.h RISC-V: KVM: Use switch-case in kvm_riscv_vcpu_set/get_reg() RISC-V: KVM: Remove redundant includes of asm/csr.h RISC-V: KVM: Remove redundant includes of asm/kvm_vcpu_timer.h RISC-V: KVM: Fix reg_val check in kvm_riscv_vcpu_set_reg_config() RISC-V: KVM: Simplify kvm_arch_prepare_memory_region() RISC-V: KVM: Exit run-loop immediately if xfer_to_guest fails RISC-V: KVM: use vma_lookup() instead of find_vma_intersection() RISC-V: KVM: Add exit logic to main.c
…ernel/git/trace/linux-trace Pull trace probes updates from Steven Rostedt: - New "symstr" type for dynamic events that writes the name of the function+offset into the ring buffer and not just the address - Prevent kernel symbol processing on addresses in user space probes (uprobes). - And minor fixes and clean ups * tag 'trace-probes-v6.2' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: tracing/probes: Reject symbol/symstr type for uprobe tracing/probes: Add symstr type for dynamic events kprobes: kretprobe events missing on 2-core KVM guest kprobes: Fix check for probe enabled in kill_kprobe() test_kprobes: Fix implicit declaration error of test_kprobes tracing: Fix race where eprobes can be called before the event
…/git/trace/linux-trace Pull tracing fix from Steven Rostedt: "I missed this minor hardening of the kernel in the first pull. - Make monitor structures read only" * tag 'trace-v6.2-1' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: rv/monitors: Move monitor structure in rodata
The function snd_azf3328_codec_outl is defined in the azt3328.c file, but not called elsewhere, so remove this unused function. sound/pci/azt3328.c:367:1: warning: unused function 'snd_azf3328_codec_outl'. Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=3432 Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Link: https://lore.kernel.org/r/20221213061355.62856-1-jiapeng.chong@linux.alibaba.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
It seems that the firmware is broken and does not accept the UAC_EP_CS_ATTR_SAMPLE_RATE URB. There is only one rate (48000Hz) available in the descriptors for the output endpoint. Create a new quirk QUIRK_FLAG_FIXED_RATE to skip the rate setup when only one rate is available (fixed). BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=216798 Signed-off-by: Jaroslav Kysela <perex@perex.cz> Link: https://lore.kernel.org/r/20221215153037.1163786-1-perex@perex.cz Signed-off-by: Takashi Iwai <tiwai@suse.de>
…l/git/broonie/sound into for-linus ASoC: Updates for v6.2 Some more small fixes and board quirks that came in since my last update, the main one being the fixes from Kai for issues around the attempts to get kexec working well on SOF based systems.
…abled The flush request initialized by blk_kick_flush has NULL bio, and it may be dealt with nvme_end_req during io completion. When blktrace is enabled, nvme_trace_bio_complete with multipath activated trying to access NULL pointer bio from flush request results in the following crash: [ 2517.831677] BUG: kernel NULL pointer dereference, address: 000000000000001a [ 2517.835213] #PF: supervisor read access in kernel mode [ 2517.838724] #PF: error_code(0x0000) - not-present page [ 2517.842222] PGD 7b2d51067 P4D 0 [ 2517.845684] Oops: 0000 [#1] SMP NOPTI [ 2517.849125] CPU: 2 PID: 732 Comm: kworker/2:1H Kdump: loaded Tainted: G S 5.15.67-0.cl9.x86_64 #1 [ 2517.852723] Hardware name: XFUSION 2288H V6/BC13MBSBC, BIOS 1.13 07/27/2022 [ 2517.856358] Workqueue: nvme_tcp_wq nvme_tcp_io_work [nvme_tcp] [ 2517.859993] RIP: 0010:blk_add_trace_bio_complete+0x6/0x30 [ 2517.863628] Code: 1f 44 00 00 48 8b 46 08 31 c9 ba 04 00 10 00 48 8b 80 50 03 00 00 48 8b 78 50 e9 e5 fe ff ff 0f 1f 44 00 00 41 54 49 89 f4 55 <0f> b6 7a 1a 48 89 d5 e8 3e 1c 2b 00 48 89 ee 4c 89 e7 5d 89 c1 ba [ 2517.871269] RSP: 0018:ff7f6a008d9dbcd0 EFLAGS: 00010286 [ 2517.875081] RAX: ff3d5b4be00b1d50 RBX: 0000000002040002 RCX: ff3d5b0a270f2000 [ 2517.878966] RDX: 0000000000000000 RSI: ff3d5b0b021fb9f8 RDI: 0000000000000000 [ 2517.882849] RBP: ff3d5b0b96a6fa00 R08: 0000000000000001 R09: 0000000000000000 [ 2517.886718] R10: 000000000000000c R11: 000000000000000c R12: ff3d5b0b021fb9f8 [ 2517.890575] R13: 0000000002000000 R14: ff3d5b0b021fb1b0 R15: 0000000000000018 [ 2517.894434] FS: 0000000000000000(0000) GS:ff3d5b42bfc80000(0000) knlGS:0000000000000000 [ 2517.898299] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 2517.902157] CR2: 000000000000001a CR3: 00000004f023e005 CR4: 0000000000771ee0 [ 2517.906053] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 2517.909930] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 2517.913761] PKRU: 55555554 [ 2517.917558] Call Trace: [ 2517.921294] <TASK> [ 2517.924982] nvme_complete_rq+0x1c3/0x1e0 [nvme_core] [ 2517.928715] nvme_tcp_recv_pdu+0x4d7/0x540 [nvme_tcp] [ 2517.932442] nvme_tcp_recv_skb+0x4f/0x240 [nvme_tcp] [ 2517.936137] ? nvme_tcp_recv_pdu+0x540/0x540 [nvme_tcp] [ 2517.939830] tcp_read_sock+0x9c/0x260 [ 2517.943486] nvme_tcp_try_recv+0x65/0xa0 [nvme_tcp] [ 2517.947173] nvme_tcp_io_work+0x64/0x90 [nvme_tcp] [ 2517.950834] process_one_work+0x1e8/0x390 [ 2517.954473] worker_thread+0x53/0x3c0 [ 2517.958069] ? process_one_work+0x390/0x390 [ 2517.961655] kthread+0x10c/0x130 [ 2517.965211] ? set_kthread_struct+0x40/0x40 [ 2517.968760] ret_from_fork+0x1f/0x30 [ 2517.972285] </TASK> To avoid this situation, add a NULL check for req->bio before calling trace_block_bio_complete. Signed-off-by: Yanjun Zhang <zhangyanjun@cestc.cn> Signed-off-by: Christoph Hellwig <hch@lst.de>
The afs_fs_probe_dispatcher() work function is passed a count on net->servers_outstanding when it is scheduled (which may come via its timer). This is passed back to the work_item, passed to the timer or dropped at the end of the dispatcher function. But, at the top of the dispatcher function, there are two checks which skip the rest of the function: if the network namespace is being destroyed or if there are no fileservers to probe. These two return paths, however, do not drop the count passed to the dispatcher, and so, sometimes, the destruction of a network namespace, such as induced by rmmod of the kafs module, may get stuck in afs_purge_servers(), waiting for net->servers_outstanding to become zero. Fix this by adding the missing decrements in afs_fs_probe_dispatcher(). Fixes: f6cbb36 ("afs: Actively poll fileservers to maintain NAT or firewall openings") Reported-by: Marc Dionne <marc.dionne@auristor.com> Signed-off-by: David Howells <dhowells@redhat.com> Tested-by: Marc Dionne <marc.dionne@auristor.com> cc: linux-afs@lists.infradead.org Link: https://lore.kernel.org/r/167164544917.2072364.3759519569649459359.stgit@warthog.procyon.org.uk/
Variable nr_servers is no longer being used, the last reference to it was removed in commit 45df846 ("afs: Fix server list handling") so clean up the code by removing it. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: linux-afs@lists.infradead.org Link: https://lore.kernel.org/r/20221020173923.21342-1-colin.i.king@gmail.com/
afs_zap_permits() has been removed since commit be080a6 ("afs: Overhaul permit caching"). afs_cache_netfs has been removed since commit 523d27c ("afs: Convert afs to use the new fscache API"). so remove the declare for them from header file. Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com> Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: linux-afs@lists.infradead.org Link: https://lore.kernel.org/r/20220909070353.1160228-1-cuigaosheng1@huawei.com/
We're trying to get rid of the ->writepage() hook[1]. Stop afs from using it by unlocking the page and calling afs_writepages_region() rather than folio_write_one(). A flag is passed to afs_writepages_region() to indicate that it should only write a single region so that we don't flush the entire file in ->write_begin(), but do add other dirty data to the region being written to try and reduce the number of RPC ops. This requires ->migrate_folio() to be implemented, so point that at filemap_migrate_folio() for files and also for symlinks and directories. This can be tested by turning on the afs_folio_dirty tracepoint and then doing something like: xfs_io -c "w 2223 7000" -c "w 15000 22222" -c "w 23 7" /afs/my/test/foo and then looking in the trace to see if the write at position 15000 gets stored before page 0 gets dirtied for the write at position 23. Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: Christoph Hellwig <hch@lst.de> cc: Matthew Wilcox <willy@infradead.org> cc: linux-afs@lists.infradead.org Link: https://lore.kernel.org/r/20221113162902.883850-1-hch@lst.de/ [1] Link: https://lore.kernel.org/r/166876785552.222254.4403222906022558715.stgit@warthog.procyon.org.uk/ # v1
Noticed this build failure on archlinux:base when building with clang: clang-14: error: optimization flag '-ffat-lto-objects' is not supported [-Werror,-Wignored-optimization-argument] In tools/perf/util/setup.py we check if clang supports that option, but since commit 3cad53a ("perf python: Account for multiple words in CC") this got broken as in the common case where CC="clang": >>> cc="clang" >>> print(cc.split()[0]) clang >>> option="-ffat-lto-objects" >>> print(str(cc.split()[1:]) + option) []-ffat-lto-objects >>> And then the Popen will call clang with that bogus option name that in turn will not produce the b"unknown argument" or b"is not supported" that this function uses to detect if the option is not available and thus later on clang will be called with an unknown/unsupported option. Fix it by looking if really there are options in the provided CC variable, and if so override 'cc' with the first token and append the options to the 'option' variable. Fixes: 3cad53a ("perf python: Account for multiple words in CC") Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Fangrui Song <maskray@google.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: Ian Rogers <irogers@google.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: John Keeping <john@metanate.com> Cc: Khem Raj <raj.khem@gmail.com> Cc: Leo Yan <leo.yan@linaro.org> Cc: Michael Petlan <mpetlan@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Nathan Chancellor <nathan@kernel.org> Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Sedat Dilek <sedat.dilek@gmail.com> Link: http://lore.kernel.org/lkml/Y6Rq5F5NI0v1QQHM@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
SOFCI TEST |
1 similar comment
SOFCI TEST |
I can't reproduce this issue on CI devices. |
SOFCI TEST |
The regression on GLK is not caused by the kernel changes, CI build server "sof-ci-build-01" is Ubuntu 18.04 and gcc version is 9.4.0. It seems that the kernel changes require higher gcc version. I have upgraded the gcc to 11.1.0 and test passed on GLK_BOB_DA7219. |
The only errors found are timeouts in suspend-resume cases https://sof-ci.01.org/linuxpr/PR4122/build2655/devicetest/index.html @ranj063 @bardliao @ujfalusi if you can give it a try on your local devices that would be nice. I'll wait until Monday for feedback. |
Let me know if you need me to look into the coreboot configuration on that board. It seems odd that a relatively simple codec driver would all of the sudden have pin problems unless it was fighting another driver for it. |
If this new kernel is not compatible with gcc 9.4.0, compilation with gcc 9.4.0 should be blocked and fail. According to the documentation and the source code the minimum gcc version is currently 7.1: If 7.1 is wrong it should be reported and corrected but... this error message does not look like a compiler-related problem, does it? It would be interesting to git bisect this failure with gcc 9.4.0 |
@plbossart I run |
@plbossart, I have compile error locally with sparse (git version) and gcc 12.2.0:
|
Whack a mole solution is to add |
@plbossart, looks good on my devices (suspend/resume works on up2 w/ pcm512x topology). |
that's what I did with the updates. |
GitHub won't let me merge this, I keep seeing the 'confirm merge' button and nothing happens. |
now it worked. Yay clouds. |
GH is sluggish recently. |
first merge based on 6.2-rc2, smoke-tested on SoundWire device