commit 183673bef8533a3744ad27e32ca901de59e09307 Author: Greg Kroah-Hartman Date: Wed May 27 17:48:31 2020 +0200 Linux 5.6.15 commit ead9998d9af85c219ec1f5ea78fb4cc7acdd7b4c Author: Phil Auld Date: Tue May 12 09:52:22 2020 -0400 sched/fair: Fix enqueue_task_fair() warning some more [ Upstream commit b34cb07dde7c2346dec73d053ce926aeaa087303 ] sched/fair: Fix enqueue_task_fair warning some more The recent patch, fe61468b2cb (sched/fair: Fix enqueue_task_fair warning) did not fully resolve the issues with the rq->tmp_alone_branch != &rq->leaf_cfs_rq_list warning in enqueue_task_fair. There is a case where the first for_each_sched_entity loop exits due to on_rq, having incompletely updated the list. In this case the second for_each_sched_entity loop can further modify se. The later code to fix up the list management fails to do what is needed because se does not point to the sched_entity which broke out of the first loop. The list is not fixed up because the throttled parent was already added back to the list by a task enqueue in a parallel child hierarchy. Address this by calling list_add_leaf_cfs_rq if there are throttled parents while doing the second for_each_sched_entity loop. Fixes: fe61468b2cb ("sched/fair: Fix enqueue_task_fair warning") Suggested-by: Vincent Guittot Signed-off-by: Phil Auld Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Dietmar Eggemann Reviewed-by: Vincent Guittot Link: https://lkml.kernel.org/r/20200512135222.GC2201@lorien.usersys.redhat.com Signed-off-by: Sasha Levin commit 2ae9f8473fb39f06f7d89dcf5a6be74e74283ba1 Author: Vincent Guittot Date: Fri Mar 6 09:42:08 2020 +0100 sched/fair: Fix reordering of enqueue/dequeue_task_fair() [ Upstream commit 5ab297bab984310267734dfbcc8104566658ebef ] Even when a cgroup is throttled, the group se of a child cgroup can still be enqueued and its gse->on_rq stays true. When a task is enqueued on such child, we still have to update the load_avg and increase h_nr_running of the throttled cfs. Nevertheless, the 1st for_each_sched_entity() loop is skipped because of gse->on_rq == true and the 2nd loop because the cfs is throttled whereas we have to update both load_avg with the old h_nr_running and increase h_nr_running in such case. The same sequence can happen during dequeue when se moves to parent before breaking in the 1st loop. Note that the update of load_avg will effectively happen only once in order to sync up to the throttled time. Next call for updating load_avg will stop early because the clock stays unchanged. Signed-off-by: Vincent Guittot Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Fixes: 6d4d22468dae ("sched/fair: Reorder enqueue/dequeue_task_fair path") Link: https://lkml.kernel.org/r/20200306084208.12583-1-vincent.guittot@linaro.org Signed-off-by: Sasha Levin commit 25c556bf393414715d58ea30df2600f10145c60d Author: Vincent Guittot Date: Mon Feb 24 09:52:14 2020 +0000 sched/fair: Reorder enqueue/dequeue_task_fair path [ Upstream commit 6d4d22468dae3d8757af9f8b81b848a76ef4409d ] The walk through the cgroup hierarchy during the enqueue/dequeue of a task is split in 2 distinct parts for throttled cfs_rq without any added value but making code less readable. Change the code ordering such that everything related to a cfs_rq (throttled or not) will be done in the same loop. In addition, the same steps ordering is used when updating a cfs_rq: - update_load_avg - update_cfs_group - update *h_nr_running This reordering enables the use of h_nr_running in PELT algorithm. No functional and performance changes are expected and have been noticed during tests. Signed-off-by: Vincent Guittot Signed-off-by: Mel Gorman Signed-off-by: Ingo Molnar Reviewed-by: "Dietmar Eggemann " Acked-by: Peter Zijlstra Cc: Juri Lelli Cc: Valentin Schneider Cc: Phil Auld Cc: Hillf Danton Link: https://lore.kernel.org/r/20200224095223.13361-5-mgorman@techsingularity.net Signed-off-by: Sasha Levin commit f469812cdabc2f0422c8df24657948621cf4f7d1 Author: Andrii Nakryiko Date: Mon May 18 22:38:24 2020 -0700 bpf: Prevent mmap()'ing read-only maps as writable [ Upstream commit dfeb376dd4cb2c5004aeb625e2475f58a5ff2ea7 ] As discussed in [0], it's dangerous to allow mapping BPF map, that's meant to be frozen and is read-only on BPF program side, because that allows user-space to actually store a writable view to the page even after it is frozen. This is exacerbated by BPF verifier making a strong assumption that contents of such frozen map will remain unchanged. To prevent this, disallow mapping BPF_F_RDONLY_PROG mmap()'able BPF maps as writable, ever. [0] https://lore.kernel.org/bpf/CAEf4BzYGWYhXdp6BJ7_=9OQPJxQpgug080MMjdSB72i9R+5c6g@mail.gmail.com/ Fixes: fc9702273e2e ("bpf: Add mmap() support for BPF_MAP_TYPE_ARRAY") Suggested-by: Jann Horn Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Reviewed-by: Jann Horn Link: https://lore.kernel.org/bpf/20200519053824.1089415-1-andriin@fb.com Signed-off-by: Sasha Levin commit f8acf4915283019bccf59e94e7e0de408e70745d Author: David Howells Date: Wed Apr 29 23:48:43 2020 +0100 rxrpc: Fix ack discard [ Upstream commit 441fdee1eaf050ef0040bde0d7af075c1c6a6d8b ] The Rx protocol has a "previousPacket" field in it that is not handled in the same way by all protocol implementations. Sometimes it contains the serial number of the last DATA packet received, sometimes the sequence number of the last DATA packet received and sometimes the highest sequence number so far received. AF_RXRPC is using this to weed out ACKs that are out of date (it's possible for ACK packets to get reordered on the wire), but this does not work with OpenAFS which will just stick the sequence number of the last packet seen into previousPacket. The issue being seen is that big AFS FS.StoreData RPC (eg. of ~256MiB) are timing out when partly sent. A trace was captured, with an additional tracepoint to show ACKs being discarded in rxrpc_input_ack(). Here's an excerpt showing the problem. 52873.203230: rxrpc_tx_data: c=000004ae DATA ed1a3584:00000002 0002449c q=00024499 fl=09 A DATA packet with sequence number 00024499 has been transmitted (the "q=" field). ... 52873.243296: rxrpc_rx_ack: c=000004ae 00012a2b DLY r=00024499 f=00024497 p=00024496 n=0 52873.243376: rxrpc_rx_ack: c=000004ae 00012a2c IDL r=0002449b f=00024499 p=00024498 n=0 52873.243383: rxrpc_rx_ack: c=000004ae 00012a2d OOS r=0002449d f=00024499 p=0002449a n=2 The Out-Of-Sequence ACK indicates that the server didn't see DATA sequence number 00024499, but did see seq 0002449a (previousPacket, shown as "p=", skipped the number, but firstPacket, "f=", which shows the bottom of the window is set at that point). 52873.252663: rxrpc_retransmit: c=000004ae q=24499 a=02 xp=14581537 52873.252664: rxrpc_tx_data: c=000004ae DATA ed1a3584:00000002 000244bc q=00024499 fl=0b *RETRANS* The packet has been retransmitted. Retransmission recurs until the peer says it got the packet. 52873.271013: rxrpc_rx_ack: c=000004ae 00012a31 OOS r=000244a1 f=00024499 p=0002449e n=6 More OOS ACKs indicate that the other packets that are already in the transmission pipeline are being received. The specific-ACK list is up to 6 ACKs and NAKs. ... 52873.284792: rxrpc_rx_ack: c=000004ae 00012a49 OOS r=000244b9 f=00024499 p=000244b6 n=30 52873.284802: rxrpc_retransmit: c=000004ae q=24499 a=0a xp=63505500 52873.284804: rxrpc_tx_data: c=000004ae DATA ed1a3584:00000002 000244c2 q=00024499 fl=0b *RETRANS* 52873.287468: rxrpc_rx_ack: c=000004ae 00012a4a OOS r=000244ba f=00024499 p=000244b7 n=31 52873.287478: rxrpc_rx_ack: c=000004ae 00012a4b OOS r=000244bb f=00024499 p=000244b8 n=32 At this point, the server's receive window is full (n=32) with presumably 1 NAK'd packet and 31 ACK'd packets. We can't transmit any more packets. 52873.287488: rxrpc_retransmit: c=000004ae q=24499 a=0a xp=61327980 52873.287489: rxrpc_tx_data: c=000004ae DATA ed1a3584:00000002 000244c3 q=00024499 fl=0b *RETRANS* 52873.293850: rxrpc_rx_ack: c=000004ae 00012a4c DLY r=000244bc f=000244a0 p=00024499 n=25 And now we've received an ACK indicating that a DATA retransmission was received. 7 packets have been processed (the occupied part of the window moved, as indicated by f= and n=). 52873.293853: rxrpc_rx_discard_ack: c=000004ae r=00012a4c 000244a0<00024499 00024499<000244b8 However, the DLY ACK gets discarded because its previousPacket has gone backwards (from p=000244b8, in the ACK at 52873.287478 to p=00024499 in the ACK at 52873.293850). We then end up in a continuous cycle of retransmit/discard. kafs fails to update its window because it's discarding the ACKs and can't transmit an extra packet that would clear the issue because the window is full. OpenAFS doesn't change the previousPacket value in the ACKs because no new DATA packets are received with a different previousPacket number. Fix this by altering the discard check to only discard an ACK based on previousPacket if there was no advance in the firstPacket. This allows us to transmit a new packet which will cause previousPacket to advance in the next ACK. The check, however, needs to allow for the possibility that previousPacket may actually have had the serial number placed in it instead - in which case it will go outside the window and we should ignore it. Fixes: 1a2391c30c0b ("rxrpc: Fix detection of out of order acks") Reported-by: Dave Botsch Signed-off-by: David Howells Signed-off-by: Sasha Levin commit 1756aa07ae9dfbb6fa42a54cc879140ad616aac6 Author: David Howells Date: Tue Apr 28 22:06:54 2020 +0100 rxrpc: Trace discarded ACKs [ Upstream commit d1f129470e6cb79b8b97fecd12689f6eb49e27fe ] Add a tracepoint to track received ACKs that are discarded due to being outside of the Tx window. Signed-off-by: David Howells Signed-off-by: Sasha Levin commit 383410f1d72ff12310beae4e527006bea238cf51 Author: Josh Poimboeuf Date: Fri May 22 08:54:35 2020 -0500 x86/unwind/orc: Fix unwind_get_return_address_ptr() for inactive tasks commit 187b96db5ca79423618dfa29a05c438c34f9e1f0 upstream. Normally, show_trace_log_lvl() scans the stack, looking for text addresses to print. In parallel, it unwinds the stack with unwind_next_frame(). If the stack address matches the pointer returned by unwind_get_return_address_ptr() for the current frame, the text address is printed normally without a question mark. Otherwise it's considered a breadcrumb (potentially from a previous call path) and it's printed with a question mark to indicate that the address is unreliable and typically can be ignored. Since the following commit: f1d9a2abff66 ("x86/unwind/orc: Don't skip the first frame for inactive tasks") ... for inactive tasks, show_trace_log_lvl() prints *only* unreliable addresses (prepended with '?'). That happens because, for the first frame of an inactive task, unwind_get_return_address_ptr() returns the wrong return address pointer: one word *below* the task stack pointer. show_trace_log_lvl() starts scanning at the stack pointer itself, so it never finds the first 'reliable' address, causing only guesses to being printed. The first frame of an inactive task isn't a normal stack frame. It's actually just an instance of 'struct inactive_task_frame' which is left behind by __switch_to_asm(). Now that this inactive frame is actually exposed to callers, fix unwind_get_return_address_ptr() to interpret it properly. Fixes: f1d9a2abff66 ("x86/unwind/orc: Don't skip the first frame for inactive tasks") Reported-by: Tetsuo Handa Signed-off-by: Josh Poimboeuf Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20200522135435.vbxs7umku5pyrdbk@treble Signed-off-by: Greg Kroah-Hartman commit 0b846ed9f5edf5afd0b2bdaaaf3be7c50933aeb8 Author: Jakub Sitnicki Date: Thu May 21 10:34:35 2020 +0200 flow_dissector: Drop BPF flow dissector prog ref on netns cleanup commit 5cf65922bb15279402e1e19b5ee8c51d618fa51f upstream. When attaching a flow dissector program to a network namespace with bpf(BPF_PROG_ATTACH, ...) we grab a reference to bpf_prog. If netns gets destroyed while a flow dissector is still attached, and there are no other references to the prog, we leak the reference and the program remains loaded. Leak can be reproduced by running flow dissector tests from selftests/bpf: # bpftool prog list # ./test_flow_dissector.sh ... selftests: test_flow_dissector [PASS] # bpftool prog list 4: flow_dissector name _dissect tag e314084d332a5338 gpl loaded_at 2020-05-20T18:50:53+0200 uid 0 xlated 552B jited 355B memlock 4096B map_ids 3,4 btf_id 4 # Fix it by detaching the flow dissector program when netns is going away. Fixes: d58e468b1112 ("flow_dissector: implements flow dissector BPF hook") Signed-off-by: Jakub Sitnicki Signed-off-by: Alexei Starovoitov Reviewed-by: Stanislav Fomichev Link: https://lore.kernel.org/bpf/20200521083435.560256-1-jakub@cloudflare.com Signed-off-by: Greg Kroah-Hartman commit 13496defdcc80d2fc5c93e602c04ce2cc69c90f7 Author: Philipp Rudo Date: Tue May 12 19:39:56 2020 +0200 s390/kexec_file: fix initrd location for kdump kernel commit 70b690547d5ea1a3d135a4cc39cd1e08246d0c3a upstream. initrd_start must not point at the location the initrd is loaded into the crashkernel memory but at the location it will be after the crashkernel memory is swapped with the memory at 0. Fixes: ee337f5469fd ("s390/kexec_file: Add crash support to image loader") Reported-by: Lianbo Jiang Signed-off-by: Philipp Rudo Tested-by: Lianbo Jiang Link: https://lore.kernel.org/r/20200512193956.15ae3f23@laptop2-ibm.local Signed-off-by: Christian Borntraeger Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit 08731bd847fd661818836fdc5dfb838d620ff499 Author: Loïc Yhuel Date: Tue May 12 06:01:13 2020 +0200 tpm: check event log version before reading final events commit b4f1874c62168159fdb419ced4afc77c1b51c475 upstream. This fixes the boot issues since 5.3 on several Dell models when the TPM is enabled. Depending on the exact grub binary, booting the kernel would freeze early, or just report an error parsing the final events log. We get an event log in the SHA-1 format, which doesn't have a tcg_efi_specid_event_head in the first event, and there is a final events table which doesn't match the crypto agile format. __calc_tpm2_event_size reads bad "count" and "efispecid->num_algs", and either fails, or loops long enough for the machine to be appear frozen. So we now only parse the final events table, which is per the spec always supposed to be in the crypto agile format, when we got a event log in this format. Fixes: c46f3405692de ("tpm: Reserve the TPM final events table") Fixes: 166a2809d65b2 ("tpm: Don't duplicate events from the final event log in the TCG2 log") Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1779611 Signed-off-by: Loïc Yhuel Link: https://lore.kernel.org/r/20200512040113.277768-1-loic.yhuel@gmail.com Reviewed-by: Javier Martinez Canillas Reviewed-by: Jerry Snitselaar Reviewed-by: Matthew Garrett [ardb: warn when final events table is missing or in the wrong format] Signed-off-by: Ard Biesheuvel Signed-off-by: Greg Kroah-Hartman commit 8b54aba26e62652e2b85726495a6cc314852b3f7 Author: Qiushi Wu Date: Fri May 22 13:45:18 2020 -0500 rxrpc: Fix a memory leak in rxkad_verify_response() commit f45d01f4f30b53c3a0a1c6c1c154acb7ff74ab9f upstream. A ticket was not released after a call of the function "rxkad_decrypt_ticket" failed. Thus replace the jump target "temporary_error_free_resp" by "temporary_error_free_ticket". Fixes: 8c2f826dc3631 ("rxrpc: Don't put crypto buffers on the stack") Signed-off-by: Qiushi Wu Signed-off-by: David Howells cc: Markus Elfring Signed-off-by: Greg Kroah-Hartman commit f89bb5b13a3a2f7ebb796933f17a26d94d9c2ae9 Author: David Howells Date: Mon May 11 14:54:34 2020 +0100 rxrpc: Fix the excessive initial retransmission timeout commit c410bf01933e5e09d142c66c3df9ad470a7eec13 upstream. rxrpc currently uses a fixed 4s retransmission timeout until the RTT is sufficiently sampled. This can cause problems with some fileservers with calls to the cache manager in the afs filesystem being dropped from the fileserver because a packet goes missing and the retransmission timeout is greater than the call expiry timeout. Fix this by: (1) Copying the RTT/RTO calculation code from Linux's TCP implementation and altering it to fit rxrpc. (2) Altering the various users of the RTT to make use of the new SRTT value. (3) Replacing the use of rxrpc_resend_timeout to use the calculated RTO value instead (which is needed in jiffies), along with a backoff. Notes: (1) rxrpc provides RTT samples by matching the serial numbers on outgoing DATA packets that have the RXRPC_REQUEST_ACK set and PING ACK packets against the reference serial number in incoming REQUESTED ACK and PING-RESPONSE ACK packets. (2) Each packet that is transmitted on an rxrpc connection gets a new per-connection serial number, even for retransmissions, so an ACK can be cross-referenced to a specific trigger packet. This allows RTT information to be drawn from retransmitted DATA packets also. (3) rxrpc maintains the RTT/RTO state on the rxrpc_peer record rather than on an rxrpc_call because many RPC calls won't live long enough to generate more than one sample. (4) The calculated SRTT value is in units of 8ths of a microsecond rather than nanoseconds. The (S)RTT and RTO values are displayed in /proc/net/rxrpc/peers. Fixes: 17926a79320a ([AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both"") Signed-off-by: David Howells Signed-off-by: Greg Kroah-Hartman commit fd738244ffb1c46284a4c7d50a88f4f7669b6d2e Author: Dan Carpenter Date: Wed Apr 22 12:38:11 2020 +0300 iio: imu: st_lsm6dsx: unlock on error in st_lsm6dsx_shub_write_raw() commit 115c215a7e5753ddf982c8760ce7904dd3fbb8ae upstream. We need to release a lock if st_lsm6dsx_check_odr() fails, we can't return directly. Fixes: 76551a3c3df1 ("iio: imu: st_lsm6dsx: specify slave odr in slv_odr") Signed-off-by: Dan Carpenter Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit a90e52a68e49722b3bc1c0cc221812610f925058 Author: Uladzislau Rezki Date: Fri May 22 22:23:12 2020 -0700 z3fold: fix use-after-free when freeing handles commit d8f117abb380ba968b5e3ef2042d901c02872a4c upstream. free_handle() for a foreign handle may race with inter-page compaction, what can lead to memory corruption. To avoid that, take write lock not read lock in free_handle to be synchronized with __release_z3fold_page(). For example KASAN can detect it: ================================================================== BUG: KASAN: use-after-free in LZ4_decompress_safe+0x2c4/0x3b8 Read of size 1 at addr ffffffc976695ca3 by task GoogleApiHandle/4121 CPU: 0 PID: 4121 Comm: GoogleApiHandle Tainted: P S OE 4.19.81-perf+ #162 Hardware name: Sony Mobile Communications. PDX-203(KONA) (DT) Call trace: LZ4_decompress_safe+0x2c4/0x3b8 lz4_decompress_crypto+0x3c/0x70 crypto_decompress+0x58/0x70 zcomp_decompress+0xd4/0x120 ... Apart from that, initialize zhdr->mapped_count in init_z3fold_page() and remove "newpage" variable because it is not used anywhere. Signed-off-by: Uladzislau Rezki Signed-off-by: Vitaly Wool Signed-off-by: Andrew Morton Cc: Qian Cai Cc: Raymond Jennings Cc: Link: http://lkml.kernel.org/r/20200520082100.28876-1-vitaly.wool@konsulko.com Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 95bd5cc32c8f58f92f5447676ef254be52790dc5 Author: Mike Rapoport Date: Sat May 23 22:57:18 2020 +0300 sparc32: fix page table traversal in srmmu_nocache_init() commit 0cfc8a8d70dcd51db783e8e87917e02149c71458 upstream. The srmmu_nocache_init() uses __nocache_fix() macro to add an offset to page table entry to access srmmu_nocache_pool. But since sparc32 has only three actual page table levels, pgd, p4d and pud are essentially the same thing and pgd_offset() and p4d_offset() are no-ops, the __nocache_fix() should be done only at PUD level. Remove __nocache_fix() for p4d_offset() and pud_offset() and keep it only for PUD and lower levels. Fixes: c2bc26f7ca1f ("sparc32: use PUD rather than PGD to get PMD in srmmu_nocache_init()") Signed-off-by: Mike Rapoport Cc: David S. Miller Cc: Anatoly Pugachev Cc: Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 183c932ade90d99e56023854cfe649761016cf13 Author: Mike Rapoport Date: Fri May 22 22:23:09 2020 -0700 sparc32: use PUD rather than PGD to get PMD in srmmu_nocache_init() commit c2bc26f7ca1ff1165bb6669a7a4cccc20ffd2ced upstream. The kbuild test robot reported the following warning: arch/sparc/mm/srmmu.c: In function 'srmmu_nocache_init': arch/sparc/mm/srmmu.c:300:9: error: variable 'pud' set but not used [-Werror=unused-but-set-variable] 300 | pud_t *pud; This warning is caused by misprint in the page table traversal in srmmu_nocache_init() function which accessed a PMD entry using PGD rather than PUD. Since sparc32 has only 3 page table levels, the PGD and PUD are essentially the same and usage of __nocache_fix() removed the type checking. Use PUD for the consistency and to silence the compiler warning. Fixes: 7235db268a2777bc38 ("sparc32: use pgtable-nopud instead of 4level-fixup") Reported-by: kbuild test robot Signed-off-by: Mike Rapoport Signed-off-by: Andrew Morton Cc: David S. Miller Cc: Anatoly Pugachev Cc: Link: http://lkml.kernel.org/r/20200520132005.GM1059226@linux.ibm.com Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 819b6d7c0f4c5326c36dd19ba52978cf3a229323 Author: Arnd Bergmann Date: Fri May 22 22:23:02 2020 -0700 sh: include linux/time_types.h for sockios commit fc94cf2092c7c1267fa2deb8388d624f50eba808 upstream. Using the socket ioctls on arch/sh (and only there) causes build time problems when __kernel_old_timeval/__kernel_old_timespec are not already visible to the compiler. Add an explict include line for the header that defines these structures. Fixes: 8c709f9a0693 ("y2038: sh: remove timeval/timespec usage from headers") Fixes: 0768e17073dc ("net: socket: implement 64-bit timestamps") Reported-by: John Paul Adrian Glaubitz Signed-off-by: Arnd Bergmann Signed-off-by: Andrew Morton Tested-by: John Paul Adrian Glaubitz Cc: Yoshinori Sato Cc: Rich Felker Cc: "David S. Miller" Cc: John Paul Adrian Glaubitz Cc: Link: http://lkml.kernel.org/r/20200519131327.1836482-1-arnd@arndb.de Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit b12f2fe23815e1437ce0bd3df3b14483fa3539cd Author: Marco Elver Date: Fri May 22 22:22:59 2020 -0700 kasan: disable branch tracing for core runtime commit 33cd65e73abd693c00c4156cf23677c453b41b3b upstream. During early boot, while KASAN is not yet initialized, it is possible to enter reporting code-path and end up in kasan_report(). While uninitialized, the branch there prevents generating any reports, however, under certain circumstances when branches are being traced (TRACE_BRANCH_PROFILING), we may recurse deep enough to cause kernel reboots without warning. To prevent similar issues in future, we should disable branch tracing for the core runtime. [elver@google.com: remove duplicate DISABLE_BRANCH_PROFILING, per Qian Cai] Link: https://lore.kernel.org/lkml/20200517011732.GE24705@shao2-debian/ Link: http://lkml.kernel.org/r/20200522075207.157349-1-elver@google.com Reported-by: kernel test robot Signed-off-by: Marco Elver Signed-off-by: Andrew Morton Reviewed-by: Andrey Konovalov Cc: Dmitry Vyukov Cc: Alexander Potapenko Cc: Andrey Ryabinin Cc: Qian Cai Cc: Link: http://lkml.kernel.org/r//20200517011732.GE24705@shao2-debian/ Link: http://lkml.kernel.org/r/20200519182459.87166-1-elver@google.com Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit f0b4f3ac06f6bcc606cd597b93d4b831b6b93db1 Author: John Hubbard Date: Fri May 22 22:22:48 2020 -0700 rapidio: fix an error in get_user_pages_fast() error handling commit ffca476a0a8d26de767cc41d62b8ca7f540ecfdd upstream. In the case of get_user_pages_fast() returning fewer pages than requested, rio_dma_transfer() does not quite do the right thing. It attempts to release all the pages that were requested, rather than just the pages that were pinned. Fix the error handling so that only the pages that were successfully pinned are released. Fixes: e8de370188d0 ("rapidio: add mport char device driver") Signed-off-by: John Hubbard Signed-off-by: Andrew Morton Reviewed-by: Andrew Morton Cc: Matt Porter Cc: Alexandre Bounine Cc: Sumit Semwal Cc: Dan Carpenter Cc: Link: http://lkml.kernel.org/r/20200517235620.205225-2-jhubbard@nvidia.com Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 513cdf8c4dc505f41573e05cb953d4603ae8b693 Author: David Hildenbrand Date: Fri May 22 22:22:42 2020 -0700 device-dax: don't leak kernel memory to user space after unloading kmem commit 60858c00e5f018eda711a3aa84cf62214ef62d61 upstream. Assume we have kmem configured and loaded: [root@localhost ~]# cat /proc/iomem ... 140000000-33fffffff : Persistent Memory$ 140000000-1481fffff : namespace0.0 150000000-33fffffff : dax0.0 150000000-33fffffff : System RAM Assume we try to unload kmem. This force-unloading will work, even if memory cannot get removed from the system. [root@localhost ~]# rmmod kmem [ 86.380228] removing memory fails, because memory [0x0000000150000000-0x0000000157ffffff] is onlined ... [ 86.431225] kmem dax0.0: DAX region [mem 0x150000000-0x33fffffff] cannot be hotremoved until the next reboot Now, we can reconfigure the namespace: [root@localhost ~]# ndctl create-namespace --force --reconfig=namespace0.0 --mode=devdax [ 131.409351] nd_pmem namespace0.0: could not reserve region [mem 0x140000000-0x33fffffff]dax [ 131.410147] nd_pmem: probe of namespace0.0 failed with error -16namespace0.0 --mode=devdax ... This fails as expected due to the busy memory resource, and the memory cannot be used. However, the dax0.0 device is removed, and along its name. The name of the memory resource now points at freed memory (name of the device): [root@localhost ~]# cat /proc/iomem ... 140000000-33fffffff : Persistent Memory 140000000-1481fffff : namespace0.0 150000000-33fffffff : �_�^7_��/_��wR��WQ���^��� ... 150000000-33fffffff : System RAM We have to make sure to duplicate the string. While at it, remove the superfluous setting of the name and fixup a stale comment. Fixes: 9f960da72b25 ("device-dax: "Hotremove" persistent memory that is used like normal RAM") Signed-off-by: David Hildenbrand Signed-off-by: Andrew Morton Cc: Dan Williams Cc: Vishal Verma Cc: Dave Jiang Cc: Pavel Tatashin Cc: Andrew Morton Cc: [5.3] Link: http://lkml.kernel.org/r/20200508084217.9160-2-david@redhat.com Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit a383e8a7864bb97dea63aadadc32d9310fc834d8 Author: Gerald Schaefer Date: Wed May 6 13:45:52 2020 +0200 s390/kaslr: add support for R_390_JMP_SLOT relocation type commit 4c1cbcbd6c56c79de2c07159be4f55386bb0bef2 upstream. With certain kernel configurations, the R_390_JMP_SLOT relocation type might be generated, which is not expected by the KASLR relocation code, and the kernel stops with the message "Unknown relocation type". This was found with a zfcpdump kernel config, where CONFIG_MODULES=n and CONFIG_VFIO=n. In that case, symbol_get() is used on undefined __weak symbols in virt/kvm/vfio.c, which results in the generation of R_390_JMP_SLOT relocation types. Fix this by handling R_390_JMP_SLOT similar to R_390_GLOB_DAT. Fixes: 805bc0bc238f ("s390/kernel: build a relocatable kernel") Cc: # v5.2+ Signed-off-by: Gerald Schaefer Reviewed-by: Philipp Rudo Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit ec42891e951f3074f62b1b9fac94d18ec93814a2 Author: Niklas Schnelle Date: Thu Mar 26 12:22:50 2020 +0100 s390/pci: Fix s390_mmio_read/write with MIO commit f058599e22d59e594e5aae1dc10560568d8f4a8b upstream. The s390_mmio_read/write syscalls are currently broken when running with MIO. The new pcistb_mio/pcstg_mio/pcilg_mio instructions are executed similiarly to normal load/store instructions and do address translation in the current address space. That means inside the kernel they are aware of mappings into kernel address space while outside the kernel they use user space mappings (usually created through mmap'ing a PCI device file). Now when existing user space applications use the s390_pci_mmio_write and s390_pci_mmio_read syscalls, they pass I/O addresses that are mapped into user space so as to be usable with the new instructions without needing a syscall. Accessing these addresses with the old instructions as done currently leads to a kernel panic. Also, for such a user space mapping there may not exist an equivalent kernel space mapping which means we can't just use the new instructions in kernel space. Instead of replicating user mappings in the kernel which then might collide with other mappings, we can conceptually execute the new instructions as if executed by the user space application using the secondary address space. This even allows us to directly store to the user pointer without the need for copy_to/from_user(). Cc: stable@vger.kernel.org Fixes: 71ba41c9b1d9 ("s390/pci: provide support for MIO instructions") Signed-off-by: Niklas Schnelle Reviewed-by: Sven Schnelle Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit f0ed431f46cd8cdfb8e55b007b09e2ae7dfc21f9 Author: Wei Yongjun Date: Thu May 7 09:42:37 2020 +0000 ipack: tpci200: fix error return code in tpci200_register() commit 133317479f0324f6faaf797c4f5f3e9b1b36ce35 upstream. Fix to return negative error code -ENOMEM from the ioremap() error handling case instead of 0, as done elsewhere in this function. Fixes: 43986798fd50 ("ipack: add error handling for ioremap_nocache") Reported-by: Hulk Robot Signed-off-by: Wei Yongjun Cc: stable Acked-by: Samuel Iglesias Gonsalvez Link: https://lore.kernel.org/r/20200507094237.13599-1-weiyongjun1@huawei.com Signed-off-by: Greg Kroah-Hartman commit 54ec7b55bee893add20d2896681157ef72af8a95 Author: Alexander Usyskin Date: Wed May 13 01:31:40 2020 +0300 mei: release me_cl object reference commit fc9c03ce30f79b71807961bfcb42be191af79873 upstream. Allow me_cl object to be freed by releasing the reference that was acquired by one of the search functions: __mei_me_cl_by_uuid_id() or __mei_me_cl_by_uuid() Cc: Reported-by: 亿一 Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler Link: https://lore.kernel.org/r/20200512223140.32186-1-tomas.winkler@intel.com Signed-off-by: Greg Kroah-Hartman commit fdf302db828f889213ccba029a07833d55f41ce6 Author: Sagar Shrikant Kadam Date: Sat May 9 03:24:12 2020 -0700 tty: serial: add missing spin_lock_init for SiFive serial console commit 17b4efdf4e4867079012a48ca10d965fe9d68822 upstream. An uninitialised spin lock for sifive serial console raises a bad magic spin_lock error as reported and discussed here [1]. Initialising the spin lock resolves the issue. The fix is tested on HiFive Unleashed A00 board with Linux 5.7-rc4 and OpenSBI v0.7 [1] https://lore.kernel.org/linux-riscv/b9fe49483a903f404e7acc15a6efbef756db28ae.camel@wdc.com Fixes: 45c054d0815b ("tty: serial: add driver for the SiFive UART") Reported-by: Atish Patra Signed-off-by: Sagar Shrikant Kadam Reviewed-by: Palmer Dabbelt Acked-by: Palmer Dabbelt Cc: stable Link: https://lore.kernel.org/r/1589019852-21505-2-git-send-email-sagar.kadam@sifive.com Signed-off-by: Greg Kroah-Hartman commit 973c9dbcc74938bcdfe4b87eec8c7d67935ad860 Author: Klaus Doth Date: Fri May 22 12:56:04 2020 +0200 misc: rtsx: Add short delay after exit from ASPM commit 7a839dbab1be59f5ed3b3b046de29e166784c9b4 upstream. DMA transfers to and from the SD card stall for 10 seconds and run into timeout on RTS5260 card readers after ASPM was enabled. Adding a short msleep after disabling ASPM fixes the issue on several Dell Precision 7530/7540 systems I tested. This function is only called when waking up after the chip went into power-save after not transferring data for a few seconds. The added msleep does therefore not change anything in data transfer speed or induce any excessive waiting while data transfers are running, or the chip is sleeping. Only the transition from sleep to active is affected. Signed-off-by: Klaus Doth Cc: stable Link: https://lore.kernel.org/r/4434eaa7-2ee3-a560-faee-6cee63ebd6d4@doth.eu Signed-off-by: Greg Kroah-Hartman commit df94bc7197f5747f0fc2d17e2c7216e150e86669 Author: Saravana Kannan Date: Tue May 19 21:36:26 2020 -0700 driver core: Fix handling of SYNC_STATE_ONLY + STATELESS device links commit 44e960490ddf868fc9135151c4a658936e771dc2 upstream. Commit 21c27f06587d ("driver core: Fix SYNC_STATE_ONLY device link implementation") didn't completely fix STATELESS + SYNC_STATE_ONLY handling. What looks like an optimization in that commit is actually a bug that causes an if condition to always take the else path. This prevents reordering of devices in the dpm_list when a DL_FLAG_STATELESS device link is create on top of an existing DL_FLAG_SYNC_STATE_ONLY device link. Fixes: 21c27f06587d ("driver core: Fix SYNC_STATE_ONLY device link implementation") Signed-off-by: Saravana Kannan Cc: stable Reviewed-by: Rafael J. Wysocki Link: https://lore.kernel.org/r/20200520043626.181820-1-saravanak@google.com Signed-off-by: Greg Kroah-Hartman commit 964ab7147dbc80dbb980cfa71930b2c233366dd4 Author: Saravana Kannan Date: Mon May 18 23:30:00 2020 -0700 driver core: Fix SYNC_STATE_ONLY device link implementation commit 21c27f06587d2c18150d27ca2382a509ec55c482 upstream. When SYNC_STATE_ONLY support was added in commit 05ef983e0d65 ("driver core: Add device link support for SYNC_STATE_ONLY flag"), device_link_add() incorrectly skipped adding the new SYNC_STATE_ONLY device link to the supplier's and consumer's "device link" list. This causes multiple issues: - The device link is lost forever from driver core if the caller didn't keep track of it (caller typically isn't expected to). This is a memory leak. - The device link is also never visible to any other code path after device_link_add() returns. If we fix the "device link" list handling, that exposes a bunch of issues. 1. The device link "status" state management code rightfully doesn't handle the case where a DL_FLAG_MANAGED device link exists between a supplier and consumer, but the consumer manages to probe successfully before the supplier. The addition of DL_FLAG_SYNC_STATE_ONLY links break this assumption. This causes device_links_driver_bound() to throw a warning when this happens. Since DL_FLAG_SYNC_STATE_ONLY device links are mainly used for creating proxy device links for child device dependencies and aren't useful once the consumer device probes successfully, this patch just deletes DL_FLAG_SYNC_STATE_ONLY device links once its consumer device probes. This way, we avoid the warning, free up some memory and avoid complicating the device links "status" state management code. 2. Creating a DL_FLAG_STATELESS device link between two devices that already have a DL_FLAG_SYNC_STATE_ONLY device link will result in the DL_FLAG_STATELESS flag not getting set correctly. This patch also fixes this. Lastly, this patch also fixes minor whitespace issues. Cc: stable@vger.kernel.org Fixes: 05ef983e0d65 ("driver core: Add device link support for SYNC_STATE_ONLY flag") Signed-off-by: Saravana Kannan Reviewed-by: Rafael J. Wysocki Link: https://lore.kernel.org/r/20200519063000.128819-1-saravanak@google.com Signed-off-by: Greg Kroah-Hartman commit dd3449fa58168e7c4e9199f713cc4fbd1daa7ba6 Author: Gregory CLEMENT Date: Thu Apr 30 15:05:47 2020 +0200 iio: adc: ti-ads8344: Fix channel selection commit bcfa1e253d2e329e1ebab5c89f3c73f6dd17606c upstream. During initial submission the selection of the channel was done using the scan_index member of the iio_chan_spec structure. It was an abuse because this member is supposed to be used with a buffer so it was removed. However there was still the need to be able to known how to select a channel, the correct member to store this information is address. Thanks to this it is possible to select any other channel than the channel 0. Fixes: 8dd2d7c0fed7 ("iio: adc: Add driver for the TI ADS8344 A/DC chips") Signed-off-by: Gregory CLEMENT Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 40694601ec11f5b4543c366aac44bebdd4aaad3f Author: Christophe JAILLET Date: Sun Apr 26 21:44:03 2020 +0200 iio: dac: vf610: Fix an error handling path in 'vf610_dac_probe()' commit aad4742fbf0a560c25827adb58695a4497ffc204 upstream. A call to 'vf610_dac_exit()' is missing in an error handling path. Fixes: 1b983bf42fad ("iio: dac: vf610_dac: Add IIO DAC driver for Vybrid SoC") Signed-off-by: Christophe JAILLET Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 32f4ac58e899646ec4a850d0fbce404b3504718f Author: Christophe JAILLET Date: Wed May 6 05:52:06 2020 +0200 iio: sca3000: Remove an erroneous 'get_device()' commit 928edefbc18cd8433f7df235c6e09a9306e7d580 upstream. This looks really unusual to have a 'get_device()' hidden in a 'dev_err()' call. Remove it. While at it add a missing \n at the end of the message. Fixes: 574fb258d636 ("Staging: IIO: VTI sca3000 series accelerometer driver (spi)") Signed-off-by: Christophe JAILLET Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 6094cff3a0ba626f70722fd9e28801402aa813c3 Author: Fabrice Gasnier Date: Thu Apr 30 11:28:46 2020 +0200 iio: adc: stm32-dfsdm: fix device used to request dma commit b455d06e6fb3c035711e8aab1ca18082ccb15d87 upstream. DMA channel request should use device struct from platform device struct. Currently it's using iio device struct. But at this stage when probing, device struct isn't yet registered (e.g. device_register is done in iio_device_register). Since commit 71723a96b8b1 ("dmaengine: Create symlinks between DMA channels and slaves"), a warning message is printed as the links in sysfs can't be created, due to device isn't yet registered: - Cannot create DMA slave symlink - Cannot create DMA dma:rx symlink Fix this by using device struct from platform device to request dma chan. Fixes: eca949800d2d ("IIO: ADC: add stm32 DFSDM support for PDM microphone") Signed-off-by: Fabrice Gasnier Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit bdec050742d5593a01a06bfee736c4457d6f9531 Author: Fabrice Gasnier Date: Thu Apr 30 11:28:45 2020 +0200 iio: adc: stm32-adc: fix device used to request dma commit 52cd91c27f3908b88e8b25aed4a4d20660abcc45 upstream. DMA channel request should use device struct from platform device struct. Currently it's using iio device struct. But at this stage when probing, device struct isn't yet registered (e.g. device_register is done in iio_device_register). Since commit 71723a96b8b1 ("dmaengine: Create symlinks between DMA channels and slaves"), a warning message is printed as the links in sysfs can't be created, due to device isn't yet registered: - Cannot create DMA slave symlink - Cannot create DMA dma:rx symlink Fix this by using device struct from platform device to request dma chan. Fixes: 2763ea0585c99 ("iio: adc: stm32: add optional dma support") Signed-off-by: Fabrice Gasnier Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 35e19f3de3502315112bfda21de90fa80109ad3a Author: Oscar Carter Date: Sun May 10 12:14:26 2020 +0200 staging: greybus: Fix uninitialized scalar variable commit 34625c1931f8204c234c532b446b9f53c69f4b68 upstream. In the "gb_tty_set_termios" function the "newline" variable is declared but not initialized. So the "flow_control" member is not initialized and the OR / AND operations with itself results in an undefined value in this member. The purpose of the code is to set the flow control type, so remove the OR / AND self operator and set the value directly. Addresses-Coverity-ID: 1374016 ("Uninitialized scalar variable") Fixes: e55c25206d5c9 ("greybus: uart: Handle CRTSCTS flag in termios") Signed-off-by: Oscar Carter Cc: stable Link: https://lore.kernel.org/r/20200510101426.23631-1-oscar.carter@gmx.com Signed-off-by: Greg Kroah-Hartman commit b72a45715fe3d010c5454f4157d7e7ee6060e4a6 Author: Wei Yongjun Date: Wed May 6 13:47:35 2020 +0000 staging: kpc2000: fix error return code in kp2000_pcie_probe() commit b17884ccf29e127b16bba6aea1438c851c9f5af1 upstream. Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Also removed var 'rv' since we can use 'err' instead. Fixes: 7dc7967fc39a ("staging: kpc2000: add initial set of Daktronics drivers") Signed-off-by: Wei Yongjun Cc: stable Reviewed-by: Dan Carpenter Link: https://lore.kernel.org/r/20200506134735.102041-1-weiyongjun1@huawei.com Signed-off-by: Greg Kroah-Hartman commit a990493efa0d4f820c15b2e8860d234337963872 Author: Dan Carpenter Date: Tue May 12 11:36:56 2020 +0300 staging: wfx: unlock on error path commit f0b9d875faa4499afe3381404c3795e9da84bc00 upstream. We need to release the tx_lock on the error path before returning. Fixes: d1c015b4ef6f ("staging: wfx: rewrite wfx_hw_scan()") Signed-off-by: Dan Carpenter Cc: stable Reviewed-by: Jérôme Pouiller Link: https://lore.kernel.org/r/20200512083656.GA251760@mwanda Signed-off-by: Greg Kroah-Hartman commit 76c83826409d03bf519cd3f07307f5df975856c9 Author: Dragos Bogdan Date: Wed Apr 29 10:21:29 2020 +0300 staging: iio: ad2s1210: Fix SPI reading commit 5e4f99a6b788047b0b8a7496c2e0c8f372f6edf2 upstream. If the serial interface is used, the 8-bit address should be latched using the rising edge of the WR/FSYNC signal. This basically means that a CS change is required between the first byte sent, and the second one. This change splits the single-transfer transfer of 2 bytes into 2 transfers with a single byte, and CS change in-between. Note fixes tag is not accurate, but reflects a point beyond which there are too many refactors to make backporting straight forward. Fixes: b19e9ad5e2cb ("staging:iio:resolver:ad2s1210 general driver cleanup.") Signed-off-by: Dragos Bogdan Signed-off-by: Alexandru Ardelean Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 5db710430bbdf90a556fcdf11a1d78dc7ce41b98 Author: Kees Cook Date: Tue Mar 3 18:18:34 2020 -0800 kbuild: Remove debug info from kallsyms linking [ Upstream commit af73d78bd384aa9b8789aa6e7ddbb165f971276f ] When CONFIG_DEBUG_INFO is enabled, the two kallsyms linking steps spend time collecting and writing the dwarf sections to the temporary output files. kallsyms does not need this information, and leaving it off halves their linking time. This is especially noticeable without CONFIG_DEBUG_INFO_REDUCED. The BTF linking stage, however, does still need those details. Refactor the BTF and kallsyms generation stages slightly for more regularized temporary names. Skip debug during kallsyms links. Additionally move "info BTF" to the correct place since commit 8959e39272d6 ("kbuild: Parameterize kallsyms generation and correct reporting"), which added "info LD ..." to vmlinux_link calls. For a full debug info build with BTF, my link time goes from 1m06s to 0m54s, saving about 12 seconds, or 18%. Signed-off-by: Kees Cook Signed-off-by: Daniel Borkmann Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/202003031814.4AEA3351@keescook Signed-off-by: Sasha Levin commit d76750df781923437a28fc29ef70d36d399bfcb2 Author: Steven Rostedt (VMware) Date: Fri May 8 11:07:56 2020 -0400 tools/bootconfig: Fix apply_xbc() to return zero on success [ Upstream commit 9d82ccda2bc5c148060543d249d54f8703741bb4 ] The return of apply_xbc() returns the result of the last write() call, which is not what is expected. It should only return zero on success. Link: https://lore.kernel.org/r/20200508093059.GF9365@kadam Fixes: 8842604446d1 ("tools/bootconfig: Fix resource leak in apply_xbc()") Reported-by: Dan Carpenter Acked-by: Masami Hiramatsu Tested-by: Masami Hiramatsu Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit 384b3049445ea343fe5a973a695135f66d458bdb Author: Sasha Levin Date: Sat May 23 22:21:13 2020 -0400 Revert "driver core: platform: Initialize dma_parms for platform devices" [ Upstream commit 1d2a14649ef5b5eb64ea5ce276d7df502bac4dbe ] [ Upstream commit 885a64715fd81e6af6d94a038556e0b2e6deb19c ] This reverts commit 7c8978c0837d40c302f5e90d24c298d9ca9fc097, a new version will come in the next release cycle. Cc: Cc: Russell King Cc: Christoph Hellwig Cc: Ludovic Barre Cc: Linus Walleij Cc: Arnd Bergmann Cc: Ulf Hansson Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 37681282be8e89ae8baf26753bf489837d74e08e Author: Michael S. Tsirkin Date: Tue Apr 7 05:43:30 2020 -0400 virtio-balloon: Revert "virtio-balloon: Switch back to OOM handler for VIRTIO_BALLOON_F_DEFLATE_ON_OOM" [ Upstream commit 835a6a649d0dd1b1f46759eb60fff2f63ed253a7 ] This reverts commit 5a6b4cc5b7a1892a8d7f63d6cbac6e0ae2a9d031. It has been queued properly in the akpm tree, this version is just creating conflicts. Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit e0c5d99beee42fdfbc3e8f29eeebfaa11d5a3b71 Author: Bob Peterson Date: Fri May 8 15:01:25 2020 -0500 Revert "gfs2: Don't demote a glock until its revokes are written" [ Upstream commit b14c94908b1b884276a6608dea3d0b1b510338b7 ] This reverts commit df5db5f9ee112e76b5202fbc331f990a0fc316d6. This patch fixes a regression: patch df5db5f9ee112 allowed function run_queue() to bypass its call to do_xmote() if revokes were queued for the glock. That's wrong because its call to do_xmote() is what is responsible for calling the go_sync() glops functions to sync both the ail list and any revokes queued for it. By bypassing the call, gfs2 could get into a stand-off where the glock could not be demoted until its revokes are written back, but the revokes would not be written back because do_xmote() was never called. It "sort of" works, however, because there are other mechanisms like the log flush daemon (logd) that can sync the ail items and revokes, if it deems it necessary. The problem is: without file system pressure, it might never deem it necessary. Signed-off-by: Bob Peterson Signed-off-by: Sasha Levin commit e906619e6058b39f1f448798e85a855950a3c378 Author: Chris Wilson Date: Wed May 6 17:21:36 2020 +0100 drm/i915: Propagate error from completed fences commit bc850943486887e3859597a266767f95db90aa72 upstream. We need to preserve fatal errors from fences that are being terminated as we hook them up. Fixes: ef4688497512 ("drm/i915: Propagate fence errors") Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Cc: Matthew Auld Reviewed-by: Matthew Auld Link: https://patchwork.freedesktop.org/patch/msgid/20200506162136.3325-1-chris@chris-wilson.co.uk (cherry picked from commit 24fe5f2ab2478053d50a3bc629ada895903a5cbc) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit 7d8aabc2ebe71c6c5b78c90aaa400433e49aa01e Author: Colin Xu Date: Fri May 8 14:05:06 2020 +0800 drm/i915/gvt: Init DPLL/DDI vreg for virtual display instead of inheritance. commit f965b68188ab59a40a421ced1b05a2fea638465c upstream. Init value of some display vregs rea inherited from host pregs. When host display in different status, i.e. all monitors unpluged, different display configurations, etc., GVT virtual display setup don't consistent thus may lead to guest driver consider display goes malfunctional. The added init vreg values are based on PRMs and fixed by calcuation from current configuration (only PIPE_A) and the virtual EDID. Fixes: 04d348ae3f0a ("drm/i915/gvt: vGPU display virtualization") Acked-by: Zhenyu Wang Signed-off-by: Colin Xu Signed-off-by: Zhenyu Wang Link: http://patchwork.freedesktop.org/patch/msgid/20200508060506.216250-1-colin.xu@intel.com Signed-off-by: Greg Kroah-Hartman commit 5af38774a6e92d93f74745e1a5470005eba2c617 Author: Ilya Dryomov Date: Tue May 19 13:26:57 2020 +0200 vsprintf: don't obfuscate NULL and error pointers commit 7bd57fbc4a4ddedc664cad0bbced1b469e24e921 upstream. I don't see what security concern is addressed by obfuscating NULL and IS_ERR() error pointers, printed with %p/%pK. Given the number of sites where %p is used (over 10000) and the fact that NULL pointers aren't uncommon, it probably wouldn't take long for an attacker to find the hash that corresponds to 0. Although harder, the same goes for most common error values, such as -1, -2, -11, -14, etc. The NULL part actually fixes a regression: NULL pointers weren't obfuscated until commit 3e5903eb9cff ("vsprintf: Prevent crash when dereferencing invalid pointers") which went into 5.2. I'm tacking the IS_ERR() part on here because error pointers won't leak kernel addresses and printing them as pointers shouldn't be any different from e.g. %d with PTR_ERR_OR_ZERO(). Obfuscating them just makes debugging based on existing pr_debug and friends excruciating. Note that the "always print 0's for %pK when kptr_restrict == 2" behaviour which goes way back is left as is. Example output with the patch applied: ptr error-ptr NULL %p: 0000000001f8cc5b fffffffffffffff2 0000000000000000 %pK, kptr = 0: 0000000001f8cc5b fffffffffffffff2 0000000000000000 %px: ffff888048c04020 fffffffffffffff2 0000000000000000 %pK, kptr = 1: ffff888048c04020 fffffffffffffff2 0000000000000000 %pK, kptr = 2: 0000000000000000 0000000000000000 0000000000000000 Fixes: 3e5903eb9cff ("vsprintf: Prevent crash when dereferencing invalid pointers") Signed-off-by: Ilya Dryomov Reviewed-by: Petr Mladek Reviewed-by: Sergey Senozhatsky Reviewed-by: Andy Shevchenko Acked-by: Steven Rostedt (VMware) Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 0deceb85de592b89f6476e2bfcb5321a95d23126 Author: Cristian Ciocaltea Date: Sat May 2 20:15:51 2020 +0300 dmaengine: owl: Use correct lock in owl_dma_get_pchan() commit f8f482deb078389b42768b2193e050a81aae137d upstream. When the kernel is built with lockdep support and the owl-dma driver is used, the following message is shown: [ 2.496939] INFO: trying to register non-static key. [ 2.501889] the code is fine but needs lockdep annotation. [ 2.507357] turning off the locking correctness validator. [ 2.512834] CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.6.3+ #15 [ 2.519084] Hardware name: Generic DT based system [ 2.523878] Workqueue: events_freezable mmc_rescan [ 2.528681] [<801127f0>] (unwind_backtrace) from [<8010da58>] (show_stack+0x10/0x14) [ 2.536420] [<8010da58>] (show_stack) from [<8080fbe8>] (dump_stack+0xb4/0xe0) [ 2.543645] [<8080fbe8>] (dump_stack) from [<8017efa4>] (register_lock_class+0x6f0/0x718) [ 2.551816] [<8017efa4>] (register_lock_class) from [<8017b7d0>] (__lock_acquire+0x78/0x25f0) [ 2.560330] [<8017b7d0>] (__lock_acquire) from [<8017e5e4>] (lock_acquire+0xd8/0x1f4) [ 2.568159] [<8017e5e4>] (lock_acquire) from [<80831fb0>] (_raw_spin_lock_irqsave+0x3c/0x50) [ 2.576589] [<80831fb0>] (_raw_spin_lock_irqsave) from [<8051b5fc>] (owl_dma_issue_pending+0xbc/0x120) [ 2.585884] [<8051b5fc>] (owl_dma_issue_pending) from [<80668cbc>] (owl_mmc_request+0x1b0/0x390) [ 2.594655] [<80668cbc>] (owl_mmc_request) from [<80650ce0>] (mmc_start_request+0x94/0xbc) [ 2.602906] [<80650ce0>] (mmc_start_request) from [<80650ec0>] (mmc_wait_for_req+0x64/0xd0) [ 2.611245] [<80650ec0>] (mmc_wait_for_req) from [<8065aa10>] (mmc_app_send_scr+0x10c/0x144) [ 2.619669] [<8065aa10>] (mmc_app_send_scr) from [<80659b3c>] (mmc_sd_setup_card+0x4c/0x318) [ 2.628092] [<80659b3c>] (mmc_sd_setup_card) from [<80659f0c>] (mmc_sd_init_card+0x104/0x430) [ 2.636601] [<80659f0c>] (mmc_sd_init_card) from [<8065a3e0>] (mmc_attach_sd+0xcc/0x16c) [ 2.644678] [<8065a3e0>] (mmc_attach_sd) from [<8065301c>] (mmc_rescan+0x3ac/0x40c) [ 2.652332] [<8065301c>] (mmc_rescan) from [<80143244>] (process_one_work+0x2d8/0x780) [ 2.660239] [<80143244>] (process_one_work) from [<80143730>] (worker_thread+0x44/0x598) [ 2.668323] [<80143730>] (worker_thread) from [<8014b5f8>] (kthread+0x148/0x150) [ 2.675708] [<8014b5f8>] (kthread) from [<801010b4>] (ret_from_fork+0x14/0x20) [ 2.682912] Exception stack(0xee8fdfb0 to 0xee8fdff8) [ 2.687954] dfa0: 00000000 00000000 00000000 00000000 [ 2.696118] dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 2.704277] dfe0: 00000000 00000000 00000000 00000000 00000013 00000000 The obvious fix would be to use 'spin_lock_init()' on 'pchan->lock' before attempting to call 'spin_lock_irqsave()' in 'owl_dma_get_pchan()'. However, according to Manivannan Sadhasivam, 'pchan->lock' was supposed to only protect 'pchan->vchan' while 'od->lock' does a similar job in 'owl_dma_terminate_pchan()'. Therefore, this patch substitutes 'pchan->lock' with 'od->lock' and removes the 'lock' attribute in 'owl_dma_pchan' struct. Fixes: 47e20577c24d ("dmaengine: Add Actions Semi Owl family S900 DMA driver") Signed-off-by: Cristian Ciocaltea Reviewed-by: Manivannan Sadhasivam Acked-by: Andreas Färber Link: https://lore.kernel.org/r/c6e6cdaca252b5364bd294093673951036488cf0.1588439073.git.cristian.ciocaltea@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 6700b0ed63bb2cf3dce2cd4c5a7f0d1ae51bc02b Author: Dave Jiang Date: Fri May 1 08:21:18 2020 -0700 dmaengine: idxd: fix interrupt completion after unmasking commit 4f302642b70c1348773fe7e3ded9fc315fa92990 upstream. The current implementation may miss completions after we unmask the interrupt. In order to make sure we process all competions, we need to: 1. Do an MMIO read from the device as a barrier to ensure that all PCI writes for completions have arrived. 2. Check for any additional completions that we missed. Fixes: 8f47d1a5e545 ("dmaengine: idxd: connect idxd to dmaengine subsystem") Reported-by: Sanjay Kumar Signed-off-by: Dave Jiang Link: https://lore.kernel.org/r/158834641769.35613.1341160109892008587.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 63a43ae3fab4a6a93d6366b8cd252b532b665125 Author: Vladimir Murzin Date: Wed Apr 29 08:15:22 2020 +0100 dmaengine: dmatest: Restore default for channel commit 6b41030fdc79086db5d673c5ed7169f3ee8c13b9 upstream. In case of dmatest is built-in and no channel was configured test doesn't run with: dmatest: Could not start test, no channels configured Even though description to "channel" parameter claims that default is any. Add default channel back as it used to be rather than reject test with no channel configuration. Fixes: d53513d5dc285d9a95a534fc41c5c08af6b60eac ("dmaengine: dmatest: Add support for multi channel testing) Reported-by: Dijil Mohan Signed-off-by: Vladimir Murzin Link: https://lore.kernel.org/r/20200429071522.58148-1-vladimir.murzin@arm.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit d0e2e87e5550b51f3efcd0d224c7e94e65145bde Author: Dan Carpenter Date: Mon May 18 14:29:55 2020 +0300 drm/etnaviv: Fix a leak in submit_pin_objects() commit ad99cb5e783bb03d512092db3387ead9504aad3d upstream. If the mapping address is wrong then we have to release the reference to it before returning -EINVAL. Fixes: 088880ddc0b2 ("drm/etnaviv: implement softpin") Signed-off-by: Dan Carpenter Signed-off-by: Lucas Stach Signed-off-by: Greg Kroah-Hartman commit 10245025c53828e21290838017c9a7af436721ec Author: Christophe JAILLET Date: Sat May 16 23:42:05 2020 +0200 dmaengine: tegra210-adma: Fix an error handling path in 'tegra_adma_probe()' commit 3a5fd0dbd87853f8bd2ea275a5b3b41d6686e761 upstream. Commit b53611fb1ce9 ("dmaengine: tegra210-adma: Fix crash during probe") has moved some code in the probe function and reordered the error handling path accordingly. However, a goto has been missed. Fix it and goto the right label if 'dma_async_device_register()' fails, so that all resources are released. Fixes: b53611fb1ce9 ("dmaengine: tegra210-adma: Fix crash during probe") Signed-off-by: Christophe JAILLET Reviewed-by: Jon Hunter Acked-by: Thierry Reding Link: https://lore.kernel.org/r/20200516214205.276266-1-christophe.jaillet@wanadoo.fr Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 7130077c447110691250193f9461e7c3e77a5840 Author: Xiyu Yang Date: Mon Apr 20 13:35:28 2020 +0800 apparmor: Fix aa_label refcnt leak in policy_update commit c6b39f070722ea9963ffe756bfe94e89218c5e63 upstream. policy_update() invokes begin_current_label_crit_section(), which returns a reference of the updated aa_label object to "label" with increased refcount. When policy_update() returns, "label" becomes invalid, so the refcount should be decreased to keep refcount balanced. The reference counting issue happens in one exception handling path of policy_update(). When aa_may_manage_policy() returns not NULL, the refcnt increased by begin_current_label_crit_section() is not decreased, causing a refcnt leak. Fix this issue by jumping to "end_section" label when aa_may_manage_policy() returns not NULL. Fixes: 5ac8c355ae00 ("apparmor: allow introspecting the loaded policy pre internal transform") Signed-off-by: Xiyu Yang Signed-off-by: Xin Tan Signed-off-by: John Johansen Signed-off-by: Greg Kroah-Hartman commit 8a530dc16a38f5af98f50d6eee02c8f98e5be9b9 Author: Xiyu Yang Date: Sun Apr 5 13:11:55 2020 +0800 apparmor: fix potential label refcnt leak in aa_change_profile commit a0b845ffa0d91855532b50fc040aeb2d8338dca4 upstream. aa_change_profile() invokes aa_get_current_label(), which returns a reference of the current task's label. According to the comment of aa_get_current_label(), the returned reference must be put with aa_put_label(). However, when the original object pointed by "label" becomes unreachable because aa_change_profile() returns or a new object is assigned to "label", reference count increased by aa_get_current_label() is not decreased, causing a refcnt leak. Fix this by calling aa_put_label() before aa_change_profile() return and dropping unnecessary aa_get_current_label(). Fixes: 9fcf78cca198 ("apparmor: update domain transitions that are subsets of confinement at nnp") Signed-off-by: Xiyu Yang Signed-off-by: Xin Tan Signed-off-by: John Johansen Signed-off-by: Greg Kroah-Hartman commit 5362451d6955c7f611a7b41c01c1a9e9ff9b6d54 Author: Navid Emamdoost Date: Mon Oct 21 10:23:47 2019 -0500 apparmor: Fix use-after-free in aa_audit_rule_init commit c54d481d71c6849e044690d3960aaebc730224cc upstream. In the implementation of aa_audit_rule_init(), when aa_label_parse() fails the allocated memory for rule is released using aa_audit_rule_free(). But after this release, the return statement tries to access the label field of the rule which results in use-after-free. Before releasing the rule, copy errNo and return it after release. Fixes: 52e8c38001d8 ("apparmor: Fix memory leak of rule on error exit path") Signed-off-by: Navid Emamdoost Signed-off-by: John Johansen Signed-off-by: Greg Kroah-Hartman commit 908545321473f70b7fe47de9d79d412d3b9631b0 Author: Venkata Narendra Kumar Gutta Date: Fri May 1 12:00:17 2020 +0530 pinctrl: qcom: Add affinity callbacks to msmgpio IRQ chip commit dca4f40742e09ec5d908a7fc2862498e6cf9d911 upstream. Wakeup capable GPIO IRQs routed via PDC are not being migrated when a CPU is hotplugged. Add affinity callbacks to msmgpio IRQ chip to update the affinity of wakeup capable IRQs. Fixes: e35a6ae0eb3a ("pinctrl/msm: Setup GPIO chip in hierarchy") Signed-off-by: Venkata Narendra Kumar Gutta [mkshah: updated commit text and minor code fixes] Signed-off-by: Maulik Shah Tested-by: Douglas Anderson Reviewed-by: Stephen Boyd Link: https://lore.kernel.org/r/1588314617-4556-1-git-send-email-mkshah@codeaurora.org Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 99b6b435cbc2515a723d82a95eeea7637abef954 Author: Christian Gmeiner Date: Tue May 19 07:30:15 2020 +0200 drm/etnaviv: fix perfmon domain interation commit 40b697e256ccdb88aaff424b44b4d300eb8460e8 upstream. The GC860 has one GPU device which has a 2d and 3d core. In this case we want to expose perfmon information for both cores. The driver has one array which contains all possible perfmon domains with some meta data - doms_meta. Here we can see that for the GC860 two elements of that array are relevant: doms_3d: is at index 0 in the doms_meta array with 8 perfmon domains doms_2d: is at index 1 in the doms_meta array with 1 perfmon domain The userspace driver wants to get a list of all perfmon domains and their perfmon signals. This is done by iterating over all domains and their signals. If the userspace driver wants to access the domain with id 8 the kernel driver fails and returns invalid data from doms_3d with and invalid offset. This results in: Unable to handle kernel paging request at virtual address 00000000 On such a device it is not possible to use the userspace driver at all. The fix for this off-by-one error is quite simple. Reported-by: Paul Cercueil Tested-by: Paul Cercueil Fixes: ed1dd899baa3 ("drm/etnaviv: rework perfmon query infrastructure") Cc: stable@vger.kernel.org Signed-off-by: Christian Gmeiner Signed-off-by: Lucas Stach Signed-off-by: Greg Kroah-Hartman commit 21b7cfd9b53aefaabbb7dfe5d32d6265a894b47f Author: Michael Ellerman Date: Wed May 20 23:36:05 2020 +1000 powerpc/64s: Disable STRICT_KERNEL_RWX commit 8659a0e0efdd975c73355dbc033f79ba3b31e82c upstream. Several strange crashes have been eventually traced back to STRICT_KERNEL_RWX and its interaction with code patching. Various paths in our ftrace, kprobes and other patching code need to be hardened against patching failures, otherwise we can end up running with partially/incorrectly patched ftrace paths, kprobes or jump labels, which can then cause strange crashes. Although fixes for those are in development, they're not -rc material. There also seem to be problems with the underlying strict RWX logic, which needs further debugging. So for now disable STRICT_KERNEL_RWX on 64-bit to prevent people from enabling the option and tripping over the bugs. Fixes: 1e0fc9d1eb2b ("powerpc/Kconfig: Enable STRICT_KERNEL_RWX for some configs") Cc: stable@vger.kernel.org # v4.13+ Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200520133605.972649-1-mpe@ellerman.id.au Signed-off-by: Greg Kroah-Hartman commit 20ab89df7c1b899da9be1fbccd59e87bf4a5a6c7 Author: Keno Fischer Date: Fri May 15 18:22:53 2020 -0400 arm64: Fix PTRACE_SYSEMU semantics commit 1cf6022bd9161081215028203919c33fcfa6debb upstream. Quoth the man page: ``` If the tracee was restarted by PTRACE_SYSCALL or PTRACE_SYSEMU, the tracee enters syscall-enter-stop just prior to entering any system call (which will not be executed if the restart was using PTRACE_SYSEMU, regardless of any change made to registers at this point or how the tracee is restarted after this stop). ``` The parenthetical comment is currently true on x86 and powerpc, but not currently true on arm64. arm64 re-checks the _TIF_SYSCALL_EMU flag after the syscall entry ptrace stop. However, at this point, it reflects which method was used to re-start the syscall at the entry stop, rather than the method that was used to reach it. Fix that by recording the original flag before performing the ptrace stop, bringing the behavior in line with documentation and x86/powerpc. Fixes: f086f67485c5 ("arm64: ptrace: add support for syscall emulation") Cc: # 5.3.x- Signed-off-by: Keno Fischer Acked-by: Will Deacon Tested-by: Sudeep Holla Tested-by: Bin Lu [catalin.marinas@arm.com: moved 'flags' bit masking] [catalin.marinas@arm.com: changed 'flags' type to unsigned long] Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit fa53bc4de113d1de7f1cd76781943798fa7b083c Author: Bodo Stroesser Date: Wed May 13 17:34:43 2020 +0200 scsi: target: Put lun_ref at end of tmr processing commit f2e6b75f6ee82308ef7b00f29e71e5f1c6b3d52a upstream. Testing with Loopback I found that, after a Loopback LUN has executed a TMR, I can no longer unlink the LUN. The rm command hangs in transport_clear_lun_ref() at wait_for_completion(&lun->lun_shutdown_comp) The reason is, that transport_lun_remove_cmd() is not called at the end of target_tmr_work(). It seems, that in other fabrics this call happens implicitly when the fabric drivers call transport_generic_free_cmd() during their ->queue_tm_rsp(). Unfortunately Loopback seems to not comply to the common way of calling transport_generic_free_cmd() from ->queue_*(). Instead it calls transport_generic_free_cmd() from its ->check_stop_free() only. But the ->check_stop_free() is called by transport_cmd_check_stop_to_fabric() after it has reset the se_cmd->se_lun pointer. Therefore the following transport_generic_free_cmd() skips the transport_lun_remove_cmd(). So this patch re-adds the transport_lun_remove_cmd() at the end of target_tmr_work(), which was removed during commit 2c9fa49e100f ("scsi: target/core: Make ABORT and LUN RESET handling synchronous"). For fabrics using transport_generic_free_cmd() in the usual way the double call to transport_lun_remove_cmd() doesn't harm, as transport_lun_remove_cmd() checks for this situation and does not release lun_ref twice. Link: https://lore.kernel.org/r/20200513153443.3554-1-bstroesser@ts.fujitsu.com Fixes: 2c9fa49e100f ("scsi: target/core: Make ABORT and LUN RESET handling synchronous") Cc: stable@vger.kernel.org Tested-by: Bryant G. Ly Reviewed-by: Bart van Assche Signed-off-by: Bodo Stroesser Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 9962196bc4b0fa13cc038b6f05d815e197d3d5e6 Author: Ewan D. Milne Date: Mon May 4 13:54:16 2020 -0400 scsi: qla2xxx: Do not log message when reading port speed via sysfs commit fb9024b0646939e59d8a0b6799b317070619795a upstream. Calling ql_log() inside qla2x00_port_speed_show() is causing messages to be output to the console for no particularly good reason. The sysfs read routine should just return the information to userspace. The only reason to log a message is when the port speed actually changes, and this already occurs elsewhere. Link: https://lore.kernel.org/r/20200504175416.15417-1-emilne@redhat.com Fixes: 4910b524ac9e ("scsi: qla2xxx: Add support for setting port speed") Cc: # v5.1+ Reviewed-by: Lee Duncan Reviewed-by: Laurence Oberman Reviewed-by: Himanshu Madhani Signed-off-by: Ewan D. Milne Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 4386feb13f959ecb71dd92a9d1f41e54aef87a39 Author: PeiSen Hou Date: Tue May 19 08:50:12 2020 +0200 ALSA: hda/realtek - Add more fixup entries for Clevo machines commit 259eb82475316672a5d682a94dc8bdd53cf8d8c3 upstream. A few known Clevo machines (PC50, PC70, X170) with ALC1220 codec need the existing quirk for pins for PB51 and co. Signed-off-by: PeiSen Hou Cc: Link: https://lore.kernel.org/r/20200519065012.13119-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 4a3b6a44e5210312d584f3776f7721a4cebd3ad1 Author: Christian Lachner Date: Mon May 18 07:38:44 2020 +0200 ALSA: hda/realtek - Fix silent output on Gigabyte X570 Aorus Xtreme commit d9e8fe0cffbfdd18de96fa68ee2a8b667a0b046e upstream. The Gigabyte X570 Aorus Xtreme motherboard with ALC1220 codec requires a similar workaround for Clevo laptops to enforce the DAC/mixer connection path. Set up a quirk entry for that. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=205275 Signed-off-by: Christian Lachner Cc: Link: https://lore.kernel.org/r/20200518053844.42743-2-gladiac@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 70103ccadf7677e9c8711e2d3fd0cd9c140f7927 Author: Brent Lu Date: Mon May 18 12:30:38 2020 +0800 ALSA: pcm: fix incorrect hw_base increase commit e7513c5786f8b33f0c107b3759e433bc6cbb2efa upstream. There is a corner case that ALSA keeps increasing the hw_ptr but DMA already stop working/updating the position for a long time. In following log we can see the position returned from DMA driver does not move at all but the hw_ptr got increased at some point of time so snd_pcm_avail() will return a large number which seems to be a buffer underrun event from user space program point of view. The program thinks there is space in the buffer and fill more data. [ 418.510086] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 4096 avail 12368 [ 418.510149] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 6910 avail 9554 ... [ 418.681052] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 15102 avail 1362 [ 418.681130] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 16464 avail 0 [ 418.726515] sound pcmC0D5p: pos 96 hw_ptr 16464 appl_ptr 16464 avail 16368 This is because the hw_base will be increased by runtime->buffer_size frames unconditionally if the hw_ptr is not updated for over half of buffer time. As the hw_base increases, so does the hw_ptr increased by the same number. The avail value returned from snd_pcm_avail() could exceed the limit (buffer_size) easily becase the hw_ptr itself got increased by same buffer_size samples when the corner case happens. In following log, the buffer_size is 16368 samples but the avail is 21810 samples so CRAS server complains about it. [ 418.851755] sound pcmC0D5p: pos 96 hw_ptr 16464 appl_ptr 27390 avail 5442 [ 418.926491] sound pcmC0D5p: pos 96 hw_ptr 32832 appl_ptr 27390 avail 21810 cras_server[1907]: pcm_avail returned frames larger than buf_size: sof-glkda7219max: :0,5: 21810 > 16368 By updating runtime->hw_ptr_jiffies each time the HWSYNC is called, the hw_base will keep the same when buffer stall happens at long as the interval between each HWSYNC call is shorter than half of buffer time. Following is a log captured by a patched kernel. The hw_base/hw_ptr value is fixed in this corner case and user space program should be aware of the buffer stall and handle it. [ 293.525543] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 4096 avail 12368 [ 293.525606] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 6880 avail 9584 [ 293.525975] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 10976 avail 5488 [ 293.611178] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 15072 avail 1392 [ 293.696429] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 16464 avail 0 ... [ 381.139517] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 16464 avail 0 Signed-off-by: Brent Lu Reviewed-by: Jaroslav Kysela Cc: Link: https://lore.kernel.org/r/1589776238-23877-1-git-send-email-brent.lu@intel.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit ca205ab4a186f4efed094fa1af92564cb1ab45e1 Author: Scott Bahling Date: Mon May 18 19:57:28 2020 +0200 ALSA: iec1712: Initialize STDSP24 properly when using the model=staudio option commit b0cb099062b0c18246c3a20caaab4c0afc303255 upstream. The ST Audio ADCIII is an STDSP24 card plus extension box. With commit e8a91ae18bdc ("ALSA: ice1712: Add support for STAudio ADCIII") we enabled the ADCIII ports using the model=staudio option but forgot this part to ensure the STDSP24 card is initialized properly. Fixes: e8a91ae18bdc ("ALSA: ice1712: Add support for STAudio ADCIII") Signed-off-by: Scott Bahling Cc: BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1048934 Link: https://lore.kernel.org/r/20200518175728.28766-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 830356a694efb6b33253e4ce9de5954a0693057a Author: Daniel Borkmann Date: Fri May 15 12:11:17 2020 +0200 bpf: Add bpf_probe_read_{user, kernel}_str() to do_refine_retval_range commit 47cc0ed574abcbbde0cf143ddb21a0baed1aa2df upstream. Given bpf_probe_read{,str}() BPF helpers are now only available under CONFIG_ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE, we need to add the drop-in replacements of bpf_probe_read_{kernel,user}_str() to do_refine_retval_range() as well to avoid hitting the same issue as in 849fa50662fbc ("bpf/verifier: refine retval R0 state for bpf_get_stack helper"). Signed-off-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Acked-by: John Fastabend Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20200515101118.6508-3-daniel@iogearbox.net Signed-off-by: Greg Kroah-Hartman commit d21e07bcaf232e0b2068b0acfed9b9c4fbc17951 Author: Daniel Borkmann Date: Fri May 15 12:11:16 2020 +0200 bpf: Restrict bpf_probe_read{, str}() only to archs where they work commit 0ebeea8ca8a4d1d453ad299aef0507dab04f6e8d upstream. Given the legacy bpf_probe_read{,str}() BPF helpers are broken on archs with overlapping address ranges, we should really take the next step to disable them from BPF use there. To generally fix the situation, we've recently added new helper variants bpf_probe_read_{user,kernel}() and bpf_probe_read_{user,kernel}_str(). For details on them, see 6ae08ae3dea2 ("bpf: Add probe_read_{user, kernel} and probe_read_{user,kernel}_str helpers"). Given bpf_probe_read{,str}() have been around for ~5 years by now, there are plenty of users at least on x86 still relying on them today, so we cannot remove them entirely w/o breaking the BPF tracing ecosystem. However, their use should be restricted to archs with non-overlapping address ranges where they are working in their current form. Therefore, move this behind a CONFIG_ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE and have x86, arm64, arm select it (other archs supporting it can follow-up on it as well). For the remaining archs, they can workaround easily by relying on the feature probe from bpftool which spills out defines that can be used out of BPF C code to implement the drop-in replacement for old/new kernels via: bpftool feature probe macro Suggested-by: Linus Torvalds Signed-off-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Reviewed-by: Masami Hiramatsu Acked-by: Linus Torvalds Cc: Brendan Gregg Cc: Christoph Hellwig Link: https://lore.kernel.org/bpf/20200515101118.6508-2-daniel@iogearbox.net Signed-off-by: Greg Kroah-Hartman commit bd348daec8a198c454bb4154c49a84ce5a68a076 Author: Jian-Hong Pan Date: Tue May 12 14:15:28 2020 +0800 ALSA: hda/realtek: Enable headset mic of ASUS UX581LV with ALC295 [ Upstream commit 7900e81797613b92f855f9921392a7430cbdf88c ] The ASUS UX581LV laptop's audio (1043:19e1) with ALC295 can't detect the headset microphone until ALC295_FIXUP_ASUS_MIC_NO_PRESENCE quirk applied. Signed-off-by: Jian-Hong Pan Link: https://lore.kernel.org/r/20200512061525.133985-3-jian-hong@endlessm.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 115a233aa082ef796ef02d514668c2b9a789e736 Author: Jian-Hong Pan Date: Tue May 12 14:15:26 2020 +0800 ALSA: hda/realtek - Enable headset mic of ASUS UX550GE with ALC295 [ Upstream commit ad97d667854c2fbce05a004e107f358ef4b04cf6 ] The ASUS laptop UX550GE with ALC295 can't detect the headset microphone until ALC295_FIXUP_ASUS_MIC_NO_PRESENCE quirk applied. Signed-off-by: Jian-Hong Pan Signed-off-by: Daniel Drake Link: https://lore.kernel.org/r/20200512061525.133985-2-jian-hong@endlessm.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 64da36b31ab7e064eb619486a31a55c9de971e56 Author: Chris Chiu Date: Tue May 12 14:15:24 2020 +0800 ALSA: hda/realtek - Enable headset mic of ASUS GL503VM with ALC295 [ Upstream commit 9e43342b464f1de570a3ad8256ac77645749ef45 ] The ASUS laptop GL503VM with ALC295 can't detect the headset microphone. The headset microphone does not work until pin 0x19 is enabled for it. Signed-off-by: Chris Chiu Signed-off-by: Daniel Drake Signed-off-by: Jian-Hong Pan Link: https://lore.kernel.org/r/20200512061525.133985-1-jian-hong@endlessm.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit bae0b353ac391e52c79a6811ed18ccee988cf241 Author: Mike Pozulp Date: Sat May 9 20:28:37 2020 -0700 ALSA: hda/realtek: Add quirk for Samsung Notebook [ Upstream commit 14425f1f521fdfe274a7bb390637c786432e08b4 ] Some models of the Samsung Notebook 9 have very quiet and distorted headphone output. This quirk changes the VREF value of the ALC298 codec NID 0x1a from default HIZ to new 100. [ adjusted to 5.7-base and rearranged in SSID order -- tiwai ] Signed-off-by: Mike Pozulp BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207423 Link: https://lore.kernel.org/r/20200510032838.1989130-1-pozulp.kernel@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 54bc42f24f971f841cabe380b71dabf08442c971 Author: Kailang Yang Date: Tue Apr 7 14:52:42 2020 +0800 ALSA: hda/realtek - Add HP new mute led supported for ALC236 [ Upstream commit 24164f434dc9c23cd34fca1e36acea9d0581bdde ] HP new platform has new mute led feature. COEF index 0x34 bit 5 to control playback mute led. COEF index 0x35 bit 2 and bit 3 to control Mic mute led. [ corrected typos by tiwai ] Signed-off-by: Kailang Yang Link: https://lore.kernel.org/r/6741211598ba499687362ff2aa30626b@realtek.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 009bb7d0d0fbb4996d777d25845ea8821276c95c Author: Kailang Yang Date: Tue Apr 7 14:40:20 2020 +0800 ALSA: hda/realtek - Add supported new mute Led for HP [ Upstream commit 431e76c3edd76d84a0ed1eb81a286b2ddecc5ee4 ] HP Note Book supported new mute Led. Hardware PIN was not enough to meet old LED rule. JD2 to control playback mute led. GPO3 to control capture mute led. (ALC285 didn't control GPO3 via verb command) This two PIN just could control by COEF registers. [ corrected typos by tiwai ] Signed-off-by: Kailang Yang Link: https://lore.kernel.org/r/6741211598ba499687362ff2aa30626b@realtek.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 2f91b0f00d01b9a2a2ef756fd96904034b1915f0 Author: Aymeric Agon-Rambosson Date: Thu May 7 18:36:03 2020 -0700 scripts/gdb: repair rb_first() and rb_last() [ Upstream commit 50e36be1fb9572b2e4f2753340bdce3116bf2ce7 ] The current implementations of the rb_first() and rb_last() gdb functions have a variable that references itself in its instanciation, which causes the function to throw an error if a specific condition on the argument is met. The original author rather intended to reference the argument and made a typo. Referring the argument instead makes the function work as intended. Signed-off-by: Aymeric Agon-Rambosson Signed-off-by: Andrew Morton Reviewed-by: Stephen Boyd Cc: Jan Kiszka Cc: Kieran Bingham Cc: Douglas Anderson Cc: Nikolay Borisov Cc: Jackie Liu Cc: Jason Wessel Link: http://lkml.kernel.org/r/20200427051029.354840-1-aymeric.agon@yandex.com Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 9645943f26373a4ce473025a32f02ceeb5271c28 Author: Yunfeng Ye Date: Thu May 7 17:23:36 2020 +0800 tools/bootconfig: Fix resource leak in apply_xbc() [ Upstream commit 8842604446d1f005abcbf8c63c12eabdb5695094 ] Fix the @data and @fd allocations that are leaked in the error path of apply_xbc(). Link: http://lkml.kernel.org/r/583a49c9-c27a-931d-e6c2-6f63a4b18bea@huawei.com Acked-by: Masami Hiramatsu Signed-off-by: Yunfeng Ye Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit f5a51dc98b6db9b309ee330f0f2532ab81cd8612 Author: Thomas Gleixner Date: Tue Apr 14 11:07:22 2020 +0200 ARM: futex: Address build warning [ Upstream commit 8101b5a1531f3390b3a69fa7934c70a8fd6566ad ] Stephen reported the following build warning on a ARM multi_v7_defconfig build with GCC 9.2.1: kernel/futex.c: In function 'do_futex': kernel/futex.c:1676:17: warning: 'oldval' may be used uninitialized in this function [-Wmaybe-uninitialized] 1676 | return oldval == cmparg; | ~~~~~~~^~~~~~~~~ kernel/futex.c:1652:6: note: 'oldval' was declared here 1652 | int oldval, ret; | ^~~~~~ introduced by commit a08971e9488d ("futex: arch_futex_atomic_op_inuser() calling conventions change"). While that change should not make any difference it confuses GCC which fails to work out that oldval is not referenced when the return value is not zero. GCC fails to properly analyze arch_futex_atomic_op_inuser(). It's not the early return, the issue is with the assembly macros. GCC fails to detect that those either set 'ret' to 0 and set oldval or set 'ret' to -EFAULT which makes oldval uninteresting. The store to the callsite supplied oldval pointer is conditional on ret == 0. The straight forward way to solve this is to make the store unconditional. Aside of addressing the build warning this makes sense anyway because it removes the conditional from the fastpath. In the error case the stored value is uninteresting and the extra store does not matter at all. Reported-by: Stephen Rothwell Signed-off-by: Thomas Gleixner Link: https://lkml.kernel.org/r/87pncao2ph.fsf@nanos.tec.linutronix.de Signed-off-by: Sasha Levin commit 16e6732f434722ea5049c90d2829862b53566f52 Author: Peter Xu Date: Mon May 4 18:06:07 2020 -0400 KVM: selftests: Fix build for evmcs.h [ Upstream commit 8ffdaf9155ebe517cdec5edbcca19ba6e7ee9c3c ] I got this error when building kvm selftests: /usr/bin/ld: /home/xz/git/linux/tools/testing/selftests/kvm/libkvm.a(vmx.o):/home/xz/git/linux/tools/testing/selftests/kvm/include/evmcs.h:222: multiple definition of `current_evmcs'; /tmp/cco1G48P.o:/home/xz/git/linux/tools/testing/selftests/kvm/include/evmcs.h:222: first defined here /usr/bin/ld: /home/xz/git/linux/tools/testing/selftests/kvm/libkvm.a(vmx.o):/home/xz/git/linux/tools/testing/selftests/kvm/include/evmcs.h:223: multiple definition of `current_vp_assist'; /tmp/cco1G48P.o:/home/xz/git/linux/tools/testing/selftests/kvm/include/evmcs.h:223: first defined here I think it's because evmcs.h is included both in a test file and a lib file so the structs have multiple declarations when linking. After all it's not a good habit to declare structs in the header files. Cc: Vitaly Kuznetsov Signed-off-by: Peter Xu Message-Id: <20200504220607.99627-1-peterx@redhat.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 0412245eacd6f7e58c21dfb62b619393507e81f3 Author: Aurabindo Pillai Date: Wed Apr 22 14:37:33 2020 -0400 drm/amd/display: Prevent dpcd reads with passive dongles [ Upstream commit e6142dd511425cb827b5db869f489eb81f5f994d ] [why] During hotplug, a DP port may be connected to the sink through passive adapter which does not support DPCD reads. Issuing reads without checking for this condition will result in errors [how] Ensure the link is in aux_mode before initiating operation that result in a DPCD read. Signed-off-by: Aurabindo Pillai Reviewed-by: Harry Wentland Acked-by: Aurabindo Pillai Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 2a4b3dc9c50ea95157715dee1fa8d06730cf159c Author: Roman Li Date: Wed Feb 26 17:30:29 2020 -0500 drm/amd/display: fix counter in wait_for_no_pipes_pending [ Upstream commit 80797dd6f1a525d1160c463d6a9f9d29af182cbb ] [Why] Wait counter is not being reset for each pipe. [How] Move counter reset into pipe loop scope. Signed-off-by: Roman Li Reviewed-by: Zhan Liu Acked-by: Aurabindo Pillai Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 6a2154c69a79a473680d96d847ee8392d4a5b7d8 Author: Joerg Roedel Date: Mon May 4 14:54:11 2020 +0200 iommu/amd: Call domain_flush_complete() in update_domain() [ Upstream commit f44a4d7e4f1cdef73c90b1dc749c4d8a7372a8eb ] The update_domain() function is expected to also inform the hardware about domain changes. This needs a COMPLETION_WAIT command to be sent to all IOMMUs which use the domain. Signed-off-by: Joerg Roedel Tested-by: Qian Cai Link: https://lore.kernel.org/r/20200504125413.16798-4-joro@8bytes.org Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit e08514d20b9b120a75224f600b75859eb3c1918a Author: Joerg Roedel Date: Mon May 4 14:54:10 2020 +0200 iommu/amd: Do not loop forever when trying to increase address space [ Upstream commit 5b8a9a047b6cad361405c7900c1e1cdd378c4589 ] When increase_address_space() fails to allocate memory, alloc_pte() will call it again until it succeeds. Do not loop forever while trying to increase the address space and just return an error instead. Signed-off-by: Joerg Roedel Tested-by: Qian Cai Link: https://lore.kernel.org/r/20200504125413.16798-3-joro@8bytes.org Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit ad9aef125451a6a3f4017b7e6c90c3e95d9e436f Author: Hans de Goede Date: Thu Apr 23 00:05:59 2020 +0200 platform/x86: asus-nb-wmi: Do not load on Asus T100TA and T200TA [ Upstream commit 3bd12da7f50b8bc191fcb3bab1f55c582234df59 ] asus-nb-wmi does not add any extra functionality on these Asus Transformer books. They have detachable keyboards, so the hotkeys are send through a HID device (and handled by the hid-asus driver) and also the rfkill functionality is not used on these devices. Besides not adding any extra functionality, initializing the WMI interface on these devices actually has a negative side-effect. For some reason the \_SB.ATKD.INIT() function which asus_wmi_platform_init() calls drives GPO2 (INT33FC:02) pin 8, which is connected to the front facing webcam LED, high and there is no (WMI or other) interface to drive this low again causing the LED to be permanently on, even during suspend. This commit adds a blacklist of DMI system_ids on which not to load the asus-nb-wmi and adds these Transformer books to this list. This fixes the webcam LED being permanently on under Linux. Signed-off-by: Hans de Goede Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin commit dcb9a22e9422d599d2913fad94798b9009456177 Author: Alan Stern Date: Fri May 1 16:07:28 2020 -0400 USB: core: Fix misleading driver bug report [ Upstream commit ac854131d9844f79e2fdcef67a7707227538d78a ] The syzbot fuzzer found a race between URB submission to endpoint 0 and device reset. Namely, during the reset we call usb_ep0_reinit() because the characteristics of ep0 may have changed (if the reset follows a firmware update, for example). While usb_ep0_reinit() is running there is a brief period during which the pointers stored in udev->ep_in[0] and udev->ep_out[0] are set to NULL, and if an URB is submitted to ep0 during that period, usb_urb_ep_type_check() will report it as a driver bug. In the absence of those pointers, the routine thinks that the endpoint doesn't exist. The log message looks like this: ------------[ cut here ]------------ usb 2-1: BOGUS urb xfer, pipe 2 != type 2 WARNING: CPU: 0 PID: 9241 at drivers/usb/core/urb.c:478 usb_submit_urb+0x1188/0x1460 drivers/usb/core/urb.c:478 Now, although submitting an URB while the device is being reset is a questionable thing to do, it shouldn't count as a driver bug as severe as submitting an URB for an endpoint that doesn't exist. Indeed, endpoint 0 always exists, even while the device is in its unconfigured state. To prevent these misleading driver bug reports, this patch updates usb_disable_endpoint() to avoid clearing the ep_in[] and ep_out[] pointers when the endpoint being disabled is ep0. There's no danger of leaving a stale pointer in place, because the usb_host_endpoint structure being pointed to is stored permanently in udev->ep0; it doesn't get deallocated until the entire usb_device structure does. Reported-and-tested-by: syzbot+db339689b2101f6f6071@syzkaller.appspotmail.com Signed-off-by: Alan Stern Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.2005011558590.903-100000@netrider.rowland.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 2e8b9f5d5032e0adf9548f968220dd56c63ef238 Author: Maxim Petrov Date: Mon May 4 09:26:43 2020 +0300 stmmac: fix pointer check after utilization in stmmac_interrupt [ Upstream commit f42234ffd531ca6b13d9da02faa60b72eccf8334 ] The paranoidal pointer check in IRQ handler looks very strange - it really protects us only against bogus drivers which request IRQ line with null pointer dev_id. However, the code fragment is incorrect because the dev pointer is used before the actual check which leads to undefined behavior. Remove the check to avoid confusing people with incorrect code. Signed-off-by: Maxim Petrov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4ad5f9a7105b0ea510c8f4e0c8cfa878c82e220d Author: Wu Bo Date: Thu Apr 30 14:12:49 2020 +0800 ceph: fix double unlock in handle_cap_export() [ Upstream commit 4d8e28ff3106b093d98bfd2eceb9b430c70a8758 ] If the ceph_mdsc_open_export_target_session() return fails, it will do a "goto retry", but the session mutex has already been unlocked. Re-lock the mutex in that case to ensure that we don't unlock it twice. Signed-off-by: Wu Bo Reviewed-by: "Yan, Zheng" Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 11bed96629aedc6f13cfe621b6fcaa809166c69d Author: Hans de Goede Date: Sat May 2 20:18:42 2020 +0200 HID: quirks: Add HID_QUIRK_NO_INIT_REPORTS quirk for Dell K12A keyboard-dock [ Upstream commit 1e189f267015a098bdcb82cc652d13fbf2203fa0 ] Add a HID_QUIRK_NO_INIT_REPORTS quirk for the Dell K12A keyboard-dock, which can be used with various Dell Venue 11 models. Without this quirk the keyboard/touchpad combo works fine when connected at boot, but when hotplugged 9 out of 10 times it will not work properly. Adding the quirk fixes this. Cc: Mario Limonciello Signed-off-by: Hans de Goede Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 047823ae9a2ad65a6def2d823f5436eaed542282 Author: Yoshiyuki Kurauchi Date: Thu Apr 30 14:01:36 2020 +0900 gtp: set NLM_F_MULTI flag in gtp_genl_dump_pdp() [ Upstream commit 846c68f7f1ac82c797a2f1db3344a2966c0fe2e1 ] In drivers/net/gtp.c, gtp_genl_dump_pdp() should set NLM_F_MULTI flag since it returns multipart message. This patch adds a new arg "flags" in gtp_genl_fill_info() so that flags can be set by the callers. Signed-off-by: Yoshiyuki Kurauchi Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 49279549344e455557327b4b238d12e817e9c789 Author: Thomas Gleixner Date: Mon Apr 27 16:55:57 2020 +0200 x86/apic: Move TSC deadline timer debug printk [ Upstream commit c84cb3735fd53c91101ccdb191f2e3331a9262cb ] Leon reported that the printk_once() in __setup_APIC_LVTT() triggers a lockdep splat due to a lock order violation between hrtimer_base::lock and console_sem, when the 'once' condition is reset via /sys/kernel/debug/clear_warn_once after boot. The initial printk cannot trigger this because that happens during boot when the local APIC timer is set up on the boot CPU. Prevent it by moving the printk to a place which is guaranteed to be only called once during boot. Mark the deadline timer check related functions and data __init while at it. Reported-by: Leon Romanovsky Signed-off-by: Thomas Gleixner Link: https://lkml.kernel.org/r/87y2qhoshi.fsf@nanos.tec.linutronix.de Signed-off-by: Sasha Levin commit b0975a7501f6450a5f50b0bb808e3d471d80d1e6 Author: Shuah Khan Date: Mon Apr 27 18:11:07 2020 -0600 selftests: fix kvm relocatable native/cross builds and installs [ Upstream commit 66d69e081b526b6a6031f0d3ca8ddff71e5707a5 ] kvm test Makefile doesn't fully support cross-builds and installs. UNAME_M = $(shell uname -m) variable is used to define the target programs and libraries to be built from arch specific sources in sub-directories. For cross-builds to work, UNAME_M has to map to ARCH and arch specific directories and targets in this Makefile. UNAME_M variable to used to run the compiles pointing to the right arch directories and build the right targets for these supported architectures. TEST_GEN_PROGS and LIBKVM are set using UNAME_M variable. LINUX_TOOL_ARCH_INCLUDE is set using ARCH variable. x86_64 targets are named to include x86_64 as a suffix and directories for includes are in x86_64 sub-directory. s390x and aarch64 follow the same convention. "uname -m" doesn't result in the correct mapping for s390x and aarch64. Fix it to set UNAME_M correctly for s390x and aarch64 cross-builds. In addition, Makefile doesn't create arch sub-directories in the case of relocatable builds and test programs under s390x and x86_64 directories fail to build. This is a problem for native and cross-builds. Fix it to create all necessary directories keying off of TEST_GEN_PROGS. The following use-cases work with this change: Native x86_64: make O=/tmp/kselftest -C tools/testing/selftests TARGETS=kvm install \ INSTALL_PATH=$HOME/x86_64 arm64 cross-build: make O=$HOME/arm64_build/ ARCH=arm64 HOSTCC=gcc \ CROSS_COMPILE=aarch64-linux-gnu- defconfig make O=$HOME/arm64_build/ ARCH=arm64 HOSTCC=gcc \ CROSS_COMPILE=aarch64-linux-gnu- all make kselftest-install TARGETS=kvm O=$HOME/arm64_build ARCH=arm64 \ HOSTCC=gcc CROSS_COMPILE=aarch64-linux-gnu- s390x cross-build: make O=$HOME/s390x_build/ ARCH=s390 HOSTCC=gcc \ CROSS_COMPILE=s390x-linux-gnu- defconfig make O=$HOME/s390x_build/ ARCH=s390 HOSTCC=gcc \ CROSS_COMPILE=s390x-linux-gnu- all make kselftest-install TARGETS=kvm O=$HOME/s390x_build/ ARCH=s390 \ HOSTCC=gcc CROSS_COMPILE=s390x-linux-gnu- all No regressions in the following use-cases: make -C tools/testing/selftests TARGETS=kvm make kselftest-all TARGETS=kvm Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 28bc0698bdf94fba906b9cf1d652b88a34e2a017 Author: Alan Maguire Date: Wed Feb 19 09:33:30 2020 +0000 ftrace/selftest: make unresolved cases cause failure if --fail-unresolved set [ Upstream commit b730d668138cb3dd9ce78f8003986d1adae5523a ] Currently, ftracetest will return 1 (failure) if any unresolved cases are encountered. The unresolved status results from modules and programs not being available, and as such does not indicate any issues with ftrace itself. As such, change the behaviour of ftracetest in line with unsupported cases; if unsupported cases happen, ftracetest still returns 0 unless --fail-unsupported. Here --fail-unresolved is added and the default is to return 0 if unresolved results occur. Signed-off-by: Alan Maguire Acked-by: Masami Hiramatsu Acked-by: Steven Rostedt (VMware) Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 8b83f5d4214a252972d2ef7d5b30a90674bf033f Author: Juliet Kim Date: Thu Apr 30 13:22:11 2020 -0500 ibmvnic: Skip fatal error reset after passive init [ Upstream commit f9c6cea0b38518741c8dcf26ac056d26ee2fd61d ] During MTU change, the following events may happen. Client-driven CRQ initialization fails due to partner’s CRQ closed, causing client to enqueue a reset task for FATAL_ERROR. Then passive (server-driven) CRQ initialization succeeds, causing client to release CRQ and enqueue a reset task for failover. If the passive CRQ initialization occurs before the FATAL reset task is processed, the FATAL error reset task would try to access a CRQ message queue that was freed, causing an oops. The problem may be most likely to occur during DLPAR add vNIC with a non-default MTU, because the DLPAR process will automatically issue a change MTU request. Fix this by not processing fatal error reset if CRQ is passively initialized after client-driven CRQ initialization fails. Signed-off-by: Juliet Kim Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 45b4201d63e1f2beaa4e6048e978148edacb069d Author: Daniel Playfair Cal Date: Sat Apr 25 20:58:17 2020 +1000 HID: i2c-hid: reset Synaptics SYNA2393 on resume [ Upstream commit 538f67407e2c0e5ed2a46e7d7ffa52f2e30c7ef8 ] On the Dell XPS 9570, the Synaptics SYNA2393 touchpad generates spurious interrupts after resuming from suspend until it receives some input or is reset. Add it to the quirk I2C_HID_QUIRK_RESET_ON_RESUME so that it is reset when resuming from suspend. More information about the bug can be found in this mailing list discussion: https://www.spinics.net/lists/linux-input/msg59530.html Signed-off-by: Daniel Playfair Cal Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 10611cd13bde8d6474af6656d8d824e76ee7b9fa Author: Tyrel Datwyler Date: Mon Apr 27 15:49:53 2020 -0700 scsi: ibmvscsi: Fix WARN_ON during event pool release [ Upstream commit b36522150e5b85045f868768d46fbaaa034174b2 ] While removing an ibmvscsi client adapter a WARN_ON like the following is seen in the kernel log: drmgr: drmgr: -r -c slot -s U9080.M9S.783AEC8-V11-C11 -w 5 -d 1 WARNING: CPU: 9 PID: 24062 at ../kernel/dma/mapping.c:311 dma_free_attrs+0x78/0x110 Supported: No, Unreleased kernel CPU: 9 PID: 24062 Comm: drmgr Kdump: loaded Tainted: G X 5.3.18-12-default NIP: c0000000001fa758 LR: c0000000001fa744 CTR: c0000000001fa6e0 REGS: c0000002173375d0 TRAP: 0700 Tainted: G X (5.3.18-12-default) MSR: 8000000000029033 CR: 28088282 XER: 20000000 CFAR: c0000000001fbf0c IRQMASK: 1 GPR00: c0000000001fa744 c000000217337860 c00000000161ab00 0000000000000000 GPR04: 0000000000000000 c000011e12250000 0000000018010000 0000000000000000 GPR08: 0000000000000000 0000000000000001 0000000000000001 c0080000190f4fa8 GPR12: c0000000001fa6e0 c000000007fc2a00 0000000000000000 0000000000000000 GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR24: 000000011420e310 0000000000000000 0000000000000000 0000000018010000 GPR28: c00000000159de50 c000011e12250000 0000000000006600 c000011e5c994848 NIP [c0000000001fa758] dma_free_attrs+0x78/0x110 LR [c0000000001fa744] dma_free_attrs+0x64/0x110 Call Trace: [c000000217337860] [000000011420e310] 0x11420e310 (unreliable) [c0000002173378b0] [c0080000190f0280] release_event_pool+0xd8/0x120 [ibmvscsi] [c000000217337930] [c0080000190f3f74] ibmvscsi_remove+0x6c/0x160 [ibmvscsi] [c000000217337960] [c0000000000f3cac] vio_bus_remove+0x5c/0x100 [c0000002173379a0] [c00000000087a0a4] device_release_driver_internal+0x154/0x280 [c0000002173379e0] [c0000000008777cc] bus_remove_device+0x11c/0x220 [c000000217337a60] [c000000000870fc4] device_del+0x1c4/0x470 [c000000217337b10] [c0000000008712a0] device_unregister+0x30/0xa0 [c000000217337b80] [c0000000000f39ec] vio_unregister_device+0x2c/0x60 [c000000217337bb0] [c00800001a1d0964] dlpar_remove_slot+0x14c/0x250 [rpadlpar_io] [c000000217337c50] [c00800001a1d0bcc] remove_slot_store+0xa4/0x110 [rpadlpar_io] [c000000217337cd0] [c000000000c091a0] kobj_attr_store+0x30/0x50 [c000000217337cf0] [c00000000057c934] sysfs_kf_write+0x64/0x90 [c000000217337d10] [c00000000057be10] kernfs_fop_write+0x1b0/0x290 [c000000217337d60] [c000000000488c4c] __vfs_write+0x3c/0x70 [c000000217337d80] [c00000000048c648] vfs_write+0xd8/0x260 [c000000217337dd0] [c00000000048ca8c] ksys_write+0xdc/0x130 [c000000217337e20] [c00000000000b488] system_call+0x5c/0x70 Instruction dump: 7c840074 f8010010 f821ffb1 20840040 eb830218 7c8407b4 48002019 60000000 2fa30000 409e003c 892d0988 792907e0 <0b090000> 2fbd0000 419e0028 2fbc0000 ---[ end trace 5955b3c0cc079942 ]--- rpadlpar_io: slot U9080.M9S.783AEC8-V11-C11 removed This is tripped as a result of irqs being disabled during the call to dma_free_coherent() by release_event_pool(). At this point in the code path we have quiesced the adapter and it is overly paranoid to be holding the host lock. [mkp: fixed build warning reported by sfr] Link: https://lore.kernel.org/r/1588027793-17952-1-git-send-email-tyreld@linux.ibm.com Signed-off-by: Tyrel Datwyler Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 2a57ac99c988d3143fe50f76e58030fdae924d19 Author: Gavin Shan Date: Tue Apr 28 14:49:45 2020 +1000 net/ena: Fix build warning in ena_xdp_set() [ Upstream commit caec66198d137c26f0d234abc498866a58c64150 ] This fixes the following build warning in ena_xdp_set(), which is observed on aarch64 with 64KB page size. In file included from ./include/net/inet_sock.h:19, from ./include/net/ip.h:27, from drivers/net/ethernet/amazon/ena/ena_netdev.c:46: drivers/net/ethernet/amazon/ena/ena_netdev.c: In function \ ‘ena_xdp_set’: \ drivers/net/ethernet/amazon/ena/ena_netdev.c:557:6: warning: \ format ‘%lu’ \ expects argument of type ‘long unsigned int’, but argument 4 \ has type ‘int’ \ [-Wformat=] "Failed to set xdp program, the current MTU (%d) is \ larger than the maximum allowed MTU (%lu) while xdp is on", Signed-off-by: Gavin Shan Acked-by: Shay Agroskin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 730575194269a0a9b96e968a59b3232ce6be6a81 Author: James Hilliard Date: Sat Apr 11 13:02:41 2020 -0600 component: Silence bind error on -EPROBE_DEFER [ Upstream commit 7706b0a76a9697021e2bf395f3f065c18f51043d ] If a component fails to bind due to -EPROBE_DEFER we should not log an error as this is not a real failure. Fixes messages like: vc4-drm soc:gpu: failed to bind 3f902000.hdmi (ops vc4_hdmi_ops): -517 vc4-drm soc:gpu: master bind failed: -517 Signed-off-by: James Hilliard Link: https://lore.kernel.org/r/20200411190241.89404-1-james.hilliard1@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e6e392a8095dc4700e2bb859e76d25b8028c7f2e Author: Richard Clark Date: Sat Apr 25 08:58:11 2020 +0800 aquantia: Fix the media type of AQC100 ethernet controller in the driver [ Upstream commit 6de556c31061e3b9c36546ffaaac5fdb679a2f14 ] The Aquantia AQC100 controller enables a SFP+ port, so the driver should configure the media type as '_TYPE_FIBRE' instead of '_TYPE_TP'. Signed-off-by: Richard Clark Cc: Igor Russkikh Cc: "David S. Miller" Acked-by: Igor Russkikh Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6046f96f2069489223111264ce95446e737f1ab0 Author: Stefano Garzarella Date: Fri Apr 24 17:08:29 2020 +0200 vhost/vsock: fix packet delivery order to monitoring devices [ Upstream commit 107bc0766b9feb5113074c753735a3f115c2141f ] We want to deliver packets to monitoring devices before it is put in the virtqueue, to avoid that replies can appear in the packet capture before the transmitted packet. Signed-off-by: Stefano Garzarella Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit aeea6b166a9c53a872cfb4e7f73da87324b07474 Author: Xiyu Yang Date: Sat Apr 25 20:52:26 2020 +0800 configfs: fix config_item refcnt leak in configfs_rmdir() [ Upstream commit 8aebfffacfa379ba400da573a5bf9e49634e38cb ] configfs_rmdir() invokes configfs_get_config_item(), which returns a reference of the specified config_item object to "parent_item" with increased refcnt. When configfs_rmdir() returns, local variable "parent_item" becomes invalid, so the refcount should be decreased to keep refcount balanced. The reference counting issue happens in one exception handling path of configfs_rmdir(). When down_write_killable() fails, the function forgets to decrease the refcnt increased by configfs_get_config_item(), causing a refcnt leak. Fix this issue by calling config_item_put() when down_write_killable() fails. Signed-off-by: Xiyu Yang Signed-off-by: Xin Tan Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit ce5d77dae8a92f09a3c1a44480a4e81b74dfdcea Author: Quinn Tran Date: Tue Mar 31 03:40:15 2020 -0700 scsi: qla2xxx: Delete all sessions before unregister local nvme port [ Upstream commit c48f849d3f7a4ec1025105f446e29d395c4dcc2f ] Delete all sessions before unregistering local nvme port. This allows nvme layer to decrement all active rport count down to zero. Once the count is down to zero, nvme would call qla to continue with the npiv port deletion. PID: 27448 TASK: ffff9e34b777c1c0 CPU: 0 COMMAND: "qaucli" 0 [ffff9e25e84abbd8] __schedule at ffffffff977858ca 1 [ffff9e25e84abc68] schedule at ffffffff97785d79 2 [ffff9e25e84abc78] schedule_timeout at ffffffff97783881 3 [ffff9e25e84abd28] wait_for_completion at ffffffff9778612d 4 [ffff9e25e84abd88] qla_nvme_delete at ffffffffc0e3024e [qla2xxx] 5 [ffff9e25e84abda8] qla24xx_vport_delete at ffffffffc0e024b9 [qla2xxx] 6 [ffff9e25e84abdf0] fc_vport_terminate at ffffffffc011c247 [scsi_transport_fc] 7 [ffff9e25e84abe28] store_fc_host_vport_delete at ffffffffc011cd94 [scsi_transport_fc] 8 [ffff9e25e84abe70] dev_attr_store at ffffffff974b376b 9 [ffff9e25e84abe80] sysfs_kf_write at ffffffff972d9a92 10 [ffff9e25e84abe90] kernfs_fop_write at ffffffff972d907b 11 [ffff9e25e84abec8] vfs_write at ffffffff9724c790 12 [ffff9e25e84abf08] sys_write at ffffffff9724d55f 13 [ffff9e25e84abf50] system_call_fastpath at ffffffff97792ed2 RIP: 00007fc0bd81a6fd RSP: 00007ffff78d9648 RFLAGS: 00010202 RAX: 0000000000000001 RBX: 0000000000000022 RCX: 00007ffff78d96e0 RDX: 0000000000000022 RSI: 00007ffff78d94e0 RDI: 0000000000000008 RBP: 00007ffff78d9440 R8: 0000000000000000 R9: 00007fc0bd48b2cd R10: 0000000000000017 R11: 0000000000000293 R12: 0000000000000000 R13: 00005624e4dac840 R14: 00005624e4da9a10 R15: 0000000000000000 ORIG_RAX: 0000000000000001 CS: 0033 SS: 002b Link: https://lore.kernel.org/r/20200331104015.24868-4-njavali@marvell.com Reviewed-by: Himanshu Madhani Signed-off-by: Quinn Tran Signed-off-by: Nilesh Javali Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 2747b963f8005dac419d7024ee65f1675e606f63 Author: Arun Easi Date: Tue Mar 31 03:40:14 2020 -0700 scsi: qla2xxx: Fix hang when issuing nvme disconnect-all in NPIV [ Upstream commit 45a76264c26fd8cfd0c9746196892d9b7e2657ee ] In NPIV environment, a NPIV host may use a queue pair created by base host or other NPIVs, so the check for a queue pair created by this NPIV is not correct, and can cause an abort to fail, which in turn means the NVME command not returned. This leads to hang in nvme_fc layer in nvme_fc_delete_association() which waits for all I/Os to be returned, which is seen as hang in the application. Link: https://lore.kernel.org/r/20200331104015.24868-3-njavali@marvell.com Reviewed-by: Himanshu Madhani Signed-off-by: Arun Easi Signed-off-by: Nilesh Javali Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 23923448795dd79f5f306ad4d29a7dafa866a179 Author: Jiri Kosina Date: Wed Apr 15 14:51:42 2020 +0200 HID: alps: ALPS_1657 is too specific; use U1_UNICORN_LEGACY instead [ Upstream commit 185af3e775b693f773d9a4b5a8c3cda69fc8ca0f ] HID_DEVICE_ID_ALPS_1657 PID is too specific, as there are many other ALPS hardware IDs using this particular touchpad. Rename the identifier to HID_DEVICE_ID_ALPS_U1_UNICORN_LEGACY in order to describe reality better. Fixes: 640e403b1fd24 ("HID: alps: Add AUI1657 device ID") Reported-by: Xiaojian Cao Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 7f7d9f2818d95cbf1c34b2d70e7daad480de9aba Author: Artem Borisov Date: Mon Apr 6 03:55:15 2020 +0400 HID: alps: Add AUI1657 device ID [ Upstream commit 640e403b1fd24e7f31ac6f29f0b6a21d285ed729 ] This device is used on Lenovo V130-15IKB variants and uses the same registers as U1. Signed-off-by: Artem Borisov Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 318f6ce8c0e3e314cf302e302bdcfa75de19769a Author: Fabian Schindlatz Date: Mon Apr 13 18:46:28 2020 +0200 HID: logitech: Add support for Logitech G11 extra keys [ Upstream commit b1bd0f75288f60e8d142a1b3e979ed0192c04931 ] The Logitech G11 keyboard is a cheap variant of the G15 without the LCD screen. It uses the same layout for its extra and macro keys (G1 - G18, M1-M3, MR) and - from the input subsystem's perspective - behaves just like the G15, so we can treat it as such. Tested it with my own keyboard. Signed-off-by: Fabian Schindlatz Reviewed-by: Hans de Goede Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit aa8431deadd4fe5a9a387d7d3be829b946e624f1 Author: Sebastian Reichel Date: Mon Apr 13 18:02:37 2020 +0200 HID: multitouch: add eGalaxTouch P80H84 support [ Upstream commit f9e82295eec141a0569649d400d249333d74aa91 ] Add support for P80H84 touchscreen from eGalaxy: idVendor 0x0eef D-WAV Scientific Co., Ltd idProduct 0xc002 iManufacturer 1 eGalax Inc. iProduct 2 eGalaxTouch P80H84 2019 vDIVA_1204_T01 k4.02.146 Signed-off-by: Sebastian Reichel Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit ce88c3dc85f74ce70a43f0a79ab1a94295bef9f3 Author: Frédéric Pierret (fepitre) Date: Tue Apr 7 13:32:59 2020 +0200 gcc-common.h: Update for GCC 10 [ Upstream commit c7527373fe28f97d8a196ab562db5589be0d34b9 ] Remove "params.h" include, which has been dropped in GCC 10. Remove is_a_helper() macro, which is now defined in gimple.h, as seen when running './scripts/gcc-plugin.sh g++ g++ gcc': In file included from :1: ./gcc-plugins/gcc-common.h:852:13: error: redefinition of ‘static bool is_a_helper::test(U*) [with U = const gimple; T = const ggoto*]’ 852 | inline bool is_a_helper::test(const_gimple gs) | ^~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from ./gcc-plugins/gcc-common.h:125, from :1: /usr/lib/gcc/x86_64-redhat-linux/10/plugin/include/gimple.h:1037:1: note: ‘static bool is_a_helper::test(U*) [with U = const gimple; T = const ggoto*]’ previously declared here 1037 | is_a_helper ::test (const gimple *gs) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ Add -Wno-format-diag to scripts/gcc-plugins/Makefile to avoid meaningless warnings from error() formats used by plugins: scripts/gcc-plugins/structleak_plugin.c: In function ‘int plugin_init(plugin_name_args*, plugin_gcc_version*)’: scripts/gcc-plugins/structleak_plugin.c:253:12: warning: unquoted sequence of 2 consecutive punctuation characters ‘'-’ in format [-Wformat-diag] 253 | error(G_("unknown option '-fplugin-arg-%s-%s'"), plugin_name, argv[i].key); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Signed-off-by: Frédéric Pierret (fepitre) Link: https://lore.kernel.org/r/20200407113259.270172-1-frederic.pierret@qubes-os.org [kees: include -Wno-format-diag for plugin builds] Signed-off-by: Kees Cook Signed-off-by: Sasha Levin commit 0fc8c0356cacc87a49c3fc4934f5efccf5a63749 Author: Masahiro Yamada Date: Wed Mar 11 15:29:25 2020 +0900 net: drop_monitor: use IS_REACHABLE() to guard net_dm_hw_report() [ Upstream commit 1cd9b3abf5332102d4d967555e7ed861a75094bf ] In net/Kconfig, NET_DEVLINK implies NET_DROP_MONITOR. The original behavior of the 'imply' keyword prevents NET_DROP_MONITOR from being 'm' when NET_DEVLINK=y. With the planned Kconfig change that relaxes the 'imply', the combination of NET_DEVLINK=y and NET_DROP_MONITOR=m would be allowed. Use IS_REACHABLE() to avoid the vmlinux link error for this case. Reported-by: Stephen Rothwell Signed-off-by: Masahiro Yamada Acked-by: Neil Horman Signed-off-by: Sasha Levin commit a38dcbc264655d2f9f430ab64e994e090835b50f Author: Masahiro Yamada Date: Wed Mar 4 12:20:36 2020 +0900 kbuild: avoid concurrency issue in parallel building dtbs and dtbs_check [ Upstream commit b5154bf63e5577faaaca1d942df274f7de91dd2a ] 'make dtbs_check' checks the shecma in addition to building *.dtb files, in other words, 'make dtbs_check' is a super-set of 'make dtbs'. So, you do not have to do 'make dtbs dtbs_check', but I want to keep the build system as robust as possible in any use. Currently, 'dtbs' and 'dtbs_check' are independent of each other. In parallel building, two threads descend into arch/*/boot/dts/, one for dtbs and the other for dtbs_check, then end up with building the same DTB simultaneously. This commit fixes the concurrency issue. Otherwise, I see build errors like follows: $ make ARCH=arm64 defconfig $ make -j16 ARCH=arm64 DT_SCHEMA_FILES=Documentation/devicetree/bindings/arm/psci.yaml dtbs dtbs_check DTC arch/arm64/boot/dts/qcom/sdm845-cheza-r2.dtb DTC arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtb DTC arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-lite2.dtb DTC arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-lite2.dtb DTC arch/arm64/boot/dts/freescale/imx8mn-evk.dtb DTC arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-one-plus.dtb DTC arch/arm64/boot/dts/zte/zx296718-pcbox.dtb DTC arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dt.yaml DTC arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dtb DTC arch/arm64/boot/dts/xilinx/zynqmp-zc1254-revA.dtb DTC arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dtb DTC arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet-inx.dtb DTC arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-one-plus.dtb CHECK arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dt.yaml fixdep: error opening file: arch/arm64/boot/dts/allwinner/.sun50i-h6-orangepi-lite2.dtb.d: No such file or directory make[2]: *** [scripts/Makefile.lib:296: arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-lite2.dtb] Error 2 make[2]: *** Deleting file 'arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-lite2.dtb' make[2]: *** Waiting for unfinished jobs.... DTC arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet-kd.dtb DTC arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p231.dtb DTC arch/arm64/boot/dts/xilinx/zynqmp-zc1275-revA.dtb DTC arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dtb fixdep: parse error; no targets found make[2]: *** [scripts/Makefile.lib:296: arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-one-plus.dtb] Error 1 make[2]: *** Deleting file 'arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-one-plus.dtb' make[1]: *** [scripts/Makefile.build:505: arch/arm64/boot/dts/allwinner] Error 2 make[1]: *** Waiting for unfinished jobs.... DTC arch/arm64/boot/dts/renesas/r8a77951-salvator-xs.dtb Signed-off-by: Masahiro Yamada Reviewed-by: Rob Herring Signed-off-by: Sasha Levin commit 764aa7a813b36734591eec4eb4db56cd4971b5d1 Author: Joerg Roedel Date: Tue May 19 15:03:40 2020 +0200 iommu: Fix deferred domain attachment [ Upstream commit bd421264ed307dd296eab036851221b225071a32 ] The IOMMU core code has support for deferring the attachment of a domain to a device. This is needed in kdump kernels where the new domain must not be attached to a device before the device driver takes it over. When the AMD IOMMU driver got converted to use the dma-iommu implementation, the deferred attaching got lost. The code in dma-iommu.c has support for deferred attaching, but it calls into iommu_attach_device() to actually do it. But iommu_attach_device() will check if the device should be deferred in it code-path and do nothing, breaking deferred attachment. Move the is_deferred_attach() check out of the attach_device path and into iommu_group_add_device() to make deferred attaching work from the dma-iommu code. Fixes: 795bbbb9b6f8 ("iommu/dma-iommu: Handle deferred devices") Reported-by: Jerry Snitselaar Suggested-by: Robin Murphy Signed-off-by: Joerg Roedel Tested-by: Jerry Snitselaar Cc: Jerry Snitselaar Cc: Tom Murphy Cc: Robin Murphy Link: https://lore.kernel.org/r/20200519130340.14564-1-joro@8bytes.org Signed-off-by: Sasha Levin commit c5e10ba6f01a2511751cc354f041e46061d2ba3a Author: Ricardo Ribalda Delgado Date: Thu Apr 30 15:17:21 2020 +0200 mtd: Fix mtd not registered due to nvmem name collision [ Upstream commit 7b01b7239d0dc9832e0d0d23605c1ff047422a2c ] When the nvmem framework is enabled, a nvmem device is created per mtd device/partition. It is not uncommon that a device can have multiple mtd devices with partitions that have the same name. Eg, when there DT overlay is allowed and the same device with mtd is attached twice. Under that circumstances, the mtd fails to register due to a name duplication on the nvmem framework. With this patch we use the mtdX name instead of the partition name, which is unique. [ 8.948991] sysfs: cannot create duplicate filename '/bus/nvmem/devices/Production Data' [ 8.948992] CPU: 7 PID: 246 Comm: systemd-udevd Not tainted 5.5.0-qtec-standard #13 [ 8.948993] Hardware name: AMD Dibbler/Dibbler, BIOS 05.22.04.0019 10/26/2019 [ 8.948994] Call Trace: [ 8.948996] dump_stack+0x50/0x70 [ 8.948998] sysfs_warn_dup.cold+0x17/0x2d [ 8.949000] sysfs_do_create_link_sd.isra.0+0xc2/0xd0 [ 8.949002] bus_add_device+0x74/0x140 [ 8.949004] device_add+0x34b/0x850 [ 8.949006] nvmem_register.part.0+0x1bf/0x640 ... [ 8.948926] mtd mtd8: Failed to register NVMEM device Fixes: c4dfa25ab307 ("mtd: add support for reading MTD devices via the nvmem API") Signed-off-by: Ricardo Ribalda Delgado Acked-by: Miquel Raynal Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit 1d369372c2b0850c5c2bbf34f5c9e93468afeda2 Author: David Howells Date: Sun May 17 21:21:05 2020 +0100 afs: Don't unlock fetched data pages until the op completes successfully [ Upstream commit 9d1be4f4dc5ff1c66c86acfd2c35765d9e3776b3 ] Don't call req->page_done() on each page as we finish filling it with the data coming from the network. Whilst this might speed up the application a bit, it's a problem if there's a network failure and the operation has to be reissued. If this happens, an oops occurs because afs_readpages_page_done() clears the pointer to each page it unlocks and when a retry happens, the pointers to the pages it wants to fill are now NULL (and the pages have been unlocked anyway). Instead, wait till the operation completes successfully and only then release all the pages after clearing any terminal gap (the server can give us less data than we requested as we're allowed to ask for more than is available). KASAN produces a bug like the following, and even without KASAN, it can oops and panic. BUG: KASAN: wild-memory-access in _copy_to_iter+0x323/0x5f4 Write of size 1404 at addr 0005088000000000 by task md5sum/5235 CPU: 0 PID: 5235 Comm: md5sum Not tainted 5.7.0-rc3-fscache+ #250 Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014 Call Trace: memcpy+0x39/0x58 _copy_to_iter+0x323/0x5f4 __skb_datagram_iter+0x89/0x2a6 skb_copy_datagram_iter+0x129/0x135 rxrpc_recvmsg_data.isra.0+0x615/0xd42 rxrpc_kernel_recv_data+0x1e9/0x3ae afs_extract_data+0x139/0x33a yfs_deliver_fs_fetch_data64+0x47a/0x91b afs_deliver_to_call+0x304/0x709 afs_wait_for_call_to_complete+0x1cc/0x4ad yfs_fs_fetch_data+0x279/0x288 afs_fetch_data+0x1e1/0x38d afs_readpages+0x593/0x72e read_pages+0xf5/0x21e __do_page_cache_readahead+0x128/0x23f ondemand_readahead+0x36e/0x37f generic_file_buffered_read+0x234/0x680 new_sync_read+0x109/0x17e vfs_read+0xe6/0x138 ksys_read+0xd8/0x14d do_syscall_64+0x6e/0x8a entry_SYSCALL_64_after_hwframe+0x49/0xb3 Fixes: 196ee9cd2d04 ("afs: Make afs_fs_fetch_data() take a list of pages") Fixes: 30062bd13e36 ("afs: Implement YFS support in the fs client") Signed-off-by: David Howells Reviewed-by: Matthew Wilcox (Oracle) Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 5fab52fefb9d57c3f27eb5dd1281e01fe4ec5e59 Author: Richard Weinberger Date: Sat May 2 14:48:02 2020 +0200 ubi: Fix seq_file usage in detailed_erase_block_info debugfs file [ Upstream commit 0e7572cffe442290c347e779bf8bd4306bb0aa7c ] 3bfa7e141b0b ("fs/seq_file.c: seq_read(): add info message about buggy .next functions") showed that we don't use seq_file correctly. So make sure that our ->next function always updates the position. Fixes: 7bccd12d27b7 ("ubi: Add debugfs file for tracking PEB state") Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit 143e6a6be44a39495e86bfee79cffffcf4944f1d Author: Christophe JAILLET Date: Wed May 6 21:21:00 2020 +0200 i2c: mux: demux-pinctrl: Fix an error handling path in 'i2c_demux_pinctrl_probe()' [ Upstream commit e9d1a0a41d4486955e96552293c1fcf1fce61602 ] A call to 'i2c_demux_deactivate_master()' is missing in the error handling path, as already done in the remove function. Fixes: 50a5ba876908 ("i2c: mux: demux-pinctrl: add driver") Signed-off-by: Christophe JAILLET Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 5cc27996f6ac1e17e4b3e7bf38b12eaa50df4df7 Author: Dan Carpenter Date: Tue May 12 16:19:17 2020 +0300 evm: Fix a small race in init_desc() [ Upstream commit 8433856947217ebb5697a8ff9c4c9cad4639a2cf ] The IS_ERR_OR_NULL() function has two conditions and if we got really unlucky we could hit a race where "ptr" started as an error pointer and then was set to NULL. Both conditions would be false even though the pointer at the end was NULL. This patch fixes the problem by ensuring that "*tfm" can only be NULL or valid. I have introduced a "tmp_tfm" variable to make that work. I also reversed a condition and pulled the code in one tab. Reported-by: Roberto Sassu Fixes: 53de3b080d5e ("evm: Check also if *tfm is an error pointer in init_desc()") Signed-off-by: Dan Carpenter Acked-by: Roberto Sassu Acked-by: Krzysztof Struczynski Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin commit ffd450007206a39e002541c1f38c8f2bbe52f1f0 Author: Raul E Rangel Date: Mon May 11 10:33:36 2020 -0600 iommu/amd: Fix get_acpihid_device_id() [ Upstream commit ea90228c7b2ae6646bb6381385229aabb6f14cd2 ] acpi_dev_hid_uid_match() expects a null pointer for UID if it doesn't exist. The acpihid_map_entry contains a char buffer for holding the UID. If no UID was provided in the IVRS table, this buffer will be zeroed. If we pass in a null string, acpi_dev_hid_uid_match() will return false because it will try and match an empty string to the ACPI UID of the device. Fixes: ae5e6c6439c3 ("iommu/amd: Switch to use acpi_dev_hid_uid_match()") Suggested-by: Andy Shevchenko Signed-off-by: Raul E Rangel Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20200511103229.v2.1.I6f1b6f973ee6c8af1348611370c73a0ec0ea53f1@changeid Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 5f18a3eb6dc1563eb6bf626b8a5812b33a607468 Author: Alexander Monakov Date: Mon May 11 10:23:52 2020 +0000 iommu/amd: Fix over-read of ACPI UID from IVRS table [ Upstream commit e461b8c991b9202b007ea2059d953e264240b0c9 ] IVRS parsing code always tries to read 255 bytes from memory when retrieving ACPI device path, and makes an assumption that firmware provides a zero-terminated string. Both of those are bugs: the entry is likely to be shorter than 255 bytes, and zero-termination is not guaranteed. With Acer SF314-42 firmware these issues manifest visibly in dmesg: AMD-Vi: ivrs, add hid:AMDI0020, uid:\_SB.FUR0\xf0\xa5, rdevid:160 AMD-Vi: ivrs, add hid:AMDI0020, uid:\_SB.FUR1\xf0\xa5, rdevid:160 AMD-Vi: ivrs, add hid:AMDI0020, uid:\_SB.FUR2\xf0\xa5, rdevid:160 AMD-Vi: ivrs, add hid:AMDI0020, uid:\_SB.FUR3>\x83e\x8d\x9a\xd1... The first three lines show how the code over-reads adjacent table entries into the UID, and in the last line it even reads garbage data beyond the end of the IVRS table itself. Since each entry has the length of the UID (uidl member of ivhd_entry struct), use that for memcpy, and manually add a zero terminator. Avoid zero-filling hid and uid arrays up front, and instead ensure the uid array is always zero-terminated. No change needed for the hid array, as it was already properly zero-terminated. Fixes: 2a0cb4e2d423c ("iommu/amd: Add new map for storing IVHD dev entry type HID") Signed-off-by: Alexander Monakov Cc: Joerg Roedel Cc: iommu@lists.linux-foundation.org Link: https://lore.kernel.org/r/20200511102352.1831-1-amonakov@ispras.ru Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit a6dd004de1e9cb0e4d1a920c4f11eeccaef2ce50 Author: Alain Volmat Date: Thu Apr 30 17:43:21 2020 +0200 i2c: fix missing pm_runtime_put_sync in i2c_device_probe [ Upstream commit 3c3dd56f760da056e821ac177e3ad0de4209a435 ] In case of the I2C client exposes the flag I2C_CLIENT_HOST_NOTIFY, pm_runtime_get_sync is called in order to always keep active the adapter. However later on, pm_runtime_put_sync is never called within the function in case of an error. This commit add this error handling. Fixes: 72bfcee11cf8 ("i2c: Prevent runtime suspend of adapter when Host Notify is required") Signed-off-by: Alain Volmat Reviewed-by: Jarkko Nikula Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 7b6aee7a9f97a2e982c2042ccef636bd6db427cd Author: Christoph Hellwig Date: Thu Apr 9 13:33:05 2020 +0200 ubifs: remove broken lazytime support [ Upstream commit ecf84096a526f2632ee85c32a3d05de3fa60ce80 ] When "ubifs: introduce UBIFS_ATIME_SUPPORT to ubifs" introduced atime support to ubifs, it also added lazytime support. As far as I can tell the lazytime support is terminally broken, as it causes mark_inode_dirty_sync to be called from __writeback_single_inode, which will then trigger the locking assert in ubifs_dirty_inode. Just remove the broken lazytime support for now, it can be added back later, especially as some infrastructure changes should make that easier soon. Fixes: 8c1c5f263833 ("ubifs: introduce UBIFS_ATIME_SUPPORT to ubifs") Signed-off-by: Christoph Hellwig Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit 3f8d62d2a4fed76d33a40e9433f0ffc96fc42034 Author: Tetsuo Handa Date: Wed May 20 08:51:59 2020 +0900 pipe: Fix pipe_full() test in opipe_prep(). [ Upstream commit 566d136289dc57816ac290de87a9a0f7d9bd3cbb ] syzbot is reporting that splice()ing from non-empty read side to already-full write side causes unkillable task, for opipe_prep() is by error not inverting pipe_full() test. CPU: 0 PID: 9460 Comm: syz-executor.5 Not tainted 5.6.0-rc3-next-20200228-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:rol32 include/linux/bitops.h:105 [inline] RIP: 0010:iterate_chain_key kernel/locking/lockdep.c:369 [inline] RIP: 0010:__lock_acquire+0x6a3/0x5270 kernel/locking/lockdep.c:4178 Call Trace: lock_acquire+0x197/0x420 kernel/locking/lockdep.c:4720 __mutex_lock_common kernel/locking/mutex.c:956 [inline] __mutex_lock+0x156/0x13c0 kernel/locking/mutex.c:1103 pipe_lock_nested fs/pipe.c:66 [inline] pipe_double_lock+0x1a0/0x1e0 fs/pipe.c:104 splice_pipe_to_pipe fs/splice.c:1562 [inline] do_splice+0x35f/0x1520 fs/splice.c:1141 __do_sys_splice fs/splice.c:1447 [inline] __se_sys_splice fs/splice.c:1427 [inline] __x64_sys_splice+0x2b5/0x320 fs/splice.c:1427 do_syscall_64+0xf6/0x790 arch/x86/entry/common.c:295 entry_SYSCALL_64_after_hwframe+0x49/0xbe Reported-by: syzbot+b48daca8639150bc5e73@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?id=9386d051e11e09973d5a4cf79af5e8cedf79386d Fixes: 8cefc107ca54c8b0 ("pipe: Use head and tail pointers for the ring, not cursor and length") Cc: stable@vger.kernel.org # 5.5+ Signed-off-by: Tetsuo Handa Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 901438c489f03468cc32142265b905508cf690c8 Author: Al Viro Date: Tue May 19 17:48:52 2020 -0400 fix multiplication overflow in copy_fdtable() [ Upstream commit 4e89b7210403fa4a8acafe7c602b6212b7af6c3b ] cpy and set really should be size_t; we won't get an overflow on that, since sysctl_nr_open can't be set above ~(size_t)0 / sizeof(void *), so nr that would've managed to overflow size_t on that multiplication won't get anywhere near copy_fdtable() - we'll fail with EMFILE before that. Cc: stable@kernel.org # v2.6.25+ Fixes: 9cfe015aa424 (get rid of NR_OPEN and introduce a sysctl_nr_open) Reported-by: Thiago Macieira Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit dae9b5f3f6f0b79293af289103ebfb9dcee689b2 Author: Miquel Raynal Date: Wed May 13 15:10:29 2020 +0200 mtd: spinand: Propagate ECC information to the MTD structure [ Upstream commit 3507273d5a4d3c2e46f9d3f9ed9449805f5dff07 ] This is done by default in the raw NAND core (nand_base.c) but was missing in the SPI-NAND core. Without these two lines the ecc_strength and ecc_step_size values are not exported to the user through sysfs. Fixes: 7529df465248 ("mtd: nand: Add core infrastructure to support SPI NANDs") Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal Reviewed-by: Boris Brezillon Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit 11130655a78d5560ae20b15b428d42945c8fe3f4 Author: Rafael J. Wysocki Date: Fri May 15 12:58:19 2020 +0200 ACPI: EC: PM: Avoid flushing EC work when EC GPE is inactive [ Upstream commit 607b9df63057a56f6172d560d5366cca6a030c76 ] Flushing the EC work while suspended to idle when the EC GPE status is not set causes some EC wakeup events (notably power button and lid ones) to be missed after a series of spurious wakeups on the Dell XPS13 9360 in my office. If that happens, the machine cannot be woken up from suspend-to-idle by the power button or lid status change and it needs to be woken up in some other way (eg. by a key press). Flushing the EC work only after successful dispatching the EC GPE, which means that its status has been set, avoids the issue, so change the code in question accordingly. Fixes: 7b301750f7f8 ("ACPI: EC: PM: Avoid premature returns from acpi_s2idle_wake()") Cc: 5.4+ # 5.4+ Signed-off-by: Rafael J. Wysocki Tested-by: Chris Chiu Signed-off-by: Sasha Levin commit 65c9b79dac14bf0011c5bfca4554b4841b984ad8 Author: Eric Biggers Date: Fri May 1 22:59:45 2020 -0700 ubifs: fix wrong use of crypto_shash_descsize() [ Upstream commit 3c3c32f85b6cc05e5db78693457deff03ac0f434 ] crypto_shash_descsize() returns the size of the shash_desc context needed to compute the hash, not the size of the hash itself. crypto_shash_digestsize() would be correct, or alternatively using c->hash_len and c->hmac_desc_len which already store the correct values. But actually it's simpler to just use stack arrays, so do that instead. Fixes: 49525e5eecca ("ubifs: Add helper functions for authentication support") Fixes: da8ef65f9573 ("ubifs: Authenticate replayed journal") Cc: # v4.20+ Cc: Sascha Hauer Signed-off-by: Eric Biggers Acked-by: Sascha Hauer Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit fcf7b3d2b395653ad74ff64c116040e69fd6e48c Author: Dan Carpenter Date: Tue May 5 21:33:31 2020 +0300 ovl: potential crash in ovl_fid_to_fh() [ Upstream commit 9aafc1b0187322fa4fd4eb905d0903172237206c ] The "buflen" value comes from the user and there is a potential that it could be zero. In do_handle_to_path() we know that "handle->handle_bytes" is non-zero and we do: handle_dwords = handle->handle_bytes >> 2; So values 1-3 become zero. Then in ovl_fh_to_dentry() we do: int len = fh_len << 2; So now len is in the "0,4-128" range and a multiple of 4. But if "buflen" is zero it will try to copy negative bytes when we do the memcpy in ovl_fid_to_fh(). memcpy(&fh->fb, fid, buflen - OVL_FH_WIRE_OFFSET); And that will lead to a crash. Thanks to Amir Goldstein for his help with this patch. Fixes: cbe7fba8edfc ("ovl: make sure that real fid is 32bit aligned in memory") Signed-off-by: Dan Carpenter Reviewed-by: Amir Goldstein Cc: # v5.5 Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit 5c133292e0eb6fbce3bedab5a9b9c886ca93635a Author: Roberto Sassu Date: Mon Apr 27 12:31:28 2020 +0200 ima: Fix return value of ima_write_policy() [ Upstream commit 2e3a34e9f409ebe83d1af7cd2f49fca7af97dfac ] This patch fixes the return value of ima_write_policy() when a new policy is directly passed to IMA and the current policy requires appraisal of the file containing the policy. Currently, if appraisal is not in ENFORCE mode, ima_write_policy() returns 0 and leads user space applications to an endless loop. Fix this issue by denying the operation regardless of the appraisal mode. Cc: stable@vger.kernel.org # 4.10.x Fixes: 19f8a84713edc ("ima: measure and appraise the IMA policy itself") Signed-off-by: Roberto Sassu Reviewed-by: Krzysztof Struczynski Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin commit 9688fc898f464d6571895dfae98774f5e53c7a6f Author: Roberto Sassu Date: Mon Apr 27 12:28:56 2020 +0200 evm: Check also if *tfm is an error pointer in init_desc() [ Upstream commit 53de3b080d5eae31d0de219617155dcc34e7d698 ] This patch avoids a kernel panic due to accessing an error pointer set by crypto_alloc_shash(). It occurs especially when there are many files that require an unsupported algorithm, as it would increase the likelihood of the following race condition: Task A: *tfm = crypto_alloc_shash() <= error pointer Task B: if (*tfm == NULL) <= *tfm is not NULL, use it Task B: rc = crypto_shash_init(desc) <= panic Task A: *tfm = NULL This patch uses the IS_ERR_OR_NULL macro to determine whether or not a new crypto context must be created. Cc: stable@vger.kernel.org Fixes: d46eb3699502b ("evm: crypto hash replaced by shash") Co-developed-by: Krzysztof Struczynski Signed-off-by: Krzysztof Struczynski Signed-off-by: Roberto Sassu Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin commit da047cf8a30bef6016a7ddbde5def0854cd2c3d6 Author: Roberto Sassu Date: Mon Apr 27 12:28:55 2020 +0200 ima: Set file->f_mode instead of file->f_flags in ima_calc_file_hash() [ Upstream commit 0014cc04e8ec077dc482f00c87dfd949cfe2b98f ] Commit a408e4a86b36 ("ima: open a new file instance if no read permissions") tries to create a new file descriptor to calculate a file digest if the file has not been opened with O_RDONLY flag. However, if a new file descriptor cannot be obtained, it sets the FMODE_READ flag to file->f_flags instead of file->f_mode. This patch fixes this issue by replacing f_flags with f_mode as it was before that commit. Cc: stable@vger.kernel.org # 4.20.x Fixes: a408e4a86b36 ("ima: open a new file instance if no read permissions") Signed-off-by: Roberto Sassu Reviewed-by: Goldwyn Rodrigues Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin commit fa29e1b46add7f42b7b9460ca0a5bf47b2146545 Author: Eugeniy Paltsev Date: Tue Apr 7 23:06:42 2020 +0300 ARC: [plat-hsdk]: fix USB regression [ Upstream commit 4c13ca86dcf80a8c705b1f3674ff43d318e970e0 ] As of today the CONFIG_USB isn't explicitly present in HSDK defconfig as it is implicitly forcibly enabled by UDL driver which selects CONFIG_USB in its kconfig. The commit 5d50bd440bc2 ("drm/udl: Make udl driver depend on CONFIG_USB") reverse the dependencies between UDL and USB so UDL now depends on CONFIG_USB and not selects it. This introduces regression for ARC HSDK board as HSDK defconfig wasn't adjusted and now it misses USB support due to lack of CONFIG_USB enabled. Fix that. Cc: # 5.6.x Fixes: 5d50bd440bc2 ("drm/udl: Make udl driver depend on CONFIG_USB") Signed-off-by: Eugeniy Paltsev Signed-off-by: Vineet Gupta Signed-off-by: Sasha Levin commit 8a231148135d2d08a3ef721d438cd468ea4209d2 Author: Kevin Hao Date: Fri Oct 11 23:00:14 2019 +0800 i2c: dev: Fix the race between the release of i2c_dev and cdev commit 1413ef638abae4ab5621901cf4d8ef08a4a48ba6 upstream. The struct cdev is embedded in the struct i2c_dev. In the current code, we would free the i2c_dev struct directly in put_i2c_dev(), but the cdev is manged by a kobject, and the release of it is not predictable. So it is very possible that the i2c_dev is freed before the cdev is entirely released. We can easily get the following call trace with CONFIG_DEBUG_KOBJECT_RELEASE and CONFIG_DEBUG_OBJECTS_TIMERS enabled. ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x38 WARNING: CPU: 19 PID: 1 at lib/debugobjects.c:325 debug_print_object+0xb0/0xf0 Modules linked in: CPU: 19 PID: 1 Comm: swapper/0 Tainted: G W 5.2.20-yocto-standard+ #120 Hardware name: Marvell OcteonTX CN96XX board (DT) pstate: 80c00089 (Nzcv daIf +PAN +UAO) pc : debug_print_object+0xb0/0xf0 lr : debug_print_object+0xb0/0xf0 sp : ffff00001292f7d0 x29: ffff00001292f7d0 x28: ffff800b82151788 x27: 0000000000000001 x26: ffff800b892c0000 x25: ffff0000124a2558 x24: 0000000000000000 x23: ffff00001107a1d8 x22: ffff0000116b5088 x21: ffff800bdc6afca8 x20: ffff000012471ae8 x19: ffff00001168f2c8 x18: 0000000000000010 x17: 00000000fd6f304b x16: 00000000ee79de43 x15: ffff800bc0e80568 x14: 79616c6564203a74 x13: 6e6968207473696c x12: 5f72656d6974203a x11: ffff0000113f0018 x10: 0000000000000000 x9 : 000000000000001f x8 : 0000000000000000 x7 : ffff0000101294cc x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000001 x3 : 00000000ffffffff x2 : 0000000000000000 x1 : 387fc15c8ec0f200 x0 : 0000000000000000 Call trace: debug_print_object+0xb0/0xf0 __debug_check_no_obj_freed+0x19c/0x228 debug_check_no_obj_freed+0x1c/0x28 kfree+0x250/0x440 put_i2c_dev+0x68/0x78 i2cdev_detach_adapter+0x60/0xc8 i2cdev_notifier_call+0x3c/0x70 notifier_call_chain+0x8c/0xe8 blocking_notifier_call_chain+0x64/0x88 device_del+0x74/0x380 device_unregister+0x54/0x78 i2c_del_adapter+0x278/0x2d0 unittest_i2c_bus_remove+0x3c/0x80 platform_drv_remove+0x30/0x50 device_release_driver_internal+0xf4/0x1c0 driver_detach+0x58/0xa0 bus_remove_driver+0x84/0xd8 driver_unregister+0x34/0x60 platform_driver_unregister+0x20/0x30 of_unittest_overlay+0x8d4/0xbe0 of_unittest+0xae8/0xb3c do_one_initcall+0xac/0x450 do_initcall_level+0x208/0x224 kernel_init_freeable+0x2d8/0x36c kernel_init+0x18/0x108 ret_from_fork+0x10/0x1c irq event stamp: 3934661 hardirqs last enabled at (3934661): [] debug_exception_exit+0x4c/0x58 hardirqs last disabled at (3934660): [] debug_exception_enter+0xa4/0xe0 softirqs last enabled at (3934654): [] __do_softirq+0x46c/0x628 softirqs last disabled at (3934649): [] irq_exit+0x104/0x118 This is a common issue when using cdev embedded in a struct. Fortunately, we already have a mechanism to solve this kind of issue. Please see commit 233ed09d7fda ("chardev: add helper function to register char devs with a struct device") for more detail. In this patch, we choose to embed the struct device into the i2c_dev, and use the API provided by the commit 233ed09d7fda to make sure that the release of i2c_dev and cdev are in sequence. Signed-off-by: Kevin Hao Signed-off-by: Wolfram Sang Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman