user/sven/linux.git, branch v6.1.23

Linux 6.1.23

2023-04-06T10:10:58Z

Link: https://lore.kernel.org/r/20230403140415.090615502@linuxfoundation.org Tested-by: Markus Reichelt Tested-by: Shuah Khan Tested-by: Takeshi Ogasawara Tested-by: Florian Fainelli Tested-by: Bagas Sanjaya Tested-by: Jon Hunter Tested-by: Chris Paterson (CIP) Tested-by: Conor Dooley Tested-by: Linux Kernel Functional Testing Link: https://lore.kernel.org/r/20230404183150.381314754@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Ron Economos Tested-by: Bagas Sanjaya Tested-by: Linux Kernel Functional Testing Tested-by: Salvatore Bonaccorso Link: https://lore.kernel.org/r/20230405100302.540890806@linuxfoundation.org Tested-by: Takeshi Ogasawara Tested-by: Florian Fainelli Tested-by: Rudi Heitbaum Tested-by: Jon Hunter Tested-by: Markus Reichelt Tested-by: Linux Kernel Functional Testing Tested-by: Guenter Roeck Tested-by: Kelsey Steele Tested-by: Bagas Sanjaya Tested-by: Allen Pais Signed-off-by: Greg Kroah-Hartman

Revert "cpuidle, intel_idle: Fix CPUIDLE_FLAG_IRQ_ENABLE again"

2023-04-06T10:10:58Z

This reverts commit 07fc78d8f0c960f7ca241de98bc8c6bfe7d200f3 which was upstream commit 6d9c7f51b1d9179bf7c3542267c656a934e8af23. Lockdep warnings on boot that are not seen with Linus's tree. Signed-off-by: Sasha Levin

x86/PVH: avoid 32-bit build warning when obtaining VGA console info

2023-04-06T10:10:58Z

commit aadbd07ff8a75ed342388846da78dfaddb8b106a upstream. In the commit referenced below I failed to pay attention to this code also being buildable as 32-bit. Adjust the type of "ret" - there's no real need for it to be wider than 32 bits. Fixes: 934ef33ee75c ("x86/PVH: obtain VGA console info in Dom0") Reported-by: kernel test robot Signed-off-by: Jan Beulich Reviewed-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman Link: https://lore.kernel.org/r/2d2193ff-670b-0a27-e12d-2c5c4c121c79@suse.com Signed-off-by: Juergen Gross

hsr: ratelimit only when errors are printed

2023-04-06T10:10:58Z

commit 1b0120e4db0bf2838d1ce741195ce4b7cc100b91 upstream. Recently, when automatically merging -net and net-next in MPTCP devel tree, our CI reported [1] a conflict in hsr, the same as the one reported by Stephen in netdev [2]. When looking at the conflict, I noticed it is in fact the v1 [3] that has been applied in -net and the v2 [4] in net-next. Maybe the v1 was applied by accident. As mentioned by Jakub Kicinski [5], the new condition makes more sense before the net_ratelimit(), not to update net_ratelimit's state which is unnecessary if we're not going to print either way. Here, this modification applies the v2 but in -net. Link: https://github.com/multipath-tcp/mptcp_net-next/actions/runs/4423171069 [1] Link: https://lore.kernel.org/netdev/20230315100914.53fc1760@canb.auug.org.au/ [2] Link: https://lore.kernel.org/netdev/20230307133229.127442-1-koverskeid@gmail.com/ [3] Link: https://lore.kernel.org/netdev/20230309092302.179586-1-koverskeid@gmail.com/ [4] Link: https://lore.kernel.org/netdev/20230308232001.2fb62013@kernel.org/ [5] Fixes: 28e8cabe80f3 ("net: hsr: Don't log netdev_err message on unknown prp dst node") Signed-off-by: Matthieu Baerts Reviewed-by: Steen Hegelund Link: https://lore.kernel.org/r/20230315-net-20230315-hsr_framereg-ratelimit-v1-1-61d2ef176d11@tessares.net Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman

drm/amdkfd: Get prange->offset after svm_range_vram_node_new

2023-04-06T10:10:58Z

commit 8eeddc0d4200762063e1c66b9cc63afa7b24ebf0 upstream. During miration to vram prange->offset is valid after vram buffer is located, either use old one or allocate a new one. Move svm_range_vram_node_new before migrate for each vma to get valid prange->offset. v2: squash in warning fix Fixes: b4ee9606378b ("drm/amdkfd: Fix BO offset for multi-VMA page migration") Signed-off-by: Xiaogang Chen Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman

usb: ucsi: Fix ucsi->connector race

2023-04-06T10:10:58Z

commit 0482c34ec6f8557e06cd0f8e2d0e20e8ede6a22c upstream. ucsi_init() which runs from a workqueue sets ucsi->connector and on an error will clear it again. ucsi->connector gets dereferenced by ucsi_resume(), this checks for ucsi->connector being NULL in case ucsi_init() has not finished yet; or in case ucsi_init() has failed. ucsi_init() setting ucsi->connector and then clearing it again on an error creates a race where the check in ucsi_resume() may pass, only to have ucsi->connector free-ed underneath it when ucsi_init() hits an error. Fix this race by making ucsi_init() store the connector array in a local variable and only assign it to ucsi->connector on success. Fixes: bdc62f2bae8f ("usb: typec: ucsi: Simplified registration and I/O API") Cc: stable@vger.kernel.org Reviewed-by: Heikki Krogerus Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20230308154244.722337-3-hdegoede@redhat.com Signed-off-by: Joakim Tjernlund Signed-off-by: Greg Kroah-Hartman

libbpf: Fix btf_dump's packed struct determination

2023-04-06T10:10:58Z

[ Upstream commit 4fb877aaa179dcdb1676d55216482febaada457e ] Fix bug in btf_dump's logic of determining if a given struct type is packed or not. The notion of "natural alignment" is not needed and is even harmful in this case, so drop it altogether. The biggest difference in btf_is_struct_packed() compared to its original implementation is that we don't really use btf__align_of() to determine overall alignment of a struct type (because it could be 1 for both packed and non-packed struct, depending on specifci field definitions), and just use field's actual alignment to calculate whether any field is requiring packing or struct's size overall necessitates packing. Add two simple test cases that demonstrate the difference this change would make. Fixes: ea2ce1ba99aa ("libbpf: Fix BTF-to-C converter's padding logic") Reported-by: Eduard Zingerman Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Eduard Zingerman Link: https://lore.kernel.org/bpf/20221215183605.4149488-1-andrii@kernel.org Signed-off-by: Sasha Levin

selftests/bpf: Add few corner cases to test padding handling of btf_dump

2023-04-06T10:10:57Z

[ Upstream commit b148c8b9b926e257a59c8eb2cd6fa3adfd443254 ] Add few hand-crafted cases and few randomized cases found using script from [0] that tests btf_dump's padding logic. [0] https://lore.kernel.org/bpf/85f83c333f5355c8ac026f835b18d15060725fcb.camel@ericsson.com/ Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20221212211505.558851-7-andrii@kernel.org Stable-dep-of: 4fb877aaa179 ("libbpf: Fix btf_dump's packed struct determination") Signed-off-by: Sasha Levin

libbpf: Fix BTF-to-C converter's padding logic

2023-04-06T10:10:57Z

[ Upstream commit ea2ce1ba99aa6a60c8d8a706e3abadf3de372163 ] Turns out that btf_dump API doesn't handle a bunch of tricky corner cases, as reported by Per, and further discovered using his testing Python script ([0]). This patch revamps btf_dump's padding logic significantly, making it more correct and also avoiding unnecessary explicit padding, where compiler would pad naturally. This overall topic turned out to be very tricky and subtle, there are lots of subtle corner cases. The comments in the code tries to give some clues, but comments themselves are supposed to be paired with good understanding of C alignment and padding rules. Plus some experimentation to figure out subtle things like whether `long :0;` means that struct is now forced to be long-aligned (no, it's not, turns out). Anyways, Per's script, while not completely correct in some known situations, doesn't show any obvious cases where this logic breaks, so this is a nice improvement over the previous state of this logic. Some selftests had to be adjusted to accommodate better use of natural alignment rules, eliminating some unnecessary padding, or changing it to `type: 0;` alignment markers. Note also that for when we are in between bitfields, we emit explicit bit size, while otherwise we use `: 0`, this feels much more natural in practice. Next patch will add few more test cases, found through randomized Per's script. [0] https://lore.kernel.org/bpf/85f83c333f5355c8ac026f835b18d15060725fcb.camel@ericsson.com/ Reported-by: Per Sundström XP Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20221212211505.558851-6-andrii@kernel.org Signed-off-by: Sasha Levin

selftests/bpf: Test btf dump for struct with padding only fields

2023-04-06T10:10:57Z

[ Upstream commit d503f1176b14f722a40ea5110312614982f9a80b ] Structures with zero regular fields but some padding constitute a special case in btf_dump.c:btf_dump_emit_struct_def with regards to newline before closing '}'. Signed-off-by: Eduard Zingerman Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20221001104425.415768-2-eddyz87@gmail.com Stable-dep-of: ea2ce1ba99aa ("libbpf: Fix BTF-to-C converter's padding logic") Signed-off-by: Sasha Levin

user/sven/linux.git, branch v6.1.23

Linux 6.1.23

Revert "cpuidle, intel_idle: Fix CPUIDLE_FLAG_IRQ_ENABLE *again*"

x86/PVH: avoid 32-bit build warning when obtaining VGA console info

hsr: ratelimit only when errors are printed

drm/amdkfd: Get prange->offset after svm_range_vram_node_new

usb: ucsi: Fix ucsi->connector race

libbpf: Fix btf_dump's packed struct determination

selftests/bpf: Add few corner cases to test padding handling of btf_dump

libbpf: Fix BTF-to-C converter's padding logic

selftests/bpf: Test btf dump for struct with padding only fields

Revert "cpuidle, intel_idle: Fix CPUIDLE_FLAG_IRQ_ENABLE again"