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
On 14.05.24 16:04, 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, avoids that the functions
On 14.05.24 16:04, Björn Töpel wrote:
From: Björn Töpel
Now that RISC-V has memory hotplugging support, virtio-mem can be used
on the platform.
Signed-off-by: Björn Töpel
---
drivers/virtio/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/virtio/Kconfig
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 to be updated as well.
>
> Instead
On Fri, May 10, 2024 at 10:57:22AM GMT, Jose Ignacio Tornos Martinez wrote:
It has been seen that for some network mac drivers (i.e. lan78xx) the
related module for the phy is loaded dynamically depending on the current
hardware. In this case, the associated phy is read using mdio bus and then
On Sun, May 12, 2024 at 7:42 AM Luis Chamberlain wrote:
>
> On Wed, Apr 17, 2024 at 01:35:30PM +0800, wang...@lemote.com wrote:
> > From: Wang Yao
> >
> > Commit ddb5cdbafaaa ("kbuild: generate KSYMTAB entries by modpost")
> > forget drop the .export_symbol section from the final modules.
> >
>
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 are enforced:
>>
>> cpu_down()
>> ...
>>
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 the
> screen.
How exactly this is supposed to be used? We have "disabled" keys
lude
> >
> > /*
> > * Define the ABI defines if needed, so people can run the tests
> > @@ -681,6 +682,141 @@ int test_32bit(void)
> > return !segv_triggered;
> > }
> >
> > +static int parse_uint_from_file(const char *file, const char
On Mon, May 13, 2024 at 05:12:31PM +, Edgecombe, Rick P wrote:
> On Mon, 2024-05-13 at 18:50 +0900, Masami Hiramatsu wrote:
> > > I guess it's doable, we'd need to keep both trampolines around, because
> > > shadow stack is enabled by app dynamically and use one based on the
> > > state of
On Mon, May 13, 2024 at 08:59:35AM GMT, Sebastian Andrzej Siewior wrote:
> On 2024-05-07 17:16:47 [+0200], Daniel Wagner wrote:
> > Dear RT Folks,
> >
> > This is the RT stable review cycle of patch 4.19.312-rt134-rc3.
> >
> > Please scream at me if I messed something up. Please test the patches
Hi Thomas,
On 5/13/24 5:44 AM, Thomas Gleixner wrote:
> On Fri, May 10 2024 at 12:06, Dongli Zhang wrote:
>> The absence of IRQD_MOVE_PCNTXT prevents immediate effectiveness of
>> interrupt affinity reconfiguration via procfs. Instead, the change is
>> deferred until the next instance of the
On Tue, Apr 09, 2024 at 11:01:26AM GMT, Steven Rostedt
wrote:
> > - tpid = pid & (PID_MAX_DEFAULT - 1);
> > + tpid = pid % PID_MAP_SIZE;
>
> Does that compile to the same? This is a fast path.
I didn't check.
If fast is the intetion, I would change it to something
like
On Mon, Apr 08, 2024 at 04:58:18PM GMT, Michal Koutný wrote:
> The kernel provides mechanisms, while it should not imply policies --
> default pid_max seems to be an example of the policy that does not fit
> all. At the same time pid_max must have some value assigned, so use the
> end of the
On Mon, 2024-05-13 at 18:50 +0900, Masami Hiramatsu wrote:
> > I guess it's doable, we'd need to keep both trampolines around, because
> > shadow stack is enabled by app dynamically and use one based on the
> > state of shadow stack when uretprobe is installed
> >
> > so you're worried the
On Fri, May 10 2024 at 12:06, Dongli Zhang wrote:
> The absence of IRQD_MOVE_PCNTXT prevents immediate effectiveness of
> interrupt affinity reconfiguration via procfs. Instead, the change is
> deferred until the next instance of the interrupt being triggered on the
> original CPU.
>
> When the
Hi Guido,
On Thu, May 9, 2024 at 2:00 PM 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 the
> screen.
>
> Signed-off-by: Guido Günther
Thanks for your patch!
This is indeed a
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
On Sun, 12 May 2024 10:54:42 -0700 SeongJae Park wrote:
> There was an RFC IDEA
On Mon, May 13, 2024 at 2:22 PM Masahiro Yamada wrote:
>
> On Sun, May 12, 2024 at 7:59 AM Kris Van Hees
> wrote:
> >
> > 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
>
On Sat, 11 May 2024 15:09:48 -0600
Jiri Olsa wrote:
> On Thu, May 09, 2024 at 04:24:37PM +, Edgecombe, Rick P wrote:
> > On Thu, 2024-05-09 at 10:30 +0200, Jiri Olsa wrote:
> > > > Per the earlier discussion, this cannot be reached unless uretprobes
> > > > are in
> > > > use,
> > > > which
e ABI defines if needed, so people can run the tests
> @@ -681,6 +682,141 @@ int test_32bit(void)
> return !segv_triggered;
> }
>
> +static int parse_uint_from_file(const char *file, const char *fmt)
> +{
> + int err, ret;
> + FILE *f;
> +
> + f = fo
On 2024-05-07 17:16:47 [+0200], Daniel Wagner wrote:
> Dear RT Folks,
>
> This is the RT stable review cycle of patch 4.19.312-rt134-rc3.
>
> Please scream at me if I messed something up. Please test the patches
> too.
>
> The -rc release is also available on kernel.org
I do have to complain a
On Sun, May 12, 2024 at 7:59 AM Kris Van Hees wrote:
>
> 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 v1:
> - Renamed
On Sun, May 12, 2024 at 7:44 AM Kris Van Hees wrote:
>
> Signed-off-by: Kris Van Hees
> Reviewed-by: Nick Alcock
> ---
> Changes since v1:
> - Renamed CONFIG_BUILTIN_RANGES to CONFIG_BUILTIN_MODULE_RANGES
> ---
> scripts/Makefile.vmlinux | 17 +
> 1 file changed, 17
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. But
> that does not work if the module is built into the kernel because the
>
Hi Markus
Thanks for your review.
在 5/13/24 01:12, Markus Elfring 写道:
When the condition ei->is_free holds,we return NULL directly to
avoid update_events_attr to use NULL point about ei.
* Please avoid typos in the summary phrase and the commit message.
* Would you like to use an
On Sat, May 11, 2024 at 4:56 PM Dmitry Baryshkov
wrote:
>
> Protection domain mapper is a QMI service providing mapping between
> 'protection domains' and services supported / allowed in these domains.
> For example such mapping is required for loading of the WiFi firmware or
> for properly
On Fri, 10 May 2024 15:50:45 +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 or not. It's up to the caller to translate the true/false
> into -EINVAL on
On Sat, 11 May 2024 13:16:17 -0700 SeongJae Park wrote:
> On Fri, 5 Apr 2024 12:19:07 -0700 SeongJae Park wrote:
>
> > On Fri, 5 Apr 2024 15:08:50 +0900 Honggyu Kim wrote:
> >
> > > This is a preparation patch that introduces migration modes.
> > >
> > > The damon_pa_pageout is renamed to
> When the condition ei->is_free holds,we return NULL directly to
> avoid update_events_attr to use NULL point about ei.
* Please avoid typos in the summary phrase and the commit message.
* Would you like to use an imperative wording for an improved change
description?
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 or not. It's up to the caller to translate the true/false
> into -EINVAL on
601 - 700 of 2410661 matches
Mail list logo
