This series depends on q6 clock removal series [1].
- Secure PIL is signed, split firmware images which only TrustZone (TZ) can
authenticate and load. Linux kernel will send a request to TZ to
authenticate and load the PIL images.
- When secure PIL support was added to the existing wcss PIL d
From: Manikanta Mylavarapu
Add new binding document for hexagon based WCSS secure PIL remoteproc.
IPQ5332, IPQ9574 follows secure PIL remoteproc.
Signed-off-by: Manikanta Mylavarapu
Signed-off-by: Gokul Sriram Palanisamy
---
.../remoteproc/qcom,wcss-sec-pil.yaml | 125
From: Vignesh Viswanathan
Add support to bring up hexagon based WCSS secure PIL remoteproc.
IPQ5332, IPQ9574 supports secure PIL remoteproc.
Signed-off-by: Vignesh Viswanathan
Signed-off-by: Manikanta Mylavarapu
Signed-off-by: Gokul Sriram Palanisamy
---
drivers/remoteproc/Kconfig
From: Manikanta Mylavarapu
Enable nodes required for q6 remoteproc bring up.
Signed-off-by: Manikanta Mylavarapu
Signed-off-by: Gokul Sriram Palanisamy
---
arch/arm64/boot/dts/qcom/ipq5332.dtsi | 62 +++
1 file changed, 62 insertions(+)
diff --git a/arch/arm64/boot/dt
From: Manikanta Mylavarapu
Enable nodes required for q6 remoteproc bring up.
Signed-off-by: Manikanta Mylavarapu
Signed-off-by: Gokul Sriram Palanisamy
---
arch/arm64/boot/dts/qcom/ipq9574.dtsi | 58 +++
1 file changed, 58 insertions(+)
diff --git a/arch/arm64/boot/dt
From: Vignesh Viswanathan
q6v5 fatal and watchdog IRQ handlers always retrieves the crash reason
information from SMEM global partition (QCOM_SMEM_HOST_ANY).
For some targets like IPQ9574 and IPQ5332, crash reason information is
present in target specific partition due to which the crash reason
his on top of -next-20240820 tag? There was a series[0]
which was merged recently which fixed this condition. I don't see this
issue when trying on top of -next-20240820 tag.
[0]: https://lore.kernel.org/all/20240808074127.2688131-1-b-pa...@ti.com/
Fixes: 3c8a9066d584 ("remoteproc:
, it will
>> find core1->rproc as NULL already and crashes. Happens on rmmod e.g.
>
>
> Did you check this on top of -next-20240820 tag? There was a series[0]
> which was merged recently which fixed this condition. I don't see this
> issue when trying on
find core1->rproc as NULL already and crashes. Happens on rmmod e.g.
Did you check this on top of -next-20240820 tag? There was a series[0]
which was merged recently which fixed this condition. I don't see this
issue when trying on top of -next-20240820 tag.
[0]: https://lore.kernel
On Sun, 7 Jul 2024 at 18:06, Mikhail Krasheninnikov
wrote:
>
> Introduce a new virtio MMC driver to enable virtio SD/MMC card
> emulation with QEMU. This driver allows emulating MMC cards in
> virtual environments, enhancing functionality and testing
> capabilities within QEMU.
>
> Link to the QEM
On Tue, Aug 20, 2024 at 10:03:30AM +0900, Masami Hiramatsu wrote:
> On Mon, 19 Aug 2024 12:02:44 -0400
> Steven Rostedt wrote:
>
> > On Tue, 20 Aug 2024 00:56:49 +0900
> > Masami Hiramatsu (Google) wrote:
> > >
> > > >
> > > > We may need to add "noinline" or something to make sure those funct
oted rprocs ]
Signed-off-by: Beleswar Padhi
---
v2: Changelog:
* Mathieu
1) Rebased changes on top of -next-20240820 tag.
Link to v1:
https://lore.kernel.org/all/20240809060132.308642-1-b-pa...@ti.com/
drivers/remoteproc/ti_k3_r5_remoteproc.c | 5 +++--
1 file changed, 3 insertions(+), 2 deleti
On 20/08/2024 10:55, Gokul Sriram Palanisamy wrote:
> This series depends on q6 clock removal series [1].
How? So this cannot be tested and merged?
That's second patchset to day with some totally bogus dependencies.
People, stop it.
Best regards,
Krzysztof
On Tue, Aug 20, 2024 at 02:25:14PM +0530, Gokul Sriram Palanisamy wrote:
> From: Manikanta Mylavarapu
>
> Add new binding document for hexagon based WCSS secure PIL remoteproc.
> IPQ5332, IPQ9574 follows secure PIL remoteproc.
>
> Signed-off-by: Manikanta Mylavarapu
> Signed-off-by: Gokul Srira
On Tue, Aug 20, 2024 at 02:25:16PM +0530, Gokul Sriram Palanisamy wrote:
> From: Manikanta Mylavarapu
>
> Enable nodes required for q6 remoteproc bring up.
>
> Signed-off-by: Manikanta Mylavarapu
> Signed-off-by: Gokul Sriram Palanisamy
> ---
> arch/arm64/boot/dts/qcom/ipq5332.dtsi | 62 +
On Tue, Aug 20, 2024 at 02:25:15PM +0530, Gokul Sriram Palanisamy wrote:
> From: Vignesh Viswanathan
>
> Add support to bring up hexagon based WCSS secure PIL remoteproc.
> IPQ5332, IPQ9574 supports secure PIL remoteproc.
>
> Signed-off-by: Vignesh Viswanathan
> Signed-off-by: Manikanta Mylavar
From: Tomas Glozar
When running timerlat with a userspace workload (NO_OSNOISE_WORKLOAD),
NULL pointer dereference can be triggered by sending consequent SIGINT
and SIGTERM signals to the workload process. That then causes
timerlat_fd_release to be called twice in a row, and the second time,
hrti
Depending on the argument 'add', uprobe_apply() may be registering or
unregistering a probe. The current comment misses the description of the
registration.
Signed-off-by: Zhen Lei
---
kernel/events/uprobes.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/events/u
On Tue, 20 Aug 2024 11:48:07 +0100
Mark Rutland wrote:
> > I found the target function already has "noinline". I tried to add noinline
> > to the testing function (callsite), but it also did not work.
> > I think "noinline" is for the compiler, but LTO is done by the linker.
>
> If LTO is brea
t;>>> When k3_r5_cluster_rproc_exit is run, core 1 is shutdown and removed
>>>> first. When core 0 should then be stopped before its removal, it will
>>>> find core1->rproc as NULL already and crashes. Happens on rmmod e.g.
>>>
>>> Did you check th
Philip Chen wrote:
> On Mon, Aug 19, 2024 at 2:56 PM Ira Weiny wrote:
> >
> > Philip Chen wrote:
> > > If a pmem device is in a bad status, the driver side could wait for
> > > host ack forever in virtio_pmem_flush(), causing the system to hang.
> >
> > I assume this was supposed to be v2 and you
On 08/20, Zhen Lei wrote:
>
> Depending on the argument 'add', uprobe_apply() may be registering or
> unregistering a probe.
...
> /*
> - * uprobe_apply - unregister an already registered probe.
> - * @inode: the file in which the probe has to be removed.
> + * uprobe_apply - register a probe or
shutdown and removed
first. When core 0 should then be stopped before its removal, it will
find core1->rproc as NULL already and crashes. Happens on rmmod e.g.
Did you check this on top of -next-20240820 tag? There was a series[0]
which was merged recently which fixed this condition. I don&#x
On 08/19, Andrii Nakryiko wrote:
>
> On Mon, Aug 19, 2024 at 6:41 AM Oleg Nesterov wrote:
> >
> > On 08/12, Andrii Nakryiko wrote:
> > >
> > > Avoid taking refcount on uprobe in prepare_uretprobe(), instead take
> > > uretprobe-specific SRCU lock and keep it active as kernel transfers
> > > contro
On Tue, Aug 20, 2024 at 3:48 AM Mark Rutland wrote:
>
> On Tue, Aug 20, 2024 at 10:03:30AM +0900, Masami Hiramatsu wrote:
> > On Mon, 19 Aug 2024 12:02:44 -0400
> > Steven Rostedt wrote:
> >
> > > On Tue, 20 Aug 2024 00:56:49 +0900
> > > Masami Hiramatsu (Google) wrote:
> > > >
> > > > >
> > > >
When k3_r5_cluster_rproc_exit is run, core 1 is shutdown and removed
first. When core 0 should then be stopped before its removal, it
will
find core1->rproc as NULL already and crashes. Happens on rmmod e.g.
Did you check this on top of -next-20240820 tag? There was a
series[0]
which
On Tue, 20 Aug 2024 08:10:42 -0700
Sami Tolvanen wrote:
> On Tue, Aug 20, 2024 at 3:48 AM Mark Rutland wrote:
> >
> > On Tue, Aug 20, 2024 at 10:03:30AM +0900, Masami Hiramatsu wrote:
> > > On Mon, 19 Aug 2024 12:02:44 -0400
> > > Steven Rostedt wrote:
> > >
> > > > On Tue, 20 Aug 2024 00:5
On Sun, Aug 18, 2024 at 03:19:36PM +0900, Masahiro Yamada wrote:
> On Fri, Aug 16, 2024 at 12:04???AM Kris Van Hees
> wrote:
>
>
> The subject should be:
> "kbuild: generate offset range data for builtin modules"
>
>
> (Drop ", kconfig")
Thank you - applied.
> >
> > Create file module.built
On Sun, Aug 18, 2024 at 03:40:36PM +0900, Masahiro Yamada wrote:
> On Fri, Aug 16, 2024 at 12:04???AM Kris Van Hees
> wrote:
> >
> > The modules.builtin.ranges offset range data for builtin modules is
> > generated at compile time based on the list of built-in modules and
> > the vmlinux.map and
If a pmem device is in a bad status, the driver side could wait for
host ack forever in virtio_pmem_flush(), causing the system to hang.
So add a status check in the beginning of virtio_pmem_flush() to return
early if the device is not activated.
Signed-off-by: Philip Chen
---
v2:
- Remove chan
On Tue, Aug 20, 2024 at 8:06 AM Oleg Nesterov wrote:
>
> On 08/19, Andrii Nakryiko wrote:
> >
> > On Mon, Aug 19, 2024 at 6:41 AM Oleg Nesterov wrote:
> > >
> > > On 08/12, Andrii Nakryiko wrote:
> > > >
> > > > Avoid taking refcount on uprobe in prepare_uretprobe(), instead take
> > > > uretprob
On Mon, Aug 19, 2024 at 10:17 PM Benno Lossin wrote:
>
> On 19.08.24 21:38, Sami Tolvanen wrote:
> >
> > This definitely looks cleaner than unions in Rust, but how would this
> > scheme be visible in DWARF? You might also need to expand the annotation
> > to allow replacing one reserved field with
On 8/20/24 10:22 AM, Philip Chen wrote:
> If a pmem device is in a bad status, the driver side could wait for
> host ack forever in virtio_pmem_flush(), causing the system to hang.
>
> So add a status check in the beginning of virtio_pmem_flush() to return
> early if the device is not activated
> > The way `KAbiReserved` is implemented is via a `union` (maybe a bit
> > ironic, considering what I said in my other replies, but in this case,
> > we would provide a safe abstraction over this `union`, thus avoiding
> > exposing users of this type to `unsafe`):
> >
> > #[repr(C)]
> > pu
On Tue, 20 Aug 2024 08:10:42 -0700
Sami Tolvanen wrote:
> On Tue, Aug 20, 2024 at 3:48 AM Mark Rutland wrote:
> >
> > On Tue, Aug 20, 2024 at 10:03:30AM +0900, Masami Hiramatsu wrote:
> > > On Mon, 19 Aug 2024 12:02:44 -0400
> > > Steven Rostedt wrote:
> > >
> > > > On Tue, 20 Aug 2024 00:56:49
On Wed, 21 Aug 2024 07:05:39 +0900
Masami Hiramatsu (Google) wrote:
> Does the noinline attribute prevent embedding callsite too? I mean
>
> extern callee()
>
> noinline callee()
> {
> ...
> }
>
> caller()
> {
> callee() // (*)
> }
>
> In this case, does noinline prevent LTO to embed t
On Tue, 20 Aug 2024 18:11:09 -0400
Steven Rostedt wrote:
> On Wed, 21 Aug 2024 07:05:39 +0900
> Masami Hiramatsu (Google) wrote:
>
>
> > Does the noinline attribute prevent embedding callsite too? I mean
> >
> > extern callee()
> >
> > noinline callee()
> > {
> > ...
> > }
> >
> > caller()
On Wed, 21 Aug 2024 08:43:51 +0900
Masami Hiramatsu (Google) wrote:
> > Can you add the __used and see if it fixes it?
>
> Adding __used to DYN_FTRACE_TEST_NAME() and DYN_FTRACE_TEST_NAME2() does
> not change, the test still fails.
OK, now that sounds like a bug in LTO itself.
-- Steve
On Tue, 20 Aug 2024 19:49:14 -0400
Steven Rostedt wrote:
> On Wed, 21 Aug 2024 08:43:51 +0900
> Masami Hiramatsu (Google) wrote:
>
> > > Can you add the __used and see if it fixes it?
> >
> > Adding __used to DYN_FTRACE_TEST_NAME() and DYN_FTRACE_TEST_NAME2() does
> > not change, the test st
On Wed, 21 Aug 2024 08:43:51 +0900
Masami Hiramatsu (Google) wrote:
> On Tue, 20 Aug 2024 18:11:09 -0400
> Steven Rostedt wrote:
>
> > On Wed, 21 Aug 2024 07:05:39 +0900
> > Masami Hiramatsu (Google) wrote:
> >
> >
> > > Does the noinline attribute prevent embedding callsite too? I mean
> >
Hello,
syzbot found the following issue on:
HEAD commit:367b5c3d53e5 Add linux-next specific files for 20240816
git tree: linux-next
console+strace: https://syzkaller.appspot.com/x/log.txt?x=109d46a398
kernel config: https://syzkaller.appspot.com/x/.config?x=61ba6f3b22ee5467
dashbo
On 2024/8/20 22:30, Oleg Nesterov wrote:
> On 08/20, Zhen Lei wrote:
>>
>> Depending on the argument 'add', uprobe_apply() may be registering or
>> unregistering a probe.
>
> ...
>
>> /*
>> - * uprobe_apply - unregister an already registered probe.
>> - * @inode: the file in which the probe h
SGX Enclave Page Cache (EPC) memory allocations are separate from normal
RAM allocations, and are managed solely by the SGX subsystem. The existing
cgroup memory controller cannot be used to limit or account for SGX EPC
memory, which is a desirable feature in some environments, e.g., support
for po
Replace boolean parameters for 'reclaim' in the function
sgx_alloc_epc_page() and its callers with an enum.
Also opportunistically remove non-static declaration of
__sgx_alloc_epc_page() and a typo
Signed-off-by: Haitao Huang
Suggested-by: Jarkko Sakkinen
Suggested-by: Dave Hansen
Reviewed-by:
From: Kristen Carlson Accardi
The misc cgroup controller (subsystem) currently does not perform
resource type specific action for Cgroups Subsystem State (CSS) events:
the 'css_alloc' event when a cgroup is created and the 'css_free' event
when a cgroup is destroyed.
Define callbacks for those e
From: Kristen Carlson Accardi
The SGX EPC cgroup will reclaim EPC pages when usage in a cgroup reaches
its or ancestor's limit. This requires a walk from the current cgroup up
to the root similar to misc_cg_try_charge(). Export misc_cg_parent() to
enable this walk.
The SGX driver also needs star
From: Kristen Carlson Accardi
Add SGX EPC memory, MISC_CG_RES_SGX_EPC, to be a valid resource type
for the misc controller.
Signed-off-by: Kristen Carlson Accardi
Co-developed-by: Haitao Huang
Signed-off-by: Haitao Huang
Reviewed-by: Jarkko Sakkinen
Reviewed-by: Kai Huang
Tested-by: Jarkko
From: Kristen Carlson Accardi
SGX Enclave Page Cache (EPC) memory allocations are separate from normal
RAM allocations, and are managed solely by the SGX subsystem. The
existing cgroup memory controller cannot be used to limit or account for
SGX EPC memory, which is a desirable feature in some en
From: Sean Christopherson
Introduce a data structure to wrap the existing reclaimable list and its
spinlock. Each cgroup later will have one instance of this structure to
track EPC pages allocated for processes associated with the same cgroup.
Just like the global SGX reclaimer (ksgxd), an EPC cg
To support the per-cgroup reclamation, each cgroup will have its own
"per-cgroup LRU" and EPC pages will be in its owner cgroup's LRU instead
of the global LRU. Abstract the code that is directly working with the
global LRU into functions reusable with per-cgroup LRUs.
Currently the basic reclamat
From: Kristen Carlson Accardi
The SGX driver tracks reclaimable EPC pages by adding a newly allocated
page into the global LRU list in sgx_mark_page_reclaimable(), and doing
the opposite in sgx_unmark_page_reclaimable().
To support SGX EPC cgroup, the SGX driver will need to maintain an LRU
list
Currently in the EPC page allocation, the kernel simply fails the
allocation when the current EPC cgroup fails to charge due to its usage
reaching limit. This is not ideal. When that happens, a better way is
to reclaim EPC page(s) from the current EPC cgroup to reduce its usage
so the new allocat
From: Kristen Carlson Accardi
In cases EPC pages need be allocated during a page fault and the cgroup
usage is near its limit, an asynchronous reclamation needs to be
triggered to avoid blocking the page fault handling.
To keep implementation simple, use a workqueue instead of kthread to
schedul
Enclave Page Cache(EPC) memory can be swapped out to regular system
memory, and the consumed memory should be charged to a proper
mem_cgroup. Currently the selection of mem_cgroup to charge is done in
sgx_encl_get_mem_cgroup(). But it considers all contexts other than the
ksgxd thread are user proc
With EPC cgroups, the global reclamation function,
sgx_reclaim_pages_global(), can no longer apply to the global LRU as
pages are now in per-cgroup LRUs.
Create a wrapper, sgx_cgroup_reclaim_global() to invoke
sgx_cgroup_reclaim_pages() passing in the root cgroup. Call this wrapper
from sgx_reclai
sgx_reclaim_direct() was introduced to preemptively reclaim some pages
as the best effort to avoid on-demand reclamation that can stall forward
progress in some situations, e.g., allocating pages to load previously
reclaimed page to perform EDMM operations on [1].
Currently when the global usage i
From: Kristen Carlson Accardi
Previous patches have implemented all infrastructure needed for
per-cgroup EPC page tracking and reclaiming. But all reclaimable EPC
pages are still tracked in the global LRU as sgx_epc_page_lru() always
returns reference to the global LRU.
Change sgx_epc_page_lru()
From: Sean Christopherson
Add initial documentation of how to regulate the distribution of
SGX Enclave Page Cache (EPC) memory via the Miscellaneous cgroup
controller.
Signed-off-by: Sean Christopherson
Co-developed-by: Kristen Carlson Accardi
Signed-off-by: Kristen Carlson Accardi
Co-develop
With different cgroups, the script starts one or multiple concurrent SGX
selftests (test_sgx), each to run the unclobbered_vdso_oversubscribed
test case, which loads an enclave of EPC size equal to the EPC capacity
available on the platform. The script checks results against the
expectation set for
Hi,
On Tue, Aug 20, 2024 at 7:23 AM Ira Weiny wrote:
>
> Philip Chen wrote:
> > On Mon, Aug 19, 2024 at 2:56 PM Ira Weiny wrote:
> > >
> > > Philip Chen wrote:
> > > > If a pmem device is in a bad status, the driver side could wait for
> > > > host ack forever in virtio_pmem_flush(), causing the
Hi,
On Tue, Aug 20, 2024 at 1:01 PM Dave Jiang wrote:
>
>
>
> On 8/20/24 10:22 AM, Philip Chen wrote:
> > If a pmem device is in a bad status, the driver side could wait for
> > host ack forever in virtio_pmem_flush(), causing the system to hang.
> >
> > So add a status check in the beginning of
When CONFIG_BUILTIN_MODULE_RANGES is enabled, the modules.builtin.ranges
file should be installed in the module install location.
Signed-off-by: Kris Van Hees
Reviewed-by: Nick Alcock
---
Changes since v3:
- Only install modules.builtin.ranges if CONFIG_BUILTIN_MODULE_RANGES=y
---
scri
In order to create the file at build time, modules.builtin.ranges, that
contains the range of addresses for all built-in modules, there needs to
be a way to identify what code is compiled into modules.
To identify what code is compiled into modules during a kernel build,
one can look for the prese
The modules.builtin.ranges offset range data for builtin modules is
generated at compile time based on the list of built-in modules and
the vmlinux.map and vmlinux.o.map linker maps. This data can be used
to determine whether a symbol at a particular address belongs to
module code that was configu
Create file module.builtin.ranges that can be used to find where
built-in modules are located by their addresses. This will be useful for
tracing tools to find what functions are for various built-in modules.
The offset range data for builtin modules is generated using:
- modules.builtin: associa
On Mon, Aug 19, 2024 at 05:27:33PM +0800, Cindy Lu wrote:
> Add a new UAPI to support setting the vhost device to
> use kthread mode. The user space application needs to use
> VHOST_SET_USE_KTHREAD to set the mode. This setting must
> be set before VHOST_SET_OWNER is set.
Usage of an API is a comp
#syz dup: [syzbot] [perf?] KASAN: slab-use-after-free Read in
__uprobe_unregister syzbot
https://lore.kernel.org/all/382d39061f59f...@google.com/
Hopefully fixed by
[PATCH tip/perf/core] bpf: fix use-after-free in bpf_uprobe_multi_link_attach()
https://lore.kernel.org/all/20240813152
> #syz dup: [syzbot] [perf?] KASAN: slab-use-after-free Read in
> __uprobe_unregister syzbot
can't find the dup bug
>
> https://lore.kernel.org/all/382d39061f59f...@google.com/
>
> Hopefully fixed by
> [PATCH tip/perf/core] bpf: fix use-after-free in
> bpf_uprobe_multi_link_attach()
On 19-08-2024 20:54, Jan Kiszka wrote:
From: Jan Kiszka
By simply bailing out, the driver was violating its rule and internal
Using device lifecycle managed functions to register the rproc
(devm_rproc_add()), bailing out with an error code will work.
assumptions that either both or no
69 matches
Mail list logo
