~mreed8855/ubuntu/+source/linux/+git/kinetic:lp_2008527_dapc_kinetic
- Git
- lp:~mreed8855/ubuntu/+source/linux/+git/kinetic
- lp_2008527_dapc_kinetic
- Get this branch:
-
git clone
-b lp_2008527_dapc_kinetic
https://git.launchpad.net/~mreed8855/ubuntu/+source/linux/+git/kinetic
Branch merges
Related source package recipes
Branch information
- Name:
- lp_2008527_dapc_kinetic
- Repository:
- lp:~mreed8855/ubuntu/+source/linux/+git/kinetic
Recent commits
- 6f8621b... by Stuart Hayes <email address hidden>
-
cpufreq: ACPI: Defer setting boost MSRs
When acpi-cpufreq is loaded, boost is enabled on every CPU (by setting an
MSR) before the driver is registered with cpufreq. This can be very time
consuming, because it is done with a CPU hotplug startup callback, and
cpuhp_setup_state() schedules the callback (cpufreq_boost_online( )) to run
on each CPU one at a time, waiting for each to run before calling the next.If cpufreq_
register_ driver( ) fails--if, for example, there are no ACPI
P-states present--this is wasted time.Since cpufreq already sets up a CPU hotplug startup callback if and when
acpi-cpufreq is registered, set the boost MSRs in acpi_cpufreq_cpu_init( ),
which is called by the cpufreq cpuhp callback. This allows acpi-cpufreq to
exit quickly if it is loaded but not needed.On one system with 192 CPUs, this patch speeds up boot by about 30 seconds.
BugLink: https:/
/bugs.launchpad .net/bugs/ 2008527 Signed-off-by: Stuart Hayes <email address hidden>
Signed-off-by: Rafael J. Wysocki <email address hidden>
(cherry picked from commit 13fdbc8b8da6a2325cad3359c9a705 04b0ff2f93)
Signed-off-by: Michael Reed <email address hidden> - 7c9644d... by Po-Hsu Lin
-
selftests: net: devlink_
port_split. py: skip test if no suitable device available BugLink: https:/
/bugs.launchpad .net/bugs/ 1937133 The `devlink -j port show` command output may not contain the "flavour"
key, an example from Ubuntu 22.10 s390x LPAR(5.19.0-37- generic) , with
mlx4 driver and iproute2-5.15.0:
{"port":{"pci/ 0001:00: 00.0/1" :{"type" :"eth", "netdev" :"ens301" },
"pci/ 0001:00: 00.0/2" :{"type" :"eth", "netdev" :"ens301d1" },
"pci/ 0002:00: 00.0/1" :{"type" :"eth", "netdev" :"ens317" },
"pci/ 0002:00: 00.0/2" :{"type" :"eth", "netdev" :"ens317d1" }}} This will cause a KeyError exception.
Create a validate_
devlink_ output( ) to check for this "flavour" from
devlink command output to avoid this KeyError exception. Also let
it handle the check for `devlink -j dev show` output in main().Apart from this, if the test was not started because the max lanes of
the designated device is 0. The script will still return 0 and thus
causing a false-negative test result.Use a found_max_lanes flag to determine if these tests were skipped
due to this reason and return KSFT_SKIP to make it more clear.Link: https:/
/bugs.launchpad .net/bugs/ 1937133
Fixes: f3348a82e727 ("selftests: net: Add port split test")
Signed-off-by: Po-Hsu Lin <email address hidden>
Link: https://<email address hidden>
Signed-off-by: Jakub Kicinski <email address hidden>(cherry picked from commit 3de66d08d37a565
eba1adfe1e10759 3cae978a20)
Signed-off-by: Po-Hsu Lin <email address hidden>
Acked-by: Roxana Nicolescu <email address hidden>
Acked-by: Tim Gardner <email address hidden>
Signed-off-by: Stefan Bader <email address hidden> - 63b5716... by Eric Dumazet <email address hidden>
-
netfilter: conntrack: adopt safer max chain length
BugLink: https:/
/bugs.launchpad .net/bugs/ 2011616 Customers using GKE 1.25 and 1.26 are facing conntrack issues
root caused to commit c9c3b6811f74 ("netfilter: conntrack: make
max chain length random").Even if we assume Uniform Hashing, a bucket often reachs 8 chained
items while the load factor of the hash table is smaller than 0.5With a limit of 16, we reach load factors of 3.
With a limit of 32, we reach load factors of 11.
With a limit of 40, we reach load factors of 15.
With a limit of 50, we reach load factors of 24.This patch changes MIN_CHAINLEN to 50, to minimize risks.
Ideally, we could in the future add a cushion based on expected
load factor (2 * nf_conntrack_max / nf_conntrack_buckets) ,
because some setups might expect unusual values.Fixes: c9c3b6811f74 ("netfilter: conntrack: make max chain length random")
Signed-off-by: Eric Dumazet <email address hidden>
Signed-off-by: Pablo Neira Ayuso <email address hidden>(cherry picked from commit c77737b736ceb50
fdf150434347dbd 81ec76dbb1)
Signed-off-by: Khalid Elmously <email address hidden>
Acked-by: Tim Gardner <email address hidden>
Acked-by: Cengiz Can <email address hidden>
Signed-off-by: Stefan Bader <email address hidden> - a46d1d8... by Kamal Mostafa
-
UBUNTU: Upstream stable to v5.15.90, v6.1.8
BugLink: https:/
/bugs.launchpad .net/bugs/ 2012977 Ignore: yes
Signed-off-by: Kamal Mostafa <email address hidden>
Signed-off-by: Stefan Bader <email address hidden> - 82947d0... by Kevin Hao <email address hidden>
-
octeontx2-pf: Fix the use of GFP_KERNEL in atomic context on rt
BugLink: https:/
/bugs.launchpad .net/bugs/ 2012977 commit 55ba18dc62deff5
910c0fa64486dea 1ff20832ff upstream. The commit 4af1b64f80fb ("octeontx2-pf: Fix lmtst ID used in aura
free") uses the get/put_cpu() to protect the usage of percpu pointer
in ->aura_freeptr() callback, but it also unnecessarily disable the
preemption for the blockable memory allocation. The commit 87b93b678e95
("octeontx2-pf: Avoid use of GFP_KERNEL in atomic context") tried to
fix these sleep inside atomic warnings. But it only fix the one for
the non-rt kernel. For the rt kernel, we still get the similar warnings
like below.
BUG: sleeping function called from invalid context at kernel/locking/ spinlock_ rt.c:46
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0
preempt_count: 1, expected: 0
RCU nest depth: 0, expected: 0
3 locks held by swapper/0/1:
#0: ffff800009fc5fe8 (rtnl_mutex){+.+.}- {3:3}, at: rtnl_lock+0x24/0x30
#1: ffff000100c276c0 (&mbox->lock){ +.+.}-{ 3:3}, at: otx2_init_ hw_resources+ 0x8c/0x3a4
#2: ffffffbfef6537e0 (&cpu_rcache->lock){ +.+.}-{ 2:2}, at: alloc_iova_ fast+0x1ac/ 0x2ac
Preemption disabled at:
[<ffff800008b1908c>] otx2_rq_ aura_pool_ init+0x14c/ 0x284
CPU: 20 PID: 1 Comm: swapper/0 Tainted: G W 6.2.0-rc3-rt1-yocto- preempt- rt #1
Hardware name: Marvell OcteonTX CN96XX board (DT)
Call trace:
dump_backtrace. part.0+ 0xe8/0xf4
show_stack+0x20/ 0x30
dump_stack_lvl+ 0x9c/0xd8
dump_stack+0x18/ 0x34
__might_resched+ 0x188/0x224
rt_spin_lock+0x64/ 0x110
alloc_iova_fast+ 0x1ac/0x2ac
iommu_dma_alloc_ iova+0xd4/ 0x110
__iommu_dma_map+ 0x80/0x144
iommu_dma_map_ page+0xe8/ 0x260
dma_map_page_ attrs+0xb4/ 0xc0
__otx2_alloc_rbuf+ 0x90/0x150
otx2_rq_aura_ pool_init+ 0x1c8/0x284
otx2_init_hw_ resources+ 0xe4/0x3a4
otx2_open+0xf0/ 0x610
__dev_open+0x104/ 0x224
__dev_change_ flags+0x1e4/ 0x274
dev_change_ flags+0x2c/ 0x7c
ic_open_devs+0x124/ 0x2f8
ip_auto_config+ 0x180/0x42c
do_one_initcall+ 0x90/0x4dc
do_basic_setup+0x10c/ 0x14c
kernel_init_freeable+ 0x10c/0x13c
kernel_init+0x2c/ 0x140
ret_from_fork+ 0x10/0x20 Of course, we can shuffle the get/put_cpu() to only wrap the invocation
of ->aura_freeptr() as what commit 87b93b678e95 does. But there are only
two ->aura_freeptr() callbacks, otx2_aura_freeptr() and
cn10k_aura_freeptr( ). There is no usage of perpcu variable in the
otx2_aura_freeptr() at all, so the get/put_cpu() seems redundant to it.
We can move the get/put_cpu() into the corresponding callback which
really has the percpu variable usage and avoid the sprinkling of
get/put_cpu() in several places.Fixes: 4af1b64f80fb ("octeontx2-pf: Fix lmtst ID used in aura free")
Signed-off-by: Kevin Hao <email address hidden>
Link: https://<email address hidden>
Signed-off-by: Paolo Abeni <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Kamal Mostafa <email address hidden>
Signed-off-by: Stefan Bader <email address hidden> - ef4f5dc... by Geetha sowjanya <email address hidden>
-
octeontx2-pf: Avoid use of GFP_KERNEL in atomic context
BugLink: https:/
/bugs.launchpad .net/bugs/ 2012977 commit 87b93b678e95c7d
93fe6a55b0e0fbd a26d8c7760 upstream. Using GFP_KERNEL in preemption disable context, causing below warning
when CONFIG_DEBUG_ATOMIC_ SLEEP is enabled. [ 32.542271] BUG: sleeping function called from invalid context at include/
linux/sched/ mm.h:274
[ 32.550883] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0
[ 32.558707] preempt_count: 1, expected: 0
[ 32.562710] RCU nest depth: 0, expected: 0
[ 32.566800] CPU: 3 PID: 1 Comm: swapper/0 Tainted: G W 6.2.0-rc2-00269-gae9dcb91 c606 #7
[ 32.576188] Hardware name: Marvell CN106XX board (DT)
[ 32.581232] Call trace:
[ 32.583670] dump_backtrace.part.0+ 0xe0/0xf0
[ 32.587937] show_stack+0x18/0x30
[ 32.591245] dump_stack_lvl+0x68/ 0x84
[ 32.594900] dump_stack+0x18/0x34
[ 32.598206] __might_resched+ 0x12c/0x160
[ 32.602122] __might_sleep+0x48/ 0xa0
[ 32.605689] __kmem_cache_alloc_ node+0x2b8/ 0x2e0
[ 32.610301] __kmalloc+0x58/0x190
[ 32.613610] otx2_sq_aura_pool_ init+0x1a8/ 0x314
[ 32.618134] otx2_open+0x1d4/0x9d0 To avoid use of GFP_ATOMIC for memory allocation, disable preemption
after all memory allocation is done.Fixes: 4af1b64f80fb ("octeontx2-pf: Fix lmtst ID used in aura free")
Signed-off-by: Geetha sowjanya <email address hidden>
Signed-off-by: Sunil Kovvuri Goutham <email address hidden>
Reviewed-by: Leon Romanovsky <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Kamal Mostafa <email address hidden>
Signed-off-by: Stefan Bader <email address hidden> - e22bf6b... by Thomas Zimmermann <email address hidden>
-
drm/i915: Allow switching away via vga-switcheroo if uninitialized
BugLink: https:/
/bugs.launchpad .net/bugs/ 2012977 commit a273e95721e9688
5971a05f1b34cb6 d093904d9d upstream. Always allow switching away via vga-switcheroo if the display is
uninitalized. Instead prevent switching to i915 if the device has
not been initialized.This issue was introduced by commit 5df7bd130818 ("drm/i915: skip
display initialization when there is no display") protected, which
protects code paths from being executed on uninitialized devices.
In the case of vga-switcheroo, we want to allow a switch away from
i915's device. So run vga_switcheroo_process_ delayed_ switch( ) and
test in the switcheroo callbacks if the i915 device is available.Fixes: 5df7bd130818 ("drm/i915: skip display initialization when there is no display")
Signed-off-by: Thomas Zimmermann <email address hidden>
Reviewed-by: Alex Deucher <email address hidden>
Cc: Radhakrishna Sripada <email address hidden>
Cc: Lucas De Marchi <email address hidden>
Cc: José Roberto de Souza <email address hidden>
Cc: Jani Nikula <email address hidden>
Cc: Ville Syrjälä <email address hidden>
Cc: Jani Nikula <email address hidden>
Cc: Joonas Lahtinen <email address hidden>
Cc: Rodrigo Vivi <email address hidden>
Cc: Tvrtko Ursulin <email address hidden>
Cc: "Ville Syrjälä" <email address hidden>
Cc: Manasi Navare <email address hidden>
Cc: Stanislav Lisovskiy <email address hidden>
Cc: Imre Deak <email address hidden>
Cc: "Jouni Högander" <email address hidden>
Cc: Uma Shankar <email address hidden>
Cc: Ankit Nautiyal <email address hidden>
Cc: "Jason A. Donenfeld" <email address hidden>
Cc: Matt Roper <email address hidden>
Cc: Ramalingam C <email address hidden>
Cc: Thomas Zimmermann <email address hidden>
Cc: Andi Shyti <email address hidden>
Cc: Andrzej Hajda <email address hidden>
Cc: "José Roberto de Souza" <email address hidden>
Cc: Julia Lawall <email address hidden>
Cc: <email address hidden>
Cc: <email address hidden> # v5.14+
Link: https://patchwork<email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Kamal Mostafa <email address hidden>
Signed-off-by: Stefan Bader <email address hidden> - cc11e3d... by jie1zhan <email address hidden>
-
drm/amdgpu: Correct the power calcultion for Renior/Cezanne.
BugLink: https:/
/bugs.launchpad .net/bugs/ 2012977 commit c7bae4aaa5609c1
fa9761c35dbcc5f cc92915222 upstream. From smu firmware,the value of power is transferred in units of watts.
Bug: https:/
/gitlab. freedesktop. org/drm/ amd/-/issues/ 2321
Fixes: 137aac26a2ed ("drm/amdgpu/smu12: fix power reporting on renoir")
Acked-by: Alex Deucher <email address hidden>
Signed-off-by: Jesse Zhang <email address hidden>
Reviewed-by: Aaron Liu <email address hidden>
Signed-off-by: Alex Deucher <email address hidden>
Cc: <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Kamal Mostafa <email address hidden>
Signed-off-by: Stefan Bader <email address hidden> - 48bfb5f... by Arnd Bergmann
-
ARM: omap1: fix !ARCH_OMAP1_ANY link failures
BugLink: https:/
/bugs.launchpad .net/bugs/ 2012977 commit 980a637d11fe8df
c734f508a422185 c2de55e669 upstream. While compile-testing randconfig builds for the upcoming boardfile
removal, I noticed that an earlier patch of mine was completely
broken, and the introduction of CONFIG_ARCH_OMAP1_ ANY only replaced
one set of build failures with another one, now resulting in
link failures likeld: drivers/
video/fbdev/ omap/omapfb_ main.o: in function `omapfb_do_probe':
drivers/video/fbdev/ omap/omapfb_ main.c: 1703: undefined reference to `omap_set_ dma_priority'
ld: drivers/dma/ti/ omap-dma. o: in function `omap_dma_ free_chan_ resources' :
drivers/dma/ti/ omap-dma. c:777: undefined reference to `omap_free_dma'
drivers/dma/ti/ omap-dma. c:1685: undefined reference to `omap_get_ plat_info'
ld: drivers/usb/gadget/ udc/omap_ udc.o: in function `next_in_dma':
drivers/usb/gadget/ udc/omap_ udc.c:820: undefined reference to `omap_get_ dma_active_ status' I tried reworking it, but the resulting patch ended up much bigger than
simply avoiding the original problem of unused-function warnings likearch/arm/
mach-omap1/ mcbsp.c: 76:30: error: unused variable 'omap1_mcbsp_ops' [-Werror, -Wunused- variable] As a result, revert the previous fix, and rearrange the code that
produces warnings to hide them. For mcbsp, the #ifdef check can
simply be removed as the cpu_is_omapxxx() checks already achieve
the same result, while in the io.c the easiest solution appears to
be to merge the common map bits into each soc specific portion.
This gets cleaned in a nicer way after omap7xx support gets dropped,
as the remaining SoCs all have the exact same I/O map.Fixes: 615dce5bf736 ("ARM: omap1: fix build with no SoC selected")
Cc: <email address hidden>
Acked-by: Aaro Koskinen <email address hidden>
Signed-off-by: Arnd Bergmann <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Kamal Mostafa <email address hidden>
Signed-off-by: Stefan Bader <email address hidden> - c3bb1ab... by Vishnu Dasa <email address hidden>
-
VMCI: Use threaded irqs instead of tasklets
BugLink: https:/
/bugs.launchpad .net/bugs/ 2012977 commit 3daed6345d58804
64f46adab871d20 8e1baa2f3a upstream. The vmci_dispatch_dgs() tasklet function calls vmci_read_data()
which uses wait_event() resulting in invalid sleep in an atomic
context (and therefore potentially in a deadlock).Use threaded irqs to fix this issue and completely remove usage
of tasklets.[ 20.264639] BUG: sleeping function called from invalid context at drivers/
misc/vmw_ vmci/vmci_ guest.c: 145
[ 20.264643] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 762, name: vmtoolsd
[ 20.264645] preempt_count: 101, expected: 0
[ 20.264646] RCU nest depth: 0, expected: 0
[ 20.264647] 1 lock held by vmtoolsd/762:
[ 20.264648] #0: ffff0000874ae440 (sk_lock-AF_VSOCK) {+.+.}- {0:0}, at: vsock_connect+ 0x60/0x330 [vsock]
[ 20.264658] Preemption disabled at:
[ 20.264659] [<ffff80000151d7d8>] vmci_send_ datagram+ 0x44/0xa0 [vmw_vmci]
[ 20.264665] CPU: 0 PID: 762 Comm: vmtoolsd Not tainted 5.19.0-0.rc8.20220727g it39c3c396f813. 60.fc37. aarch64 #1
[ 20.264667] Hardware name: VMware, Inc. VBSA/VBSA, BIOS VEFI 12/31/2020
[ 20.264668] Call trace:
[ 20.264669] dump_backtrace+0xc4/0x130
[ 20.264672] show_stack+0x24/0x80
[ 20.264673] dump_stack_lvl+0x88/ 0xb4
[ 20.264676] dump_stack+0x18/0x34
[ 20.264677] __might_resched+ 0x1a0/0x280
[ 20.264679] __might_sleep+0x58/ 0x90
[ 20.264681] vmci_read_data+0x74/ 0x120 [vmw_vmci]
[ 20.264683] vmci_dispatch_dgs+0x64/ 0x204 [vmw_vmci]
[ 20.264686] tasklet_action_ common. constprop. 0+0x13c/ 0x150
[ 20.264688] tasklet_action+ 0x40/0x50
[ 20.264689] __do_softirq+0x23c/0x6b4
[ 20.264690] __irq_exit_rcu+0x104/ 0x214
[ 20.264691] irq_exit_rcu+0x1c/ 0x50
[ 20.264693] el1_interrupt+0x38/0x6c
[ 20.264695] el1h_64_irq_handler+ 0x18/0x24
[ 20.264696] el1h_64_irq+0x68/ 0x6c
[ 20.264697] preempt_count_sub+ 0xa4/0xe0
[ 20.264698] _raw_spin_unlock_ irqrestore+ 0x64/0xb0
[ 20.264701] vmci_send_datagram+ 0x7c/0xa0 [vmw_vmci]
[ 20.264703] vmci_datagram_dispatch+ 0x84/0x100 [vmw_vmci]
[ 20.264706] vmci_datagram_send+0x2c/ 0x40 [vmw_vmci]
[ 20.264709] vmci_transport_send_control_ pkt+0xb8/ 0x120 [vmw_vsock_ vmci_transport]
[ 20.264711] vmci_transport_connect+ 0x40/0x7c [vmw_vsock_ vmci_transport]
[ 20.264713] vsock_connect+0x278/0x330 [vsock]
[ 20.264715] __sys_connect_file+0x8c/ 0xc0
[ 20.264718] __sys_connect+0x84/0xb4
[ 20.264720] __arm64_sys_connect+ 0x2c/0x3c
[ 20.264721] invoke_syscall+ 0x78/0x100
[ 20.264723] el0_svc_common. constprop. 0+0x68/ 0x124
[ 20.264724] do_el0_svc+0x38/ 0x4c
[ 20.264725] el0_svc+0x60/0x180
[ 20.264726] el0t_64_sync_handler+ 0x11c/0x150
[ 20.264728] el0t_64_sync+0x190/ 0x194 Signed-off-by: Vishnu Dasa <email address hidden>
Suggested-by: Zack Rusin <email address hidden>
Reported-by: Nadav Amit <email address hidden>
Reported-by: Nathan Chancellor <email address hidden>
Tested-by: Nathan Chancellor <email address hidden>
Fixes: 463713eb6164 ("VMCI: dma dg: add support for DMA datagrams receive")
Cc: <email address hidden> # v5.18+
Cc: VMware PV-Drivers Reviewers <email address hidden>
Cc: Greg Kroah-Hartman <email address hidden>
Cc: Bryan Tan <email address hidden>
Reviewed-by: Bryan Tan <email address hidden>
Reviewed-by: Zack Rusin <email address hidden>
Link: https://<email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Kamal Mostafa <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>