- Linux-stable-mirror - lists.linaro.org

[PATCH net] virtio-net: zero unused hash fields

by Jason Wang

When GSO tunnel is negotiated virtio_net_hdr_tnl_from_skb() tries to initialize the tunnel metadata but forget to zero unused rxhash fields. This may leak information to another side. Fixing this by zeroing the unused hash fields. Fixes: a2fb4bc4e2a6a ("net: implement virtio helpers to handle UDP GSO tunneling")x Cc: <stable(a)vger.kernel.org> Signed-off-by: Jason Wang <jasowang(a)redhat.com> --- include/linux/virtio_net.h | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/include/linux/virtio_net.h b/include/linux/virtio_net.h index 20e0584db1dd..4d1780848d0e 100644 --- a/include/linux/virtio_net.h +++ b/include/linux/virtio_net.h @@ -401,6 +401,10 @@ virtio_net_hdr_tnl_from_skb(const struct sk_buff *skb, if (!tnl_hdr_negotiated) return -EINVAL; + vhdr->hash_hdr.hash_value = 0; + vhdr->hash_hdr.hash_report = 0; + vhdr->hash_hdr.padding = 0; + /* Let the basic parsing deal with plain GSO features. */ skb_shinfo(skb)->gso_type &= ~tnl_gso_type; ret = virtio_net_hdr_from_skb(skb, hdr, true, false, vlan_hlen); -- 2.42.0

1 month, 4 weeks

3
3
0 0

ORDER 8745631

by Diana Owen

Greetings, I hope this email finds you well. I am Mrs. Diana Owen contacting you from Reality Trading Group Ltd India. . As a new growing company, we are looking for reliable company of your product as seen in your website for urgent purchase order basis. Could you please give me more details and specification of your products. We also need your products catalog, MOQ, Production Lead Time and Unit price? Best Regards, Mrs. Diana Owen Purchase Manager Company: Reality Trading Group Ltd

1 month, 4 weeks

1
0
0 0

[PATCH] scsi: aacraid: Fix DMA mapping leak in aac_send_raw_srb error paths

by Yuhao Jiang

The aac_send_raw_srb function creates DMA mappings for scatter-gather buffers but fails to unmap them in most error paths, leading to DMA mapping resource leaks. This patch fixes all error paths except -ERESTARTSYS. The -ERESTARTSYS case is a known design issue where resources cannot be safely freed (hardware may still be accessing them) but also cannot be properly tracked for later cleanup (they are local variables). Fixed paths: - copy_from_user failures during SG buffer setup - aac_hba_send/aac_fib_send errors after DMA mapping - copy_to_user failures after successful command execution Fixes: 423400e64d377 ("scsi: aacraid: Include HBA direct interface") Cc: stable(a)vger.kernel.org Signed-off-by: Yuhao Jiang <danisjiang(a)gmail.com> --- drivers/scsi/aacraid/commctrl.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/drivers/scsi/aacraid/commctrl.c b/drivers/scsi/aacraid/commctrl.c index 68240d6f27ab..e0495f278e2e 100644 --- a/drivers/scsi/aacraid/commctrl.c +++ b/drivers/scsi/aacraid/commctrl.c @@ -493,6 +493,8 @@ static int aac_send_raw_srb(struct aac_dev* dev, void __user * arg) void __user *sg_user[HBA_MAX_SG_EMBEDDED]; void *sg_list[HBA_MAX_SG_EMBEDDED]; u32 sg_count[HBA_MAX_SG_EMBEDDED]; + dma_addr_t sg_dma_addr[HBA_MAX_SG_EMBEDDED]; + int sg_dma_last_mapped = -1; u32 sg_indx = 0; u32 byte_count = 0; u32 actual_fibsize64, actual_fibsize = 0; @@ -690,6 +692,8 @@ static int aac_send_raw_srb(struct aac_dev* dev, void __user * arg) } addr = dma_map_single(&dev->pdev->dev, p, sg_count[i], data_dir); + sg_dma_addr[i] = addr; + sg_dma_last_mapped = i; hbacmd->sge[i].addr_hi = cpu_to_le32((u32)(addr>>32)); hbacmd->sge[i].addr_lo = cpu_to_le32( (u32)(addr & 0xffffffff)); @@ -752,6 +756,8 @@ static int aac_send_raw_srb(struct aac_dev* dev, void __user * arg) } addr = dma_map_single(&dev->pdev->dev, p, sg_count[i], data_dir); + sg_dma_addr[i] = addr; + sg_dma_last_mapped = i; psg->sg[i].addr[0] = cpu_to_le32(addr & 0xffffffff); psg->sg[i].addr[1] = cpu_to_le32(addr>>32); @@ -808,6 +814,8 @@ static int aac_send_raw_srb(struct aac_dev* dev, void __user * arg) } addr = dma_map_single(&dev->pdev->dev, p, sg_count[i], data_dir); + sg_dma_addr[i] = addr; + sg_dma_last_mapped = i; psg->sg[i].addr[0] = cpu_to_le32(addr & 0xffffffff); psg->sg[i].addr[1] = cpu_to_le32(addr>>32); @@ -865,6 +873,8 @@ static int aac_send_raw_srb(struct aac_dev* dev, void __user * arg) addr = dma_map_single(&dev->pdev->dev, p, usg->sg[i].count, data_dir); + sg_dma_addr[i] = addr; + sg_dma_last_mapped = i; psg->sg[i].addr = cpu_to_le32(addr & 0xffffffff); byte_count += usg->sg[i].count; @@ -905,6 +915,8 @@ static int aac_send_raw_srb(struct aac_dev* dev, void __user * arg) } addr = dma_map_single(&dev->pdev->dev, p, sg_count[i], data_dir); + sg_dma_addr[i] = addr; + sg_dma_last_mapped = i; psg->sg[i].addr = cpu_to_le32(addr); byte_count += sg_count[i]; @@ -986,6 +998,10 @@ static int aac_send_raw_srb(struct aac_dev* dev, void __user * arg) cleanup: kfree(user_srbcmd); if (rcode != -ERESTARTSYS) { + for (i = 0; i <= sg_dma_last_mapped; i++) { + dma_unmap_single(&dev->pdev->dev, sg_dma_addr[i], + sg_count[i], data_dir); + } for (i = 0; i <= sg_indx; i++) kfree(sg_list[i]); aac_fib_complete(srbfib); -- 2.34.1

1 month, 4 weeks

1
0
0 0

[PATCH 6.1.y ] drm/amdgpu: Fix potential out-of-bounds access in 'amdgpu_discovery_reg_base_init()'

by Vasiliy Kovalev

From: Srinivasan Shanmugam <srinivasan.shanmugam(a)amd.com> commit cdb637d339572398821204a1142d8d615668f1e9 upstream. The issue arises when the array 'adev->vcn.vcn_config' is accessed before checking if the index 'adev->vcn.num_vcn_inst' is within the bounds of the array. The fix involves moving the bounds check before the array access. This ensures that 'adev->vcn.num_vcn_inst' is within the bounds of the array before it is used as an index. Fixes the below: drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c:1289 amdgpu_discovery_reg_base_init() error: testing array offset 'adev->vcn.num_vcn_inst' after use. Fixes: a0ccc717c4ab ("drm/amdgpu/discovery: validate VCN and SDMA instances") Cc: Christian König <christian.koenig(a)amd.com> Cc: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam(a)amd.com> Reviewed-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> [ kovalev: bp to fix CVE-2024-27042 ] Signed-off-by: Vasiliy Kovalev <kovalev(a)altlinux.org> --- drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c index d8441e273..8bc3a4bf3 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c @@ -1128,15 +1128,16 @@ static int amdgpu_discovery_reg_base_init(struct amdgpu_device *adev) * 0b10 : encode is disabled * 0b01 : decode is disabled */ - adev->vcn.vcn_config[adev->vcn.num_vcn_inst] = - ip->revision & 0xc0; - ip->revision &= ~0xc0; - if (adev->vcn.num_vcn_inst < AMDGPU_MAX_VCN_INSTANCES) + if (adev->vcn.num_vcn_inst < AMDGPU_MAX_VCN_INSTANCES) { + adev->vcn.vcn_config[adev->vcn.num_vcn_inst] = + ip->revision & 0xc0; adev->vcn.num_vcn_inst++; + } else dev_err(adev->dev, "Too many VCN instances: %d vs %d\n", adev->vcn.num_vcn_inst + 1, AMDGPU_MAX_VCN_INSTANCES); + ip->revision &= ~0xc0; } if (le16_to_cpu(ip->hw_id) == SDMA0_HWID || le16_to_cpu(ip->hw_id) == SDMA1_HWID || -- 2.50.1

1 month, 4 weeks

1
0
0 0

【年に一度】SBIポイントで豪華賞品を交換 — 在庫がなくなり次第終了No.86212

by SBI証券

平素よりSBI証券をご利用いただき、誠にありがとうございます。SBI証券では、日頃のご愛顧に感謝を込めて、年に一度だけの「ポイント交換キャンペーン」を開催しております。お客様の現在の保有ポイントは以下のとおりです。保有ポイント28,810ポイント本キャンペーンでは、貯まったポイントを豪華賞品と交換いただけます。交換は先着順で、在庫がなくなり次第終了となります。交換は以下のページからお手続きください。ポイント交換ページhttps://www.sbisec.co.jp/member/point/交換可能賞品の一例キャンペーン終了日：2025年10月22日・Apple iPad（第9世代 Wi-Fiモデル 64GB）【限定100台／残り15台】・Dyson コードレス掃除機【限定200台／残り90台】・Apple Watch SE（GPSモデル）・BALMUDA The Toaster（バルミューダトースター）・JCBギフトカード（5,000円分）・SBIオリジナル記念グッズ（非売品）この「年に一度の特別企画」は、例年多くのお客様にご参加いただいております。人気商品の在庫はすでに残りわずかです。ご注意・本キャンペーンは年に一度のみの開催です。・在庫がなくなり次第、予告なく終了いたします。・ポイント交換後の変更・キャンセルはお受けできません。一年に一度の特別なチャンスを、ぜひお見逃しなく。この機会にポイント交換をご利用ください。 SBI証券株式会社東京都港区六本木1-6-1 泉ガーデンタワーhttps://www.sbisec.co.jp/ © 2025 SBI SECURITIES Co., Ltd.

1 month, 4 weeks

1
0
0 0

FAILED: patch "[PATCH] fuse: fix livelock in synchronous file put from fuseblk" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-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-5.10.y git checkout FETCH_HEAD git cherry-pick -x 26e5c67deb2e1f42a951f022fdf5b9f7eb747b01 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025101630-unvaried-protector-cae4@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 26e5c67deb2e1f42a951f022fdf5b9f7eb747b01 Mon Sep 17 00:00:00 2001 From: "Darrick J. Wong" <djwong(a)kernel.org> Date: Mon, 15 Sep 2025 17:24:17 -0700 Subject: [PATCH] fuse: fix livelock in synchronous file put from fuseblk workers I observed a hang when running generic/323 against a fuseblk server. This test opens a file, initiates a lot of AIO writes to that file descriptor, and closes the file descriptor before the writes complete. Unsurprisingly, the AIO exerciser threads are mostly stuck waiting for responses from the fuseblk server: # cat /proc/372265/task/372313/stack [<0>] request_wait_answer+0x1fe/0x2a0 [fuse] [<0>] __fuse_simple_request+0xd3/0x2b0 [fuse] [<0>] fuse_do_getattr+0xfc/0x1f0 [fuse] [<0>] fuse_file_read_iter+0xbe/0x1c0 [fuse] [<0>] aio_read+0x130/0x1e0 [<0>] io_submit_one+0x542/0x860 [<0>] __x64_sys_io_submit+0x98/0x1a0 [<0>] do_syscall_64+0x37/0xf0 [<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53 But the /weird/ part is that the fuseblk server threads are waiting for responses from itself: # cat /proc/372210/task/372232/stack [<0>] request_wait_answer+0x1fe/0x2a0 [fuse] [<0>] __fuse_simple_request+0xd3/0x2b0 [fuse] [<0>] fuse_file_put+0x9a/0xd0 [fuse] [<0>] fuse_release+0x36/0x50 [fuse] [<0>] __fput+0xec/0x2b0 [<0>] task_work_run+0x55/0x90 [<0>] syscall_exit_to_user_mode+0xe9/0x100 [<0>] do_syscall_64+0x43/0xf0 [<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53 The fuseblk server is fuse2fs so there's nothing all that exciting in the server itself. So why is the fuse server calling fuse_file_put? The commit message for the fstest sheds some light on that: "By closing the file descriptor before calling io_destroy, you pretty much guarantee that the last put on the ioctx will be done in interrupt context (during I/O completion). Aha. AIO fgets a new struct file from the fd when it queues the ioctx. The completion of the FUSE_WRITE command from userspace causes the fuse server to call the AIO completion function. The completion puts the struct file, queuing a delayed fput to the fuse server task. When the fuse server task returns to userspace, it has to run the delayed fput, which in the case of a fuseblk server, it does synchronously. Sending the FUSE_RELEASE command sychronously from fuse server threads is a bad idea because a client program can initiate enough simultaneous AIOs such that all the fuse server threads end up in delayed_fput, and now there aren't any threads left to handle the queued fuse commands. Fix this by only using asynchronous fputs when closing files, and leave a comment explaining why. Cc: stable(a)vger.kernel.org # v2.6.38 Fixes: 5a18ec176c934c ("fuse: fix hang of single threaded fuseblk filesystem") Signed-off-by: Darrick J. Wong <djwong(a)kernel.org> Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com> diff --git a/fs/fuse/file.c b/fs/fuse/file.c index 54786f62a9d8..f1ef77a0be05 100644 --- a/fs/fuse/file.c +++ b/fs/fuse/file.c @@ -356,8 +356,14 @@ void fuse_file_release(struct inode *inode, struct fuse_file *ff, * Make the release synchronous if this is a fuseblk mount, * synchronous RELEASE is allowed (and desirable) in this case * because the server can be trusted not to screw up. + * + * Always use the asynchronous file put because the current thread + * might be the fuse server. This can happen if a process starts some + * aio and closes the fd before the aio completes. Since aio takes its + * own ref to the file, the IO completion has to drop the ref, which is + * how the fuse server can end up closing its clients' files. */ - fuse_file_put(ff, ff->fm->fc->destroy); + fuse_file_put(ff, false); } void fuse_release_common(struct file *file, bool isdir)

1 month, 4 weeks

2
1
0 0

[PATCH net 0/5] mptcp: handle late ADD_ADDR + selftests skip

by Matthieu Baerts (NGI0)

Here are a few independent fixes related to MPTCP and its selftests: - Patch 1: correctly handle ADD_ADDR being received after the switch to 'fully-established'. A fix for another recent fix backported up to v5.14. - Patches 2-5: properly mark some MPTCP Join subtests as 'skipped' if the tested kernel doesn't support the feature being validated. Some fixes for up to v5.13, v5.18, v6.11 and v6.18-rc1 respectively. Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> --- Matthieu Baerts (NGI0) (5): mptcp: pm: in-kernel: C-flag: handle late ADD_ADDR selftests: mptcp: join: mark 'flush re-add' as skipped if not supported selftests: mptcp: join: mark implicit tests as skipped if not supported selftests: mptcp: join: mark 'delete re-add signal' as skipped if not supported selftests: mptcp: join: mark laminar tests as skipped if not supported net/mptcp/pm_kernel.c | 6 ++++++ tools/testing/selftests/net/mptcp/mptcp_join.sh | 18 +++++++++--------- 2 files changed, 15 insertions(+), 9 deletions(-) --- base-commit: ffff5c8fc2af2218a3332b3d5b97654599d50cde change-id: 20251020-net-mptcp-c-flag-late-add-addr-1d954e7b63d2 Best regards, -- Matthieu Baerts (NGI0) <matttbe(a)kernel.org>

1 month, 4 weeks

2
5
0 0

[REGRESSION] Secureboot violation for linux enrolled by-hash into db v6.17.4 and v6.18-rc1

by Dimitri John Ledkov

If one enrolls linux kernel by-hash into db (for example using virt-fw-vars), the secureboot fails with security violation as EDK2 computation of authenticode for the linux binary doesn't match the enrolled hash. This is reproducible in AWS VMs, as well as locally with EDK2 builds with secureboot. Not affected v6.17 Not affected v6.17.3 Affected v6.17.4 Affected v6.18-rc1 Affected v6.18-rc2 Suspected patches are: $ git log --oneline v6.17.3..v6.17.4 -- scripts/ 8e5e13c8df9e6 kbuild: Add '.rel.*' strip pattern for vmlinux 7b80f81ae3190 kbuild: Restore pattern to avoid stripping .rela.dyn from vmlinux 5b5cdb1fe434e kbuild: keep .modinfo section in vmlinux.unstripped 86f364ee58420 kbuild: always create intermediate vmlinux.unstripped Reverting all of the above, makes secureboot with by-hash enrolled into db work again. I will try to bisect this further to determine the culprit. It feels like the strip potentially didn't update section offsets or their numbers or something like that. -- Regards, Dimitri.

1 month, 4 weeks

3
2
0 0

[merged mm-hotfixes-stable] mm-damon-core-use-damos_commit_quota_goal-for-new-goal-commit.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm/damon/core: use damos_commit_quota_goal() for new goal commit has been removed from the -mm tree. Its filename was mm-damon-core-use-damos_commit_quota_goal-for-new-goal-commit.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: SeongJae Park <sj(a)kernel.org> Subject: mm/damon/core: use damos_commit_quota_goal() for new goal commit Date: Mon, 13 Oct 2025 17:18:44 -0700 When damos_commit_quota_goals() is called for adding new DAMOS quota goals of DAMOS_QUOTA_USER_INPUT metric, current_value fields of the new goals should be also set as requested. However, damos_commit_quota_goals() is not updating the field for the case, since it is setting only metrics and target values using damos_new_quota_goal(), and metric-optional union fields using damos_commit_quota_goal_union(). As a result, users could see the first current_value parameter that committed online with a new quota goal is ignored. Users are assumed to commit the current_value for DAMOS_QUOTA_USER_INPUT quota goals, since it is being used as a feedback. Hence the real impact would be subtle. That said, this is obviously not intended behavior. Fix the issue by using damos_commit_quota_goal() which sets all quota goal parameters, instead of damos_commit_quota_goal_union(), which sets only the union fields. Link: https://lkml.kernel.org/r/20251014001846.279282-1-sj@kernel.org Fixes: 1aef9df0ee90 ("mm/damon/core: commit damos_quota_goal->nid") Signed-off-by: SeongJae Park <sj(a)kernel.org> Cc: <stable(a)vger.kernel.org> [6.16+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/damon/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/damon/core.c~mm-damon-core-use-damos_commit_quota_goal-for-new-goal-commit +++ a/mm/damon/core.c @@ -835,7 +835,7 @@ int damos_commit_quota_goals(struct damo src_goal->metric, src_goal->target_value); if (!new_goal) return -ENOMEM; - damos_commit_quota_goal_union(new_goal, src_goal); + damos_commit_quota_goal(new_goal, src_goal); damos_add_quota_goal(dst, new_goal); } return 0; _ Patches currently in -mm which might be from sj(a)kernel.org are mm-zswap-remove-unnecessary-dlen-writes-for-incompressible-pages.patch mm-zswap-fix-typos-s-zwap-zswap.patch mm-zswap-s-red-black-tree-xarray.patch docs-admin-guide-mm-zswap-s-red-black-tree-xarray.patch mm-damon-document-damos_quota_goal-nid-use-case.patch mm-damon-add-damos-quota-goal-type-for-per-memcg-per-node-memory-usage.patch mm-damon-core-implement-damos_quota_node_memcg_used_bp.patch mm-damon-sysfs-schemes-implement-path-file-under-quota-goal-directory.patch mm-damon-sysfs-schemes-support-damos_quota_node_memcg_used_bp.patch mm-damon-core-add-damos-quota-gaol-metric-for-per-memcg-per-numa-free-memory.patch mm-damon-sysfs-schemes-support-damos_quota_node_memcg_free_bp.patch docs-mm-damon-design-document-damos_quota_node_memcg_usedfree_bp.patch docs-admin-guide-mm-damon-usage-document-damos-quota-goal-path-file.patch docs-abi-damon-document-damos-quota-goal-path-file.patch

1 month, 4 weeks

1
0
0 0

[merged mm-hotfixes-stable] mm-damon-core-fix-potential-memory-leak-by-cleaning-ops_filter-in-damon_destroy_scheme.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm/damon/core: fix potential memory leak by cleaning ops_filter in damon_destroy_scheme has been removed from the -mm tree. Its filename was mm-damon-core-fix-potential-memory-leak-by-cleaning-ops_filter-in-damon_destroy_scheme.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Enze Li <lienze(a)kylinos.cn> Subject: mm/damon/core: fix potential memory leak by cleaning ops_filter in damon_destroy_scheme Date: Tue, 14 Oct 2025 16:42:25 +0800 Currently, damon_destroy_scheme() only cleans up the filter list but leaves ops_filter untouched, which could lead to memory leaks when a scheme is destroyed. This patch ensures both filter and ops_filter are properly freed in damon_destroy_scheme(), preventing potential memory leaks. Link: https://lkml.kernel.org/r/20251014084225.313313-1-lienze@kylinos.cn Fixes: ab82e57981d0 ("mm/damon/core: introduce damos->ops_filters") Signed-off-by: Enze Li <lienze(a)kylinos.cn> Reviewed-by: SeongJae Park <sj(a)kernel.org> Tested-by: SeongJae Park <sj(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/damon/core.c | 3 +++ 1 file changed, 3 insertions(+) --- a/mm/damon/core.c~mm-damon-core-fix-potential-memory-leak-by-cleaning-ops_filter-in-damon_destroy_scheme +++ a/mm/damon/core.c @@ -452,6 +452,9 @@ void damon_destroy_scheme(struct damos * damos_for_each_filter_safe(f, next, s) damos_destroy_filter(f); + damos_for_each_ops_filter_safe(f, next, s) + damos_destroy_filter(f); + kfree(s->migrate_dests.node_id_arr); kfree(s->migrate_dests.weight_arr); damon_del_scheme(s); _ Patches currently in -mm which might be from lienze(a)kylinos.cn are

1 month, 4 weeks

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror