This driver is no longer buildable since the PPC_MAPLE platform was
removed, see commit 62f8f307c8 ("powerpc/64: Remove maple platform").
Remove the driver.
Note that the comment in the driver says it supports "SMU & 970FX
based G5 Macs", but that's not true, that comment was copied from
pmac64-cpufreq.c, which still exists and continues to support those
machines.
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://patch.msgid.link/20241112085148.415574-1-mpe@ellerman.id.au
A last minute mlx5 bugfix
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
-----BEGIN PGP SIGNATURE-----
iQFDBAABCAAtFiEEXQn9CHHI+FuUyooNKB8NuNKNVGkFAmcz5NMPHG1zdEByZWRo
YXQuY29tAAoJECgfDbjSjVRptJcIAMuzl2PX/HzYwMBGI7TrRObAaZo8j6Zub9Be
TVw6H33OKK86y2MoBz1hTj1Z32KA+qAGJEui03ckrFpHSVkzRvNGXJEI2rbtY5sX
bmP3ch/9Yr4aEw1eF1cpcQlTMyFFFoeqbTLf5qBItsZ+qMfqiknAeSRL31YDBteK
uOWaTPHMW8nNyy6wQaI9dEdP84Dluhx+B/IxcGcl8FySpSl+faA/uHr5YJP9kTO4
e7PxFYa0oBeCqu7varkVRHuaoMaPk4OCrjeZWZAY9dp9LOGtfgh/YbYj7wsNfkXH
mvKy8lRu+o1/Fh6bRc0TxNmtvOPpB1Myto6wj4ntEtNQun3khOo=
=uDap
-----END PGP SIGNATURE-----
Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost
Pull virtio fix from Michael Tsirkin:
"A last minute mlx5 bugfix"
* tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost:
vdpa/mlx5: Fix PA offset with unaligned starting iotlb map
This commit fixes the bug in the handling of partial mapping of the
buffer objects to the GPU, which caused kernel warnings.
Panthor didn't correctly handle the case where the partial mapping
spanned multiple scatterlists and the mapping offset didn't point
to the 1st page of starting scatterlist. The offset variable was
not cleared after reaching the starting scatterlist.
Following warning messages were seen.
WARNING: CPU: 1 PID: 650 at drivers/iommu/io-pgtable-arm.c:659 __arm_lpae_unmap+0x254/0x5a0
<snip>
pc : __arm_lpae_unmap+0x254/0x5a0
lr : __arm_lpae_unmap+0x2cc/0x5a0
<snip>
Call trace:
__arm_lpae_unmap+0x254/0x5a0
__arm_lpae_unmap+0x108/0x5a0
__arm_lpae_unmap+0x108/0x5a0
__arm_lpae_unmap+0x108/0x5a0
arm_lpae_unmap_pages+0x80/0xa0
panthor_vm_unmap_pages+0xac/0x1c8 [panthor]
panthor_gpuva_sm_step_unmap+0x4c/0xc8 [panthor]
op_unmap_cb.isra.23.constprop.30+0x54/0x80
__drm_gpuvm_sm_unmap+0x184/0x1c8
drm_gpuvm_sm_unmap+0x40/0x60
panthor_vm_exec_op+0xa8/0x120 [panthor]
panthor_vm_bind_exec_sync_op+0xc4/0xe8 [panthor]
panthor_ioctl_vm_bind+0x10c/0x170 [panthor]
drm_ioctl_kernel+0xbc/0x138
drm_ioctl+0x210/0x4b0
__arm64_sys_ioctl+0xb0/0xf8
invoke_syscall+0x4c/0x110
el0_svc_common.constprop.1+0x98/0xf8
do_el0_svc+0x24/0x38
el0_svc+0x34/0xc8
el0t_64_sync_handler+0xa0/0xc8
el0t_64_sync+0x174/0x178
<snip>
panthor : [drm] drm_WARN_ON(unmapped_sz != pgsize * pgcount)
WARNING: CPU: 1 PID: 650 at drivers/gpu/drm/panthor/panthor_mmu.c:922 panthor_vm_unmap_pages+0x124/0x1c8 [panthor]
<snip>
pc : panthor_vm_unmap_pages+0x124/0x1c8 [panthor]
lr : panthor_vm_unmap_pages+0x124/0x1c8 [panthor]
<snip>
panthor : [drm] *ERROR* failed to unmap range ffffa388f000-ffffa3890000 (requested range ffffa388c000-ffffa3890000)
Fixes: 647810ec24 ("drm/panthor: Add the MMU/VM logical block")
Signed-off-by: Akash Goel <akash.goel@arm.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241111134720.780403-1-akash.goel@arm.com
Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
Yonghong Song says:
====================
bpf: Support private stack for bpf progs
The main motivation for private stack comes from nested scheduler in
sched-ext from Tejun. The basic idea is that
- each cgroup will its own associated bpf program,
- bpf program with parent cgroup will call bpf programs
in immediate child cgroups.
Let us say we have the following cgroup hierarchy:
root_cg (prog0):
cg1 (prog1):
cg11 (prog11):
cg111 (prog111)
cg112 (prog112)
cg12 (prog12):
cg121 (prog121)
cg122 (prog122)
cg2 (prog2):
cg21 (prog21)
cg22 (prog22)
cg23 (prog23)
In the above example, prog0 will call a kfunc which will call prog1 and
prog2 to get sched info for cg1 and cg2 and then the information is
summarized and sent back to prog0. Similarly, prog11 and prog12 will be
invoked in the kfunc and the result will be summarized and sent back to
prog1, etc. The following illustrates a possible call sequence:
... -> bpf prog A -> kfunc -> ops.<callback_fn> (bpf prog B) ...
Currently, for each thread, the x86 kernel allocate 16KB stack. Each
bpf program (including its subprograms) has maximum 512B stack size to
avoid potential stack overflow. Nested bpf programs further increase the
risk of stack overflow. To avoid potential stack overflow caused by bpf
programs, this patch set supported private stack and bpf program stack
space is allocated during jit time. Using private stack for bpf progs
can reduce or avoid potential kernel stack overflow.
Currently private stack is applied to tracing programs like kprobe/uprobe,
perf_event, tracepoint, raw tracepoint and struct_ops progs.
Tracing progs enable private stack if any subprog stack size is more
than a threshold (i.e. 64B). Struct-ops progs enable private stack
based on particular struct op implementation which can enable private
stack before verification at per-insn level. Struct-ops progs have
the same treatment as tracing progs w.r.t when to enable private stack.
For all these progs, the kernel will do recursion check (no nesting for
per prog per cpu) to ensure that private stack won't be overwritten.
The bpf_prog_aux struct has a callback func recursion_detected() which
can be implemented by kernel subsystem to synchronously detect recursion,
report error, etc.
Only x86_64 arch supports private stack now. It can be extended to other
archs later. Please see each individual patch for details.
Change logs:
v11 -> v12:
- v11 link: https://lore.kernel.org/bpf/20241109025312.148539-1-yonghong.song@linux.dev/
- Fix a bug where allocated percpu space is less than actual private stack.
- Add guard memory (before and after actual prog stack) to detect potential
underflow/overflow.
v10 -> v11:
- v10 link: https://lore.kernel.org/bpf/20241107024138.3355687-1-yonghong.song@linux.dev/
- Use two bool variables, priv_stack_requested (used by struct-ops only) and
jits_use_priv_stack, in order to make code cleaner.
- Set env->prog->aux->jits_use_priv_stack to true if any subprog uses private stack.
This is for struct-ops use case to kick in recursion protection.
v9 -> v10:
- v9 link: https://lore.kernel.org/bpf/20241104193455.3241859-1-yonghong.song@linux.dev/
- Simplify handling async cbs by making those async cb related progs using normal
kernel stack.
- Do percpu allocation in jit instead of verifier.
v8 -> v9:
- v8 link: https://lore.kernel.org/bpf/20241101030950.2677215-1-yonghong.song@linux.dev/
- Use enum to express priv stack mode.
- Use bits in bpf_subprog_info struct to do subprog recursion check between
main/async and async subprogs.
- Fix potential memory leak.
- Rename recursion detection func from recursion_skipped() to recursion_detected().
v7 -> v8:
- v7 link: https://lore.kernel.org/bpf/20241029221637.264348-1-yonghong.song@linux.dev/
- Add recursion_skipped() callback func to bpf_prog->aux structure such that if
a recursion miss happened and bpf_prog->aux->recursion_skipped is not NULL, the
callback fn will be called so the subsystem can do proper action based on their
respective design.
v6 -> v7:
- v6 link: https://lore.kernel.org/bpf/20241020191341.2104841-1-yonghong.song@linux.dev/
- Going back to do private stack allocation per prog instead per subtree. This can
simplify implementation and avoid verifier complexity.
- Handle potential nested subprog run if async callback exists.
- Use struct_ops->check_member() callback to set whether a particular struct-ops
prog wants private stack or not.
v5 -> v6:
- v5 link: https://lore.kernel.org/bpf/20241017223138.3175885-1-yonghong.song@linux.dev/
- Instead of using (or not using) private stack at struct_ops level,
each prog in struct_ops can decide whether to use private stack or not.
v4 -> v5:
- v4 link: https://lore.kernel.org/bpf/20241010175552.1895980-1-yonghong.song@linux.dev/
- Remove bpf_prog_call() related implementation.
- Allow (opt-in) private stack for sched-ext progs.
v3 -> v4:
- v3 link: https://lore.kernel.org/bpf/20240926234506.1769256-1-yonghong.song@linux.dev/
There is a long discussion in the above v3 link trying to allow private
stack to be used by kernel functions in order to simplify implementation.
But unfortunately we didn't find a workable solution yet, so we return
to the approach where private stack is only used by bpf programs.
- Add bpf_prog_call() kfunc.
v2 -> v3:
- Instead of per-subprog private stack allocation, allocate private
stacks at main prog or callback entry prog. Subprogs not main or callback
progs will increment the inherited stack pointer to be their
frame pointer.
- Private stack allows each prog max stack size to be 512 bytes, intead
of the whole prog hierarchy to be 512 bytes.
- Add some tests.
====================
Link: https://lore.kernel.org/r/20241112163902.2223011-1-yonghong.song@linux.dev
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Add three tests for struct_ops using private stack.
./test_progs -t struct_ops_private_stack
#336/1 struct_ops_private_stack/private_stack:OK
#336/2 struct_ops_private_stack/private_stack_fail:OK
#336/3 struct_ops_private_stack/private_stack_recur:OK
#336 struct_ops_private_stack:OK
The following is a snippet of a struct_ops check_member() implementation:
u32 moff = __btf_member_bit_offset(t, member) / 8;
switch (moff) {
case offsetof(struct bpf_testmod_ops3, test_1):
prog->aux->priv_stack_requested = true;
prog->aux->recursion_detected = test_1_recursion_detected;
fallthrough;
default:
break;
}
return 0;
The first test is with nested two different callback functions where the
first prog has more than 512 byte stack size (including subprogs) with
private stack enabled.
The second test is a negative test where the second prog has more than 512
byte stack size without private stack enabled.
The third test is the same callback function recursing itself. At run time,
the jit trampoline recursion check kicks in to prevent the recursion. The
recursion_detected() callback function is implemented by the bpf_testmod,
the following message in dmesg
bpf_testmod: oh no, recursing into test_1, recursion_misses 1
demonstrates the callback function is indeed triggered when recursion miss
happens.
Signed-off-by: Yonghong Song <yonghong.song@linux.dev>
Link: https://lore.kernel.org/r/20241112163938.2225528-1-yonghong.song@linux.dev
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
For struct_ops progs, whether a particular prog uses private stack
depends on prog->aux->priv_stack_requested setting before actual
insn-level verification for that prog. One particular implementation
is to piggyback on struct_ops->check_member(). The next patch has
an example for this. The struct_ops->check_member() sets
prog->aux->priv_stack_requested to be true which enables private stack
usage.
The struct_ops prog follows the same rule as kprobe/tracing progs after
function bpf_enable_priv_stack(). For example, even a struct_ops prog
requests private stack, it could still use normal kernel stack if
the stack size is small (< 64 bytes).
Similar to tracing progs, nested same cpu same prog run will be skipped.
A field (recursion_detected()) is added to bpf_prog_aux structure.
If bpf_prog->aux->recursion_detected is implemented by the struct_ops
subsystem and nested same cpu/prog happens, the function will be
triggered to report an error, collect related info, etc.
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Yonghong Song <yonghong.song@linux.dev>
Link: https://lore.kernel.org/r/20241112163933.2224962-1-yonghong.song@linux.dev
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Some private stack tests are added including:
- main prog only with stack size greater than BPF_PSTACK_MIN_SIZE.
- main prog only with stack size smaller than BPF_PSTACK_MIN_SIZE.
- prog with one subprog having MAX_BPF_STACK stack size and another
subprog having non-zero small stack size.
- prog with callback function.
- prog with exception in main prog or subprog.
- prog with async callback without nesting
- prog with async callback with possible nesting
Signed-off-by: Yonghong Song <yonghong.song@linux.dev>
Link: https://lore.kernel.org/r/20241112163927.2224750-1-yonghong.song@linux.dev
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Private stack is allocated in function bpf_int_jit_compile() with
alignment 8. Private stack allocation size includes the stack size
determined by verifier and additional space to protect stack overflow
and underflow. See below an illustration:
---> memory address increasing
[8 bytes to protect overflow] [normal stack] [8 bytes to protect underflow]
If overflow/underflow is detected, kernel messages will be
emited in dmesg like
BPF private stack overflow/underflow detected for prog Fx
BPF Private stack overflow/underflow detected for prog bpf_prog_a41699c234a1567a_subprog1x
Those messages are generated when I made some changes to jitted code
to intentially cause overflow for some progs.
For the jited prog, The x86 register 9 (X86_REG_R9) is used to replace
bpf frame register (BPF_REG_10). The private stack is used per
subprog per cpu. The X86_REG_R9 is saved and restored around every
func call (not including tailcall) to maintain correctness of
X86_REG_R9.
Signed-off-by: Yonghong Song <yonghong.song@linux.dev>
Link: https://lore.kernel.org/r/20241112163922.2224385-1-yonghong.song@linux.dev
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Refactor the code to avoid repeated usage of bpf_prog->aux->stack_depth
in do_jit() func. If the private stack is used, the stack_depth will be
0 for that prog. Refactoring make it easy to adjust stack_depth.
Signed-off-by: Yonghong Song <yonghong.song@linux.dev>
Link: https://lore.kernel.org/r/20241112163917.2224189-1-yonghong.song@linux.dev
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
If private stack is used by any subprog, set that subprog
prog->aux->jits_use_priv_stack to be true so later jit can allocate
private stack for that subprog properly.
Also set env->prog->aux->jits_use_priv_stack to be true if
any subprog uses private stack. This is a use case for a
single main prog (no subprogs) to use private stack, and
also a use case for later struct-ops progs where
env->prog->aux->jits_use_priv_stack will enable recursion
check if any subprog uses private stack.
Signed-off-by: Yonghong Song <yonghong.song@linux.dev>
Link: https://lore.kernel.org/r/20241112163912.2224007-1-yonghong.song@linux.dev
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Private stack will be allocated with percpu allocator in jit time.
To avoid complexity at runtime, only one copy of private stack is
available per cpu per prog. So runtime recursion check is necessary
to avoid stack corruption.
Current private stack only supports kprobe/perf_event/tp/raw_tp
which has recursion check in the kernel, and prog types that use
bpf trampoline recursion check. For trampoline related prog types,
currently only tracing progs have recursion checking.
To avoid complexity, all async_cb subprogs use normal kernel stack
including those subprogs used by both main prog subtree and async_cb
subtree. Any prog having tail call also uses kernel stack.
To avoid jit penalty with private stack support, a subprog stack
size threshold is set such that only if the stack size is no less
than the threshold, private stack is supported. The current threshold
is 64 bytes. This avoids jit penality if the stack usage is small.
A useless 'continue' is also removed from a loop in func
check_max_stack_depth().
Signed-off-by: Yonghong Song <yonghong.song@linux.dev>
Link: https://lore.kernel.org/r/20241112163907.2223839-1-yonghong.song@linux.dev
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
These two fields are populated and stored as a "frequently used value"
in ufs_fill_super, but are not used afterwards in the driver.
Moreover, one of the shifts triggers UBSAN: shift-out-of-bounds when
apbshift is 12 because 12 * 3 = 36 and 1 << 36 does not fit in the 32
bit integer used to store the value.
Closes: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2087853
Signed-off-by: Agathe Porte <agathe.porte@canonical.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
It seems that the cacheflush syscall got broken when PAN for LPAE was
implemented. User access was not enabled around the cache maintenance
instructions, causing them to fault.
Fixes: 7af5b901e8 ("ARM: 9358/2: Implement PAN for LPAE by TTBR0 page table walks disablement")
Reported-by: Michał Pecio <michal.pecio@gmail.com>
Tested-by: Michał Pecio <michal.pecio@gmail.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
There is a spelling mistake of 'absense' in comments which
should be 'absence'.
Link: https://lore.kernel.org/all/fca25741-c89f-43ea-95af-5e3232d513fc@arm.com/
Signed-off-by: WangYuli <wangyuli@uniontech.com>
Reviewed-by: Vladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
When enabling expert mode CONFIG_EXPERT and using that power
user mode to disable the branch prediction hardening
!CONFIG_HARDEN_BRANCH_PREDICTOR, the assembly linker
in CLANG notices that some assembly in proc-v7.S does
not have corresponding C call sites, i.e. the prototypes
in proc-v7-bugs.c are enclosed in ifdef
CONFIG_HARDEN_BRANCH_PREDICTOR so this assembly:
SYM_TYPED_FUNC_START(cpu_v7_smc_switch_mm)
SYM_TYPED_FUNC_START(cpu_v7_hvc_switch_mm)
Results in:
ld.lld: error: undefined symbol: __kcfi_typeid_cpu_v7_smc_switch_mm
>>> referenced by proc-v7.S:94 (.../arch/arm/mm/proc-v7.S:94)
>>> arch/arm/mm/proc-v7.o:(.text+0x108) in archive vmlinux.a
ld.lld: error: undefined symbol: __kcfi_typeid_cpu_v7_hvc_switch_mm
>>> referenced by proc-v7.S:105 (.../arch/arm/mm/proc-v7.S:105)
>>> arch/arm/mm/proc-v7.o:(.text+0x124) in archive vmlinux.a
Fix this by adding an additional requirement that
CONFIG_HARDEN_BRANCH_PREDICTOR has to be enabled to compile
these assembly calls.
Closes: https://lore.kernel.org/oe-kbuild-all/202411041456.ZsoEiD7T-lkp@intel.com/
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
For compiling with W=1, the following warning can be seen:
drivers/md/raid5.c: In function ‘setup_conf’:
drivers/md/raid5.c:2423:12: error: ‘%s’ directive output may be truncated writing up to 31 bytes into a region of size between 16 and 26 [-Werror=format-truncation=]
"raid%d-%s", conf->level, mdname(conf->mddev));
^~
drivers/md/raid5.c:2422:3: note: ‘snprintf’ output between 7 and 48 bytes into a destination of size 32
snprintf(conf->cache_name[0], namelen,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"raid%d-%s", conf->level, mdname(conf->mddev));
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
Increase the array size to avoid this warning.
Signed-off-by: John Garry <john.g.garry@oracle.com>
Link: https://lore.kernel.org/r/20241112161019.4154616-2-john.g.garry@oracle.com
Signed-off-by: Song Liu <song@kernel.org>
The boolean variable has_affinity is true when desc is non-null and
ops->set_vq_affinity is non-null. Hence the call to create_affinity_masks
does not need to check for desc being non-null is redundant when
has_affinity is true, so it can be removed as well as the now unused
default_affd.
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Message-Id: <20241107132114.22188-1-colin.i.king@gmail.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Eugenio Pérez <eperezma@redhat.com>
This will eliminate the need for index recalculation during the fast
path.
Signed-off-by: Max Gurtovoy <mgurtovoy@nvidia.com>
Message-Id: <20241006184341.9081-1-mgurtovoy@nvidia.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Enhance the device probing process by adding a log message when a new
virtio-fs tag is successfully discovered. This improvement provides
better visibility into the initialization of virtio-fs devices.
Signed-off-by: Max Gurtovoy <mgurtovoy@nvidia.com>
Message-Id: <20241006184324.8497-1-mgurtovoy@nvidia.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
It is used for testing in tools/virtio/vringh_test.c.
If vring_new_virtqueue supports packed vring, we can add support for
packed vring to vringh and test it.
Signed-off-by: Wenyu Huang <huangwenyu1998@gmail.com>
Message-Id: <20241013033233.65026-1-huangwenyu1998@gmail.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Add basic freeze/restore PM callbacks to support hibernation (S4):
- On freeze, delete vq and quiesce the device to prepare for
snapshotting.
- On restore, re-init vq and mark DRIVER_OK.
Signed-off-by: Philip Chen <philipchen@chromium.org>
Message-Id: <20240815004617.2325269-1-philipchen@chromium.org>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
The starting iova address to iterate iotlb map entry within a range
was set to an irrelevant value when passing to the itree_next()
iterator, although luckily it doesn't affect the outcome of finding
out the granule of the smallest iotlb map size. Fix the code to make
it consistent with the following for-loop.
Fixes: 94abbccdf2 ("vdpa/mlx5: Add shared memory registration code")
Signed-off-by: Si-Wei Liu <si-wei.liu@oracle.com>
Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com>
Message-Id: <20241021134040.975221-3-dtatulea@nvidia.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
When calculating the physical address range based on the iotlb and mr
[start,end) ranges, the offset of mr->start relative to map->start
is not taken into account. This leads to some incorrect and duplicate
mappings.
For the case when mr->start < map->start the code is already correct:
the range in [mr->start, map->start) was handled by a different
iteration.
Fixes: 94abbccdf2 ("vdpa/mlx5: Add shared memory registration code")
Cc: stable@vger.kernel.org
Signed-off-by: Si-Wei Liu <si-wei.liu@oracle.com>
Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com>
Message-Id: <20241021134040.975221-2-dtatulea@nvidia.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Commit d1703dc7bc ("RISC-V: Detect unaligned vector accesses
supported") removed the default handlers for handle_misaligned_load()
and handle_misaligned_store(). When the kernel is compiled without
RISCV_SCALAR_MISALIGNED, these handlers are never defined, causing
compilation errors.
Signed-off-by: Charlie Jenkins <charlie@rivosinc.com>
Fixes: d1703dc7bc ("RISC-V: Detect unaligned vector accesses supported")
Reviewed-by: Jesse Taube <mr.bossman075@gmail.com>
Link: https://lore.kernel.org/r/20241108-fix_handle_misaligned_load-v2-1-91d547ce64db@rivosinc.com
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
There is a strapping issue on NBIO 7.7.0 that can lead to spurious PME
events while in the D0 state.
Co-developed-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Link: https://lore.kernel.org/r/20241112161142.28974-1-mario.limonciello@amd.com
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 447a54a0f7)
Cc: stable@vger.kernel.org
That is just a waste of time on APUs.
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3704
Fixes: 216c1282dd ("drm/amdgpu: use GTT only as fallback for VRAM|GTT")
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit e8fc090d32)
Cc: stable@vger.kernel.org
If srcu_read_lock_lite() is used on a given srcu_struct structure, then
the grace-period processing must do synchronize_rcu() instead of smp_mb()
between the scans of the ->srcu_unlock_count[] and ->srcu_lock_count[]
counters. Currently, it does that by testing the SRCU_READ_FLAVOR_LITE
bit of the ->srcu_reader_flavor mask, which works well. But only if
the CPU running that srcu_struct structure's grace period has previously
executed srcu_read_lock_lite(), which might not be the case, especially
just after that srcu_struct structure has been created and initialized.
This commit therefore updates the srcu_readers_unlock_idx() function
to OR together the ->srcu_reader_flavor masks from all CPUs, and
then make the srcu_readers_active_idx_check() function that test the
SRCU_READ_FLAVOR_LITE bit in the resulting mask.
Note that the srcu_readers_unlock_idx() function is already scanning all
the CPUs to sum up the ->srcu_unlock_count[] fields and that this is on
the grace-period slow path, hence no concerns about the small amount of
extra work.
Reported-by: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>
Closes: https://lore.kernel.org/all/d07e8f4a-d5ff-4c8e-8e61-50db285c57e9@amd.com/
Fixes: c0f08d6b5a61 ("srcu: Add srcu_read_lock_lite() and srcu_read_unlock_lite()")
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Cc: Frederic Weisbecker <frederic@kernel.org>
Reviewed-by: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>
Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
The srcu_read_unlock_lite() function invokes __srcu_read_unlock() instead
of __srcu_read_unlock_lite(), which means that it is doing an unnecessary
smp_mb(). This is harmless other than the performance degradation.
This commit therefore switches to __srcu_read_unlock_lite().
Reported-by: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>
Closes: https://lore.kernel.org/all/d07e8f4a-d5ff-4c8e-8e61-50db285c57e9@amd.com/
Fixes: c0f08d6b5a61 ("srcu: Add srcu_read_lock_lite() and srcu_read_unlock_lite()")
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Cc: Frederic Weisbecker <frederic@kernel.org>
Reviewed-by: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>
Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
- A change from Andrew Davis to convert i.MX6 PM code to use new
sys-off API
-----BEGIN PGP SIGNATURE-----
iQFIBAABCgAyFiEEFmJXigPl4LoGSz08UFdYWoewfM4FAmcoe/MUHHNoYXduZ3Vv
QGtlcm5lbC5vcmcACgkQUFdYWoewfM58Ogf/Z3+r8M479tEnIkCMMy64Fpl7KlTJ
LvEZGChV7kaqTrwcE5HzW1sVbccNZbBVtXICjOfyleRI251dsxr3/c0DcduWxNM1
Ss10x7yavWReJUCscLDiIDMKA6IIGR6z3V5BJUWj43iVdImIGWLgoJwbbWwKWn07
qoc+S38gcws5JUSZtahEEIaOv98x8olOrFxKV5x0zMYK7tvD83rpmvxFFJFnbiXN
DlPykFvIY42+G1QpHCiND0JzPpLAN9XZE62Rpt045OMKswJFTJR6+Wo0cpsCYIJE
COOyTukXW1xgnYtsP2YL/Wpj40hk+bIr7WAu6GnT2ES3OIjwQNgyFsjyqA==
=Q548
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmcz01oACgkQYKtH/8kJ
UifZ4A//bf7ctofN4CBUtdwpS4FeQKgwVQzs4naI5t6idP2EmWSfPBeVOxwKpTB9
6bKSuK2iVq3qf+o7rQC4RasHDylzGN442hVOXVs5h0rIYjQ3k5DXsMCk7VYzO+qZ
8ycx5hFr6j5XNCweMyVc/QVITiwo4iIUKJ89xa1fvHyvB5zgB5vyTA0oyUFnyp2w
Rv1c/9ovL3A5+lunTO35gpgW6qHf12Z4r1ihdMIpRy4JmHjwzXzBPS43AkBcC5ed
qb8G4EHjFO1xcFuNcumvbvSZqGgsoUBiDS0kvWuvpRjAsmRNKb56XN7LEbTVvl0h
Fgi5mnstWewpomswo7vEhT/PytqCB3+klkaozkXYjmParLrKXhU6k2+xuBfgn0ge
VaZnijGyorV8cRmDFka2UDwyBdFmDrFHELiP35NWvHaKIfnulJQ3TrFKwWf4M8a+
F3kPcp0faSJusFebm8YDIXJPkeG3MhcT7KyXFwhJTpXtBMJgqtxtttwT4VkRld0l
gCC8FJvTX+YjqJ8wPz3/HEBxBnvbgg5jotOTdcS3Z/3ooLCVONMlU+hDQ0RFCxSe
BFuYYkyNA5wvknWMgv8W024q6VVRut5quwFdgMibAcK1EH31o4V8USQKGT7h9vpJ
cPkdIxCys4FJkrN54wTMfw16KvqOHhWFsIqXdPWr74gwKvlXkp4=
=IX9G
-----END PGP SIGNATURE-----
Merge tag 'imx-soc-6.13' of https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into soc/arm
i.MX SoC changes for 6.13:
- A change from Andrew Davis to convert i.MX6 PM code to use new
sys-off API
* tag 'imx-soc-6.13' of https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux:
ARM: imx: Switch to new sys-off handler API
Link: https://lore.kernel.org/r/20241104090055.1881860-2-shawnguo2@yeah.net
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
please pull the following:
- Linus adds support for the debug UART on BCM6846 (BCMBCA) platform
- Florian dros the custom init_irq() callback which does the same thing
as the standard irqchip_init()
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEm+Rq3+YGJdiR9yuFh9CWnEQHBwQFAmcfCrEACgkQh9CWnEQH
BwRxBxAArVZ/cjrpMTvmNi9qgoZaT6Qtp5+fMdATSbIA6+O1lW+04anmGliH4ntm
gTsrchds8c3+Uf78rMWcI4rwztInRb7k2tjtWsH1S6Z+xWwaC050AVNvlQP66QJJ
N/S5WMTtROVE3ZXLENGQLdeTUvjoZjfvydUCReOsH1CX8aqnKNGzUjEW6O7mPtAc
1wWpQnZ/9BVEikcnKhcWouS5MkXejwbOO7YIbpQfUQCHOUjuSj5QAfZSZfNZpVOJ
OHtTS0Ukw3Ejcd8zNYI8+zBzNMyhuwnbKmMaE7CMK8PyfU1gx9Gp/0dQUunTx1eJ
Fj6QyzZ5Tw4U/Li4O9g90X+rdcCsuAjhDW1uf7SyaBTuSChCDrtrYcjXiNxnWOLs
vJiZOzj5VhHJNEKgVeJSGi17ZmXIqxOCKeMEVoG3N6430/tz5OsN8GlQlyZXsEe3
PWG9LsHrG78zSQs3bP8nzkW0yVmErvhoyaNXfL3EY/+4QnYgSn7tQG4L+ztIG93W
fC+TBz/zN3+cs9TpXBcnRK/Bv7+CSQGWvsqikPL7+zM0eshtyFwKzAUAM4ox0kaN
Es9f8Y6sjbRKu4J7n9cUHXzudh3El3P9fE47+oTLJwL8AL2H865A/EALYs6qaEW0
uTx7S4IskKn8hvV5UmBX10JXG6Vet3b5EfWPGULf9QuKcH+IcKc=
=IKb0
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmcz0sQACgkQYKtH/8kJ
Uife1g/9Gv6grB9m9KP3bu631sptFXPAAUHXRAxRzIbX46pSVBVNGxtcvTp07Og0
1Ise+WgJNReMW9JZplZGg7YubpfEbA0hLskOHBR7oJWQ4R2NvvKdx1bJB+oIo87h
UnlW+AeX4RlXVyfu4GkNXPHlWNnSU166njGJ7oqk6d9ExZMJZw31bBqVL6bZrKSe
VJyNr9iqKJ7upfFl0ldY9N6pL5ubZxWz54ni55HPtSe4BaCtfGoo4zM2SxDZiVPE
jbIhU/2GfOUysWdoxoZIQDqL8gyqC/tb2W1DDtQUgYmIK2WPiaqEtrBeot2tYE+6
UbldlaUsVmwAGtj367dyz8g45cIlcMLKQuasFSS2LYl4+YgUxqujXxvxvxWNTvYc
8PE72ZgzrOuTvOJPI5sFO0XTrsN3MbeJSKmsWQda3imZ3B2Zyc2mxV9tZCBsDw3O
3S+2dui3T4oppGLqUtqt6oocVVtf86lTSQHaVGlakFQ/Wo3uLRprvcluXjbQL4Qm
VS8qJ84cYgw7kxzWUwzBcUK2NdUDo+lExpAqSUUkSJOBIt0ey/7TWB2bE8u1NJ5y
PByGOuPQYzFBHvKHQcVOHADNyMEEkNRTwlYeblmA0WkwmtfxX6dY8yeR+v1d4PjC
T1ctBNOPUSewVKypbVZT1lQ4TtIN7t+MDKYXeHJD06/yU/6XYg0=
=pE/r
-----END PGP SIGNATURE-----
Merge tag 'arm-soc/for-6.13/soc' of https://github.com/Broadcom/stblinux into soc/arm
This pull request contains Broadcom ARM-based SoC changes for 6.13,
please pull the following:
- Linus adds support for the debug UART on BCM6846 (BCMBCA) platform
- Florian dros the custom init_irq() callback which does the same thing
as the standard irqchip_init()
* tag 'arm-soc/for-6.13/soc' of https://github.com/Broadcom/stblinux:
ARM: bcm: brcmstb: Drop custom init_irq callback
ARM: bcm: Support BCMBCA debug UART
Link: https://lore.kernel.org/r/20241028035449.734504-2-florian.fainelli@broadcom.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
There is a strapping issue on NBIO 7.7.0 that can lead to spurious PME
events while in the D0 state.
Co-developed-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Link: https://lore.kernel.org/r/20241112161142.28974-1-mario.limonciello@amd.com
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
That is just a waste of time on APUs.
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3704
Fixes: 216c1282dd ("drm/amdgpu: use GTT only as fallback for VRAM|GTT")
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
- Enable Battery Backup Function (VBATTB) and RTC support for the
RZ/G3S SoC and the RZ/G3S SMARC SoM.
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQQ9qaHoIs/1I4cXmEiKwlD9ZEnxcAUCZyjGoAAKCRCKwlD9ZEnx
cNneAPwMpcOT+xNkIHv3DAdOML2LEPEJlSW0NVjL51xV8FdNKgD+PqNQjo7E54QK
RqeJwTxiAxiSZQoe9vCOZ3Fx/DTnfA8=
=PPxK
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmcz0hsACgkQYKtH/8kJ
UidqpBAArgPtM8HDE67Xn9whNezu4MPBkE54T7a9/7nBUIhlkEET+DFJr45T7k93
IWESaD9ycW09l8V969Wz5iohTLQew0+Nm8rXPy/JL8JiKOU3JRohdXxxCaFZAhPZ
Vo+6USQK9ZeA47EcAhVVWRNriMRYNjlwbCQ4qR0P3A+HfKMo1bZGwJBlz2/Suub9
twQA2rhc1V+a8Ja6Yl9Qxb2Wb7vplLNG8Q/X9KmelYtLgG3bl15/2O7AcYox9yYi
72YgvsjO3bOCULder1muiZdR/WWkf11v918AENGHfqZHbdEPDNzFv47E/Wj0dnFz
/yrPfwqnnFKeg9r7Ly8yX8+t5Ha8OmyVfqB14MngQaiRRqLR2EqwMzxiYGpY8LL7
iLcNiYN2bFocBrSsGZm8cnJ25bBrEyU2urRB+M4iaIfPAPVBhu6XIBI1y+yuhw9d
F7rexA6iO6IKa98rd/QghP2WfK2hnGpDbJO/TXJWyrpov1YNlx7IoyUhnU6erSsO
cF4CeCYCPP4pnHoNERDDcOghL5eLkKxv8tmMp84J7rfdsqtyEEfbkySkHuHbxYsk
Uf9j5Br9o6asJfmGXBjP5GsEBjZlB8Jcnf0JSfvPIGB2gktu//eKhzfmk9FYTNv3
tcIYBrv+OYRrUInFrz4mbvf4y/VRrqs0gWLjn6w/UpRsSJkG8/o=
=UmbS
-----END PGP SIGNATURE-----
Merge tag 'renesas-arm-defconfig-for-v6.13-tag1' of https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into soc/defconfig
Renesas ARM defconfig updates for v6.13
- Enable Battery Backup Function (VBATTB) and RTC support for the
RZ/G3S SoC and the RZ/G3S SMARC SoM.
* tag 'renesas-arm-defconfig-for-v6.13-tag1' of https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel:
arm64: defconfig: Enable VBATTB clock and Renesas RTCA-3
Link: https://lore.kernel.org/r/cover.1730726154.git.geert+renesas@glider.be
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
- Enable BD71828 regulator and NXPUART Bluetooth driver support in
imx_v6_v7_defconfig (needed by Kobo Clara 2E device)
-----BEGIN PGP SIGNATURE-----
iQFIBAABCgAyFiEEFmJXigPl4LoGSz08UFdYWoewfM4FAmcojA0UHHNoYXduZ3Vv
QGtlcm5lbC5vcmcACgkQUFdYWoewfM5PTAgAuIjJWSs48S1ITX67Y3T8ZeaKTpcc
gkfy2D/2VF39gWSfWGyFFQBUToBInu5WZQmUX/z8tKeEKuKneEh1YxSDyWdH0Dop
+VmSXcNotemQAvTirc9n6XixxH6seouIeZYvHYW/KwMcfrhZc3F2ALsKI+40NkAp
5v6JVRmRjmS0+FrMR2MqPDvrfoRzO6ENbKs1Y+wjOEvCld6AaLHGInSGW0+UmB8b
UzFdg7m+NBHGGZ3eTWIhkXh8vOkJ1o3WERV6it8GPVevsJg9X9eKo7m9HICPwVeV
I6EFpmAq7kLS4U8+BpuqcnGOzm8CBl5JVEg76Qe1RqlzZlz3JGlUbSEZ2Q==
=moI9
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmcz0f0ACgkQYKtH/8kJ
Uifd5Q/6A6h66NLDqDOpsTnQHGxMXYdWPyPnd+R9/tpiCyB8rijuBlPNJYeTATyB
5RYeQilAjtWRJBB9Bg67lFAQZC/orID4nAnO05gHlxi+dGjiUtdxSIXnplt+8vYE
9vDjNFBakL6jhWL65Bj5thL0Ijvm75Mk3/ttAqrtsrB7FLyV0XqV4NWEr510PvgM
Zb35YnzUS83ukZ1d1vXOexrzaq+GaMdKvJlu7olAvZEiPeTxZWF3lgl0HY21ZoOx
/viyvDQVA1aG0pInvXxxLv9mzPNMoMreEgHpPlXVunAsQAkRYgWS737PQHer9JEi
J6OG9D/bNUj/GqVsbTpk74QWMranMhbD7ICA1X+DoWYm5WNm6PSydIFjSfTNOCP8
lLZueyce1+bMmeu406L4YpGMMJXZcPdTYuNwipkj72InBasgoFcly+kUgetWNFCt
s9M0XyrKvXd9Fq1TxMuADNzslWJulRXL6BrOopmTEgdUS8zoiXUgPUHqeP+2dUmk
bLvSEp+zHG3VrQOATLa6Ge6x+HHyLuj6IzFAgcPzXpBhLkcHdwkWWlYU8ESHG9NX
H+EngiKrNFlSZUChIMynPbjrcIXS8QQ1mU+V1XAUE8DQIGT7l3YcRlHatB2ozuw0
6FsEzcQ1PXHe+L5S4i7Nta+z0zoz75JZyg5D4De+4yu8wFq5qEY=
=iawl
-----END PGP SIGNATURE-----
Merge tag 'imx-defconfig-6.13' of https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into soc/defconfig
i.MX defconfig changes for 6.13:
- Enable BD71828 regulator and NXPUART Bluetooth driver support in
imx_v6_v7_defconfig (needed by Kobo Clara 2E device)
* tag 'imx-defconfig-6.13' of https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux:
ARM: imx_v6_v7_defconfig: Enable drivers for Kobo Clara 2E
Link: https://lore.kernel.org/r/20241104090055.1881860-6-shawnguo2@yeah.net
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
- Florian aligns the ARM64 and ARM multi_v7_defconfig by enabling the
kernel with debugging symbols by default and using the toolchain's
dwarf version
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEm+Rq3+YGJdiR9yuFh9CWnEQHBwQFAmcfCvQACgkQh9CWnEQH
BwR9wBAAvhEZTD0qYLCXwFk1rA3CV0y2RNiw9v+lD2MmBCjviqVKJ6WtyCVDttm8
15w83QfCEs8JnHv/iEYtsXKDM5GRb6Ukz9CJj1cSPZmwql6Te7mXTwzKcBqY9ZUV
t85OK4RgIYTohyL5wdncMpyF0axP0qjT2KSc5/wFiyoefaywLSeifvHZHpIh0xEK
004eVuAVGKt7lMwvC6/rd0e8+ZpC81Utueonkl/qRcU7YQmn1JkfFL8wAWMAMwXQ
FUDjwfIyPCXaf9ZN//FbEpFAjded5PmLL5zyWCEuYAMMtliwMlbr08CGw6z5UrD0
w8DNhSMC60K9bHKnVCCGvTpgS05GOFLuZ5iaQt+e+PUYUyx42qfG1RkJmB4/xU5i
ktfkId14ZeizI1e6dXg6k+B7RltVMASpcjt7p4K6/XP/jk5N0wN7WDBk1lNK4/XO
hlVLYbv4UJGOJlpsVIJBNg0pPzeI08p21uwZLDP916eoj9NbIjQq7IRrfTtO7qCe
wsVaE5E0zIk8nYw1GQXH6e/VZTQ9gnoHAUC+Kv7lstmDx2VSh5lq5R/s90mfyTj1
VxevabH6pxkQYzMm4BvWmjRzuty0MCCLO1+Jzr8399nwtPXOrW1V8f/q/5lakh1w
lX3e6wpEeoDxscRlGot9Tl4hrUAW/e1JEiApObMqvtiqVke/wjU=
=Dt31
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmcz0XkACgkQYKtH/8kJ
UielaQ/8DY6aGGtoE6a2PgGHW8F/3KILuva1fNFc42sL+bbZQxdxKbz5Bh0lUcrR
1AwDYgFVBI+yFi0cSDKhva0f9d66WhYeQRGNP2Bdqyg9B8Jk8Pr0TOf3f9fCgGGr
qISxCNr9vGI3auEjc+pfO4GesxOheQ8wyYDKuXsD9n7Ryxyvc8hpH2LMSZXr9t+Y
t1xHRtykt4pkt5wpbiXrJLmdmyK6oW5P6Ltw1sXkHRJRxkxrQmOEooz/XYE+iOHt
gQDaKwdtEL+zhgORa+diIn1p+l5x00VOq1e+qx7/LzJ4Oz/NMcLQUtIXbbp/LVZ5
6F0c2/FUbN/dJWOndzAwSjRAc6NrAFvKjNp9NnfT7JIO2t+MYOxbsp4hBPDPYNoZ
jK8Fy6Gsq9nyteEPNswm0Y3e0tkdR5EXmo5mnAIl8M0uJFg1EbvrLVeSwEuOAslV
sbjXa0uR2MpecDVrxFVJMtbQjw/rOngDz991+tjEmMR1q7sQXVOhJCQrz/Js0JgJ
p33o0lA1SZ4tki1VA3h7UmGiOllGFU5Df+sxGrqT/+sBtJFLbshVNePFQQecyp0O
yoGuDY8sIfu5JQ8Pa6QuB1FYo2kz3VPPhqPRzQ/uJu6MpIQJisybguJBaGQm5i9i
MAslPLtwRDUzL/W+WvNTfrzZlvyD0VavAVDNw2n0za93FWPkjio=
=1G37
-----END PGP SIGNATURE-----
Merge tag 'arm-soc/for-6.13/defconfig' of https://github.com/Broadcom/stblinux into soc/defconfig
This pull request contains a multi_v7_defconfig update:
- Florian aligns the ARM64 and ARM multi_v7_defconfig by enabling the
kernel with debugging symbols by default and using the toolchain's
dwarf version
* tag 'arm-soc/for-6.13/defconfig' of https://github.com/Broadcom/stblinux:
ARM: multi_v7_defconfig: Enable debugging symbols by default
Link: https://lore.kernel.org/r/20241028035449.734504-1-florian.fainelli@broadcom.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
If a CPU runs throughout the stalled grace period without passing
through a quiescent state, RCU priority boosting cannot help.
The rcu_torture_boost_failed() function therefore prints a message
flagging the first such CPU. However, if the stall was instead due to
(for example) RCU's grace-period kthread being starved of CPU, there will
be no such CPU, causing rcu_check_boost_fail() to instead pass back -1
through its cpup CPU-pointer parameter.
Therefore, the current message complains about a mythical CPU -1.
This commit therefore checks for this situation, and notes that all CPUs
have passed through a quiescent state.
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Reviewed-by: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>
Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
This commit adds a guest_os_delay module parameter that extends warm-up
and cool-down the specified number of seconds before and after the series
of test runs. This allows the data-collection intervals from any given
rcuscale guest OSes to line up with active periods in the other rcuscale
guest OSes, and also allows the thermal warm-up period required to obtain
consistent results from one test to the next.
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Reviewed-by: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>
Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
The current affinity check works fine until there are more reader
processes than CPUs, at which point the affinity check is looking for
non-existent CPUs. This commit therefore applies the same modulus to
the check as is present in the set_cpus_allowed_ptr() call.
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Reviewed-by: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>
Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
In performance tests, it can be counter-productive to spread torture-test
guest OSes across sockets. Plus the experimenter might have ideas about
what CPUs individual guest OSes are to run on. This commit therefore
adds a --no-affinity parameter to kvm.sh to prevent it from running
taskset on its guest OSes.
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Reviewed-by: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>
Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
