On Sat, 18 May 2024 15:54:49 -0700
Jeff Johnson wrote:
> Fix the 'make W=1' warning:
>
> WARNING: modpost: missing MODULE_DESCRIPTION() in
> kernel/trace/preemptirq_delay_test.o
>
Looks good to me.
Acked-by: Masami Hiramatsu (Google)
Fixes: f96e8577da10 ("lib: Add module for testing
Le 30/04/2024 à 12:53, Beleswar Padhi a écrit :
PSC controller has a limitation that it can only power-up the second
core when the first core is in ON state. Power-state for core0 should be
equal to or higher than core1.
Therefore, prevent core1 from powering up before core0 during the start
On 5/17/24 11:00, Guenter Roeck wrote:
On 5/17/24 10:48, Steven Rostedt wrote:
On Fri, 17 May 2024 10:36:37 -0700
Guenter Roeck wrote:
Building csky:allmodconfig (and others) ... failed
--
Error log:
In file included from include/trace/trace_events.h:419,
from
* li...@treblig.org (li...@treblig.org) wrote:
> From: "Dr. David Alan Gilbert"
>
> It doesn't look like this was ever used.
>
> Build tested only.
>
> Signed-off-by: Dr. David Alan Gilbert
Ping
> ---
> drivers/virt/acrn/irqfd.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git
On 5/17/24 10:48, Steven Rostedt wrote:
On Fri, 17 May 2024 10:36:37 -0700
Guenter Roeck wrote:
Building csky:allmodconfig (and others) ... failed
--
Error log:
In file included from include/trace/trace_events.h:419,
from include/trace/define_trace.h:102,
On Fri, 17 May 2024 10:36:37 -0700
Guenter Roeck wrote:
> Building csky:allmodconfig (and others) ... failed
> --
> Error log:
> In file included from include/trace/trace_events.h:419,
> from include/trace/define_trace.h:102,
> from
On Thu, May 16, 2024 at 01:34:54PM -0400, Steven Rostedt wrote:
> From: "Steven Rostedt (Google)"
>
> [
>This is a treewide change. I will likely re-create this patch again in
>the second week of the merge window of v6.10 and submit it then. Hoping
&
On Thu, May 16, 2024 at 01:34:54PM -0400, Steven Rostedt wrote:
> From: "Steven Rostedt (Google)"
>
> [
>This is a treewide change. I will likely re-create this patch again in
>the second week of the merge window of v6.10 and submit it then. Hoping
&
On 2024-05-17 17:46, Will Deacon wrote:
Hi Klara,
On Fri, May 17, 2024 at 01:00:31AM +0200, Klara Modin wrote:
This does not seem to work entirely. If build with BPF_JIT without module
support for my Raspberry Pi 3 B I get warnings in my kernel log (easiest way
to trigger it seems to be
Hi Klara,
On Fri, May 17, 2024 at 01:00:31AM +0200, Klara Modin wrote:
> On 2024-05-05 18:06, Mike Rapoport wrote:
> > From: "Mike Rapoport (IBM)"
> >
> > BPF just-in-time compiler depended on CONFIG_MODULES because it used
> > module_alloc() to allocate memory for the generated code.
> >
> >
On Fri, 17 May 2024 10:08:51 +0300
Jani Nikula wrote:
> On Thu, 16 May 2024, Steven Rostedt wrote:
> > There's over 700 users of __assign_str() and because coccinelle does not
> > handle the TRACE_EVENT() macro I ended up using the following sed script:
> >
> > git grep -l __assign_str |
Hi Yang
On 5/17/24 11:14, Yang Li wrote:
> The patch updates the function documentation comment for
> rv_en(dis)able_monitor to adhere to the kernel-doc specification.
>
> Signed-off-by: Yang Li
> ---
> kernel/trace/rv/rv.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git
On Thu, 16 May 2024 19:34:54 +0200,
Steven Rostedt wrote:
>
> From: "Steven Rostedt (Google)"
>
> [
>This is a treewide change. I will likely re-create this patch again in
>the second week of the merge window of v6.10 and submit it then. Hopin
On Thu, May 16, 2024 at 7:35 PM Steven Rostedt wrote:
>
> From: "Steven Rostedt (Google)"
>
> [
>This is a treewide change. I will likely re-create this patch again in
>the second week of the merge window of v6.10 and submit it then. Hoping
>to keep t
On Thu, 16 May 2024, Steven Rostedt wrote:
> There's over 700 users of __assign_str() and because coccinelle does not
> handle the TRACE_EVENT() macro I ended up using the following sed script:
>
> git grep -l __assign_str | while read a ; do
> sed -e 's/\(__assign_str([^,]*[^ ,]\)
On Wed, 15 May 2024 11:05:43 -0400 Michael S. Tsirkin wrote:
> There are two issues around seqpacket_allow:
> 1. seqpacket_allow is not initialized when socket is
>created. Thus if features are never set, it will be
>read uninitialized.
> 2. if VIRTIO_VSOCK_F_SEQPACKET is set and then
Hi,
On 2024-05-05 18:06, Mike Rapoport wrote:
From: "Mike Rapoport (IBM)"
BPF just-in-time compiler depended on CONFIG_MODULES because it used
module_alloc() to allocate memory for the generated code.
Since code allocations are now implemented with execmem, drop dependency of
CONFIG_BPF_JIT
On 16.05.24 19:44, Guillaume Morin wrote:
On 02 May 5:59, Guillaume Morin wrote:
On 30 Apr 21:25, David Hildenbrand wrote:
I tried to get the hugepd stuff right but this was the first I heard
about it :-) Afaict follow_huge_pmd and friends were already DTRT
I'll have to have a closer look
On 02 May 5:59, Guillaume Morin wrote:
>
> On 30 Apr 21:25, David Hildenbrand wrote:
> > > I tried to get the hugepd stuff right but this was the first I heard
> > > about it :-) Afaict follow_huge_pmd and friends were already DTRT
> >
> > I'll have to have a closer look at some details (the
On Wed, May 15, 2024 at 5:05 PM Michael S. Tsirkin wrote:
>
> There are two issues around seqpacket_allow:
> 1. seqpacket_allow is not initialized when socket is
>created. Thus if features are never set, it will be
>read uninitialized.
> 2. if VIRTIO_VSOCK_F_SEQPACKET is set and then
> Subject: Re: [PATCH] vhost: use pr_err for vq_err
>
> On Thu, May 16, 2024 at 03:46:29PM +0800, Peng Fan (OSS) wrote:
> > From: Peng Fan
> >
> > Use pr_err to print out error message without enabling DEBUG. This
> > could make people catch error easier
On Thu, May 16, 2024 at 03:46:29PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan
>
> Use pr_err to print out error message without enabling DEBUG. This could
> make people catch error easier.
>
> Signed-off-by: Peng Fan
This isn't appropriate: pr_err must not be triggerable
by userspace. If
On Thu, May 16, 2024 at 5:46 PM Catherine Redfield
wrote:
>
> Feng,
>
> Thank you for providing your debugging steps; I used them on a gce image
> locally and was not able to replicate the issue. I also attempted to
> replicate in qemu/virsh using qemu-guest-agent to enable the S3 suspend
>
On Thu May 16, 2024 at 1:29 AM EEST, Haitao Huang wrote:
> On Wed, 15 May 2024 16:55:59 -0500, Haitao Huang
> wrote:
>
> > On Wed, 15 May 2024 01:55:21 -0500, Bojun Zhu
> > wrote:
> >
> >> EDMM's ioctl()s support batch operations, which may be
> >> time-consuming. Try to explicitly give up
On Thu May 16, 2024 at 12:55 AM EEST, Haitao Huang wrote:
> On Wed, 15 May 2024 01:55:21 -0500, Bojun Zhu
> wrote:
>
> > EDMM's ioctl()s support batch operations, which may be
> > time-consuming. Try to explicitly give up the CPU as the prefix
> > operation at the every begin of "for loop" in
>
On Wed, May 15, 2024 at 11:05:43AM GMT, Michael S. Tsirkin wrote:
There are two issues around seqpacket_allow:
1. seqpacket_allow is not initialized when socket is
created. Thus if features are never set, it will be
read uninitialized.
2. if VIRTIO_VSOCK_F_SEQPACKET is set and then cleared,
On Wed, May 15, 2024 at 11:05 PM Michael S. Tsirkin wrote:
>
> There are two issues around seqpacket_allow:
> 1. seqpacket_allow is not initialized when socket is
>created. Thus if features are never set, it will be
>read uninitialized.
> 2. if VIRTIO_VSOCK_F_SEQPACKET is set and then
On Thu, May 16, 2024 at 1:50 AM Kris Van Hees wrote:
>
> On Mon, May 13, 2024 at 01:43:15PM +0900, Masahiro Yamada wrote:
> > On Sun, May 12, 2024 at 7:42???AM Kris Van Hees
> > wrote:
> > >
> > > Especially for tracing applications, it is convenient to be able to
> > > refer to a symbol using
The pull request you sent on Tue, 14 May 2024 01:22:35 -0700:
> git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux.git/
> tags/modules-6.10-rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/a49468240e89628236b738b5ab9416eae8f90c15
Thank you!
--
The pull request you sent on Wed, 15 May 2024 09:41:46 -0700:
> git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git
> tags/libnvdimm-for-6.10
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/c405aa3ea36c1f973a9f10bbcfabc9aeeb38040c
Thank you!
--
On Wed, 15 May 2024 16:55:59 -0500, Haitao Huang
wrote:
On Wed, 15 May 2024 01:55:21 -0500, Bojun Zhu
wrote:
EDMM's ioctl()s support batch operations, which may be
time-consuming. Try to explicitly give up the CPU as the prefix
operation at the every begin of "for loop" in
sgx_enclave_{
On Wed, 15 May 2024 08:12:39 -0500, Dmitrii Kuvaiskii
wrote:
Two enclave threads may try to access the same non-present enclave page
simultaneously (e.g., if the SGX runtime supports lazy allocation). The
threads will end up in sgx_encl_eaug_page(), racing to acquire the
enclave lock. The
On Wed, 15 May 2024 08:12:40 -0500, Dmitrii Kuvaiskii
wrote:
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
On Wed, 15 May 2024 01:55:21 -0500, Bojun Zhu
wrote:
EDMM's ioctl()s support batch operations, which may be
time-consuming. Try to explicitly give up the CPU as the prefix
operation at the every begin of "for loop" in
sgx_enclave_{ modify_types | restrict_permissions | remove_pages}
to give
On Wed, May 15, 2024 at 02:30:37PM -0700, Alexei Starovoitov wrote:
> On Tue, May 14, 2024 at 12:33 AM Ubisectech Sirius
> wrote:
> >
> > Hello.
> > We are Ubisectech Sirius Team, the vulnerability lab of China ValiantSec.
> > Recently, our team has discovered a issue in Linux kernel 6.7.
On Tue, May 14, 2024 at 12:33 AM Ubisectech Sirius
wrote:
>
> Hello.
> We are Ubisectech Sirius Team, the vulnerability lab of China ValiantSec.
> Recently, our team has discovered a issue in Linux kernel 6.7. Attached to
> the email were a PoC file of the issue.
Jiri,
please take a look.
>
The pull request you sent on Wed, 15 May 2024 14:24:41 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/livepatching/livepatching
> tags/livepatching-for-6.10
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/8c06da67d0bd3139a97f301b4aa9c482b9d4f29e
Thank you!
On 5/13/24 3:46 PM, Thomas Gleixner wrote:
> On Mon, May 13 2024 at 10:43, Dongli Zhang wrote:
>> On 5/13/24 5:44 AM, Thomas Gleixner wrote:
>>> On Fri, May 10 2024 at 12:06, Dongli Zhang wrote:
>>> Any interrupt which is affine to an outgoing CPU is migrated and
>>> eventually pending moves
On 05/15/24 08:50, Phil Auld wrote:
> > > My point was just to call it rt_task() still.
> >
> > It is called rt_task() still. I just added a new realtime_task() to return
> > true
> > for RT and DL. rt_task() will return true only for RT now.
> >
> > How do you see this should be done
On Mon, May 13, 2024 at 01:43:15PM +0900, Masahiro Yamada wrote:
> On Sun, May 12, 2024 at 7:42???AM Kris Van Hees
> wrote:
> >
> > 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.
> Thank you very much. I understand the changelog is still being discussed
> and those changes look good to me, to which you can add:
>
> Reviewed-by: Reinette Chatre
also for this (with changelog tweak Dave suggested) so that we don't
need a new round:
Reviewed-by: Jarkko Sakkinen
BR, Jarkko
Hi Honggyu,
On Mon, 13 May 2024 20:59:15 +0900 Honggyu Kim wrote:
> Hi SeongJae,
>
> Thanks very much for your work! It got delayed due to the priority
> changes in my workplace for building another heterogeneous memory
> allocator.
> https://github.com/skhynix/hmsdk/wiki/hmalloc
No problem
Hi Dmitrii,
On 5/15/2024 6:12 AM, Dmitrii Kuvaiskii wrote:
> Two enclave threads may try to access the same non-present enclave page
> simultaneously (e.g., if the SGX runtime supports lazy allocation). The
> threads will end up in sgx_encl_eaug_page(), racing to acquire the
> enclave lock. The
Hi Dmitrii,
On 5/15/2024 6:12 AM, Dmitrii Kuvaiskii wrote:
> 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
On 05/15, Edgecombe, Rick P wrote:
>
> On Wed, 2024-05-15 at 13:35 +0200, Oleg Nesterov wrote:
> >
> > > I'm ok with not using optimized uretprobe when shadow stack is detected
> > > as enabled and we go with current uretprobe in that case
> >
> > But how can we detect it? Again, suppose userspace
On Wed, 2024-05-15 at 17:26 +0200, Oleg Nesterov wrote:
> > I think it will crash, there's explanation in the comment in
> > tools/testing/selftests/x86/test_shadow_stack.c test
>
> OK, thanks...
>
> But test_shadow_stack.c doesn't do ARCH_PRCTL(ARCH_SHSTK_DISABLE) if
> all the tests succeed ?
On 05/15, Jiri Olsa wrote:
>
> On Wed, May 15, 2024 at 01:19:20PM +0200, Oleg Nesterov wrote:
> > Let me ask a couple of really stupid questions. What if the shadow stack
> > is "shorter" than the normal stack? I mean,
> >
> > enable_shstk()
> > {
> > prctl(ARCH_SHSTK_SHSTK);
On Wed, 2024-05-15 at 08:36 -0600, Jiri Olsa wrote:
> >
> > Let me ask a couple of really stupid questions. What if the shadow stack
> > is "shorter" than the normal stack? I mean,
The shadow stack could overflow if it is not big enough. However since the
normal stack has return addresses and
On Wed, 2024-05-15 at 13:35 +0200, Oleg Nesterov wrote:
> Let me repeat I know nothing about shadow stacks, only tried to
> read Documentation/arch/x86/shstk.rst few minutes ago ;)
>
> On 05/13, Jiri Olsa wrote:
> >
> > 1) current uretprobe which are not working at the moment and we change
> >
Hi Rob,
Any feedback on the below topic?
Regards
Luca
On Donnerstag, 25. April 2024 20:54:40 MESZ Luca Weiss wrote:
> On Donnerstag, 25. April 2024 18:17:15 MESZ Rob Herring wrote:
> > On Wed, Apr 24, 2024 at 07:21:51PM +0200, Luca Weiss wrote:
> > > The qcom,ipc-N properties are essentially
On Wed, May 15, 2024 at 04:50:48PM +0200, Dan Carpenter wrote:
> On Sun, May 12, 2024 at 12:01:55PM -0400, Michael S. Tsirkin wrote:
> > On Fri, May 10, 2024 at 03:50:45PM +0300, Dan Carpenter wrote:
> > > The virtnet_send_command_reply() function returns true on success or
> > > false on failure.
On Sun, May 12, 2024 at 12:01:55PM -0400, Michael S. Tsirkin wrote:
> On Fri, May 10, 2024 at 03:50:45PM +0300, Dan Carpenter wrote:
> > The virtnet_send_command_reply() function returns true on success or
> > false on failure. The "ok" variable is true/false depending on whether
> > it succeeds
On Wed May 15, 2024 at 4:12 PM EEST, Dmitrii Kuvaiskii wrote:
> 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
On Wed, May 15, 2024 at 01:19:20PM +0200, Oleg Nesterov wrote:
> Sorry for the late reply, I was on PTO.
>
> On 05/14, Deepak Gupta wrote:
> >
> > Question,
> >
> > Is it kernel who is maintaining all return probes, meaning original return
> > addresses
> > are saved in kernel data structures on
On Wed, May 15, 2024 at 3:30 AM Peter Zijlstra wrote:
>
> On Wed, May 08, 2024 at 02:26:03PM -0700, Andrii Nakryiko wrote:
>
> > +static void fixup_uretprobe_trampoline_entries(struct perf_callchain_entry
> > *entry,
> > +int start_entry_idx)
> > +{
>
On Wed May 15, 2024 at 5:15 PM EEST, Dave Hansen wrote:
> On 5/15/24 06:54, Jarkko Sakkinen wrote:
> > I'd cut out 90% of the description out and just make the argument of
> > the wrong error code, and done. The sequence is great for showing
> > how this could happen. The prose makes my head hurt
On 5/15/24 06:54, Jarkko Sakkinen wrote:
> I'd cut out 90% of the description out and just make the argument of
> the wrong error code, and done. The sequence is great for showing
> how this could happen. The prose makes my head hurt tbh.
The changelog is too long, but not fatally so. I'd much
On Wed May 15, 2024 at 4:54 PM EEST, Jarkko Sakkinen wrote:
> On Wed May 15, 2024 at 4:12 PM EEST, Dmitrii Kuvaiskii wrote:
> > diff --git a/arch/x86/kernel/cpu/sgx/encl.c b/arch/x86/kernel/cpu/sgx/encl.c
> > index 279148e72459..41f14b1a3025 100644
> > --- a/arch/x86/kernel/cpu/sgx/encl.c
> > +++
On Wed May 15, 2024 at 4:12 PM EEST, Dmitrii Kuvaiskii wrote:
> diff --git a/arch/x86/kernel/cpu/sgx/encl.c b/arch/x86/kernel/cpu/sgx/encl.c
> index 279148e72459..41f14b1a3025 100644
> --- a/arch/x86/kernel/cpu/sgx/encl.c
> +++ b/arch/x86/kernel/cpu/sgx/encl.c
> @@ -382,8 +382,11 @@ static
.
>
> It is called rt_task() still. I just added a new realtime_task() to return
> true
> for RT and DL. rt_task() will return true only for RT now.
>
> How do you see this should be done instead? I'm not seeing the problem.
>
Right, sorry. I misread your commit message completely and then all the
places where you changed rt_task() to realtime_task() fit my misreading.
rt_task() means rt class and realtime_task does what rt_task() used to do.
That's how I would do it, too :)
(Re)
Reviewed-by: Phil Auld
Cheers,
Phil
--
On Wed May 15, 2024 at 9:55 AM EEST, Bojun Zhu wrote:
> EDMM's ioctl()s support batch operations, which may be
> time-consuming. Try to explicitly give up the CPU as the prefix
> operation at the every begin of "for loop" in
> sgx_enclave_{ modify_types | restrict_permissions | remove_pages}
> to
On 05/15/24 07:20, Phil Auld wrote:
> On Wed, May 15, 2024 at 10:32:38AM +0200 Peter Zijlstra wrote:
> > On Tue, May 14, 2024 at 07:58:51PM -0400, Phil Auld wrote:
> > >
> > > Hi Qais,
> > >
> > > On Wed, May 15, 2024 at 12:41:12AM +0100 Qais Yousef wrote:
> > > > rt_task() checks if a task has
Let me repeat I know nothing about shadow stacks, only tried to
read Documentation/arch/x86/shstk.rst few minutes ago ;)
On 05/13, Jiri Olsa wrote:
>
> 1) current uretprobe which are not working at the moment and we change
>the top value of shadow stack with shstk_push_frame
> 2) optimized
Sorry for the late reply, I was on PTO.
On 05/14, Deepak Gupta wrote:
>
> Question,
>
> Is it kernel who is maintaining all return probes, meaning original return
> addresses
> are saved in kernel data structures on per task basis.
Yes. task_struct->utask->return_instances
See
On Wed, May 15, 2024 at 10:32:38AM +0200 Peter Zijlstra wrote:
> On Tue, May 14, 2024 at 07:58:51PM -0400, Phil Auld wrote:
> >
> > Hi Qais,
> >
> > On Wed, May 15, 2024 at 12:41:12AM +0100 Qais Yousef wrote:
> > > rt_task() checks if a task has RT priority. But depends on your
> > > dictionary,
On 05/15/24 10:32, Peter Zijlstra wrote:
> On Tue, May 14, 2024 at 07:58:51PM -0400, Phil Auld wrote:
> >
> > Hi Qais,
> >
> > On Wed, May 15, 2024 at 12:41:12AM +0100 Qais Yousef wrote:
> > > rt_task() checks if a task has RT priority. But depends on your
> > > dictionary, this could mean it
On Wed, May 08, 2024 at 02:26:03PM -0700, Andrii Nakryiko wrote:
> +static void fixup_uretprobe_trampoline_entries(struct perf_callchain_entry
> *entry,
> +int start_entry_idx)
> +{
> +#ifdef CONFIG_UPROBES
> + struct uprobe_task *utask =
On Tue, May 14, 2024 at 07:58:51PM -0400, Phil Auld wrote:
>
> Hi Qais,
>
> On Wed, May 15, 2024 at 12:41:12AM +0100 Qais Yousef wrote:
> > rt_task() checks if a task has RT priority. But depends on your
> > dictionary, this could mean it belongs to RT class, or is a 'realtime'
> > task, which
Björn Töpel writes:
> From: Björn Töpel
>
> ZONE_DEVICE pages need DEVMAP PTEs support to function
> (ARCH_HAS_PTE_DEVMAP). Claim another RSW (reserved for software) bit
> in the PTE for DEVMAP mark, add the corresponding helpers, and enable
> ARCH_HAS_PTE_DEVMAP for riscv64.
...and this patch
Oscar Salvador writes:
> On Tue, May 14, 2024 at 04:04:42PM +0200, Björn Töpel wrote:
>> +static void __meminit free_vmemmap_storage(struct page *page, size_t size,
>> + struct vmem_altmap *altmap)
>> +{
>> +if (altmap)
>> +
Oscar Salvador writes:
> On Tue, May 14, 2024 at 04:04:40PM +0200, Björn Töpel wrote:
>> From: Björn Töpel
>>
>> Prepare for memory hotplugging support by changing from __init to
>> __meminit for the page table functions that are used by the upcoming
>> architecture specific callbacks.
>>
>>
On Tue, May 14, 2024 at 06:21:57PM -0700, Yuanchu Xie wrote:
> On Tue, May 14, 2024 at 9:06 AM Greg Kroah-Hartman
> wrote:
> >
> > On Mon, May 13, 2024 at 07:03:00PM -0700, Yuanchu Xie wrote:
> > > Memctl provides a way for the guest to control its physical memory
> > > properties, and enables
On Wed, May 15, 2024 at 01:10:03AM +, Edgecombe, Rick P wrote:
On Mon, 2024-05-13 at 15:23 -0600, Jiri Olsa wrote:
so at the moment the patch 6 changes shadow stack for
1) current uretprobe which are not working at the moment and we change
the top value of shadow stack with
On Tue, May 14, 2024 at 9:06 AM Greg Kroah-Hartman
wrote:
>
> On Mon, May 13, 2024 at 07:03:00PM -0700, Yuanchu Xie wrote:
> > Memctl provides a way for the guest to control its physical memory
> > properties, and enables optimizations and security features. For
> > example, the guest can provide
On Mon, 2024-05-13 at 15:23 -0600, Jiri Olsa wrote:
> so at the moment the patch 6 changes shadow stack for
>
> 1) current uretprobe which are not working at the moment and we change
> the top value of shadow stack with shstk_push_frame
> 2) optimized uretprobe which needs to push new frame on
Hi Qais,
On Wed, May 15, 2024 at 12:41:12AM +0100 Qais Yousef wrote:
> rt_task() checks if a task has RT priority. But depends on your
> dictionary, this could mean it belongs to RT class, or is a 'realtime'
> task, which includes RT and DL classes.
>
> Since this has caused some confusion
Hi Kris,
kernel test robot noticed the following build warnings:
[auto build test WARNING on dd5a440a31fae6e459c0d627162825505361]
url:
https://github.com/intel-lab-lkp/linux/commits/Kris-Van-Hees/kbuild-add-modules-builtin-objs/20240512-065954
base:
On Tue, May 14, 2024 at 04:04:44PM +0200, Björn Töpel wrote:
> From: Björn Töpel
>
> Enable ARCH_ENABLE_MEMORY_HOTPLUG and ARCH_ENABLE_MEMORY_HOTREMOVE for
> RISC-V.
>
> Signed-off-by: Björn Töpel
> ---
> arch/riscv/Kconfig | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git
On Tue, May 14, 2024 at 04:04:43PM +0200, Björn Töpel wrote:
> From: Björn Töpel
>
> During memory hot remove, the ptdump functionality can end up touching
> stale data. Avoid any potential crashes (or worse), by holding the
> memory hotplug read-lock while traversing the page table.
>
> This
On Tue, May 14, 2024 at 04:04:42PM +0200, Björn Töpel wrote:
> +static void __meminit free_vmemmap_storage(struct page *page, size_t size,
> +struct vmem_altmap *altmap)
> +{
> + if (altmap)
> + vmem_altmap_free(altmap, size >> PAGE_SHIFT);
>
On 14.05.24 20:17, Björn Töpel wrote:
Alexandre Ghiti writes:
On Tue, May 14, 2024 at 4:05 PM Björn Töpel wrote:
From: Björn Töpel
Enable ARCH_ENABLE_MEMORY_HOTPLUG and ARCH_ENABLE_MEMORY_HOTREMOVE for
RISC-V.
Signed-off-by: Björn Töpel
---
arch/riscv/Kconfig | 2 ++
1 file changed,
On 14.05.24 16:04, Björn Töpel wrote:
From: Björn Töpel
During memory hot remove, the ptdump functionality can end up touching
stale data. Avoid any potential crashes (or worse), by holding the
memory hotplug read-lock while traversing the page table.
This change is analogous to arm64's
On Tue, May 14, 2024 at 04:04:41PM +0200, Björn Töpel wrote:
> From: Björn Töpel
>
> Add a parameter to the direct map setup function, so it can be used in
> arch_add_memory() later.
>
> Signed-off-by: Björn Töpel
Reviewed-by: Oscar Salvador
> ---
> arch/riscv/mm/init.c | 15
On Tue, May 14, 2024 at 04:04:40PM +0200, Björn Töpel wrote:
> From: Björn Töpel
>
> Prepare for memory hotplugging support by changing from __init to
> __meminit for the page table functions that are used by the upcoming
> architecture specific callbacks.
>
> Changing the __init attribute to
Alexandre Ghiti writes:
> On Tue, May 14, 2024 at 4:05 PM Björn Töpel wrote:
>> +int __ref arch_add_memory(int nid, u64 start, u64 size, struct mhp_params
>> *params)
>> +{
>> + int ret;
>> +
>> + create_linear_mapping_range(start, start + size, 0, >pgprot);
>> +
On Tue, May 14, 2024 at 8:17 PM Björn Töpel wrote:
>
> Alexandre Ghiti writes:
>
> > On Tue, May 14, 2024 at 4:05 PM Björn Töpel wrote:
> >>
> >> From: Björn Töpel
> >>
> >> Enable ARCH_ENABLE_MEMORY_HOTPLUG and ARCH_ENABLE_MEMORY_HOTREMOVE for
> >> RISC-V.
> >>
> >> Signed-off-by: Björn Töpel
The pull request you sent on Tue, 14 May 2024 16:34:42 +0100:
> https://github.com/openrisc/linux.git tags/for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/590103732442b4bb83886f03f2ddd39d129c3289
Thank you!
--
Deet-doot-dot, I am a bot.
Alexandre Ghiti writes:
> On Tue, May 14, 2024 at 4:05 PM Björn Töpel wrote:
>>
>> From: Björn Töpel
>>
>> Enable ARCH_ENABLE_MEMORY_HOTPLUG and ARCH_ENABLE_MEMORY_HOTREMOVE for
>> RISC-V.
>>
>> Signed-off-by: Björn Töpel
>> ---
>> arch/riscv/Kconfig | 2 ++
>> 1 file changed, 2
On Tue, May 14, 2024 at 4:05 PM Björn Töpel wrote:
>
> From: Björn Töpel
>
> Enable ARCH_ENABLE_MEMORY_HOTPLUG and ARCH_ENABLE_MEMORY_HOTREMOVE for
> RISC-V.
>
> Signed-off-by: Björn Töpel
> ---
> arch/riscv/Kconfig | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/riscv/Kconfig
On Tue, May 14, 2024 at 4:05 PM Björn Töpel wrote:
>
> From: Björn Töpel
>
> For an architecture to support memory hotplugging, a couple of
> callbacks needs to be implemented:
>
> arch_add_memory()
> This callback is responsible for adding the physical memory into the
> direct map, and
Alexandre Ghiti writes:
> On Tue, May 14, 2024 at 4:05 PM Björn Töpel wrote:
>>
>> From: Björn Töpel
>>
>> Prepare for memory hotplugging support by changing from __init to
>> __meminit for the page table functions that are used by the upcoming
>> architecture specific callbacks.
>>
>>
On Tue, May 14, 2024 at 4:05 PM Björn Töpel wrote:
>
> From: Björn Töpel
>
> Add a parameter to the direct map setup function, so it can be used in
> arch_add_memory() later.
>
> Signed-off-by: Björn Töpel
> ---
> arch/riscv/mm/init.c | 15 ++-
> 1 file changed, 6 insertions(+), 9
On Tue, May 14, 2024 at 4:05 PM Björn Töpel wrote:
>
> From: Björn Töpel
>
> Prepare for memory hotplugging support by changing from __init to
> __meminit for the page table functions that are used by the upcoming
> architecture specific callbacks.
>
> Changing the __init attribute to __meminit,
David Hildenbrand writes:
> On 14.05.24 16:04, Björn Töpel wrote:
>> From: Björn Töpel
>>
>> For an architecture to support memory hotplugging, a couple of
>> callbacks needs to be implemented:
>>
>> arch_add_memory()
>>This callback is responsible for adding the physical memory into
Alexandre Ghiti writes:
> Hi Björn,
>
> On Tue, May 14, 2024 at 4:05 PM Björn Töpel wrote:
>>
>> From: Björn Töpel
>>
>> The RISC-V port copies the PGD table from init_mm/swapper_pg_dir to
>> all userland page tables, which means that if the PGD level table is
>> changed, other page tables has
On Mon, May 13, 2024 at 07:03:00PM -0700, Yuanchu Xie wrote:
> +/*
> + * Used for internal kernel memctl calls, i.e. to better support kernel
> stacks,
> + * or to efficiently zero hugetlb pages.
> + */
> +long memctl_vmm_call(__u64 func_code, __u64 addr, __u64 length, __u64 arg,
> +
On Mon, May 13, 2024 at 07:03:00PM -0700, Yuanchu Xie wrote:
> Memctl provides a way for the guest to control its physical memory
> properties, and enables optimizations and security features. For
> example, the guest can provide information to the host where parts of a
> hugepage may be unbacked,
Hi,
On Mon, May 13, 2024 at 03:13:53PM -0700, Dmitry Torokhov wrote:
> Hi Guido,
>
> On Thu, May 09, 2024 at 02:00:28PM +0200, Guido Günther wrote:
> > This helps user space to figure out which keys should be used to unidle a
> > device. E.g on phones the volume rocker should usually not unblank
On 14.05.24 16:04, Björn Töpel wrote:
From: Björn Töpel
For an architecture to support memory hotplugging, a couple of
callbacks needs to be implemented:
arch_add_memory()
This callback is responsible for adding the physical memory into the
direct map, and call into the memory
On 14.05.24 16:04, Björn Töpel wrote:
From: Björn Töpel
Add a parameter to the direct map setup function, so it can be used in
arch_add_memory() later.
Signed-off-by: Björn Töpel
---
Reviewed-by: David Hildenbrand
--
Cheers,
David / dhildenb
1 - 100 of 2410091 matches
Mail list logo
