On Mon, Oct 07, 2024 at 08:22:39PM +0530, Mukesh Ojha wrote:
> On Mon, Oct 07, 2024 at 10:05:08AM +0200, neil.armstr...@linaro.org wrote:
> > On 04/10/2024 23:23, Mukesh Ojha wrote:
> > > For Qualcomm SoCs runnning with Qualcomm EL2 hypervisor(QHEE), IOMMU
> > > translation for remote processors is
On Sat, Oct 05, 2024 at 02:56:00PM -0700, Greg Thelen wrote:
> Starting with 6.12 commit 85585b4bc8d8 ("selftests: add ncdevmem, netcat
> for devmem TCP") kselftest-all creates additional outputs that
> kselftest-clean does not cleanup:
> $ make defconfig
> $ make kselftest-all
> $ make kself
On Mon, Oct 7, 2024 at 11:29 AM Tyrone Wu wrote:
>
> From: tyrone-wu
>
> Previously when retrieving `bpf_link_info.perf_event` for
> kprobe/uprobe/tracepoint, the `name_len` field was not populated by the
> kernel, leaving it to reflect the value initially set by the user. This
> behavior was inc
On Mon, Oct 07, 2024 at 07:59:35PM GMT, Jonathan Marek wrote:
> The name len field of the CMD_OPEN packet is only 16-bits and the upper
> 16-bits of "param2" are a different "prio" field, which can be nonzero in
> certain situations, and CMD_OPEN packets can be unexpectedly dropped
> because of thi
Hello:
This series was applied to bpf/bpf-next.git (master)
by Andrii Nakryiko :
On Fri, 27 Sep 2024 15:13:52 +0200 you wrote:
> From: Björn Töpel
>
> libbpf does not include the per-arch tools include path, e.g.
> tools/arch/riscv/include. Some architectures depend those files to
> build prope
Hi Ignat,
Thanks for the patch.
On Tue. 8 Oct. 2024 at 06:37, Ignat Korchagin wrote:
> On error can_create() frees the allocated sk object, but sock_init_data()
> has already attached it to the provided sock object. This will leave a
> dangling sk pointer in the sock object and may cause use-aft
The previous commit introduced the use of CLONE_NEWTIME without including
which contains its definition.
Add an explicit include of to ensure that CLONE_NEWTIME
is correctly defined before it is used.
Fixes: 2aec90036dcd ("selftests: vDSO: ensure vgetrandom works in a time
namespace")
Signed-o
Hi, Josh.
> On Oct 8, 2024, at 01:39, Josh Poimboeuf wrote:
>
> On Mon, Oct 07, 2024 at 10:11:39PM +0800, Wardenjohn wrote:
>> Add test case of stack_order sysfs interface of livepatch.
>>
>> Signed-off-by: Wardenjohn
>> ---
>> .../testing/selftests/livepatch/test-sysfs.sh | 24 ++
Add "stack_order" sysfs attribute which holds the order in which a live
patch module was loaded into the system. A user can then determine an
active live patched version of a function.
cat /sys/kernel/livepatch/livepatch_1/stack_order -> 1
means that livepatch_1 is the first live patch applied
c
As previous discussion, maintainers think that patch-level sysfs interface is
the
only acceptable way to maintain the information of the order that klp_patch is
applied to the system.
However, the previous patch introduce klp_ops into klp_func is a optimization
methods of the patch introducing
Add "stack_order" sysfs attribute which holds the order in which a live
patch module was loaded into the system. A user can then determine an
active live patched version of a function.
cat /sys/kernel/livepatch/livepatch_1/stack_order -> 1
means that livepatch_1 is the first live patch applied
c
As previous discussion, maintainers think that patch-level sysfs interface is
the
only acceptable way to maintain the information of the order that klp_patch is
applied to the system.
However, the previous patch introduce klp_ops into klp_func is a optimization
methods of the patch introducing
在 2024/10/2 20:15, Daniel Borkmann 写道:
On 9/30/24 3:33 AM, Yaxiong Tian wrote:
From: Yaxiong Tian
To save some running memory,Add __init and __exit to the
module load/unload functions.
Signed-off-by: Yaxiong Tian
---
tools/testing/selftests/bpf/bpf_test_no_cfi/bpf_test_no_cfi.c | 4 ++--
On Mon, 7 Oct 2024 22:34:55 +0100 Ignat Korchagin wrote:
> diff --git a/net/socket.c b/net/socket.c
> index 601ad74930ef..042451f01c65 100644
> --- a/net/socket.c
> +++ b/net/socket.c
> @@ -1574,8 +1574,13 @@ int __sock_create(struct net *net, int family, int
> type, int protocol,
> rcu_rea
The name len field of the CMD_OPEN packet is only 16-bits and the upper
16-bits of "param2" are a different "prio" field, which can be nonzero in
certain situations, and CMD_OPEN packets can be unexpectedly dropped
because of this.
Fix this by masking out the upper 16 bits of param2.
Fixes: b4f8e
On Sun, 2024-09-29 at 12:56 +0200, Thorsten Blum wrote:
> Use vmalloc_array() instead of vmalloc() to calculate the number of
> bytes to allocate.
>
> Signed-off-by: Thorsten Blum
> ---
> arch/x86/kernel/cpu/sgx/main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arc
> [PATCH v2 0/8] do not leave dangling sk pointers in pf->create functions
For the future patches, please specify the target tree, net or net-next.
From: Ignat Korchagin
Date: Mon, 7 Oct 2024 22:34:54 +0100
> Some protocol family create() implementations have an error path after
> allocating t
From: Ignat Korchagin
Date: Mon, 7 Oct 2024 22:34:55 +0100
> We have recently noticed the exact same KASAN splat as in commit
> 6cd4a78d962b ("net: do not leave a dangling sk pointer, when socket
> creation fails"). The problem is that commit did not fully address the
> problem, as some pf->creat
sock_init_data() attaches the allocated sk pointer to the provided sock
object. If inet6_create() fails later, the sk object is released, but the
sock object retains the dangling sk pointer, which may cause use-after-free
later.
Clear the sock sk pointer on error.
Signed-off-by: Ignat Korchagin
sock_init_data() attaches the allocated sk object to the provided sock
object. If inet_create() fails later, the sk object is freed, but the
sock object retains the dangling pointer, which may create use-after-free
later.
Clear the sk pointer in the sock object on error.
Signed-off-by: Ignat Korc
On error can_create() frees the allocated sk object, but sock_init_data()
has already attached it to the provided sock object. This will leave a
dangling sk pointer in the sock object and may cause use-after-free later.
Signed-off-by: Ignat Korchagin
---
net/can/af_can.c | 1 +
1 file changed, 1
sock_init_data() attaches the allocated sk object to the provided sock
object. If ieee802154_create() fails later, the allocated sk object is
freed, but the dangling pointer remains in the provided sock object, which
may allow use-after-free.
Clear the sk pointer in the sock object on error.
Sign
bt_sock_alloc() attaches allocated sk object to the provided sock object.
If rfcomm_dlc_alloc() fails, we release the sk object, but leave the
dangling pointer in the sock object, which may cause use-after-free.
Fix this by swapping calls to bt_sock_alloc() and rfcomm_dlc_alloc().
Signed-off-by:
bt_sock_alloc() allocates the sk object and attaches it to the provided
sock object. On error l2cap_sock_alloc() frees the sk object, but the
dangling pointer is still attached to the sock object, which may create
use-after-free in other code.
Signed-off-by: Ignat Korchagin
---
net/bluetooth/l2c
After sock_init_data() the allocated sk object is attached to the provided
sock object. On error, packet_create() frees the sk object leaving the
dangling pointer in the sock object on return. Some other code may try
to use this pointer and cause use-after-free.
Suggested-by: Eric Dumazet
Signed-
We have recently noticed the exact same KASAN splat as in commit
6cd4a78d962b ("net: do not leave a dangling sk pointer, when socket
creation fails"). The problem is that commit did not fully address the
problem, as some pf->create implementations do not use sk_common_release
in their error paths.
Some protocol family create() implementations have an error path after
allocating the sk object and calling sock_init_data(). sock_init_data()
attaches the allocated sk object to the sock object, provided by the
caller.
If the create() implementation errors out after calling sock_init_data(),
it r
On Mon, Oct 07, 2024 at 06:00:57PM +0200, Björn Töpel wrote:
> The sched_ext BPF programs relies on a vmlinux.h, which is generated
> using bpftool and the vmlinux with BTF information. Have you built a
> kernel with BTF support?
OK, so having beaten the kernel config into shape and using GCC rat
At least since commit 334304ac2bac ("dma-mapping: don't return errors
from dma_set_max_seg_size") setting up device.dma_parms is basically
mandated by the DMA API. As of now Channel (CCW) I/O in general does not
utilize the DMA API, except for virtio. For virtio-ccw however the
common virtio DMA in
On Mon, Oct 07, 2024 at 03:28:16PM -0300, Jason Gunthorpe wrote:
> On Mon, Oct 07, 2024 at 10:25:01AM -0700, Nicolin Chen wrote:
>
> > This is for vdev/dev v.s. hwpt. We need the lock for viommu's
> > vdev xarray.
> >
> > Yet, giving a 2nd thought, I feel the lock would be useless if
> > a driver
On Mon, Oct 07, 2024 at 06:45:32PM +0200, Björn Töpel wrote:
> Mark Brown writes:
> > I didn't actually build a kernel, if the build system needs a kernel
> > it's just silently not detected that it's missing?
> It tries to find a kernel with BTF:
> | VMLINUX_BTF_PATHS ?= $(if $(O),$(O)/vmlinu
On 2024-10-07 21:06, Paul E. McKenney wrote:
On Mon, Oct 07, 2024 at 11:18:14AM -0700, Paul E. McKenney wrote:
On Mon, Oct 07, 2024 at 10:50:46AM -0400, Mathieu Desnoyers wrote:
On 2024-10-07 12:40, Peter Zijlstra wrote:
On Sat, Oct 05, 2024 at 02:50:17PM -0400, Mathieu Desnoyers wrote:
On 20
On Tue, Oct 01, 2024 at 02:15:52PM -0700, Bjorn Andersson wrote:
> On Tue, Oct 01, 2024 at 12:06:17PM +0530, Mukesh Ojha wrote:
> > On Fri, Sep 27, 2024 at 02:59:09PM -0700, Bjorn Andersson wrote:
> > > On Sat, Sep 28, 2024 at 01:07:43AM +0530, Mukesh Ojha wrote:
> > > > On Wed, Sep 25, 2024 at 08:
On Mon, Oct 07, 2024 at 11:18:14AM -0700, Paul E. McKenney wrote:
> On Mon, Oct 07, 2024 at 10:50:46AM -0400, Mathieu Desnoyers wrote:
> > On 2024-10-07 12:40, Peter Zijlstra wrote:
> > > On Sat, Oct 05, 2024 at 02:50:17PM -0400, Mathieu Desnoyers wrote:
> > > > On 2024-10-05 18:04, Peter Zijlstra
On Sun, Oct 06, 2024 at 10:34:19PM +0300, Dmitry Baryshkov wrote:
> On Sat, Oct 05, 2024 at 02:53:53AM GMT, Mukesh Ojha wrote:
> > Qualcomm is looking to enable remote processors on the SA8775p SoC
> > running KVM Linux host and is currently trying to figure out an
> > upstream-compatible solution
The pull request you sent on Mon, 7 Oct 2024 11:51:58 -0400:
> https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/87d6aab2389e5ce0197d8257d5f8ee965a67c4cd
Thank you!
--
Deet-doot-dot, I am a bo
On Tue, 8 Oct 2024 00:20:43 +0800 I Hsin Cheng wrote:
> > I would recommend updating the patch description slightly, as it's a
> > little bit confusing as-is (partly due to the early version having
> > already been applied and reverted).
>
> No problem, I'll refine the commit message, hoever, I
From: tyrone-wu
Fix `name_len` field assertions in `bpf_link_info.perf_event` for
kprobe/uprobe/tracepoint to validate correct name size instead of 0.
Link:
https://lore.kernel.org/bpf/cabvu1kxwqxhqqge0rtrr7eegtm6svw_kayzby16-yb0snzt...@mail.gmail.com/
Fixes: 23cf7aa539dc ("selftests/bpf: Add s
From: tyrone-wu
Previously when retrieving `bpf_link_info.perf_event` for
kprobe/uprobe/tracepoint, the `name_len` field was not populated by the
kernel, leaving it to reflect the value initially set by the user. This
behavior was inconsistent with how other input/output string buffer
fields func
On Mon, Oct 07, 2024 at 10:25:01AM -0700, Nicolin Chen wrote:
> This is for vdev/dev v.s. hwpt. We need the lock for viommu's
> vdev xarray.
>
> Yet, giving a 2nd thought, I feel the lock would be useless if
> a driver tries to refer the returned vdev (with this helper)
> after the vdev object is
On Mon, Oct 07, 2024 at 10:50:46AM -0400, Mathieu Desnoyers wrote:
> On 2024-10-07 12:40, Peter Zijlstra wrote:
> > On Sat, Oct 05, 2024 at 02:50:17PM -0400, Mathieu Desnoyers wrote:
> > > On 2024-10-05 18:04, Peter Zijlstra wrote:
> >
> >
> > > > > +/*
> > > > > + * hp_allocate: Allocate a hazar
On Mon, Oct 07, 2024 at 10:09:11PM +0800, Wardenjohn wrote:
> +++ b/Documentation/ABI/testing/sysfs-kernel-livepatch
> @@ -55,6 +55,15 @@ Description:
> An attribute which indicates whether the patch supports
> atomic-replace.
>
> +What:/sys/kernel/live
On Mon, Oct 07, 2024 at 10:11:39PM +0800, Wardenjohn wrote:
> Add test case of stack_order sysfs interface of livepatch.
>
> Signed-off-by: Wardenjohn
> ---
> .../testing/selftests/livepatch/test-sysfs.sh | 24 +++
> 1 file changed, 24 insertions(+)
>
> diff --git a/tools/testin
Hi Andre
On Sun, 6 Oct 2024 at 22:41, André wrote:
>
> Hi Dave,
>
> Am Freitag, dem 13.09.2024 um 18:40 +0100 schrieb Dave Stevenson:
> > On Thu, 12 Sept 2024 at 15:51, Dave Stevenson
> > wrote:
> > >
> > > Hi André & Ricardo
> > >
> > > On Thu, 12 Sept 2024 at 14:41, Ricardo Ribalda Delgado
> >
On Mon, Oct 07, 2024 at 02:11:19PM -0300, Jason Gunthorpe wrote:
> On Mon, Oct 07, 2024 at 09:36:18AM -0700, Nicolin Chen wrote:
> > On Mon, Oct 07, 2024 at 12:38:37PM -0300, Jason Gunthorpe wrote:
> > > On Fri, Oct 04, 2024 at 10:19:43PM -0700, Nicolin Chen wrote:
> > > > I tried exposing the stru
On Fri, Oct 04, 2024 at 01:33:33PM -0700, Nicolin Chen wrote:
> On Fri, Oct 04, 2024 at 05:17:46PM -0300, Jason Gunthorpe wrote:
> > On Fri, Oct 04, 2024 at 12:25:19PM -0700, Nicolin Chen wrote:
> >
> > > With that, I wonder what is better for the initial version of
> > > this structure, a generic
On Mon, Oct 07, 2024 at 09:36:18AM -0700, Nicolin Chen wrote:
> On Mon, Oct 07, 2024 at 12:38:37PM -0300, Jason Gunthorpe wrote:
> > On Fri, Oct 04, 2024 at 10:19:43PM -0700, Nicolin Chen wrote:
> > > I tried exposing the struct iommufd_viommu to drivers, and was
> > > able to drop a couple of help
Mark Brown writes:
> On Mon, Oct 07, 2024 at 06:00:57PM +0200, Björn Töpel wrote:
>> Mark Brown writes:
>> > On Mon, Oct 07, 2024 at 09:31:32AM +0200, Björn Töpel wrote:
>
>> > CLNG-BPF create_dsq.bpf.o
>> > In file included from create_dsq.bpf.c:9:
>> > /home/broonie/git/linux/tools/sched_ext
On Mon, Oct 07, 2024 at 12:38:37PM -0300, Jason Gunthorpe wrote:
> On Fri, Oct 04, 2024 at 10:19:43PM -0700, Nicolin Chen wrote:
> > I tried exposing the struct iommufd_viommu to drivers, and was
> > able to drop a couple of helpers, except these two:
> >
> > struct device *vdev_to_dev(struct iomm
On Mon, Oct 07, 2024 at 06:00:57PM +0200, Björn Töpel wrote:
> Mark Brown writes:
> > When building for arm64 with this applied on top of mainline or -next
> > I'm seeing:
> Thanks for taking it for a spin!
> >make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -C
> > tools/testing/selftests
On Mon, 7 Oct 2024 at 17:35, Mukesh Ojha wrote:
>
> On Sun, Oct 06, 2024 at 10:38:01PM +0300, Dmitry Baryshkov wrote:
> > On Sat, Oct 05, 2024 at 02:53:54AM GMT, Mukesh Ojha wrote:
> > > From: Shiraz Hashim
> > >
> > > Qualcomm’s PAS implementation for remote processors only supports a
> > > sing
On Mon, Oct 07, 2024 at 06:00:57PM +0200, Björn Töpel wrote:
> Mark Brown writes:
> > On Mon, Oct 07, 2024 at 09:31:32AM +0200, Björn Töpel wrote:
> > CLNG-BPF create_dsq.bpf.o
> > In file included from create_dsq.bpf.c:9:
> > /home/broonie/git/linux/tools/sched_ext/include/scx/common.bpf.h:33:
Thu, Oct 03, 2024 at 02:49:15PM +0800, David Gow wrote:
> On Tue, 1 Oct 2024 at 01:06, I Hsin Cheng wrote:
> >
> > Mending test for list_cut_position*() for the missing check of integer
> > "i" after the second loop. The variable should be checked for second
> > time to make sure both lists after
On Sun, Oct 06, 2024 at 08:17:58AM +0100, David Woodhouse wrote:
> From: David Woodhouse
>
> The vmclock device addresses the problem of live migration with
> precision clocks. The tolerances of a hardware counter (e.g. TSC) are
> typically around ±50PPM. A guest will use NTP/PTP/PPS to disciplin
Mark Brown writes:
> On Mon, Oct 07, 2024 at 09:31:32AM +0200, Björn Töpel wrote:
>
>> When building the kselftest suite, e.g.:
>
>> make ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- \
>> SKIP_TARGETS="" O=/output/foo -C tools/testing/selftests install
>
>> The expectation is that the sched_
Hi Ackerley,
On Thu, 2024-10-03 at 22:32 +0100, Ackerley Tng wrote:
> Elliot Berman writes:
>
>> On Tue, Sep 10, 2024 at 11:44:01PM +, Ackerley Tng wrote:
>>> Since guest_memfd now supports mmap(), folios have to be prepared
>>> before they are faulted into userspace.
>>>
>>> When memory att
On Mon, 7 Oct 2024 12:04:22 +0200 Antonio Quartulli wrote:
> > Or we could check if len(self.checks) <= 1 early and throw our hands up
> > if there is more, for now?
>
> We already perform the same check in the 'else' branch below.
> It'd be about moving it at the beginning of the function and b
The following changes since commit efcd71af38be403fa52223092f79ada446e121ba:
vsock/virtio: avoid queuing packets when intermediate queue is empty
(2024-09-25 07:07:44 -0400)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus
On Mon, Oct 07, 2024 at 08:39:20AM -0700, Jakub Kicinski wrote:
> On Wed, 2 Oct 2024 09:41:42 -0400 Michael S. Tsirkin wrote:
> > virtio_transport_send_pkt in now called on transport fast path,
> > under RCU read lock. In that case, we have a bug: virtio_add_sgs
> > is called with GFP_KERNEL, and m
On Mon, Oct 07, 2024 at 09:31:32AM +0200, Björn Töpel wrote:
> When building the kselftest suite, e.g.:
> make ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- \
> SKIP_TARGETS="" O=/output/foo -C tools/testing/selftests install
> The expectation is that the sched_ext is included, cross-built,
On Wed, 2 Oct 2024 09:41:42 -0400 Michael S. Tsirkin wrote:
> virtio_transport_send_pkt in now called on transport fast path,
> under RCU read lock. In that case, we have a bug: virtio_add_sgs
> is called with GFP_KERNEL, and might sleep.
>
> Pass the gfp flags as an argument, and use GFP_ATOMIC o
On Fri, Oct 04, 2024 at 10:19:43PM -0700, Nicolin Chen wrote:
> I tried exposing the struct iommufd_viommu to drivers, and was
> able to drop a couple of helpers, except these two:
>
> struct device *vdev_to_dev(struct iommufd_vdevice *vdev)
> {
> return vdev ? vdev->idev->dev : NULL;
> } //
On Sun, Oct 06, 2024 at 10:38:01PM +0300, Dmitry Baryshkov wrote:
> On Sat, Oct 05, 2024 at 02:53:54AM GMT, Mukesh Ojha wrote:
> > From: Shiraz Hashim
> >
> > Qualcomm’s PAS implementation for remote processors only supports a
> > single stage of IOMMU translation and is presently managed by the
Wed, Oct 02, 2024 at 11:02:17AM CEST, anto...@openvpn.net wrote:
[...]
>+operations:
>+ list:
>+-
>+ name: dev-new
>+ attribute-set: ovpn
>+ flags: [ admin-perm ]
>+ doc: Create a new interface of type ovpn
>+ do:
>+request:
>+ attributes:
>+
Am 10/7/2024 um 3:18 PM schrieb David Laight:
From: Jonas Oberhauser
Sent: 07 October 2024 12:55
Am 10/3/2024 um 3:23 PM schrieb Mathieu Desnoyers:
What _does_ work however are the following two approaches:
1) Perform the equality check on the original variables, creating
new versions (wit
On 2024-10-07 15:47, Boqun Feng wrote:
On Thu, Oct 03, 2024 at 09:30:53AM -0400, Mathieu Desnoyers wrote:
[...]
+ /*
+* Use RCU dereference without lockdep checks, because
+* lockdep is not aware of HP guarantees.
+*/
+ addr2 = rcu_access_pointer(*addr_p);
On Mon, Oct 07, 2024 at 10:05:08AM +0200, neil.armstr...@linaro.org wrote:
> On 04/10/2024 23:23, Mukesh Ojha wrote:
> > For Qualcomm SoCs runnning with Qualcomm EL2 hypervisor(QHEE), IOMMU
> > translation for remote processors is managed by QHEE and if the same SoC
> > run under KVM, remoteproc ca
On 2024-10-07 12:40, Peter Zijlstra wrote:
On Sat, Oct 05, 2024 at 02:50:17PM -0400, Mathieu Desnoyers wrote:
On 2024-10-05 18:04, Peter Zijlstra wrote:
+/*
+ * hp_allocate: Allocate a hazard pointer.
+ *
+ * Allocate a hazard pointer slot for @addr. The object existence should
+ * be guaran
On Mon, Oct 07, 2024 at 10:07:24AM +0530, Dev Jain wrote:
> On 9/16/24 09:28, Dev Jain wrote:
> > Gentle ping, adding all x86 maintainers and the x86 list, in case they
> > missed.
> Gentle ping
Given that this was posted prior to the merge window you should probably
resend it at this point.
s
On Mon, Oct 07, 2024 at 10:08:16AM +0200, neil.armstr...@linaro.org wrote:
> On 04/10/2024 23:23, Mukesh Ojha wrote:
> > From: Shiraz Hashim
> >
> > Qualcomm SoCs runnning with Qualcomm EL2 hypervisor(QHEE), IOMMU
> > translation set up for remote processors is managed by QHEE itself
> > however,
On Wed, 02 Oct 2024 14:58:06 +0200, Luca Weiss wrote:
> Make sure the GPU frequencies are marked as supported for the respective
> speedbins according to downstream msm-4.19 kernel:
>
> * 850 MHz: Speedbins 0 + 180
> * 800 MHz: Speedbins 0 + 180 + 169
> * 650 MHz: Speedbins 0 + 180 + 169 + 138
>
On Wed, 02 Oct 2024 15:01:08 +0200, Luca Weiss wrote:
> Configure the ADC and thermal zone for the thermistor next to the
> UFS+RAM chip which is connected to GPIO_12 of PM7250B. It is used to
> measure the temperature of that area of the PCB.
>
>
Applied, thanks!
[1/1] arm64: dts: qcom: qcm6
Add test case of stack_order sysfs interface of livepatch.
Signed-off-by: Wardenjohn
---
.../testing/selftests/livepatch/test-sysfs.sh | 24 +++
1 file changed, 24 insertions(+)
diff --git a/tools/testing/selftests/livepatch/test-sysfs.sh
b/tools/testing/selftests/livepatch/tes
Add "stack_order" sysfs attribute which holds the order in which a live
patch module was loaded into the system. A user can then determine an
active live patched version of a function.
cat /sys/kernel/livepatch/livepatch_1/stack_order -> 1
means that livepatch_1 is the first live patch applied
c
As previous discussion, maintainers think that patch-level sysfs interface is
the
only acceptable way to maintain the information of the order that klp_patch is
applied to the system.
However, the previous patch introduce klp_ops into klp_func is a optimization
methods of the patch introducing
On 07.10.24 15:38, Vitaly Kuznetsov wrote:
> "Linux regression tracking (Thorsten Leemhuis)"
> writes:
>
>> On 30.08.24 11:35, Vitaly Kuznetsov wrote:
>>> Sean Christopherson writes:
>>>
Unconditionally honor guest PAT on CPUs that support self-snoop, as
Intel has confirmed that CPUs t
On 04/10/2024 23:01, Maxim Levitsky wrote:
> When memslot_perf_test is run nested, first iteration of test_memslot_rw_loop
> testcase, sometimes takes more than 2 seconds due to build of shadow page
> tables.
>
> Following iterations are fast.
>
> To be on the safe side, bump the timeout to 10 s
On Mon, Oct 07, 2024 at 09:19:05AM GMT, Jonathan Marek wrote:
> On 10/7/24 9:16 AM, Dmitry Baryshkov wrote:
> > On Mon, Oct 07, 2024 at 12:47:22AM GMT, Jonathan Marek wrote:
> > > The name len field of the CMD_OPEN packet is only 16-bits and the upper
> > > 16-bits of "param2" are a different field
On Thu, Oct 03, 2024 at 09:30:53AM -0400, Mathieu Desnoyers wrote:
[...]
> > > + /*
> > > + * Use RCU dereference without lockdep checks, because
> > > + * lockdep is not aware of HP guarantees.
> > > + */
> > > + addr2 = rcu_access_pointer(*addr_p);/* Load A */
> >
> > Why rcu_access_point
"Linux regression tracking (Thorsten Leemhuis)"
writes:
> On 30.08.24 11:35, Vitaly Kuznetsov wrote:
>> Sean Christopherson writes:
>>
>>> Unconditionally honor guest PAT on CPUs that support self-snoop, as
>>> Intel has confirmed that CPUs that support self-snoop always snoop caches
>>> and st
On Fri, Oct 04, 2024 at 09:58:21AM GMT, Cindy Lu wrote:
Add a new UAPI to support setting the vhost device to
use task mode. The user space application needs to use
VHOST_SET_INHERIT_FROM_OWNER to set the mode.
This setting must be set before VHOST_SET_OWNER is set.
Why?
Signed-off-by: Cindy
On Fri, Oct 04, 2024 at 09:58:17AM GMT, Cindy Lu wrote:
Added back the previously removed function vhost_workers_free() and
renamed it to vhost_workers_free_khtread(). The new vhost_workers_free()
will select the different mode based on the value of the parameter.
The old function vhost_workers_
On Fri, Oct 04, 2024 at 09:58:15AM GMT, Cindy Lu wrote:
The vhost is now using vhost_task and working as a child of the owner thread.
While this makes sense from containerization POV, some old userspace is
confused, as previously vhost not
not what?
and so was allowed to steal cpu resources
On 30.08.24 11:35, Vitaly Kuznetsov wrote:
> Sean Christopherson writes:
>
>> Unconditionally honor guest PAT on CPUs that support self-snoop, as
>> Intel has confirmed that CPUs that support self-snoop always snoop caches
>> and store buffers. I.e. CPUs with self-snoop maintain cache coherency
On 2024-10-07 12:42, Peter Zijlstra wrote:
On Sat, Oct 05, 2024 at 02:56:26PM -0400, Mathieu Desnoyers wrote:
On 2024-10-05 18:07, Peter Zijlstra wrote:
On Sat, Oct 05, 2024 at 06:04:44PM +0200, Peter Zijlstra wrote:
On Fri, Oct 04, 2024 at 02:27:33PM -0400, Mathieu Desnoyers wrote:
+void h
From: Arnd Bergmann
The k3-m4 remoteproc driver was merged with incorrect dependencies.
Despite multiple people trying to fix this, the version 6.12-rc2
remains broken and causes a build failure with CONFIG_TI_SCI_PROTOCOL=m
when the driver is built-in.
arm-linux-gnueabi-ld: drivers/remoteproc/t
On 2024-10-07 15:18, David Laight wrote:
From: Jonas Oberhauser
Sent: 07 October 2024 12:55
Am 10/3/2024 um 3:23 PM schrieb Mathieu Desnoyers:
What _does_ work however are the following two approaches:
1) Perform the equality check on the original variables, creating
new versions (with OPTIMI
On 10/7/24 9:16 AM, Dmitry Baryshkov wrote:
On Mon, Oct 07, 2024 at 12:47:22AM GMT, Jonathan Marek wrote:
The name len field of the CMD_OPEN packet is only 16-bits and the upper
16-bits of "param2" are a different field, which can be nonzero in certain
situations, and CMD_OPEN packets can be une
The "st,stm32mp1-m4-tee" compatible is utilized in a system configuration
where the Cortex-M4 firmware is loaded by the Trusted Execution Environment
(TEE).
For instance, this compatible is used in both the Linux and OP-TEE device
trees:
- In OP-TEE, a node is defined in the device tree with the
To prepare for the support of TEE remoteproc, create sub-functions
that can be used in both cases, with and without remoteproc TEE support.
Signed-off-by: Arnaud Pouliquen
---
Update vs previous version
- Fix stm32_rproc_request_shutdown code, which was not an exact move of the
source code from
Add a remoteproc TEE (Trusted Execution Environment) driver
that will be probed by the TEE bus. If the associated Trusted
application is supported on secure part this driver offers a client
interface to load a firmware by the secure part.
This firmware could be authenticated by the secure trusted a
This patch updates the rproc_ops struct to include an optional
release_fw function.
The release_fw ops is responsible for releasing the remote processor
firmware image. The ops is called in the following cases:
- An error occurs in rproc_start() between the loading of the segments and
the
The new TEE remoteproc driver is used to manage remote firmware in a
secure, trusted context. The 'st,stm32mp1-m4-tee' compatibility is
introduced to delegate the loading of the firmware to the trusted
execution context. In such cases, the firmware should be signed and
adhere to the image format de
Main updates from version V9[1]:
- Introduce release_fw remoteproc ops to avoid direct call of
tee_rproc_release_fw() in remoteproc_core.c:
- allow to remove link between remoteproc and remoteproc_tee
- allow to build the remoteproc_tee as a module
[1] https://lore.kernel.org/linux-arm-kern
When a resource table is loaded by an external entity such as U-boot or
OP-TEE, we do not necessarily get the device address(da) but the physical
address(pa).
This helper performs similar translation than the rproc_da_to_va()
but based on a physical address.
Signed-off-by: Arnaud Pouliquen
---
d
This patch centralizing the cleanup of the resource table into a new
helper function rproc_release_fw().
More than just factorizing the code into a common function, it is the
first step to integrate the release of the firmware image loaded by the
OP-TEE remoteproc framework.
Suggested-by: Mathieu
From: Jonas Oberhauser
> Sent: 07 October 2024 12:55
>
> Am 10/3/2024 um 3:23 PM schrieb Mathieu Desnoyers:
> > What _does_ work however are the following two approaches:
> >
> > 1) Perform the equality check on the original variables, creating
> > new versions (with OPTIMIZER_HIDE_VAR) of both va
On Mon, Oct 07, 2024 at 12:47:22AM GMT, Jonathan Marek wrote:
> The name len field of the CMD_OPEN packet is only 16-bits and the upper
> 16-bits of "param2" are a different field, which can be nonzero in certain
> situations, and CMD_OPEN packets can be unexpectedly dropped because of
> this.
Any
On 7.10.2024 2:46 PM, Dmitry Baryshkov wrote:
> On Mon, 7 Oct 2024 at 09:22, Luca Weiss wrote:
>>
>> On Sun Oct 6, 2024 at 10:26 PM CEST, Dmitry Baryshkov wrote:
>>> On Wed, Oct 02, 2024 at 03:01:08PM GMT, Luca Weiss wrote:
Configure the ADC and thermal zone for the thermistor next to the
>>>
On Mon, 7 Oct 2024 at 09:22, Luca Weiss wrote:
>
> On Sun Oct 6, 2024 at 10:26 PM CEST, Dmitry Baryshkov wrote:
> > On Wed, Oct 02, 2024 at 03:01:08PM GMT, Luca Weiss wrote:
> > > Configure the ADC and thermal zone for the thermistor next to the
> > > UFS+RAM chip which is connected to GPIO_12 of
1 - 100 of 117 matches
Mail list logo
