commit c65e0603de154d4b5d1cb350ac4d8b646412f700 Author: Alexandre Frade Date: Tue Sep 15 04:11:28 2020 +0000 Linux 5.8.9-xanmod1 Signed-off-by: Alexandre Frade commit 631e8b7b0f1c8b22268ec7f5a6bc8e4ba1dd74e3 Author: Alexandre Frade Date: Tue Sep 15 04:07:30 2020 +0000 cachy: Remove rq_clock_task(rq) at hrrn_start_time to improve system preemption Signed-off-by: Alexandre Frade commit 5876926d4285426e637d86e3a2ea4991a8745b46 Author: Hamad Marri Date: Sun Sep 13 12:56:58 2020 +0000 sched: Add Cachy CPU scheduler v5.8-r2 Cachy-sched is a cpu process scheduler that utilizes CPU cache and it is based on Highest Response Ratio Next (HRRN) policy. About Cachy Scheduler * All balancing code is removed except for idle CPU balancing. There is no periodic balancing, only idle CPU balancing is applied. Once a task is assigned to a CPU, it sticks with it until another CPUS got idle then this task might get pulled to new cpu. The reason of disabling periodic balancing is to utilize the CPU cache of tasks. * No grouping for tasks, FAIR_GROUP_SCHED must be disabled. * No support for NUMA, NUMA must be disabled. * Each CPU has its own runqueue. * NORMAL runqueue is a linked list of sched_entities (instead of RB-Tree). * RT and other runqueues are just the same as the CFS's. * A task gets preempted in every tick. If the clock ticks in 250HZ (i.e. CONFIG_HZ_250=y) then a task runs for 4 milliseconds and then got preempted if there are other tasks in the runqueue. * Wake up tasks preempt currently running tasks if its HRRN value is higher. * This scheduler is designed for desktop usage since it is about responsiveness. It may be not bad for servers. * Cachy might be good for mobiles or Android since it has high responsiveness. Cachy need to be integrated to Android, I don't think the current version it is ready to go without some tweeking and adapting to Android hacks. Signed-off-by: Alexandre Frade Signed-off-by: Hamad Marri commit 837592f454275c248fb5a8eacbc7ce4434b9b589 Merge: 5c2d139e62a1 f82f36b2fb1d Author: Alexandre Frade Date: Tue Sep 15 03:58:22 2020 +0000 Merge tag 'v5.8.9' into 5.8 This is the 5.8.9 stable release commit f82f36b2fb1ddb42102bba34336d8038a946dd54 Author: Greg Kroah-Hartman Date: Sat Sep 12 14:22:15 2020 +0200 Linux 5.8.9 Tested-by: Jon Hunter Tested-by: Shuah Khan Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Signed-off-by: Greg Kroah-Hartman commit cdba995d2f19932db89a91cf0d9a99d6e7d4659e Author: Florian Westphal Date: Wed Aug 26 01:31:05 2020 +0200 mptcp: free acked data before waiting for more memory [ Upstream commit 1cec170d458b1d18f6f1654ca84c0804a701c5ef ] After subflow lock is dropped, more wmem might have been made available. This fixes a deadlock in mptcp_connect.sh 'mmap' mode: wmem is exhausted. But as the mptcp socket holds on to already-acked data (for retransmit) no wakeup will occur. Using 'goto restart' calls mptcp_clean_una(sk) which will free pages that have been acked completely in the mean time. Fixes: fb529e62d3f3 ("mptcp: break and restart in case mptcp sndbuf is full") Signed-off-by: Florian Westphal Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 655e1af6aecdd960df1fc99020aec3cd4527117b Author: Jakub Kicinski Date: Wed Aug 26 12:40:06 2020 -0700 net: disable netpoll on fresh napis [ Upstream commit 96e97bc07e90f175a8980a22827faf702ca4cb30 ] napi_disable() makes sure to set the NAPI_STATE_NPSVC bit to prevent netpoll from accessing rings before init is complete. However, the same is not done for fresh napi instances in netif_napi_add(), even though we expect NAPI instances to be added as disabled. This causes crashes during driver reconfiguration (enabling XDP, changing the channel count) - if there is any printk() after netif_napi_add() but before napi_enable(). To ensure memory ordering is correct we need to use RCU accessors. Reported-by: Rob Sherwood Fixes: 2d8bff12699a ("netpoll: Close race condition between poll_one_napi and napi_disable") Signed-off-by: Jakub Kicinski Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6f0e276cda3e452d634b05070fd23a5ef7e6d0a4 Author: Tuong Lien Date: Sun Aug 30 02:37:55 2020 +0700 tipc: fix using smp_processor_id() in preemptible [ Upstream commit bb8872a1e6bc911869a729240781076ed950764b ] The 'this_cpu_ptr()' is used to obtain the AEAD key' TFM on the current CPU for encryption, however the execution can be preemptible since it's actually user-space context, so the 'using smp_processor_id() in preemptible' has been observed. We fix the issue by using the 'get/put_cpu_ptr()' API which consists of a 'preempt_disable()' instead. Fixes: fc1b6d6de220 ("tipc: introduce TIPC encryption & authentication") Acked-by: Jon Maloy Signed-off-by: Tuong Lien Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit aae250a268933d6eb4a7454e96abeb9c9a85fc04 Author: Tetsuo Handa Date: Wed Sep 2 22:44:16 2020 +0900 tipc: fix shutdown() of connectionless socket [ Upstream commit 2a63866c8b51a3f72cea388dfac259d0e14c4ba6 ] syzbot is reporting hung task at nbd_ioctl() [1], for there are two problems regarding TIPC's connectionless socket's shutdown() operation. ---------- #include #include #include #include #include int main(int argc, char *argv[]) { const int fd = open("/dev/nbd0", 3); alarm(5); ioctl(fd, NBD_SET_SOCK, socket(PF_TIPC, SOCK_DGRAM, 0)); ioctl(fd, NBD_DO_IT, 0); /* To be interrupted by SIGALRM. */ return 0; } ---------- One problem is that wait_for_completion() from flush_workqueue() from nbd_start_device_ioctl() from nbd_ioctl() cannot be completed when nbd_start_device_ioctl() received a signal at wait_event_interruptible(), for tipc_shutdown() from kernel_sock_shutdown(SHUT_RDWR) from nbd_mark_nsock_dead() from sock_shutdown() from nbd_start_device_ioctl() is failing to wake up a WQ thread sleeping at wait_woken() from tipc_wait_for_rcvmsg() from sock_recvmsg() from sock_xmit() from nbd_read_stat() from recv_work() scheduled by nbd_start_device() from nbd_start_device_ioctl(). Fix this problem by always invoking sk->sk_state_change() (like inet_shutdown() does) when tipc_shutdown() is called. The other problem is that tipc_wait_for_rcvmsg() cannot return when tipc_shutdown() is called, for tipc_shutdown() sets sk->sk_shutdown to SEND_SHUTDOWN (despite "how" is SHUT_RDWR) while tipc_wait_for_rcvmsg() needs sk->sk_shutdown set to RCV_SHUTDOWN or SHUTDOWN_MASK. Fix this problem by setting sk->sk_shutdown to SHUTDOWN_MASK (like inet_shutdown() does) when the socket is connectionless. [1] https://syzkaller.appspot.com/bug?id=3fe51d307c1f0a845485cf1798aa059d12bf18b2 Reported-by: syzbot Signed-off-by: Tetsuo Handa Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 44c3fca3de64b976c2260605ca61277e5951c864 Author: Vinicius Costa Gomes Date: Tue Aug 25 10:44:04 2020 -0700 taprio: Fix using wrong queues in gate mask [ Upstream commit 09e31cf0c528dac3358a081dc4e773d1b3de1bc9 ] Since commit 9c66d1564676 ("taprio: Add support for hardware offloading") there's a bit of inconsistency when offloading schedules to the hardware: In software mode, the gate masks are specified in terms of traffic classes, so if say "sched-entry S 03 20000", it means that the traffic classes 0 and 1 are open for 20us; when taprio is offloaded to hardware, the gate masks are specified in terms of hardware queues. The idea here is to fix hardware offloading, so schedules in hardware and software mode have the same behavior. What's needed to do is to map traffic classes to queues when applying the offload to the driver. Fixes: 9c66d1564676 ("taprio: Add support for hardware offloading") Signed-off-by: Vinicius Costa Gomes Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit db16256c95ac7d74ecd43bce68f85a88663f3d9c Author: Xin Long Date: Fri Aug 21 14:59:38 2020 +0800 sctp: not disable bh in the whole sctp_get_port_local() [ Upstream commit 3106ecb43a05dc3e009779764b9da245a5d082de ] With disabling bh in the whole sctp_get_port_local(), when snum == 0 and too many ports have been used, the do-while loop will take the cpu for a long time and cause cpu stuck: [ ] watchdog: BUG: soft lockup - CPU#11 stuck for 22s! [ ] RIP: 0010:native_queued_spin_lock_slowpath+0x4de/0x940 [ ] Call Trace: [ ] _raw_spin_lock+0xc1/0xd0 [ ] sctp_get_port_local+0x527/0x650 [sctp] [ ] sctp_do_bind+0x208/0x5e0 [sctp] [ ] sctp_autobind+0x165/0x1e0 [sctp] [ ] sctp_connect_new_asoc+0x355/0x480 [sctp] [ ] __sctp_connect+0x360/0xb10 [sctp] There's no need to disable bh in the whole function of sctp_get_port_local. So fix this cpu stuck by removing local_bh_disable() called at the beginning, and using spin_lock_bh() instead. The same thing was actually done for inet_csk_get_port() in Commit ea8add2b1903 ("tcp/dccp: better use of ephemeral ports in bind()"). Thanks to Marcelo for pointing the buggy code out. v1->v2: - use cond_resched() to yield cpu to other tasks if needed, as Eric noticed. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Ying Xu Signed-off-by: Xin Long Acked-by: Marcelo Ricardo Leitner Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 05a8237c08f0adf7f41be7565f85775171f39e05 Author: Kamil Lorenc Date: Tue Sep 1 10:57:38 2020 +0200 net: usb: dm9601: Add USB ID of Keenetic Plus DSL [ Upstream commit a609d0259183a841621f252e067f40f8cc25d6f6 ] Keenetic Plus DSL is a xDSL modem that uses dm9620 as its USB interface. Signed-off-by: Kamil Lorenc Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6540bd18bf2fe2091ae61a5f6138080451b8e20f Author: Paul Moore Date: Fri Aug 21 16:34:52 2020 -0400 netlabel: fix problems with mapping removal [ Upstream commit d3b990b7f327e2afa98006e7666fb8ada8ed8683 ] This patch fixes two main problems seen when removing NetLabel mappings: memory leaks and potentially extra audit noise. The memory leaks are caused by not properly free'ing the mapping's address selector struct when free'ing the entire entry as well as not properly cleaning up a temporary mapping entry when adding new address selectors to an existing entry. This patch fixes both these problems such that kmemleak reports no NetLabel associated leaks after running the SELinux test suite. The potentially extra audit noise was caused by the auditing code in netlbl_domhsh_remove_entry() being called regardless of the entry's validity. If another thread had already marked the entry as invalid, but not removed/free'd it from the list of mappings, then it was possible that an additional mapping removal audit record would be generated. This patch fixes this by returning early from the removal function when the entry was previously marked invalid. This change also had the side benefit of improving the code by decreasing the indentation level of large chunk of code by one (accounting for most of the diffstat). Fixes: 63c416887437 ("netlabel: Add network address selectors to the NetLabel/LSM domain mapping") Reported-by: Stephen Smalley Signed-off-by: Paul Moore Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 089097476c4cf4fe2700ce00d0e55d8b0c3cefec Author: Ido Schimmel Date: Wed Sep 2 16:16:59 2020 +0300 ipv6: Fix sysctl max for fib_multipath_hash_policy [ Upstream commit 05d4487197b2b71d5363623c28924fd58c71c0b6 ] Cited commit added the possible value of '2', but it cannot be set. Fix it by adjusting the maximum value to '2'. This is consistent with the corresponding IPv4 sysctl. Before: # sysctl -w net.ipv6.fib_multipath_hash_policy=2 sysctl: setting key "net.ipv6.fib_multipath_hash_policy": Invalid argument net.ipv6.fib_multipath_hash_policy = 2 # sysctl net.ipv6.fib_multipath_hash_policy net.ipv6.fib_multipath_hash_policy = 0 After: # sysctl -w net.ipv6.fib_multipath_hash_policy=2 net.ipv6.fib_multipath_hash_policy = 2 # sysctl net.ipv6.fib_multipath_hash_policy net.ipv6.fib_multipath_hash_policy = 2 Fixes: d8f74f0975d8 ("ipv6: Support multipath hashing on inner IP pkts") Signed-off-by: Ido Schimmel Reviewed-by: Stephen Suryaputra Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit d68c3397de4868d70fca0bbe1aa5d0bc75116412 Author: Ido Schimmel Date: Wed Aug 26 19:48:10 2020 +0300 ipv4: Silence suspicious RCU usage warning [ Upstream commit 7f6f32bb7d3355cd78ebf1dece9a6ea7a0ca8158 ] fib_info_notify_update() is always called with RTNL held, but not from an RCU read-side critical section. This leads to the following warning [1] when the FIB table list is traversed with hlist_for_each_entry_rcu(), but without a proper lockdep expression. Since modification of the list is protected by RTNL, silence the warning by adding a lockdep expression which verifies RTNL is held. [1] ============================= WARNING: suspicious RCU usage 5.9.0-rc1-custom-14233-g2f26e122d62f #129 Not tainted ----------------------------- net/ipv4/fib_trie.c:2124 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by ip/834: #0: ffffffff85a3b6b0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x49a/0xbd0 stack backtrace: CPU: 0 PID: 834 Comm: ip Not tainted 5.9.0-rc1-custom-14233-g2f26e122d62f #129 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-2.fc32 04/01/2014 Call Trace: dump_stack+0x100/0x184 lockdep_rcu_suspicious+0x143/0x14d fib_info_notify_update+0x8d1/0xa60 __nexthop_replace_notify+0xd2/0x290 rtm_new_nexthop+0x35e2/0x5946 rtnetlink_rcv_msg+0x4f7/0xbd0 netlink_rcv_skb+0x17a/0x480 rtnetlink_rcv+0x22/0x30 netlink_unicast+0x5ae/0x890 netlink_sendmsg+0x98a/0xf40 ____sys_sendmsg+0x879/0xa00 ___sys_sendmsg+0x122/0x190 __sys_sendmsg+0x103/0x1d0 __x64_sys_sendmsg+0x7d/0xb0 do_syscall_64+0x32/0x50 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7fde28c3be57 Code: 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 89 74 24 10 RSP: 002b:00007ffc09330028 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fde28c3be57 RDX: 0000000000000000 RSI: 00007ffc09330090 RDI: 0000000000000003 RBP: 000000005f45f911 R08: 0000000000000001 R09: 00007ffc0933012c R10: 0000000000000076 R11: 0000000000000246 R12: 0000000000000001 R13: 00007ffc09330290 R14: 00007ffc09330eee R15: 00005610e48ed020 Fixes: 1bff1a0c9bbd ("ipv4: Add function to send route updates") Signed-off-by: Ido Schimmel Reviewed-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit bd15d2192261183fb4af1a26f9eef8aa5f2e3fba Author: Jason Gunthorpe Date: Thu Jul 23 10:07:07 2020 +0300 RDMA/cma: Execute rdma_cm destruction from a handler properly [ Upstream commit f6a9d47ae6854980fc4b1676f1fe9f9fa45ea4e2 ] When a rdma_cm_id needs to be destroyed after a handler callback fails, part of the destruction pattern is open coded into each call site. Unfortunately the blind assignment to state discards important information needed to do cma_cancel_operation(). This results in active operations being left running after rdma_destroy_id() completes, and the use-after-free bugs from KASAN. Consolidate this entire pattern into destroy_id_handler_unlock() and manage the locking correctly. The state should be set to RDMA_CM_DESTROYING under the handler_lock to atomically ensure no futher handlers are called. Link: https://lore.kernel.org/r/20200723070707.1771101-5-leon@kernel.org Reported-by: syzbot+08092148130652a6faae@syzkaller.appspotmail.com Reported-by: syzbot+a929647172775e335941@syzkaller.appspotmail.com Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit d4794085738d7912ec1fc6ebc9fabb20e07242f3 Author: Jason Gunthorpe Date: Thu Jul 23 10:07:06 2020 +0300 RDMA/cma: Remove unneeded locking for req paths [ Upstream commit cc9c037343898eb7a775e6b81d092ee21eeff218 ] The REQ flows are concerned that once the handler is called on the new cm_id the ULP can choose to trigger a rdma_destroy_id() concurrently at any time. However, this is not true, while the ULP can call rdma_destroy_id(), it immediately blocks on the handler_mutex which prevents anything harmful from running concurrently. Remove the confusing extra locking and refcounts and make the handler_mutex protecting state during destroy more clear. Link: https://lore.kernel.org/r/20200723070707.1771101-4-leon@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit c2064ac303312f5bb077d5e944f621d5b206d85e Author: Jason Gunthorpe Date: Thu Jul 23 10:07:05 2020 +0300 RDMA/cma: Using the standard locking pattern when delivering the removal event [ Upstream commit 3647a28de1ada8708efc78d956619b9df5004478 ] Whenever an event is delivered to the handler it should be done under the handler_mutex and upon any non-zero return from the handler it should trigger destruction of the cm_id. cma_process_remove() skips some steps here, it is not necessarily wrong since the state change should prevent any races, but it is confusing and unnecessary. Follow the standard pattern here, with the slight twist that the transition to RDMA_CM_DEVICE_REMOVAL includes a cma_cancel_operation(). Link: https://lore.kernel.org/r/20200723070707.1771101-3-leon@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 5a0c4cbd099b82576dfb5aea6aab3d27517c91a2 Author: Jason Gunthorpe Date: Thu Jul 23 10:07:04 2020 +0300 RDMA/cma: Simplify DEVICE_REMOVAL for internal_id [ Upstream commit d54f23c09ec62670901f1a2a4712a5218522ca2b ] cma_process_remove() triggers an unconditional rdma_destroy_id() for internal_id's and skips the event deliver and transition through RDMA_CM_DEVICE_REMOVAL. This is confusing and unnecessary. internal_id always has cma_listen_handler() as the handler, have it catch the RDMA_CM_DEVICE_REMOVAL event and directly consume it and signal removal. This way the FSM sequence never skips the DEVICE_REMOVAL case and the logic in this hard to test area is simplified. Link: https://lore.kernel.org/r/20200723070707.1771101-2-leon@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 87d8175e9c3de7b12584ec80baa5d4cc436b66da Author: Pavel Begunkov Date: Sun Sep 6 00:45:15 2020 +0300 io_uring: fix linked deferred ->files cancellation [ Upstream commit c127a2a1b7baa5eb40a7e2de4b7f0c51ccbbb2ef ] While looking for ->files in ->defer_list, consider that requests there may actually be links. Signed-off-by: Pavel Begunkov Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit f5fea75f4ea401df7870ef7bf510c62ac9268745 Author: Pavel Begunkov Date: Sun Sep 6 00:45:14 2020 +0300 io_uring: fix cancel of deferred reqs with ->files [ Upstream commit b7ddce3cbf010edbfac6c6d8cc708560a7bcd7a4 ] While trying to cancel requests with ->files, it also should look for requests in ->defer_list, otherwise it might end up hanging a thread. Cancel all requests in ->defer_list up to the last request there with matching ->files, that's needed to follow drain ordering semantics. Signed-off-by: Pavel Begunkov Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin