Before this patch .get_stats() for venetdev was not defended from
racing, Documentation/networking/netdevices.txt states ndo_get_stats()
is to be syncronized by dev_base_lock rwlock, but we do READ stats, so
can go in parallel.
At the same time the algorithm of gathering per-cpu stats into a singl
On 29.08.2023 18:01, Konstantin Khorenko wrote:
Before this patch .get_stats() for venetdev was not defended from
racing, Documentation/networking/netdevices.txt states ndo_get_stats()
is to be syncronized by dev_base_lock rwlock, but we do READ stats, so
can go in parallel.
At the same time
The commit is pushed to "branch-rh7-3.10.0-1160.95.1.vz7.210.x-ovz" and will
appear at https://src.openvz.org/scm/ovz/vzkernel.git
after rh7-3.10.0-1160.95.1.vz7.210.2
-->
commit 03fb68e6bc2215087c1d2ae2b93e29cd91126b16
Author: Konstantin Khorenko
Date: Wed Aug 23 20:13:01 2023 +0300
v
This reverts commit e318bc7bbcbb40076038ce34efd588cb4f7a4fd1.
drgn expects 'struct inactive_task_frame' to have many fields if exists
at all, so drgn just does not work if this patch is applied alone.
The patch has been applied because it was easier to apply 226263231f8c
("ms/x86/unwind: Disable
From: Josh Poimboeuf
There are a handful of callers to save_stack_trace_tsk() and
show_stack() which try to unwind the stack of a task other than current.
In such cases, it's remotely possible that the task is running on one
CPU while the unwinder is reading its stack from another CPU, causing
th
In the scope of https://jira.vzint.dev/browse/HCI-171 we have backported
a set of patches, in particular e318bc7bbcbb ("ms/sched/x86: Add 'struct
inactive_task_frame' to better document the sleeping task stack frame").
This patch has added a new structure 'struct inactive_task_frame' but
with only
This reverts commit 226263231f8ce9f54a4fec6e0279c8c13e570d3b.
We are reverting the patch because we need to revert an underlying patch
d21e78475d01 "(ms/sched/x86: Add 'struct inactive_task_frame' to better
document the sleeping task stack frame")
and later we'll rework and re-apply "ms/x86/unwin
On 28.08.23 16:07, Alexander Atanasov wrote:
Lockdep reports circular lock dependency here
&p->lock --> &plo->ctl_mutex --> sb_writers.
this is only triggered by trinity and it did not happen
in real world for the last 10 years. fixing it at this stage is not feasible
since it could break so many
