Hi, Mark
My bad for taking so long to rely, I generally agree with your suggestions to
STP emulation.
在 2024/8/15 17:58, Mark Rutland 写道:
> On Wed, Aug 14, 2024 at 08:03:56AM +, Liao Chang wrote:
>> As Andrii pointed out, the uprobe/uretprobe selftest bench run into a
>> counterintuitive resu
On Tue, Aug 20, 2024 at 11:21 AM maobibo wrote:
>
> Huacai,
>
> Thanks for reviewing my patch.
> I reply inline.
>
> On 2024/8/19 下午9:32, Huacai Chen wrote:
> > Hi, Bibo,
> >
> > On Mon, Aug 12, 2024 at 11:02 AM Bibo Mao wrote:
> >>
> >> Export kernel paravirt features to user space, so that VMM
On Tue, Aug 20, 2024 at 12:02 PM maobibo wrote:
>
> Huacai,
>
> On 2024/8/19 下午9:34, Huacai Chen wrote:
> > Hi, Bibo,
> >
> > On Mon, Aug 12, 2024 at 11:02 AM Bibo Mao wrote:
> >>
> >> Interrupts can be routed to maximal four virtual CPUs with one HW
> >> EIOINTC interrupt controller model, since
Dear Anna-Maria,
Thank you very much for the support. I was finally able to collect the
data you asked for.
Am 09.04.24 um 09:57 schrieb Anna-Maria Behnsen:
Paul Menzel writes:
[…]
Am 08.04.24 um 12:10 schrieb Anna-Maria Behnsen:
Paul Menzel writes:
On Dell XPS 13 9360/0596KF, BIOS
Hello Mathieu,
I've talked to Peng and if my understanding is correct I think the patch is OK.
Maybe we can split the patch in two:
* first, adding the power off callback with explanations.
* second, adding the restart callback with explanations.
And also add a more detailed explanation.
Power o
On 2024/8/21 下午4:13, Huacai Chen wrote:
On Tue, Aug 20, 2024 at 11:21 AM maobibo wrote:
Huacai,
Thanks for reviewing my patch.
I reply inline.
On 2024/8/19 下午9:32, Huacai Chen wrote:
Hi, Bibo,
On Mon, Aug 12, 2024 at 11:02 AM Bibo Mao wrote:
Export kernel paravirt features to user sp
On 2024/8/21 下午4:15, Huacai Chen wrote:
On Tue, Aug 20, 2024 at 12:02 PM maobibo wrote:
Huacai,
On 2024/8/19 下午9:34, Huacai Chen wrote:
Hi, Bibo,
On Mon, Aug 12, 2024 at 11:02 AM Bibo Mao wrote:
Interrupts can be routed to maximal four virtual CPUs with one HW
EIOINTC interrupt contro
在 2024/8/16 0:53, Andrii Nakryiko 写道:
> On Wed, Aug 14, 2024 at 7:58 PM Liao, Chang wrote:
>>
>>
>>
>> 在 2024/8/15 2:42, Andrii Nakryiko 写道:
>>> On Tue, Aug 13, 2024 at 9:17 PM Liao, Chang wrote:
在 2024/8/13 1:49, Andrii Nakryiko 写道:
> On Mon, Aug 12, 2024 at 4:11 AM Li
SGX runtimes such as Gramine may implement EDMM-based lazy allocation of
enclave pages and may support MADV_DONTNEED semantics [1]. The former
implies #PF-based page allocation, and the latter implies the usage of
SGX_IOC_ENCLAVE_REMOVE_PAGES ioctl.
EDMM-based lazy allocation and MADV_DONTNEED sem
The page reclaimer thread sets SGX_ENC_PAGE_BEING_RECLAIMED flag when
the enclave page is being reclaimed (moved to the backing store). This
flag however has two logical meanings:
1. Don't attempt to load the enclave page (the page is busy), see
__sgx_encl_load_page().
2. Don't attempt to remov
Imagine an mmap()'d file. Two threads touch the same address at the same
time and fault. Both allocate a physical page and race to install a PTE
for that page. Only one will win the race. The loser frees its page, but
still continues handling the fault as a success and returns
VM_FAULT_NOPAGE from
Two enclave threads may try to add and remove the same enclave page
simultaneously (e.g., if the SGX runtime supports both lazy allocation
and MADV_DONTNEED semantics). Consider some enclave page added to the
enclave. User space decides to temporarily remove this page (e.g.,
emulating the MADV_DONT
[...]
>
> Additionally fix a similar race: user space converts a normal enclave
> page to a TCS page (via SGX_IOC_ENCLAVE_MODIFY_TYPES) on CPU1, and at
> the same time, user space performs a memory access on the same page on
> CPU2. This fix is not strictly necessary (this particular race would
>
On Wed, 2024-08-21 at 03:02 -0700, Dmitrii Kuvaiskii wrote:
> Imagine an mmap()'d file. Two threads touch the same address at the same
> time and fault. Both allocate a physical page and race to install a PTE
> for that page. Only one will win the race. The loser frees its page, but
> still continu
On 20.08.24 22:03, Matthew Maurer wrote:
>>> 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 `un
Use the async interface to issue MTT MKEY creation.
Extra care is taken at the allocation of FW input commands
due to the MTT tables having variable sizes depending on
MR.
The indirect MKEY is still created synchronously at the
end as the direct MKEYs need to be filled in.
This makes create_user_
A followup patch will use this name for something else.
Signed-off-by: Dragos Tatulea
Reviewed-by: Cosmin Ratiu
---
drivers/vdpa/mlx5/core/mlx5_vdpa.h | 2 +-
drivers/vdpa/mlx5/core/mr.c| 2 +-
drivers/vdpa/mlx5/net/mlx5_vnet.c | 8
3 files changed, 6 insertions(+), 6 deletion
Use the async interface to issue MTT MKEY deletion.
This makes destroy_user_mr() on average 8x times faster.
This number is also dependent on the size of the MR being
deleted.
Signed-off-by: Dragos Tatulea
Reviewed-by: Cosmin Ratiu
---
drivers/vdpa/mlx5/core/mr.c | 66 +
Group all mapping related resources into their own structure.
Upcoming patches will add more members in this new structure.
Signed-off-by: Dragos Tatulea
Reviewed-by: Cosmin Ratiu
---
drivers/vdpa/mlx5/core/mlx5_vdpa.h | 13 ++-
drivers/vdpa/mlx5/core/mr.c| 30 -
There's currently not a lot of action happening during
the init/destroy of MR resources. But more will be added
in the upcoming patches.
Signed-off-by: Dragos Tatulea
Reviewed-by: Cosmin Ratiu
---
drivers/vdpa/mlx5/core/mlx5_vdpa.h | 2 ++
drivers/vdpa/mlx5/core/mr.c| 17 ++
This series improves the time of .set_map() operations by parallelizing
the MKEY creation and deletion for direct MKEYs. Looking at the top
level MKEY creation/deletion functions, the following improvement can be
seen:
|---+-|
| operation | improvement |
|--
Now that the mr resources have their own namespace in the
struct, give the lock a clearer name.
Signed-off-by: Dragos Tatulea
Reviewed-by: Cosmin Ratiu
---
drivers/vdpa/mlx5/core/mlx5_vdpa.h | 2 +-
drivers/vdpa/mlx5/core/mr.c| 20 ++--
drivers/vdpa/mlx5/core/resources.
Currently, when a new MR is set up, the old MR is deleted. MR deletion
is about 30-40% the time of MR creation. As deleting the old MR is not
important for the process of setting up the new MR, this operation
can be postponed.
This series adds a workqueue that does MR garbage collection at a later
Currently, when using both function tracer and function graph simultaneously,
it is found that function tracer sometimes captures a fake parent
ip(return_to_handler)
instead of the true parent ip.
This issue is easy to reproduce. Below are my reproduction steps:
jeff-labs:~/bin # ./trace-net.sh
On Wed, 21 Aug 2024 21:27:55 +0800
Jeff Xie wrote:
Hi Jeff,
Thanks for the patch.
> Signed-off-by: Jeff Xie
> ---
> kernel/trace/trace_functions.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/kernel/trace/trace_functions.c b/kernel/trace/trace_functions.c
> in
August 21, 2024 at 9:59 PM, "Steven Rostedt" wrote:
Hi Steven,
>
> On Wed, 21 Aug 2024 21:27:55 +0800
>
> Jeff Xie wrote:
>
> Hi Jeff,
>
> Thanks for the patch.
>
> >
> > Signed-off-by: Jeff Xie
> >
> > ---
> >
> > kernel/trace/trace_functions.c | 18 ++
> >
> > 1
At build time, create the file modules.builtin.ranges that will hold
address range data of the built-in modules that can be used by tracers.
Especially for tracing applications, it is convenient to be able to
refer to a symbol using a pair and to be able
to translate an address into a pair. But
On Tue, Aug 20, 2024 at 5:21 PM Masami Hiramatsu wrote:
>
> 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:
> > >
> > >
>
On Thu 2024-07-25 16:40:20, Nicolai Stange wrote:
> Miroslav Benes writes:
>
> >
> > Do we still need klp_state->data member? Now that it can be easily coupled
> > with shadow variables, is there a reason to preserve it?
Good point. I have actually forgot the pointer completely.
> I would say
On Wed, Aug 21, 2024 at 07:05:39AM +0900, Masami Hiramatsu wrote:
> 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:
On Wed, Aug 21, 2024 at 04:32:46PM +0100, Mark Rutland wrote:
> On Wed, Aug 21, 2024 at 07:05:39AM +0900, Masami Hiramatsu wrote:
> > 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
On Wed, 21 Aug 2024 16:42:07 +0100
Mark Rutland wrote:
> FWIW, that was in samples/ftrace/ftrace-ops.c, where tracee_relevant() and
> tracee_irrelevant() have the barrier():
>
> | /*
> | * Marked as noinline to ensure that an out-of-line traceable copy is
> | * generated by the compiler.
> |
On Fri, 28 Jun 2024 11:46:11 +0100
Vincent Donnefort wrote:
> diff --git a/tools/testing/selftests/ring-buffer/map_test.c
> b/tools/testing/selftests/ring-buffer/map_test.c
> index a9006fa7097e..4bb0192e43f3 100644
> --- a/tools/testing/selftests/ring-buffer/map_test.c
> +++ b/tools/testing/self
On Tue, Aug 13, 2024 at 1:34 PM Andrii Nakryiko wrote:
>
> trace_uprobe->nhit counter is not incremented atomically, so its value
> is questionable in when uprobe is hit on multiple CPUs simultaneously.
>
> Also, doing this shared counter increment across many CPUs causes heavy
> cache line bounci
On Thu, Aug 15, 2024 at 9:49 AM Andrii Nakryiko
wrote:
>
> On Thu, Aug 15, 2024 at 6:25 AM Oleg Nesterov wrote:
> >
> > On 08/12, Andrii Nakryiko wrote:
> > >
> > > ( In addition to previously posted first 8 patches, I'm sending 5 more as
> > > an
> > > RFC for people to get the general gist of
On Wed, 21 Aug 2024 at 02:32, Daniel Baluta wrote:
>
> Hello Mathieu,
>
> I've talked to Peng and if my understanding is correct I think the patch is
> OK.
> Maybe we can split the patch in two:
> * first, adding the power off callback with explanations.
> * second, adding the restart callback wi
On Fri, Aug 16, 2024 at 11:07:42AM +, Alice Ryhl wrote:
> To allow the Rust implementation of static_key_false to use runtime code
> patching instead of the generic implementation, pull in the relevant
> inline assembly from the jump_label.h header by running the C
> preprocessor on a .rs.S fil
On Mon, Aug 19, 2024 at 10:54:11AM -0500, Andrew Davis wrote:
> On 8/19/24 10:39 AM, Krzysztof Kozlowski wrote:
> > On 19/08/2024 17:32, Mathieu Poirier wrote:
> >
> > > > > > Please remove.
> > > > > Forget this comment since it would cause an error in __rproc_detach().
> > > > >
> > > > > > Oth
We're looking to add Rust module support, and I don't speak
Rust yet. The compromise was reached that in order to scale we'd
get volunteers committed from the Rust community willing to review
both Rust and C code for modules so we can ensure we get proper
reviews for both parts of the code and so t
On Thu, 15 Aug 2024 16:16:33 -0500
Avadhut Naik wrote:
> diff --git a/include/trace/events/mce.h b/include/trace/events/mce.h
> index 65aba1afcd07..1e7d5696b3ba 100644
> --- a/include/trace/events/mce.h
> +++ b/include/trace/events/mce.h
> @@ -43,6 +43,8 @@ TRACE_EVENT(mce_record,
>
From: Steven Rostedt
When printing a dynamic array in a trace event, the method is rather ugly.
It has the format of:
__print_array(__get_dynamic_array(array),
__get_dynmaic_array_len(array) / el_size, el_size)
Since dynamic arrays are known to the tracing infrastructure, create a
On Wed, Aug 21, 2024 at 7:08 PM Boqun Feng wrote:
>
> Have you try this with "make O="? I hit the following issue, but I
> am rebasing on rust-dev, so I might miss something:
>
> error: couldn't read ../rust/kernel/arch_static_branch_asm.rs: No
> such file or directory (os error 2)
>
On Tue, Dec 19, 2023 at 05:37:31PM +0900, Masahiro Yamada wrote:
> On Thu, Dec 7, 2023 at 3:37 AM Lucas De Marchi
> wrote:
> >
> > On Fri, Nov 10, 2023 at 01:13:53PM +0100, Michal Suchanek wrote:
> > >Hello,
> > >
> > >This is resend of the last patch in the series that adds prefix support
> > >t
On 21.08.24 07:30, Beleswar Prasad Padhi wrote:
>
> 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
On Wed, Aug 21, 2024 at 07:54:51PM +0200, Miguel Ojeda wrote:
> On Wed, Aug 21, 2024 at 7:08 PM Boqun Feng wrote:
> >
> > Have you try this with "make O="? I hit the following issue, but I
> > am rebasing on rust-dev, so I might miss something:
> >
> > error: couldn't read ../rust/kernel/a
On 8/21/24 12:40, Steven Rostedt wrote:
> On Thu, 15 Aug 2024 16:16:33 -0500
> Avadhut Naik wrote:
>
>> diff --git a/include/trace/events/mce.h b/include/trace/events/mce.h
>> index 65aba1afcd07..1e7d5696b3ba 100644
>> --- a/include/trace/events/mce.h
>> +++ b/include/trace/events/mce.h
>> @@
Li Zhijian wrote:
> scan_labels() leaks memory when label scanning fails and it falls back
> to just creating a default "seed" namespace for userspace to configure.
> Root can force the kernel to leak memory.
>
> Allocate the minimum resources unconditionally and release them when
> unneeded to av
Li Zhijian wrote:
> The only way create_namespace_pmem() returns an ENODEV code is if
> select_pmem_id(nd_region, &uuid) returns ENODEV when its 2nd parameter
> is a null pointer. However, this is impossible because &uuid is always
> valid.
>
> Furthermore, create_namespace_pmem() is the only user
On Tue, 20 Aug 2024 15:00:01 +0200
tglo...@redhat.com wrote:
> 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
>
Philip Chen wrote:
> 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.
> > >
> > > S
trace file is 320 MB big. If you need the full trace and log, please
tell me, and I’ll upload it somewhere.
https://owww.molgen.mpg.de/~pmenzel/20240821--linux-6.10-rc4+.txt
https://owww.molgen.mpg.de/~pmenzel/20240821--soft-irq--trace.7z
Kind regards,
Paul
Hi
On Wed, Aug 21, 2024 at 1:37 PM Ira Weiny wrote:
>
> Philip Chen wrote:
> > 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 ac
From: David Woodhouse
The vmclock "device" provides a shared memory region with precision clock
information. By using shared memory, it is safe across Live Migration.
Like the KVM PTP clock, this can convert TSC-based cross timestamps into
KVM clock values. Unlike the KVM PTP clock, it does so o
On Wed, Aug 21, 2024 at 4:31 AM Benno Lossin wrote:
>
> On 20.08.24 22:03, Matthew Maurer wrote:
> >>> 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 thi
On Wed, Aug 21, 2024 at 10:40 AM Luis Chamberlain wrote:
>
> We're looking to add Rust module support, and I don't speak
> Rust yet. The compromise was reached that in order to scale we'd
> get volunteers committed from the Rust community willing to review
> both Rust and C code for modules so we
On Wed, Aug 21, 2024 at 11:31:25AM +, Benno Lossin wrote:
> On 20.08.24 22:03, Matthew Maurer wrote:
> >>> 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 o
Currently, when using both function tracer and function graph simultaneously,
it is found that function tracer sometimes captures a fake parent
ip(return_to_handler)
instead of the true parent ip.
This issue is easy to reproduce. Below are my reproduction steps:
jeff-labs:~/bin # ./trace-net.sh
This patch introduce one sysfs attribute of "using" to klp_func.
For example, if there are serval patches make changes to function
"meminfo_proc_show", the attribute "enabled" of all the patch is 1.
With this attribute, we can easily know the version enabling belongs
to which patch.
Changes v1 =>
1. Move klp_ops into klp_func structure.
Rewrite the logic of klp_find_ops and
other logic to get klp_ops of a function.
2. Move definition of struct klp_ops into
include/linux/livepatch.h
Signed-off-by: Wardenjohn
diff --git a/include/linux/livepatch.h b/include/linux/livepatch.h
index 51a258c
One system may contains more than one livepatch module. We can see
which patch is enabled. If some patches applied to one system
modifing the same function, livepatch will use the function enabled
on top of the function stack. However, we can not excatly know
which function of which patch is now en
+static struct sgx_cgroup *sgx_cgroup_next_descendant_pre(struct
sgx_cgroup *root,
+struct sgx_cgroup *cg)
+{
+ struct cgroup_subsys_state *next;
+
+ rcu_read_lock();
+ for (;;) {
+ next = css_next_descendant
On Wed, Aug 21, 2024 at 10:58:43AM GMT, Nathan Chancellor wrote:
Did this conversation go anywhere? After the upgrade to kmod 33 in Arch
no, it stalled, thanks for reminding me. I will follow up on it.
Lucas De Marchi
On 21-08-2024 23:40, Jan Kiszka wrote:
On 21.08.24 07:30, Beleswar Prasad Padhi wrote:
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_a
On 22.08.24 07:22, Beleswar Prasad Padhi wrote:
>
> On 21-08-2024 23:40, Jan Kiszka wrote:
>> On 21.08.24 07:30, Beleswar Prasad Padhi wrote:
>>> On 19-08-2024 20:54, Jan Kiszka wrote:
From: Jan Kiszka
By simply bailing out, the driver was violating its rule and internal
>>>
>>> Us
On 22-08-2024 10:57, Jan Kiszka wrote:
On 22.08.24 07:22, Beleswar Prasad Padhi wrote:
On 21-08-2024 23:40, Jan Kiszka wrote:
On 21.08.24 07:30, Beleswar Prasad Padhi wrote:
On 19-08-2024 20:54, Jan Kiszka wrote:
From: Jan Kiszka
By simply bailing out, the driver was violating its rule an
On 22.08.24 07:42, Beleswar Prasad Padhi wrote:
>
> On 22-08-2024 10:57, Jan Kiszka wrote:
>> On 22.08.24 07:22, Beleswar Prasad Padhi wrote:
>>> On 21-08-2024 23:40, Jan Kiszka wrote:
On 21.08.24 07:30, Beleswar Prasad Padhi wrote:
> On 19-08-2024 20:54, Jan Kiszka wrote:
>> From: Ja
On 22.08.24 01:29, Greg Kroah-Hartman wrote:
> On Wed, Aug 21, 2024 at 11:31:25AM +, Benno Lossin wrote:
>> On 20.08.24 22:03, Matthew Maurer wrote:
> The way `KAbiReserved` is implemented is via a `union` (maybe a bit
> ironic, considering what I said in my other replies, but in this c
On Tue, Dec 19, 2023 at 05:37:31PM GMT, Masahiro Yamada wrote:
On Thu, Dec 7, 2023 at 3:37 AM Lucas De Marchi wrote:
On Fri, Nov 10, 2023 at 01:13:53PM +0100, Michal Suchanek wrote:
>Hello,
>
>This is resend of the last patch in the series that adds prefix support
>to kernel module location to
68 matches
Mail list logo
