May 2023 - Linux-stable-mirror

FAILED: patch "[PATCH] cxl/port: Enable the HDM decoder capability for switch ports" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x eb0764b822b9b26880b28ccb9100b2983e01bc17 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023052837-carve-antics-2e83@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: eb0764b822b9 ("cxl/port: Enable the HDM decoder capability for switch ports") 7bba261e0aa6 ("cxl/port: Scan single-target ports for decoders") a5fcd228ca1d ("Merge branch 'for-6.3/cxl-rr-emu' into cxl/next") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From eb0764b822b9b26880b28ccb9100b2983e01bc17 Mon Sep 17 00:00:00 2001 From: Dan Williams <dan.j.williams(a)intel.com> Date: Wed, 17 May 2023 20:19:43 -0700 Subject: [PATCH] cxl/port: Enable the HDM decoder capability for switch ports Derick noticed, when testing hot plug, that hot-add behaves nominally after a removal. However, if the hot-add is done without a prior removal, CXL.mem accesses fail. It turns out that the original implementation of the port driver and region programming wrongly assumed that platform-firmware always enables the host-bridge HDM decoder capability. Add support turning on switch-level HDM decoders in the case where platform-firmware has not. The implementation is careful to only arrange for the enable to be undone if the current instance of the driver was the one that did the enable. This is to interoperate with platform-firmware that may expect CXL.mem to remain active after the driver is shutdown. This comes at the cost of potentially not shutting down the enable on kexec flows, but it is mitigated by the fact that the related HDM decoders still need to be enabled on an individual basis. Cc: <stable(a)vger.kernel.org> Reported-by: Derick Marks <derick.w.marks(a)intel.com> Fixes: 54cdbf845cf7 ("cxl/port: Add a driver for 'struct cxl_port' objects") Reviewed-by: Ira Weiny <ira.weiny(a)intel.com> Link: https://lore.kernel.org/r/168437998331.403037.15719879757678389217.stgit@dw… Signed-off-by: Dan Williams <dan.j.williams(a)intel.com> diff --git a/drivers/cxl/core/pci.c b/drivers/cxl/core/pci.c index f332fe7af92b..c35c002b65dd 100644 --- a/drivers/cxl/core/pci.c +++ b/drivers/cxl/core/pci.c @@ -241,17 +241,36 @@ static void disable_hdm(void *_cxlhdm) hdm + CXL_HDM_DECODER_CTRL_OFFSET); } -static int devm_cxl_enable_hdm(struct device *host, struct cxl_hdm *cxlhdm) +int devm_cxl_enable_hdm(struct cxl_port *port, struct cxl_hdm *cxlhdm) { - void __iomem *hdm = cxlhdm->regs.hdm_decoder; + void __iomem *hdm; u32 global_ctrl; + /* + * If the hdm capability was not mapped there is nothing to enable and + * the caller is responsible for what happens next. For example, + * emulate a passthrough decoder. + */ + if (IS_ERR(cxlhdm)) + return 0; + + hdm = cxlhdm->regs.hdm_decoder; global_ctrl = readl(hdm + CXL_HDM_DECODER_CTRL_OFFSET); + + /* + * If the HDM decoder capability was enabled on entry, skip + * registering disable_hdm() since this decode capability may be + * owned by platform firmware. + */ + if (global_ctrl & CXL_HDM_DECODER_ENABLE) + return 0; + writel(global_ctrl | CXL_HDM_DECODER_ENABLE, hdm + CXL_HDM_DECODER_CTRL_OFFSET); - return devm_add_action_or_reset(host, disable_hdm, cxlhdm); + return devm_add_action_or_reset(&port->dev, disable_hdm, cxlhdm); } +EXPORT_SYMBOL_NS_GPL(devm_cxl_enable_hdm, CXL); int cxl_dvsec_rr_decode(struct device *dev, int d, struct cxl_endpoint_dvsec_info *info) @@ -425,7 +444,7 @@ int cxl_hdm_decode_init(struct cxl_dev_state *cxlds, struct cxl_hdm *cxlhdm, if (info->mem_enabled) return 0; - rc = devm_cxl_enable_hdm(&port->dev, cxlhdm); + rc = devm_cxl_enable_hdm(port, cxlhdm); if (rc) return rc; diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h index 044a92d9813e..f93a28538962 100644 --- a/drivers/cxl/cxl.h +++ b/drivers/cxl/cxl.h @@ -710,6 +710,7 @@ struct cxl_endpoint_dvsec_info { struct cxl_hdm; struct cxl_hdm *devm_cxl_setup_hdm(struct cxl_port *port, struct cxl_endpoint_dvsec_info *info); +int devm_cxl_enable_hdm(struct cxl_port *port, struct cxl_hdm *cxlhdm); int devm_cxl_enumerate_decoders(struct cxl_hdm *cxlhdm, struct cxl_endpoint_dvsec_info *info); int devm_cxl_add_passthrough_decoder(struct cxl_port *port); diff --git a/drivers/cxl/port.c b/drivers/cxl/port.c index eb57324c4ad4..17a95f469c26 100644 --- a/drivers/cxl/port.c +++ b/drivers/cxl/port.c @@ -60,13 +60,17 @@ static int discover_region(struct device *dev, void *root) static int cxl_switch_port_probe(struct cxl_port *port) { struct cxl_hdm *cxlhdm; - int rc; + int rc, nr_dports; - rc = devm_cxl_port_enumerate_dports(port); - if (rc < 0) - return rc; + nr_dports = devm_cxl_port_enumerate_dports(port); + if (nr_dports < 0) + return nr_dports; cxlhdm = devm_cxl_setup_hdm(port, NULL); + rc = devm_cxl_enable_hdm(port, cxlhdm); + if (rc) + return rc; + if (!IS_ERR(cxlhdm)) return devm_cxl_enumerate_decoders(cxlhdm, NULL); @@ -75,7 +79,7 @@ static int cxl_switch_port_probe(struct cxl_port *port) return PTR_ERR(cxlhdm); } - if (rc == 1) { + if (nr_dports == 1) { dev_dbg(&port->dev, "Fallback to passthrough decoder\n"); return devm_cxl_add_passthrough_decoder(port); } diff --git a/tools/testing/cxl/Kbuild b/tools/testing/cxl/Kbuild index fba7bec96acd..6f9347ade82c 100644 --- a/tools/testing/cxl/Kbuild +++ b/tools/testing/cxl/Kbuild @@ -6,6 +6,7 @@ ldflags-y += --wrap=acpi_pci_find_root ldflags-y += --wrap=nvdimm_bus_register ldflags-y += --wrap=devm_cxl_port_enumerate_dports ldflags-y += --wrap=devm_cxl_setup_hdm +ldflags-y += --wrap=devm_cxl_enable_hdm ldflags-y += --wrap=devm_cxl_add_passthrough_decoder ldflags-y += --wrap=devm_cxl_enumerate_decoders ldflags-y += --wrap=cxl_await_media_ready diff --git a/tools/testing/cxl/test/mock.c b/tools/testing/cxl/test/mock.c index de3933a776fd..284416527644 100644 --- a/tools/testing/cxl/test/mock.c +++ b/tools/testing/cxl/test/mock.c @@ -149,6 +149,21 @@ struct cxl_hdm *__wrap_devm_cxl_setup_hdm(struct cxl_port *port, } EXPORT_SYMBOL_NS_GPL(__wrap_devm_cxl_setup_hdm, CXL); +int __wrap_devm_cxl_enable_hdm(struct cxl_port *port, struct cxl_hdm *cxlhdm) +{ + int index, rc; + struct cxl_mock_ops *ops = get_cxl_mock_ops(&index); + + if (ops && ops->is_mock_port(port->uport)) + rc = 0; + else + rc = devm_cxl_enable_hdm(port, cxlhdm); + put_cxl_mock_ops(index); + + return rc; +} +EXPORT_SYMBOL_NS_GPL(__wrap_devm_cxl_enable_hdm, CXL); + int __wrap_devm_cxl_add_passthrough_decoder(struct cxl_port *port) { int rc, index;

1 year, 4 months

1
0
0 0

Re: mix of ACPICA regression and EFISTUB regression (Was: kernel >= v6.2 no longer boots on Apple's Virtualization.framework (x86_64); likely to be related to ACPICA)

by Akihiro Suda

[Resending as a plain text email] Turned out that this is a mixture of an ACPICA issue and an EFISTUB issue. Kernel v6.2 can boot by reverting the *both* of the following two commits: - 5c62d5aab8752e5ee7bfbe75ed6060db1c787f98 "ACPICA: Events: Support fixed PCIe wake event" - e346bebbd36b1576a3335331fed61bb48c6d8823 "efi: libstub: Always enable initrd command line loader and bump version" Kernel v6.3 can boot by just reverting e346bebb, as 5c62d5a has been already reverted in 8e41e0a575664d26bb87e012c39435c4c3914ed9. The situation is the same for v6.4-rc3 too. Note that in my test I let Virtualization.framework directly load bzImage without GRUB (akin to `qemu-system-x86_64 -kernel bzImage`). Apparently, reverting e346bebb is not necessary for loading bzImage via GRUB. > Also, the reporter can't provide dmesg log (forget to attach serial console?). Uploaded v6.1 dmesg in the bugzilla. v6.2 dmesg can't be provided, as it hangs before printing something in console=hvc0. (IIUC, console=ttyS0 (RS-232C) is not implemented in Virtualization.framework.) > 2023年5月25日(木) 21:46 Bagas Sanjaya <bagasdotme(a)gmail.com>: >> >> Hi, >> >> I notice a regression report on Bugzilla [1]. Quoting from it: >> >> > Linux kernel >= v6.2 no longer boots on Apple's Virtualization.framework (x86_64). >> > >> > It is reported that the issue is not reproducible on ARM64: https://github.com/lima-vm/lima/issues/1577#issuecomment-1561577694 >> > >> > >> > ## Reproduction >> > - Checkout the kernel repo, and run `make defconfig bzImage`. >> > >> > - Create an initrd (see the attached `initrd-example.txt`) >> > >> > - Transfer the bzImage and initrd to an Intel Mac. >> > >> > - On Mac, download `RunningLinuxInAVirtualMachine.zip` from https://developer.apple.com/documentation/virtualization/running_linux_in_a… , and build the `LinuxVirtualMachine` binary with Xcode. >> > Building this binary with Xcode requires logging in to Apple. >> > If you do not like logging in, a third party equivalent such as https://github.com/Code-Hex/vz/blob/v3.0.6/example/linux/main.go can be used. >> > >> > - Run `LinuxVirtualMachine /tmp/bzImage /tmp/initrd.img`. >> > v6.1 successfully boots into the busybox shell. >> > v6.2 just hangs before printing something in the console. >> > >> > >> > ## Tested versions >> > ``` >> > v6.1: OK >> > ... >> > v6.1.0-rc2-00002-g60f2096b59bc (included in v6.2-rc1): OK >> > v6.1.0-rc2-00003-g5c62d5aab875 (included in v6.2-rc1): NG <-- This commit caused a regression >> > ... >> > v6.2-rc1: NG >> > ... >> > v6.2: NG >> > ... >> > v6.3.0-rc7-00181-g8e41e0a57566 (included in v6.3): NG <-- Reverts 5c62d5aab875 but still NG >> > ... >> > v6.3: NG >> > v6.4-rc3: NG >> > ``` >> > >> > Tested on MacBookPro 2020 (Intel(R) Core(TM) i7-1068NG7 CPU @ 2.30GHz) running macOS 13.4. >> > >> > >> > The issue seems a regression in [5c62d5aab8752e5ee7bfbe75ed6060db1c787f98](https://git.kernel.org/pub/scm/li… "ACPICA: Events: Support fixed PCIe wake event". >> > >> > This commit was introduced in v6.2-rc1, and apparently reverted in v6.3 ([8e41e0a575664d26bb87e012c39435c4c3914ed9](https://git.kernel.org/pub/scm/li…). >> > However, v6.3 and the latest v6.4-rc3 still don't boot. >> >> See bugzilla for the full thread. >> >> Interestingly, this regression still occurs despite the culprit is >> reverted in 8e41e0a575664d ("Revert "ACPICA: Events: Support fixed >> PCIe wake event""), so this (obviously) isn't wake-on-lan regression, >> but rather early boot one. >> >> Also, the reporter can't provide dmesg log (forget to attach serial >> console?). >> >> Anyway, I'm adding it to regzbot: >> >> #regzbot introduced: 5c62d5aab8752e https://bugzilla.kernel.org/show_bug.cgi?id=217485 >> #regzbot title: Linux v6.2+ (x86_64) no longer boots on Apple's Virtualization framework (ACPICA issue) >> >> Thanks. >> >> [1]: https://bugzilla.kernel.org/show_bug.cgi?id=217485 >> >> -- >> An old man doll... just what I always wanted! - Clara

1 year, 4 months

3
6
0 0

[PATCH, STABLE 6.3.x] xfs: fix livelock in delayed allocation at ENOSPC

by Dave Chinner

Hi Greg, A regression in 6.3.0 has been identified in XFS that causes filesystem corruption. It has been seen in the wild by a number of users, and bisected down to an issued we'd already fixed in 6.4-rc1 with commit: 9419092fb263 ("xfs: fix livelock in delayed allocation at ENOSPC") This was reported with much less harmful symptoms (alloctor livelock) and it wasn't realised that it could have other, more impactful symptoms. A reproducer for the corruption was found yesterday and, soon after than, the cause of the corruption reports was identified. The commit applies cleanly to a 6.3.0 kernel here, so it should also apply cleanly to a current 6.3.x kernel. I've included the entire commit below in case that's easier for you. Can you please pull this commit into the next 6.3.x release as a matter of priority? Cheers, Dave. -- Dave Chinner david(a)fromorbit.com xfs: fix livelock in delayed allocation at ENOSPC From: Dave Chinner <dchinner(a)redhat.com> On a filesystem with a non-zero stripe unit and a large sequential write, delayed allocation will set a minimum allocation length of the stripe unit. If allocation fails because there are no extents long enough for an aligned minlen allocation, it is supposed to fall back to unaligned allocation which allows single block extents to be allocated. When the allocator code was rewritting in the 6.3 cycle, this fallback was broken - the old code used args->fsbno as the both the allocation target and the allocation result, the new code passes the target as a separate parameter. The conversion didn't handle the aligned->unaligned fallback path correctly - it reset args->fsbno to the target fsbno on failure which broke allocation failure detection in the high level code and so it never fell back to unaligned allocations. This resulted in a loop in writeback trying to allocate an aligned block, getting a false positive success, trying to insert the result in the BMBT. This did nothing because the extent already was in the BMBT (merge results in an unchanged extent) and so it returned the prior extent to the conversion code as the current iomap. Because the iomap returned didn't cover the offset we tried to map, xfs_convert_blocks() then retries the allocation, which fails in the same way and now we have a livelock. Reported-and-tested-by: Brian Foster <bfoster(a)redhat.com> Fixes: 85843327094f ("xfs: factor xfs_bmap_btalloc()") Signed-off-by: Dave Chinner <dchinner(a)redhat.com> Reviewed-by: Darrick J. Wong <djwong(a)kernel.org> --- diff --git a/fs/xfs/libxfs/xfs_bmap.c b/fs/xfs/libxfs/xfs_bmap.c index 1a4e446194dd..b512de0540d5 100644 --- a/fs/xfs/libxfs/xfs_bmap.c +++ b/fs/xfs/libxfs/xfs_bmap.c @@ -3540,7 +3540,6 @@ xfs_bmap_btalloc_at_eof( * original non-aligned state so the caller can proceed on allocation * failure as if this function was never called. */ - args->fsbno = ap->blkno; args->alignment = 1; return 0; }

1 year, 4 months

3
2
0 0

REPLY BACK FOR DETAILS

by Ms Nadage Lassou

Greetings. I am Ms Nadage Lassou,I have something important to discuss with you. i will send you the details once i hear from you. Thanks, Ms Nadage Lassou

1 year, 4 months

1
0
0 0

selftests: net: udpgso_bench.sh: RIP: 0010:lookup_reuseport

by Naresh Kamboju

While running selftests: net: udpgso_bench.sh on qemu-x86_64 the following kernel crash noticed on stable rc 6.3.4-rc2 kernel. Reported-by: Linux Kernel Functional Testing <lkft(a)linaro.org> Test run log: ========= <12>[ 38.049122] kselftest: Running tests in net TAP version 13 1..16 # selftests: net: udpgso_bench.sh # ipv4 # tcp # tcp tx: 230 MB/s 3905 calls/s 3905 msg/s # tcp rx: 231 MB/s 3668 calls/s # tcp tx: 225 MB/s 3817 calls/s 3817 msg/s # tcp rx: 225 MB/s 3525 calls/s # tcp tx: 225 MB/s 3820 calls/s 3820 msg/s # tcp zerocopy # tcp tx: 198 MB/s 3369 calls/s 3369 msg/s # tcp rx: 197 MB/s 2855 calls/s # tcp tx: 195 MB/s 3318 calls/s 3318 msg/s # tcp rx: 197 MB/s 2845 calls/s # udp # udp rx: 8 MB/s 5811 calls/s # udp tx: 11 MB/s 7938 calls/s 189 msg/s # udp rx: 10 MB/s 7523 calls/s # udp tx: 10 MB/s 7308 calls/s 174 msg/s # udp rx: 10 MB/s 7338 calls/s # udp gso # udp rx: 19 MB/s 14080 calls/s # udp tx: 118 MB/s 2012 calls/s 2012 msg/s # udp rx: 26 MB/s 18688 calls/s # udp tx: 117 MB/s 2000 calls/s 2000 msg/s # udp rx: 26 MB/s 18688 calls/s # udp tx: 118 MB/s 2008 calls/s 2008 msg/s # udp gso zerocopy # udp rx: 19 MB/s 13824 calls/s # udp tx: 102 MB/s 1736 calls/s 1736 msg/s # udp rx: 25 MB/s 18176 calls/s # udp tx: 101 MB/s 1714 calls/s 1714 msg/s # udp rx: 25 MB/s 18176 calls/s # udp tx: 98 MB/s 1679 calls/s 1679 msg/s # udp gso timestamp # udp rx: 19 MB/s 13824 calls/s # udp tx: 94 MB/s 1606 calls/s 1606 msg/s # udp rx: 25 MB/s 18432 calls/s # udp tx: 92 MB/s 1574 calls/s 1574 msg/s # udp rx: 27 MB/s 19309 calls/s # udp tx: 88 MB/s 1502 calls/s 1502 msg/s # udp gso zerocopy audit # udp rx: 19 MB/s 14080 calls/s # udp tx: 101 MB/s 1728 calls/s 1728 msg/s # udp rx: 25 MB/s 18432 calls/s # udp tx: 100 MB/s 1699 calls/s 1699 msg/s # udp rx: 26 MB/s 18688 calls/s # udp tx: 101 MB/s 1724 calls/s 1724 msg/s # Summary over 3.000 seconds... # sum udp tx: 103 MB/s 5151 calls (1717/s) 5151 msgs (1717/s) # Zerocopy acks: 5151 # udp gso timestamp audit # udp rx: 19 MB/s 13843 calls/s # udp tx: 92 MB/s 1571 calls/s 1571 msg/s # udp rx: 26 MB/s 18568 calls/s # udp tx: 95 MB/s 1614 calls/s 1614 msg/s # udp rx: 26 MB/s 19200 calls/s # udp tx: 93 MB/s 1589 calls/s 1589 msg/s # Summary over 3.000 seconds... # sum udp tx: 96 MB/s 4774 calls (1591/s) 4774 msgs (1591/s) # Tx Timestamps: 4774 received 0 errors # udp gso zerocopy timestamp audit # udp rx: 18 MB/s 13312 calls/s # udp tx: 76 MB/s 1297 calls/s 1297 msg/s # udp rx: 26 MB/s 18524 calls/s # udp tx: 74 MB/s 1269 calls/s 1269 msg/s # udp rx: 25 MB/s 18176 calls/s # udp tx: 75 MB/s 1289 calls/s 1289 msg/s # Summary over 3.000 seconds... # sum udp tx: 77 MB/s 3855 calls (1285/s) 3855 msgs (1285/s) # Tx Timestamps: 3855 received 0 errors # Zerocopy acks: 3855 # ipv6 # tcp # tcp tx: 215 MB/s 3657 calls/s 3657 msg/s # tcp rx: 216 MB/s 3431 calls/s # tcp tx: 211 MB/s 3590 calls/s 3590 msg/s # tcp rx: 211 MB/s 3319 calls/s # tcp tx: 211 MB/s 3579 calls/s 3579 msg/s # tcp zerocopy # tcp tx: 191 MB/s 3245 calls/s 3245 msg/s # tcp rx: 193 MB/s 2908 calls/s # tcp tx: 184 MB/s 3135 calls/s 3135 msg/s # tcp rx: 185 MB/s 2830 calls/s # tcp tx: 191 MB/s 3254 calls/s 3254 msg/s # udp <4>[ 88.821235] int3: 0000 [#1] PREEMPT SMP PTI <4>[ 88.821491] CPU: 1 PID: 561 Comm: udpgso_bench_tx Not tainted 6.3.4-rc2 #1 <4>[ 88.821576] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 <4>[ 88.821685] RIP: 0010:lookup_reuseport+0x4a/0x200 <4>[ 88.822122] Code: 74 0b 49 89 f6 0f b6 46 12 3c 01 75 07 31 c0 e9 ed 00 00 00 4d 89 cf 44 89 c5 49 89 cd 49 89 fc 0f 1f 44 00 00 8b 5c 24 50 0f <1f> 44 00 00 41 8b 45 04 41 33 45 00 8b 0d b0 c5 ed 00 44 8d 04 08 <4>[ 88.822175] RSP: 0018:ffffa95c800c0b90 EFLAGS: 00000206 <4>[ 88.822215] RAX: 0000000000000007 RBX: 0000000000001f40 RCX: ffff966c02b66020 <4>[ 88.822228] RDX: ffff966c01a9aa00 RSI: ffff966c02801500 RDI: ffff966c03ae2e80 <4>[ 88.822241] RBP: 00000000000093bf R08: 00000000000093bf R09: ffffffffb0b2c8a0 <4>[ 88.822254] R10: 0000000042388386 R11: 00000000000093bf R12: ffff966c03ae2e80 <4>[ 88.822266] R13: ffff966c02b66020 R14: ffff966c02801500 R15: ffffffffb0b2c8a0 <4>[ 88.822312] FS: 00007f4e6ede4740(0000) GS:ffff966c7bd00000(0000) knlGS:0000000000000000 <4>[ 88.822330] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4>[ 88.822343] CR2: 000055a1c0b90bf0 CR3: 0000000103b0e000 CR4: 00000000000006e0 <4>[ 88.822438] Call Trace: <4>[ 88.823080] <IRQ> <4>[ 88.823274] udp6_lib_lookup2+0xf8/0x1c0 <4>[ 88.823368] __udp6_lib_lookup+0x113/0x3c0 <4>[ 88.823382] ? __wake_up_common_lock+0x79/0x190 <4>[ 88.823403] __udp6_lib_lookup_skb+0x76/0x90 <4>[ 88.823426] __udp6_lib_rcv+0x295/0x400 <4>[ 88.823440] ip6_protocol_deliver_rcu+0x34e/0x5c0 <4>[ 88.823483] ip6_input+0x60/0x110 <4>[ 88.823496] ? ip6_rcv_core+0x311/0x450 <4>[ 88.823509] ipv6_rcv+0x47/0xf0 <4>[ 88.823523] __netif_receive_skb+0x65/0x170 <4>[ 88.823539] process_backlog+0xd7/0x180 <4>[ 88.823553] __napi_poll+0x2c/0x1b0 <4>[ 88.823565] net_rx_action+0x178/0x2e0 <4>[ 88.823580] __do_softirq+0xc4/0x274 <4>[ 88.823595] do_softirq+0x7e/0xb0 <4>[ 88.823751] </IRQ> <4>[ 88.823769] <TASK> <4>[ 88.823773] __local_bh_enable_ip+0x6e/0x70 <4>[ 88.823786] ip6_finish_output2+0x3fc/0x560 <4>[ 88.823803] ip6_finish_output+0x1ab/0x320 <4>[ 88.823816] ip6_output+0x6b/0x130 <4>[ 88.823827] ? __pfx_ip6_finish_output+0x10/0x10 <4>[ 88.823839] ip6_send_skb+0x1e/0x80 <4>[ 88.823850] udp_v6_send_skb+0x26e/0x400 <4>[ 88.823865] udpv6_sendmsg+0xb33/0xc60 <4>[ 88.823879] ? __pfx_ip_generic_getfrag+0x10/0x10 <4>[ 88.823902] sock_sendmsg+0x42/0xa0 <4>[ 88.823915] __sys_sendto+0x281/0x2f0 <4>[ 88.823938] __x64_sys_sendto+0x21/0x30 <4>[ 88.823949] do_syscall_64+0x48/0xa0 <4>[ 88.823969] ? exit_to_user_mode_prepare+0x2a/0x80 <4>[ 88.823981] entry_SYSCALL_64_after_hwframe+0x72/0xdc <4>[ 88.824104] RIP: 0033:0x7f4e6eef1973 <4>[ 88.824267] Code: 8b 15 91 74 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 80 3d 71 fc 0c 00 00 41 89 ca 74 14 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 75 c3 0f 1f 40 00 55 48 83 ec 30 44 89 4c 24 <4>[ 88.824276] RSP: 002b:00007ffc3a3d79f8 EFLAGS: 00000202 ORIG_RAX: 000000000000002c <4>[ 88.824293] RAX: ffffffffffffffda RBX: 00005596927cf110 RCX: 00007f4e6eef1973 <4>[ 88.824298] RDX: 00000000000005ac RSI: 00005596927cf110 RDI: 0000000000000005 <4>[ 88.824304] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 <4>[ 88.824309] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000002 <4>[ 88.824313] R13: 0000000000000005 R14: 000000000000e628 R15: 00000000000005ac <4>[ 88.824335] </TASK> <4>[ 88.824377] Modules linked in: mptcp_diag tcp_diag inet_diag ip_tables x_tables <4>[ 88.845108] ---[ end trace 0000000000000000 ]--- <4>[ 88.845178] RIP: 0010:lookup_reuseport+0x4a/0x200 <4>[ 88.845216] Code: 74 0b 49 89 f6 0f b6 46 12 3c 01 75 07 31 c0 e9 ed 00 00 00 4d 89 cf 44 89 c5 49 89 cd 49 89 fc 0f 1f 44 00 00 8b 5c 24 50 0f <1f> 44 00 00 41 8b 45 04 41 33 45 00 8b 0d b0 c5 ed 00 44 8d 04 08 <4>[ 88.845232] RSP: 0018:ffffa95c800c0b90 EFLAGS: 00000206 <4>[ 88.845249] RAX: 0000000000000007 RBX: 0000000000001f40 RCX: ffff966c02b66020 <4>[ 88.845257] RDX: ffff966c01a9aa00 RSI: ffff966c02801500 RDI: ffff966c03ae2e80 <4>[ 88.845266] RBP: 00000000000093bf R08: 00000000000093bf R09: ffffffffb0b2c8a0 <4>[ 88.845273] R10: 0000000042388386 R11: 00000000000093bf R12: ffff966c03ae2e80 <4>[ 88.845281] R13: ffff966c02b66020 R14: ffff966c02801500 R15: ffffffffb0b2c8a0 <4>[ 88.845290] FS: 00007f4e6ede4740(0000) GS:ffff966c7bd00000(0000) knlGS:0000000000000000 <4>[ 88.845302] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4>[ 88.845311] CR2: 000055a1c0b90bf0 CR3: 0000000103b0e000 CR4: 00000000000006e0 <0>[ 88.845862] Kernel panic - not syncing: Fatal exception in interrupt <0>[ 88.848258] Kernel Offset: 0x2e800000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) log: ==== - https://tuxapi.tuxsuite.com/v1/groups/linaro/projects/lkft/tests/2QCexh5uf8… - https://storage.tuxsuite.com/public/linaro/lkft/builds/2QCeuW0pJ8XVzYeG3rpg… - https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.3.y/build/v6.3.3… -- Linaro LKFT https://lkft.linaro.org

1 year, 4 months

4
5
0 0

Money Available For Pick Up,

by Western Union Money Transfer

Western Union Money Transfer Republic of Burkina Faso Address: CG46+G6G, Somgandé, Ouagadougou, Burkina Faso website: www.westernunion.com Money Available For Pick Up, Western Union Money Transfer in conjunction with the United Nation during their recently concluded meeting with the International Monetary Fund (IMF) Payment Reconciliation Board Committee agreed to pay you a total amount of ($350.000.00) Three Hundred and Fifty Thousand US Dollars Only compensation fund. The awarded compensation amount has been signed under giving credence ensuring your payment transaction is devoid of any form of illegality to be paid to you for the money you lost to scammers through internet frauds. Your name appeared on our payment schedule list 2023 of beneficiaries that will receive their funds in this 2nd Quarter Payment of the year 2023. The sum of $5,000.00 daily sending or its equivalent in your local currency will be transferred to you via Western Union every day until all the ($350.000.00) Three Hundred and Fifty Thousand US Dollars Only is completely sent across to you. Meanwhile, we have registered your First Payment Transfer Sum $5.000 USD online through Western Union Money Transfer. For you to confirm your First Payment Transfer please follow the instructions. Open this website: www.westernunion.com, then click "Track Transfer", then enter this Tracking Number (MTCN) 9361788041 and click "Track Transfer" to confirm you will see the status of the transaction online. Below are the details you need to present to the Western Union officials. Also go with your ID Card. MTCN: 9361788041 Sender Names: Prince Maxwell Okoronkwo Sender City: Ouagadougou Sender Country: Burkina Faso Amount sent: $5.000 Dollars Money Transfer | Global Money Transfer | Western Union Go to any Western Union Office in your area and pick it up. Make sure you go with an Identification of yourself like a Driving License or National ID or International Passport. Sincerely, Ms Omarh Waleed. Send Money Worldwide Registered C 2007 - 2023 Western Union Money Transfer. All Right Reserved. This email is intended for the named recipient only and may contain privileged and confidential information. If you have received this email in error, please notify us immediately. Please do not disclose the contents to anyone or copy it to outside parties. Our website: http. westernunion.com. Message from Western Union Aspect of your payment Burkina Faso

1 year, 4 months

1
0
0 0

[net PATCH] wireguard: allowedips: fix compilation warning for stack limit exceeded

by Christian Marangi

On some arch (for example IPQ8074) and other with KERNEL_STACKPROTECTOR_STRONG enabled, the following compilation error is triggered: drivers/net/wireguard/allowedips.c: In function 'root_remove_peer_lists': drivers/net/wireguard/allowedips.c:80:1: error: the frame size of 1040 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] 80 | } | ^ drivers/net/wireguard/allowedips.c: In function 'root_free_rcu': drivers/net/wireguard/allowedips.c:67:1: error: the frame size of 1040 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] 67 | } | ^ cc1: all warnings being treated as errors Since these are free function and returns void, using function that can fail is not ideal since an error would result in data not freed. Since the free are under RCU lock, we can allocate the required stack array as static outside the function and memset when needed. This effectively fix the stack frame warning without changing how the function work. Fixes: Fixes: e7096c131e51 ("net: WireGuard secure network tunnel") Signed-off-by: Christian Marangi <ansuelsmth(a)gmail.com> Cc: stable(a)vger.kernel.org --- drivers/net/wireguard/allowedips.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/drivers/net/wireguard/allowedips.c b/drivers/net/wireguard/allowedips.c index 5bf7822c53f1..c129082f04c6 100644 --- a/drivers/net/wireguard/allowedips.c +++ b/drivers/net/wireguard/allowedips.c @@ -53,12 +53,16 @@ static void node_free_rcu(struct rcu_head *rcu) kmem_cache_free(node_cache, container_of(rcu, struct allowedips_node, rcu)); } +static struct allowedips_node *tmpstack[MAX_ALLOWEDIPS_BITS]; + static void root_free_rcu(struct rcu_head *rcu) { - struct allowedips_node *node, *stack[MAX_ALLOWEDIPS_BITS] = { - container_of(rcu, struct allowedips_node, rcu) }; + struct allowedips_node *node, **stack = tmpstack; unsigned int len = 1; + memset(stack, 0, sizeof(*stack) * MAX_ALLOWEDIPS_BITS); + stack[0] = container_of(rcu, struct allowedips_node, rcu); + while (len > 0 && (node = stack[--len])) { push_rcu(stack, node->bit[0], &len); push_rcu(stack, node->bit[1], &len); @@ -68,9 +72,12 @@ static void root_free_rcu(struct rcu_head *rcu) static void root_remove_peer_lists(struct allowedips_node *root) { - struct allowedips_node *node, *stack[MAX_ALLOWEDIPS_BITS] = { root }; + struct allowedips_node *node, **stack = tmpstack; unsigned int len = 1; + memset(stack, 0, sizeof(*stack) * MAX_ALLOWEDIPS_BITS); + stack[0] = root; + while (len > 0 && (node = stack[--len])) { push_rcu(stack, node->bit[0], &len); push_rcu(stack, node->bit[1], &len); -- 2.39.2

1 year, 4 months

2
2
0 0

enquiry

by Lc

Hello dear Do you have the passion for humanitarian welfare? Can you devote your time and be totally committed and devoted to run multi-million pounds humanitarian charity project sponsored totally by me; with an incentive/compensation accrual to you for your time and effort and at no cost to you. If interested, reply me for the full details Thanks & regards Les Scadding. � �� ! �� -�� "��" ��.: +7 (48444) 6-91-69 ��. 495 e-mail: info(a)ludinovocable.ru ��

1 year, 4 months

1
0
0 0

[PATCH] soc: qcom: mdt_loader: Fix unconditional call to scm_pas_mem_setup

by Christian Marangi

Commit ebeb20a9cd3f ("soc: qcom: mdt_loader: Always invoke PAS mem_setup") dropped the relocate check and made pas_mem_setup run unconditionally. The code was later moved with commit f4e526ff7e38 ("soc: qcom: mdt_loader: Extract PAS operations") to qcom_mdt_pas_init() effectively losing track of what was actually done. The assumption that PAS mem_setup can be done anytime was effectively wrong, with no good reason and this caused regression on some SoC that use remoteproc to bringup ath11k. One example is IPQ8074 SoC that effectively broke resulting in remoteproc silently die and ath11k not working. On this SoC FW relocate is not enabled and PAS mem_setup was correctly skipped in previous kernel version resulting in correct bringup and function of remoteproc and ath11k. To fix the regression, reintroduce the relocate check in qcom_mdt_pas_init() and correctly skip PAS mem_setup where relocate is not enabled. Fixes: ebeb20a9cd3f ("soc: qcom: mdt_loader: Always invoke PAS mem_setup") Tested-by: Robert Marko <robimarko(a)gmail.com> Co-developed-by: Robert Marko <robimarko(a)gmail.com> Signed-off-by: Robert Marko <robimarko(a)gmail.com> Signed-off-by: Christian Marangi <ansuelsmth(a)gmail.com> Cc: stable(a)vger.kernel.org --- drivers/soc/qcom/mdt_loader.c | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/drivers/soc/qcom/mdt_loader.c b/drivers/soc/qcom/mdt_loader.c index 33dd8c315eb7..46820bcdae98 100644 --- a/drivers/soc/qcom/mdt_loader.c +++ b/drivers/soc/qcom/mdt_loader.c @@ -210,6 +210,7 @@ int qcom_mdt_pas_init(struct device *dev, const struct firmware *fw, const struct elf32_hdr *ehdr; phys_addr_t min_addr = PHYS_ADDR_MAX; phys_addr_t max_addr = 0; + bool relocate = false; size_t metadata_len; void *metadata; int ret; @@ -224,6 +225,9 @@ int qcom_mdt_pas_init(struct device *dev, const struct firmware *fw, if (!mdt_phdr_valid(phdr)) continue; + if (phdr->p_flags & QCOM_MDT_RELOCATABLE) + relocate = true; + if (phdr->p_paddr < min_addr) min_addr = phdr->p_paddr; @@ -246,11 +250,13 @@ int qcom_mdt_pas_init(struct device *dev, const struct firmware *fw, goto out; } - ret = qcom_scm_pas_mem_setup(pas_id, mem_phys, max_addr - min_addr); - if (ret) { - /* Unable to set up relocation */ - dev_err(dev, "error %d setting up firmware %s\n", ret, fw_name); - goto out; + if (relocate) { + ret = qcom_scm_pas_mem_setup(pas_id, mem_phys, max_addr - min_addr); + if (ret) { + /* Unable to set up relocation */ + dev_err(dev, "error %d setting up firmware %s\n", ret, fw_name); + goto out; + } } out: -- 2.39.2

1 year, 4 months

3
2
0 0

[PATCH v2] mm/damon/core: fix divide error in damon_nr_accesses_to_accesses_bp()

by Kefeng Wang

If 'aggr_interval' is smaller than 'sample_interval', max_nr_accesses in damon_nr_accesses_to_accesses_bp() becomes zero which leads to divide error, let's validate the values of them in damon_set_attrs() to fix it, which similar to others attrs check. Reported-by: syzbot+841a46899768ec7bec67(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=841a46899768ec7bec67 Link: https://lore.kernel.org/damon/00000000000055fc4e05fc975bc2@google.com/ Fixes: 2f5bef5a590b ("mm/damon/core: update monitoring results for new monitoring attributes") Cc: <stable(a)vger.kernel.org> # 6.3.x- Reviewed-by: SeongJae Park <sj(a)kernel.org> Signed-off-by: Kefeng Wang <wangkefeng.wang(a)huawei.com> --- v2: close checkpatch warning, add RB/cc stable, per SJ mm/damon/core.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/mm/damon/core.c b/mm/damon/core.c index d9ef62047bf5..91cff7f2997e 100644 --- a/mm/damon/core.c +++ b/mm/damon/core.c @@ -551,6 +551,8 @@ int damon_set_attrs(struct damon_ctx *ctx, struct damon_attrs *attrs) return -EINVAL; if (attrs->min_nr_regions > attrs->max_nr_regions) return -EINVAL; + if (attrs->sample_interval > attrs->aggr_interval) + return -EINVAL; damon_update_monitoring_results(ctx, attrs); ctx->attrs = *attrs; -- 2.35.3

1 year, 4 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror May 2023