MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/7569
JIRA: INTERNAL
Upstream Status: RHEL only
We no longer need to run automotive pipelines in c9s but instead of
removing them we'll mark them disabled for now.
Signed-off-by: Scott Weaver <scweaver@redhat.com>
Approved-by: Tales da Aparecida <tales.aparecida@redhat.com>
Approved-by: Jarod Wilson <jarod@redhat.com>
Approved-by: CKI KWF Bot <cki-ci-bot+kwf-gitlab-com@redhat.com>
Merged-by: CKI GitLab Kmaint Pipeline Bot <26919896-cki-kmaint-pipeline-bot@users.noreply.gitlab.com>
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/7553
JIRA: INTERNAL
Upstream Status: RHEL only
Sometimes we run into situation where people forget to set proper
localversion during official builds and end up with .test in NVR.
Introduce a new variable to Makefile.variables, which will be persisted
in source-git as well (contrast to localversion) and take priority when
used for dist-rtg targets. The scenarios where we need custom localversion
for official build should be very rare, meaning that the maintainer doesn't
need to touch this variable and default (empty localversion) will be used
instead of whatever may be left in 'localversion' (or DISTLOCALVERSION).
Signed-off-by: Jan Stancek <jstancek@redhat.com>
Approved-by: Scott Weaver <scweaver@redhat.com>
Approved-by: Patrick Talbert <ptalbert@redhat.com>
Approved-by: CKI KWF Bot <cki-ci-bot+kwf-gitlab-com@redhat.com>
Merged-by: CKI GitLab Kmaint Pipeline Bot <26919896-cki-kmaint-pipeline-bot@users.noreply.gitlab.com>
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/7552
JIRA: INTERNAL
Upstream Status: RHEL only (ARK commit 31028fbea1a742c36d19053ade720ea44316ccce)
commit 31028fbea1a742c36d19053ade720ea44316ccce
Author: Jan Stancek <jstancek@redhat.com>
Date: Thu Oct 30 07:47:25 2025 +0100
redhat: remove EARLY ystream bits
This was used in downstream RHEL to avoid NVR collisions between stream
that is about to GA and next one (which overlap for ~6 weeks). While
back we started using ZSTREAM numbering early and hence this option
is no longer used. Remove all related bits.
Signed-off-by: Jan Stancek <jstancek@redhat.com>
Signed-off-by: Jan Stancek <jstancek@redhat.com>
Approved-by: Scott Weaver <scweaver@redhat.com>
Approved-by: Patrick Talbert <ptalbert@redhat.com>
Approved-by: CKI KWF Bot <cki-ci-bot+kwf-gitlab-com@redhat.com>
Merged-by: CKI GitLab Kmaint Pipeline Bot <26919896-cki-kmaint-pipeline-bot@users.noreply.gitlab.com>
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/7544
JIRA: https://issues.redhat.com/browse/RHEL-105376
Backport one commit that silences CAP_SYS_ADMIN denials when BPF decides whether to apply a Spectre mitigation.
Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
Approved-by: Viktor Malik <vmalik@redhat.com>
Approved-by: Gregory Bell <grbell@redhat.com>
Approved-by: CKI KWF Bot <cki-ci-bot+kwf-gitlab-com@redhat.com>
Merged-by: CKI GitLab Kmaint Pipeline Bot <26919896-cki-kmaint-pipeline-bot@users.noreply.gitlab.com>
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/7462
JIRA: https://issues.redhat.com/browse/RHEL-117031
The following error is seen on Nvidia systems:
<4>[ 1062.336158] NVRM: VM: nv_alloc_pages:3801: 0x0000000021ac81f7, 32 page(s), count = 1, flags = 0x00000004, page_table = 0x00000000677eb7bb
<3>[ 1062.339224] nvidia-uvm: uvm_pmm_gpu.c:3480 devmem_init[pid:6006] request_free_mem_region() err -34
<3>[ 1062.339530] nvidia-uvm: uvm_gpu.c:1311 init_gpu[pid:6006] PMM initialization failed: Failure: Generic Error [NV_ERR_GENERIC], GPU ID 1: GPU-de9f6996-a0bf-2443-d0b7-eca4d994dab2 UVM-GI-de9f6996-a0bf-2443-d0b7-eca4d994dab2
Nvidia's documention [1] points out that the problem has been fixed upstream. After discussions with Nvidia, they pointed out two commits (backported in this changeset) that will resolve the issue.
This fix has been tested by the reporter.
[1] https://docs.nvidia.com/cuda/archive/13.0.0/cuda-toolkit-release-notes/index.html#known-issues
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Approved-by: David Arcari <darcari@redhat.com>
Approved-by: Rafael Aquini <raquini@redhat.com>
Approved-by: Lucas Zampieri <lzampier@redhat.com>
Approved-by: Eder Zulian <ezulian@redhat.com>
Approved-by: John W. Linville <linville@redhat.com>
Approved-by: CKI KWF Bot <cki-ci-bot+kwf-gitlab-com@redhat.com>
Merged-by: CKI GitLab Kmaint Pipeline Bot <26919896-cki-kmaint-pipeline-bot@users.noreply.gitlab.com>
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/7461
# Merge Request Required Information
## Summary of Changes
Latest AMD Platforms introduce a new instruction, PREFETCHI, that loads a cache line from a specified memory address into the indicated data or instruction cache level, based on locality reference hints.
Advertise support for the instruction to the user space
## Approved Development Ticket(s)
```
JIRA: https://issues.redhat.com/browse/RHEL-98696
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
```
<details><summary>Click for formatting instructions</summary>
Please follow the CentOS Stream [contribution documentation](https://docs.centos.org/en-US/stream-contrib/quickstart/) for how to file this ticket and have it approved.
List tickets each on their own line of this description using the format "Resolves: RHEL-76229", "Related: RHEL-76229" or "Reverts: RHEL-76229", as appropriate.
</details>
Approved-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Approved-by: Bandan Das <bsd@redhat.com>
Approved-by: Steve Best <sbest@redhat.com>
Approved-by: CKI KWF Bot <cki-ci-bot+kwf-gitlab-com@redhat.com>
Merged-by: CKI GitLab Kmaint Pipeline Bot <26919896-cki-kmaint-pipeline-bot@users.noreply.gitlab.com>
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/7388
JIRA: https://issues.redhat.com/browse/RHEL-113452
JIRA: https://issues.redhat.com/browse/RHEL-43214
JIRA: https://issues.redhat.com/browse/RHEL-72996
Refresh the zKVM subsystem to the latest upstream kernel, fix one important bug with postcopy migration and add the "Report vfio-ap configuration changes with CHSC Store Event Information" feature.
Omitted-fix: 0fc670d07d5de36a54f061f457743c9cde1d8b46
(it's a risc-v patch, not applicable to RHEL-9)
Signed-off-by: Thomas Huth <thuth@redhat.com>
Approved-by: Tony Camuso <tcamuso@redhat.com>
Approved-by: Vladis Dronov <vdronov@redhat.com>
Approved-by: Jerry Snitselaar <jsnitsel@redhat.com>
Approved-by: Rafael Aquini <raquini@redhat.com>
Approved-by: Eder Zulian <ezulian@redhat.com>
Approved-by: CKI KWF Bot <cki-ci-bot+kwf-gitlab-com@redhat.com>
Merged-by: CKI GitLab Kmaint Pipeline Bot <26919896-cki-kmaint-pipeline-bot@users.noreply.gitlab.com>
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/7379
JIRA: https://issues.redhat.com/browse/RHEL-71501
ENODATA (aka ENOATTR) has a very specific meaning in the xfs xattr code;
namely, that the requested attribute name could not be found.
However, a medium error from disk may also return ENODATA. At best,
this medium error may escape to userspace as "attribute not found"
when in fact it's an IO (disk) error.
At worst, we may oops in xfs_attr_leaf_get() when we do:
error = xfs_attr_leaf_hasname(args, &bp);
if (error == -ENOATTR) {
xfs_trans_brelse(args->trans, bp);
return error;
}
because an ENODATA/ENOATTR error from disk leaves us with a null bp,
and the xfs_trans_brelse will then null-deref it.
As discussed on the list, we really need to modify the lower level
IO functions to trap all disk errors and ensure that we don't let
unique errors like this leak up into higher xfs functions - many
like this should be remapped to EIO.
However, this patch directly addresses a reported bug in the xattr
code, and should be safe to backport to stable kernels. A larger-scope
patch to handle more unique errors at lower levels can follow later.
(Note, prior to 07120f1abd we did not oops, but we did return the
wrong error code to userspace.)
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Fixes: 07120f1abd ("xfs: Add xfs_has_attr and subroutines")
Cc: stable@vger.kernel.org # v5.9+
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
(cherry picked from commit ae668cd567a6a7622bc813ee0bb61c42bed61ba7)
Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
Approved-by: Brian Foster <bfoster@redhat.com>
Approved-by: Pavel Reichl <preichl@redhat.com>
Approved-by: CKI KWF Bot <cki-ci-bot+kwf-gitlab-com@redhat.com>
Merged-by: CKI GitLab Kmaint Pipeline Bot <26919896-cki-kmaint-pipeline-bot@users.noreply.gitlab.com>
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/7175
JIRA: https://issues.redhat.com/browse/RHEL-40885
commit 8671bad873ebeb082afcf7b4501395c374da6023
Author: Luis Claudio R. Goncalves <lgoncalv@redhat.com>
Date: Mon Jul 7 11:03:59 2025 -0300
sched: Do not call __put_task_struct() on rt if pi_blocked_on is set
With PREEMPT_RT enabled, some of the calls to put_task_struct() coming
from rt_mutex_adjust_prio_chain() could happen in preemptible context and
with a mutex enqueued. That could lead to this sequence:
rt_mutex_adjust_prio_chain()
put_task_struct()
__put_task_struct()
sched_ext_free()
spin_lock_irqsave()
rtlock_lock() ---> TRIGGERS
lockdep_assert(!current->pi_blocked_on);
This is not a SCHED_EXT bug. The first cleanup function called by
__put_task_struct() is sched_ext_free() and it happens to take a
(RT) spin_lock, which in the scenario described above, would trigger
the lockdep assertion of "!current->pi_blocked_on".
Crystal Wood was able to identify the problem as __put_task_struct()
being called during rt_mutex_adjust_prio_chain(), in the context of
a process with a mutex enqueued.
Instead of adding more complex conditions to decide when to directly
call __put_task_struct() and when to defer the call, unconditionally
resort to the deferred call on PREEMPT_RT to simplify the code.
Fixes: 893cdaaa3977 ("sched: avoid false lockdep splat in put_task_struct()")
Suggested-by: Crystal Wood <crwood@redhat.com>
Signed-off-by: Luis Claudio R. Goncalves <lgoncalv@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Wander Lairson Costa <wander@redhat.com>
Reviewed-by: Valentin Schneider <vschneid@redhat.com>
Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: https://lore.kernel.org/r/aGvTz5VaPFyj0pBV@uudg.org
Signed-off-by: Luis Claudio R. Goncalves <lgoncalv@redhat.com>
Approved-by: Oleg Nesterov <oleg@redhat.com>
Approved-by: Wander Lairson Costa <wander@redhat.com>
Approved-by: Phil Auld <pauld@redhat.com>
Approved-by: CKI KWF Bot <cki-ci-bot+kwf-gitlab-com@redhat.com>
Merged-by: CKI GitLab Kmaint Pipeline Bot <26919896-cki-kmaint-pipeline-bot@users.noreply.gitlab.com>
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/7554
# Merge Request Required Information
JIRA: https://issues.redhat.com/browse/RHEL-117873
CVE: CVE-2025-38493
CVE: CVE-2025-39887
CVE: CVE-2025-39974
CVE: CVE-2025-21733
## Summary of Changes
Rebase RTLA in RHEL 9.8 to upstream 6.17, with one fix from 6.18.
## Approved Development Ticket(s)
All submissions to CentOS Stream must reference a ticket in [Red Hat Jira](https://issues.redhat.com/).
<details><summary>Click for formatting instructions</summary>
Please follow the CentOS Stream [contribution documentation](https://docs.centos.org/en-US/stream-contrib/quickstart/) for how to file this ticket and have it approved.
List tickets each on their own line of this description using the format "Resolves: RHEL-76229", "Related: RHEL-76229" or "Reverts: RHEL-76229", as appropriate.
</details>
Signed-off-by: Tomas Glozar <tglozar@redhat.com>
Approved-by: Phil Auld <pauld@redhat.com>
Approved-by: Wander Lairson Costa <wander@redhat.com>
Approved-by: Luis Claudio R. Goncalves <lgoncalv@redhat.com>
Approved-by: CKI KWF Bot <cki-ci-bot+kwf-gitlab-com@redhat.com>
Merged-by: CKI GitLab Kmaint Pipeline Bot <26919896-cki-kmaint-pipeline-bot@users.noreply.gitlab.com>
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/7523
io_uring: enable per-io write streams
JIRA: https://issues.redhat.com/browse/RHEL-122870
This is actually one bug fix for initializing kiocb.ki_write_stream,
otherwise it may fail blktests block/035.
Signed-off-by: Ming Lei <ming.lei@redhat.com>
Approved-by: Brian Foster <bfoster@redhat.com>
Approved-by: John Meneghini <jmeneghi@redhat.com>
Approved-by: CKI KWF Bot <cki-ci-bot+kwf-gitlab-com@redhat.com>
Merged-by: CKI GitLab Kmaint Pipeline Bot <26919896-cki-kmaint-pipeline-bot@users.noreply.gitlab.com>
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/7518
# Merge Request Required Information
## Summary of Changes
JIRA: https://issues.redhat.com/browse/RHEL-114502
Update the nvme drivers and sync them with kernel version 6.16
Signed-off-by: Maurizio Lombardi <mlombard@redhat.com>
## Approved Development Ticket(s)
All submissions to CentOS Stream must reference a ticket in [Red Hat Jira](https://issues.redhat.com/).
<details><summary>Click for formatting instructions</summary>
Please follow the CentOS Stream [contribution documentation](https://docs.centos.org/en-US/stream-contrib/quickstart/) for how to file this ticket and have it approved.
List tickets each on their own line of this description using the format "Resolves: RHEL-76229", "Related: RHEL-76229" or "Reverts: RHEL-76229", as appropriate.
</details>
Approved-by: Ewan D. Milne <emilne@redhat.com>
Approved-by: Ming Lei <ming.lei@redhat.com>
Approved-by: CKI KWF Bot <cki-ci-bot+kwf-gitlab-com@redhat.com>
Merged-by: CKI GitLab Kmaint Pipeline Bot <26919896-cki-kmaint-pipeline-bot@users.noreply.gitlab.com>
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/7501
```
JIRA: https://issues.redhat.com/browse/RHEL-122025
Upstream Status: 11 commits are merged into the linux.git
Bring in the latest OcteonTX2 driver bugfixes and updates.
Almost all the commits apply cleanly. One commit has a partial
scope limited to the OcteonTX2 driver only. One commit requires
a small edit due to a missing tree-wide upstream commit.
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
```
Approved-by: Tony Camuso <tcamuso@redhat.com>
Approved-by: Herbert Xu <zxu@redhat.com>
Approved-by: CKI KWF Bot <cki-ci-bot+kwf-gitlab-com@redhat.com>
Merged-by: CKI GitLab Kmaint Pipeline Bot <26919896-cki-kmaint-pipeline-bot@users.noreply.gitlab.com>
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/7476
JIRA: https://issues.redhat.com/browse/RHEL-116016
This MR rebases supported usb/tbt/memstick/extcon drivers to upstream kernel v6.16. By design, rebase changes are limited to supported drivers and their relevant physical infrastructure. Treewide changes which touch these drivers are partially pulled in, whenever found out to be relevant. A new pm wakeup function also had to be imported in this merge request.
1) Common Vulnerabilities and Exposures:
```
CVE: CVE-2023-53356
CVE: CVE-2023-53551
CVE: CVE-2024-56670
CVE: CVE-2025-38103
CVE: CVE-2025-38174
CVE: CVE-2025-38268
CVE: CVE-2025-38391
CVE: CVE-2025-38404
CVE: CVE-2025-38448
CVE: CVE-2025-38497
CVE: CVE-2025-38535
```
2) Omitted fixes:
```
Omitted-fix: 9fc5986fbcd7 usb: typec: tcpci: Fix wakeup source leaks on device unbind
Omitted-fix: 015c0e63eb7c usb: gadget: udc-xilinx: Remove the invalid comment
Omitted-fix: e2d8ae899760 ASoC: qdsp6: fix compile-testing without CONFIG_OF
Omitted-fix: d8163a32ca95 phy: tegra: xusb: Add Tegra234 support
Omitted-fix: 56ad91c1aa9c i2c: robotfuzz-osif: disable zero-length read messages
```
Signed-off-by: Desnes Nunes <desnesn@redhat.com>
Approved-by: David Marlin <dmarlin@redhat.com>
Approved-by: Tony Camuso <tcamuso@redhat.com>
Approved-by: Bastien Nocera <bnocera@redhat.com>
Approved-by: Eric Chanudet <echanude@redhat.com>
Approved-by: CKI KWF Bot <cki-ci-bot+kwf-gitlab-com@redhat.com>
Merged-by: CKI GitLab Kmaint Pipeline Bot <26919896-cki-kmaint-pipeline-bot@users.noreply.gitlab.com>
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/7163
JIRA: https://issues.redhat.com/browse/RHEL-104731
CVE: CVE-2025-38351
```
Upstream: Merged
commit fa787ac07b3ceb56dd88a62d1866038498e96230
Author: Manuel Andreas <manuel.andreas@tum.de>
Date: Wed Jun 25 15:53:19 2025 +0200
KVM: x86/hyper-v: Skip non-canonical addresses during PV TLB flush
In KVM guests with Hyper-V hypercalls enabled, the hypercalls
HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST and HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX
allow a guest to request invalidation of portions of a virtual TLB.
For this, the hypercall parameter includes a list of GVAs that are supposed
to be invalidated.
However, when non-canonical GVAs are passed, there is currently no
filtering in place and they are eventually passed to checked invocations of
INVVPID on Intel / INVLPGA on AMD. While AMD's INVLPGA silently ignores
non-canonical addresses (effectively a no-op), Intel's INVVPID explicitly
signals VM-Fail and ultimately triggers the WARN_ONCE in invvpid_error():
invvpid failed: ext=0x0 vpid=1 gva=0xaaaaaaaaaaaaa000
WARNING: CPU: 6 PID: 326 at arch/x86/kvm/vmx/vmx.c:482
invvpid_error+0x91/0xa0 [kvm_intel]
Modules linked in: kvm_intel kvm 9pnet_virtio irqbypass fuse
CPU: 6 UID: 0 PID: 326 Comm: kvm-vm Not tainted 6.15.0 #14 PREEMPT(voluntary)
RIP: 0010:invvpid_error+0x91/0xa0 [kvm_intel]
Call Trace:
vmx_flush_tlb_gva+0x320/0x490 [kvm_intel]
kvm_hv_vcpu_flush_tlb+0x24f/0x4f0 [kvm]
kvm_arch_vcpu_ioctl_run+0x3013/0x5810 [kvm]
Hyper-V documents that invalid GVAs (those that are beyond a partition's
GVA space) are to be ignored. While not completely clear whether this
ruling also applies to non-canonical GVAs, it is likely fine to make that
assumption, and manual testing on Azure confirms "real" Hyper-V interprets
the specification in the same way.
Skip non-canonical GVAs when processing the list of address to avoid
tripping the INVVPID failure. Alternatively, KVM could filter out "bad"
GVAs before inserting into the FIFO, but practically speaking the only
downside of pushing validation to the final processing is that doing so
is suboptimal for the guest, and no well-behaved guest will request TLB
flushes for non-canonical addresses.
Fixes: 260970862c88 ("KVM: x86: hyper-v: Handle HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST{,EX} calls gently")
Cc: stable@vger.kernel.org
Signed-off-by: Manuel Andreas <manuel.andreas@tum.de>
Suggested-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Link: https://lore.kernel.org/r/c090efb3-ef82-499f-a5e0-360fc8420fb7@tum.de
Signed-off-by: Sean Christopherson <seanjc@google.com>
```
Signed-off-by: Jon Maloy <jmaloy@redhat.com>
---
<small>Created 2025-07-24 17:58 UTC by backporter - [KWF FAQ](https://red.ht/kernel_workflow_doc) - [Slack #team-kernel-workflow](https://redhat-internal.slack.com/archives/C04LRUPMJQ5) - [Source](https://gitlab.com/cki-project/kernel-workflow/-/blob/main/webhook/utils/backporter.py) - [Documentation](https://gitlab.com/cki-project/kernel-workflow/-/blob/main/docs/README.backporter.md) - [Report an issue](https://issues.redhat.com/secure/CreateIssueDetails!init.jspa?pid=12334433&issuetype=1&priority=4&summary=backporter+webhook+issue&components=kernel-workflow+/+backporter)</small>
Approved-by: Waiman Long <longman@redhat.com>
Approved-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Approved-by: CKI KWF Bot <cki-ci-bot+kwf-gitlab-com@redhat.com>
Merged-by: CKI GitLab Kmaint Pipeline Bot <26919896-cki-kmaint-pipeline-bot@users.noreply.gitlab.com>
JIRA: https://issues.redhat.com/browse/RHEL-99989
commit 4814f9110ec6b7b2a25ec0c397f996ce34d31115
Author: Easwar Hariharan <easwar.hariharan@linux.microsoft.com>
Date: Mon Jul 7 15:03:32 2025 -0700
net/smc: convert timeouts to secs_to_jiffies()
Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
secs_to_jiffies(). As the value here is a multiple of 1000, use
secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.
This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with
the following Coccinelle rules:
@depends on patch@
expression E;
@@
-msecs_to_jiffies(E * 1000)
+secs_to_jiffies(E)
-msecs_to_jiffies(E * MSEC_PER_SEC)
+secs_to_jiffies(E)
Signed-off-by: Easwar Hariharan <eahariha@linux.microsoft.com>
Reviewed-by: Dust Li <dust.li@linux.alibaba.com>
Reviewed-by: Guangguan Wang <guangguan.wang@linux.alibaba.com>
Link: https://patch.msgid.link/20250707-netdev-secs-to-jiffies-part-2-v2-1-b7817036342f@linux.microsoft.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Mahanta Jambigi <mjambigi@linux.ibm.com>
Signed-off-by: Mete Durlu <mdurlu@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-99989
commit ae2402bf882b40fb9cf3b6a5c9ff0e6c7a9ef842
Author: Pranav Tyagi <pranav.tyagi03@gmail.com>
Date: Fri Jun 20 15:55:59 2025 +0530
net/smc: replace strncpy with strscpy
Replace the deprecated strncpy() with two-argument version of
strscpy() as the destination is an array
and should be NUL-terminated.
Signed-off-by: Pranav Tyagi <pranav.tyagi03@gmail.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20250620102559.6365-1-pranav.tyagi03@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Mahanta Jambigi <mjambigi@linux.ibm.com>
Signed-off-by: Mete Durlu <mdurlu@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-99989
commit 091d019adce033118776ef93b50a268f715ae8f6
Author: Wang Liang <wangliang74@huawei.com>
Date: Thu Jun 19 11:08:54 2025 +0800
net/smc: remove unused function smc_lo_supports_v2
The smcd_ops->supports_v2 is only called in smcd_register_dev(), which
calls function smcd_supports_v2 for ism. For loopback-ism, function
smc_lo_supports_v2 is unused, remove it.
Signed-off-by: Wang Liang <wangliang74@huawei.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20250619030854.1536676-1-wangliang74@huawei.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Mahanta Jambigi <mjambigi@linux.ibm.com>
Signed-off-by: Mete Durlu <mdurlu@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-99989
Conflicts: Conflicts due to change in line numbers between 5.14 & 6.17
kernel, no functional changes
commit c3ee72ded0d2fc6433a009291d7825b28426e4c0
Author: Wang Liang <wangliang74@huawei.com>
Date: Wed Jun 18 18:33:42 2025 +0800
net/smc: remove unused input parameters in smc_buf_get_slot
The input parameter "compressed_bufsize" of smc_buf_get_slot is unused,
remove it.
Signed-off-by: Wang Liang <wangliang74@huawei.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20250618103342.1423913-1-wangliang74@huawei.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Mahanta Jambigi <mjambigi@linux.ibm.com>
Signed-off-by: Mete Durlu <mdurlu@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-99989
commit 199561a48f026bf674424fd9019c0690a3570377
Author: Simon Horman <horms@kernel.org>
Date: Thu Apr 17 11:28:23 2025 +0100
s390: ism: Pass string literal as format argument of dev_set_name()
GCC 14.2.0 reports that passing a non-string literal as the
format argument of dev_set_name() is potentially insecure.
drivers/s390/net/ism_drv.c: In function 'ism_probe':
drivers/s390/net/ism_drv.c:615:2: warning: format not a string literal and no format arguments [-Wformat-security]
615 | dev_set_name(&ism->dev, dev_name(&pdev->dev));
| ^~~~~~~~~~~~
It seems to me that as pdev is a PCIE device then the dev_name
call above should always return the device's BDF, e.g. 00:12.0.
That this should not contain format escape sequences. And thus
the current usage is safe.
But, it seems better to be safe than sorry. And, as a bonus, compiler
output becomes less verbose by addressing this issue.
Compile tested only.
No functional change intended.
Signed-off-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20250417-ism-str-fmt-v1-1-9818b029874d@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Mahanta Jambigi <mjambigi@linux.ibm.com>
Signed-off-by: Mete Durlu <mdurlu@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-99989
commit bfc6c67ec2d64d0ca4e5cc3e1ac84298a10b8d62
Author: Guangguan Wang <guangguan.wang@linux.alibaba.com>
Date: Tue Mar 4 20:43:04 2025 +0800
net/smc: use the correct ndev to find pnetid by pnetid table
When using smc_pnet in SMC, it will only search the pnetid in the
base_ndev of the netdev hierarchy(both HW PNETID and User-defined
sw pnetid). This may not work for some scenarios when using SMC in
container on cloud environment.
In container, there have choices of different container network,
such as directly using host network, virtual network IPVLAN, veth,
etc. Different choices of container network have different netdev
hierarchy. Examples of netdev hierarchy show below. (eth0 and eth1
in host below is the netdev directly related to the physical device).
_______________________________
| _________________ |
| |POD | |
| | | |
| | eth0_________ | |
| |____| |__| |
| | | |
| | | |
| eth1|base_ndev| eth0_______ |
| | | | RDMA ||
| host |_________| |_______||
---------------------------------
netdev hierarchy if directly using host network
________________________________
| _________________ |
| |POD __________ | |
| | |upper_ndev| | |
| |eth0|__________| | |
| |_______|_________| |
| |lower netdev |
| __|______ |
| eth1| | eth0_______ |
| |base_ndev| | RDMA ||
| host |_________| |_______||
---------------------------------
netdev hierarchy if using IPVLAN
_______________________________
| _____________________ |
| |POD _________ | |
| | |base_ndev|| |
| |eth0(veth)|_________|| |
| |____________|________| |
| |pairs |
| _______|_ |
| | | eth0_______ |
| veth|base_ndev| | RDMA ||
| |_________| |_______||
| _________ |
| eth1|base_ndev| |
| host |_________| |
---------------------------------
netdev hierarchy if using veth
Due to some reasons, the eth1 in host is not RDMA attached netdevice,
pnetid is needed to map the eth1(in host) with RDMA device so that POD
can do SMC-R. Because the eth1(in host) is managed by CNI plugin(such
as Terway, network management plugin in container environment), and in
cloud environment the eth(in host) can dynamically be inserted by CNI
when POD create and dynamically be removed by CNI when POD destroy and
no POD related to the eth(in host) anymore. It is hard to config the
pnetid to the eth1(in host). But it is easy to config the pnetid to the
netdevice which can be seen in POD. When do SMC-R, both the container
directly using host network and the container using veth network can
successfully match the RDMA device, because the configured pnetid netdev
is a base_ndev. But the container using IPVLAN can not successfully
match the RDMA device and 0x03030000 fallback happens, because the
configured pnetid netdev is not a base_ndev. Additionally, if config
pnetid to the eth1(in host) also can not work for matching RDMA device
when using veth network and doing SMC-R in POD.
To resolve the problems list above, this patch extends to search user
-defined sw pnetid in the clc handshake ndev when no pnetid can be found
in the base_ndev, and the base_ndev take precedence over ndev for backward
compatibility. This patch also can unify the pnetid setup of different
network choices list above in container(Config user-defined sw pnetid in
the netdevice can be seen in POD).
Signed-off-by: Guangguan Wang <guangguan.wang@linux.alibaba.com>
Reviewed-by: Wenjia Zhang <wenjia@linux.ibm.com>
Reviewed-by: Halil Pasic <pasic@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Mahanta Jambigi <mjambigi@linux.ibm.com>
Signed-off-by: Mete Durlu <mdurlu@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-99989
commit a4b6539038c1aa1ae871aacf6e41b566c3613993
Author: Guangguan Wang <guangguan.wang@linux.alibaba.com>
Date: Sat Jan 4 22:32:01 2025 +0800
net/smc: fix data error when recvmsg with MSG_PEEK flag
When recvmsg with MSG_PEEK flag, the data will be copied to
user's buffer without advancing consume cursor and without
reducing the length of rx available data. Once the expected
peek length is larger than the value of bytes_to_rcv, in the
loop of do while in smc_rx_recvmsg, the first loop will copy
bytes_to_rcv bytes of data from the position local_tx_ctrl.cons,
the second loop will copy the min(bytes_to_rcv, read_remaining)
bytes from the position local_tx_ctrl.cons again because of the
lacking of process with advancing consume cursor and reducing
the length of available data. So do the subsequent loops. The
data copied in the second loop and the subsequent loops will
result in data error, as it should not be copied if no more data
arrives and it should be copied from the position advancing
bytes_to_rcv bytes from the local_tx_ctrl.cons if more data arrives.
This issue can be reproduce by the following python script:
server.py:
import socket
import time
server_ip = '0.0.0.0'
server_port = 12346
server_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server_socket.bind((server_ip, server_port))
server_socket.listen(1)
print('Server is running and listening for connections...')
conn, addr = server_socket.accept()
print('Connected by', addr)
while True:
data = conn.recv(1024)
if not data:
break
print('Received request:', data.decode())
conn.sendall(b'Hello, client!\n')
time.sleep(5)
conn.sendall(b'Hello, again!\n')
conn.close()
client.py:
import socket
server_ip = '<server ip>'
server_port = 12346
resp=b'Hello, client!\nHello, again!\n'
client_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
client_socket.connect((server_ip, server_port))
request = 'Hello, server!'
client_socket.sendall(request.encode())
peek_data = client_socket.recv(len(resp),
socket.MSG_PEEK | socket.MSG_WAITALL)
print('Peeked data:', peek_data.decode())
client_socket.close()
Fixes: 952310ccf2 ("smc: receive data from RMBE")
Reported-by: D. Wythe <alibuda@linux.alibaba.com>
Signed-off-by: Guangguan Wang <guangguan.wang@linux.alibaba.com>
Link: https://patch.msgid.link/20250104143201.35529-1-guangguan.wang@linux.alibaba.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Mahanta Jambigi <mjambigi@linux.ibm.com>
Signed-off-by: Mete Durlu <mdurlu@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-99989
commit 10bc9761d12e440656062ef78cd889bbfa827dcf
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date: Wed Jan 8 12:26:06 2025 +0300
net/smc: delete pointless divide by one
Here "buf" is a void pointer so sizeof(*buf) is one. Doing a divide
by one makes the code less readable. Delete it.
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
Link: https://patch.msgid.link/ee1a790b-f874-4512-b3ae-9c45f99dc640@stanley.mountain
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Mahanta Jambigi <mjambigi@linux.ibm.com>
Signed-off-by: Mete Durlu <mdurlu@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-99989
commit 27ef6a9981fe74191849966a6d5e0400a4008ab8
Author: Guangguan Wang <guangguan.wang@linux.alibaba.com>
Date: Wed Dec 11 10:30:54 2024 +0800
net/smc: support SMC-R V2 for rdma devices with max_recv_sge equals to 1
For SMC-R V2, llc msg can be larger than SMC_WR_BUF_SIZE, thus every
recv wr has 2 sges, the first sge with length SMC_WR_BUF_SIZE is for
V1/V2 compatible llc/cdc msg, and the second sge with length
SMC_WR_BUF_V2_SIZE-SMC_WR_TX_SIZE is for V2 specific llc msg, like
SMC_LLC_DELETE_RKEY and SMC_LLC_ADD_LINK for SMC-R V2. The memory
buffer in the second sge is shared by all recv wr in one link and
all link in one lgr for saving memory usage purpose.
But not all RDMA devices with max_recv_sge greater than 1. Thus SMC-R
V2 can not support on such RDMA devices and SMC_CLC_DECL_INTERR fallback
happens because of the failure of create qp.
This patch introduce the support for SMC-R V2 on RDMA devices with
max_recv_sge equals to 1. Every recv wr has only one sge with individual
buffer whose size is SMC_WR_BUF_V2_SIZE once the RDMA device's max_recv_sge
equals to 1. It may use more memory, but it is better than
SMC_CLC_DECL_INTERR fallback.
Co-developed-by: Wen Gu <guwen@linux.alibaba.com>
Signed-off-by: Wen Gu <guwen@linux.alibaba.com>
Signed-off-by: Guangguan Wang <guangguan.wang@linux.alibaba.com>
Reviewed-by: Wenjia Zhang <wenjia@linux.ibm.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Mahanta Jambigi <mjambigi@linux.ibm.com>
Signed-off-by: Mete Durlu <mdurlu@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-99989
commit 2c7f14ed9c19ec0f149479d1c2842ec1f9bf76d7
Author: Wen Gu <guwen@linux.alibaba.com>
Date: Wed Nov 27 21:30:14 2024 +0800
net/smc: fix LGR and link use-after-free issue
We encountered a LGR/link use-after-free issue, which manifested as
the LGR/link refcnt reaching 0 early and entering the clear process,
making resource access unsafe.
refcount_t: addition on 0; use-after-free.
WARNING: CPU: 14 PID: 107447 at lib/refcount.c:25 refcount_warn_saturate+0x9c/0x140
Workqueue: events smc_lgr_terminate_work [smc]
Call trace:
refcount_warn_saturate+0x9c/0x140
__smc_lgr_terminate.part.45+0x2a8/0x370 [smc]
smc_lgr_terminate_work+0x28/0x30 [smc]
process_one_work+0x1b8/0x420
worker_thread+0x158/0x510
kthread+0x114/0x118
or
refcount_t: underflow; use-after-free.
WARNING: CPU: 6 PID: 93140 at lib/refcount.c:28 refcount_warn_saturate+0xf0/0x140
Workqueue: smc_hs_wq smc_listen_work [smc]
Call trace:
refcount_warn_saturate+0xf0/0x140
smcr_link_put+0x1cc/0x1d8 [smc]
smc_conn_free+0x110/0x1b0 [smc]
smc_conn_abort+0x50/0x60 [smc]
smc_listen_find_device+0x75c/0x790 [smc]
smc_listen_work+0x368/0x8a0 [smc]
process_one_work+0x1b8/0x420
worker_thread+0x158/0x510
kthread+0x114/0x118
It is caused by repeated release of LGR/link refcnt. One suspect is that
smc_conn_free() is called repeatedly because some smc_conn_free() from
server listening path are not protected by sock lock.
e.g.
Calls under socklock | smc_listen_work
-------------------------------------------------------
lock_sock(sk) | smc_conn_abort
smc_conn_free | \- smc_conn_free
\- smcr_link_put | \- smcr_link_put (duplicated)
release_sock(sk)
So here add sock lock protection in smc_listen_work() path, making it
exclusive with other connection operations.
Fixes: 3b2dec2603 ("net/smc: restructure client and server code in af_smc")
Co-developed-by: Guangguan Wang <guangguan.wang@linux.alibaba.com>
Signed-off-by: Guangguan Wang <guangguan.wang@linux.alibaba.com>
Co-developed-by: Kai <KaiShen@linux.alibaba.com>
Signed-off-by: Kai <KaiShen@linux.alibaba.com>
Signed-off-by: Wen Gu <guwen@linux.alibaba.com>
Reviewed-by: Wenjia Zhang <wenjia@linux.ibm.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Mahanta Jambigi <mjambigi@linux.ibm.com>
Signed-off-by: Mete Durlu <mdurlu@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-99989
commit 0541db8ee32c09463a72d0987382b3a3336b0043
Author: Wen Gu <guwen@linux.alibaba.com>
Date: Wed Nov 27 21:30:13 2024 +0800
net/smc: initialize close_work early to avoid warning
We encountered a warning that close_work was canceled before
initialization.
WARNING: CPU: 7 PID: 111103 at kernel/workqueue.c:3047 __flush_work+0x19e/0x1b0
Workqueue: events smc_lgr_terminate_work [smc]
RIP: 0010:__flush_work+0x19e/0x1b0
Call Trace:
? __wake_up_common+0x7a/0x190
? work_busy+0x80/0x80
__cancel_work_timer+0xe3/0x160
smc_close_cancel_work+0x1a/0x70 [smc]
smc_close_active_abort+0x207/0x360 [smc]
__smc_lgr_terminate.part.38+0xc8/0x180 [smc]
process_one_work+0x19e/0x340
worker_thread+0x30/0x370
? process_one_work+0x340/0x340
kthread+0x117/0x130
? __kthread_cancel_work+0x50/0x50
ret_from_fork+0x22/0x30
This is because when smc_close_cancel_work is triggered, e.g. the RDMA
driver is rmmod and the LGR is terminated, the conn->close_work is
flushed before initialization, resulting in WARN_ON(!work->func).
__smc_lgr_terminate | smc_connect_{rdma|ism}
-------------------------------------------------------------
| smc_conn_create
| \- smc_lgr_register_conn
for conn in lgr->conns_all |
\- smc_conn_kill |
\- smc_close_active_abort |
\- smc_close_cancel_work |
\- cancel_work_sync |
\- __flush_work |
(close_work) |
| smc_close_init
| \- INIT_WORK(&close_work)
So fix this by initializing close_work before establishing the
connection.
Fixes: 46c28dbd4c ("net/smc: no socket state changes in tasklet context")
Fixes: 413498440e ("net/smc: add SMC-D support in af_smc")
Signed-off-by: Wen Gu <guwen@linux.alibaba.com>
Reviewed-by: Wenjia Zhang <wenjia@linux.ibm.com>
Reviewed-by: Alexandra Winter <wintera@linux.ibm.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Mahanta Jambigi <mjambigi@linux.ibm.com>
Signed-off-by: Mete Durlu <mdurlu@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-99989
commit 82ac39ebd6db0c9f7a97a934bda1e3e101a9d201
Author: Li RongQing <lirongqing@baidu.com>
Date: Mon Oct 14 19:53:21 2024 +0800
net/smc: Fix searching in list of known pnetids in smc_pnet_add_pnetid
pnetid of pi (not newly allocated pe) should be compared
Fixes: e888a2e833 ("net/smc: introduce list of pnetids for Ethernet devices")
Reviewed-by: D. Wythe <alibuda@linux.alibaba.com>
Reviewed-by: Wen Gu <guwen@linux.alibaba.com>
Signed-off-by: Li RongQing <lirongqing@baidu.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Gerd Bayer <gbayer@linux.ibm.com>
Link: https://patch.msgid.link/20241014115321.33234-1-lirongqing@baidu.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Mahanta Jambigi <mjambigi@linux.ibm.com>
Signed-off-by: Mete Durlu <mdurlu@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-99989
commit cd959bf7c3bbaf64a29750c5e36776078a18a8fe
Author: Simon Horman <horms@kernel.org>
Date: Wed Oct 9 11:05:21 2024 +0100
net/smc: Address spelling errors
Address spelling errors flagged by codespell.
This patch is intended to cover all files under drivers/smc
Signed-off-by: Simon Horman <horms@kernel.org>
Reviewed-by: D. Wythe <alibuda@linux.alibaba.com>
Reviewed-by: Guangguan Wang <guangguan.wang@linux.alibaba.com>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Wenjia Zhang <wenjia@linux.ibm.com>
Link: https://patch.msgid.link/20241009-smc-starspell-v1-1-b8b395bbaf82@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Mahanta Jambigi <mjambigi@linux.ibm.com>
Signed-off-by: Mete Durlu <mdurlu@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-99989
Conflicts: Conflicts due to change in line numbers between 5.14 & 6.17
kernel, no functional changes
commit f8406a2fd279d05eb4a76c9b77cb740b6f350549
Author: D. Wythe <alibuda@linux.alibaba.com>
Date: Fri Sep 6 10:35:35 2024 +0800
net/smc: add sysctl for smc_limit_hs
In commit 48b6190a0042 ("net/smc: Limit SMC visits when handshake workqueue congested"),
we introduce a mechanism to put constraint on SMC connections visit
according to the pressure of SMC handshake process.
At that time, we believed that controlling the feature through netlink
was sufficient. However, most people have realized now that netlink is
not convenient in container scenarios, and sysctl is a more suitable
approach.
In addition, since commit 462791bbfa35 ("net/smc: add sysctl interface for SMC")
had introcuded smc_sysctl_net_init(), it is reasonable for us to
initialize limit_smc_hs in it instead of initializing it in
smc_pnet_net_int().
Signed-off-by: D. Wythe <alibuda@linux.alibaba.com>
Reviewed-by: Wen Gu <guwen@linux.alibaba.com>
Reviewed-by: Jan Karcher <jaka@linux.ibm.com>
Link: https://patch.msgid.link/1725590135-5631-1-git-send-email-alibuda@linux.alibaba.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Mahanta Jambigi <mjambigi@linux.ibm.com>
Signed-off-by: Mete Durlu <mdurlu@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-99989
commit 98d4435efcbf37801a3246fb53856c4b934a2613
Author: Jeongjun Park <aha310510@gmail.com>
Date: Thu Aug 29 12:56:48 2024 +0900
net/smc: prevent NULL pointer dereference in txopt_get
Since smc_inet6_prot does not initialize ipv6_pinfo_offset, inet6_create()
copies an incorrect address value, sk + 0 (offset), to inet_sk(sk)->pinet6.
In addition, since inet_sk(sk)->pinet6 and smc_sk(sk)->clcsock practically
point to the same address, when smc_create_clcsk() stores the newly
created clcsock in smc_sk(sk)->clcsock, inet_sk(sk)->pinet6 is corrupted
into clcsock. This causes NULL pointer dereference and various other
memory corruptions.
To solve this problem, you need to initialize ipv6_pinfo_offset, add a
smc6_sock structure, and then add ipv6_pinfo as the second member of
the smc_sock structure.
Reported-by: syzkaller <syzkaller@googlegroups.com>
Fixes: d25a92ccae6b ("net/smc: Introduce IPPROTO_SMC")
Signed-off-by: Jeongjun Park <aha310510@gmail.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Mahanta Jambigi <mjambigi@linux.ibm.com>
Signed-off-by: Mete Durlu <mdurlu@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-99989
commit e0d103542b06c36240e3887edfe49578464866eb
Author: Wen Gu <guwen@linux.alibaba.com>
Date: Wed Aug 14 21:08:27 2024 +0800
net/smc: introduce statistics for ringbufs usage of net namespace
The buffer size histograms in smc_stats, namely rx/tx_rmbsize, record
the sizes of ringbufs for all connections that have ever appeared in
the net namespace. They are incremental and we cannot know the actual
ringbufs usage from these. So here introduces statistics for current
ringbufs usage of existing smc connections in the net namespace into
smc_stats, it will be incremented when new connection uses a ringbuf
and decremented when the ringbuf is unused.
Signed-off-by: Wen Gu <guwen@linux.alibaba.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Mahanta Jambigi <mjambigi@linux.ibm.com>
Signed-off-by: Mete Durlu <mdurlu@redhat.com>
CKI KWF Bot
Mete Durlu