Re: [PATCH] sched/rt: Clean up usage of rt_task()

2024-05-15 Thread Phil Auld
. > > 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 --

Re: [RFC PATCH v3 1/1] x86/sgx: Explicitly give up the CPU in EDMM's ioctl() to avoid softlockup

2024-05-15 Thread Jarkko Sakkinen
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

Re: [PATCH] sched/rt: Clean up usage of rt_task()

2024-05-15 Thread Qais Yousef
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

Re: [PATCHv5 bpf-next 6/8] x86/shstk: Add return uprobe support

2024-05-15 Thread Oleg Nesterov
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

Re: [PATCHv5 bpf-next 6/8] x86/shstk: Add return uprobe support

2024-05-15 Thread Oleg Nesterov
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

Re: [PATCH] sched/rt: Clean up usage of rt_task()

2024-05-15 Thread Phil Auld
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,

Re: [PATCH] sched/rt: Clean up usage of rt_task()

2024-05-15 Thread Qais Yousef
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

Re: [PATCH 2/4] perf,uprobes: fix user stack traces in the presence of pending uretprobes

2024-05-15 Thread Peter Zijlstra
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 =

Re: [PATCH] sched/rt: Clean up usage of rt_task()

2024-05-15 Thread Peter Zijlstra
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

Re: [PATCH v2 8/8] riscv: mm: Add support for ZONE_DEVICE

2024-05-15 Thread Björn Töpel
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

Re: [PATCH v2 4/8] riscv: mm: Add memory hotplugging support

2024-05-14 Thread Björn Töpel
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) >> +

Re: [PATCH v2 2/8] riscv: mm: Change attribute from __init to __meminit for page functions

2024-05-14 Thread Björn Töpel
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. >> >>

Re: [RFC PATCH v1 1/2] virt: memctl: control guest physical memory properties

2024-05-14 Thread Greg Kroah-Hartman
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

Re: [PATCHv5 bpf-next 6/8] x86/shstk: Add return uprobe support

2024-05-14 Thread Deepak Gupta
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

Re: [RFC PATCH v1 1/2] virt: memctl: control guest physical memory properties

2024-05-14 Thread Yuanchu Xie
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

Re: [PATCHv5 bpf-next 6/8] x86/shstk: Add return uprobe support

2024-05-14 Thread Edgecombe, Rick P
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

Re: [PATCH] sched/rt: Clean up usage of rt_task()

2024-05-14 Thread Phil Auld
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

Re: [PATCH v2 2/6] trace: add CONFIG_BUILTIN_MODULE_RANGES option

2024-05-14 Thread kernel test robot
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:

Re: [PATCH v2 6/8] riscv: Enable memory hotplugging for RISC-V

2024-05-14 Thread Oscar Salvador
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

Re: [PATCH v2 5/8] riscv: mm: Take memory hotplug read-lock during kernel page table dump

2024-05-14 Thread Oscar Salvador
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

Re: [PATCH v2 4/8] riscv: mm: Add memory hotplugging support

2024-05-14 Thread Oscar Salvador
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); >

Re: [PATCH v2 6/8] riscv: Enable memory hotplugging for RISC-V

2024-05-14 Thread David Hildenbrand
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,

Re: [PATCH v2 5/8] riscv: mm: Take memory hotplug read-lock during kernel page table dump

2024-05-14 Thread David Hildenbrand
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

Re: [PATCH v2 3/8] riscv: mm: Refactor create_linear_mapping_range() for memory hot add

2024-05-14 Thread Oscar Salvador
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

Re: [PATCH v2 2/8] riscv: mm: Change attribute from __init to __meminit for page functions

2024-05-14 Thread Oscar Salvador
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

Re: [PATCH v2 4/8] riscv: mm: Add memory hotplugging support

2024-05-14 Thread Björn Töpel
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); >> +

Re: [PATCH v2 6/8] riscv: Enable memory hotplugging for RISC-V

2024-05-14 Thread Alexandre Ghiti
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

Re: [GIT PULL] OpenRISC updates for 6.10

2024-05-14 Thread pr-tracker-bot
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.

Re: [PATCH v2 6/8] riscv: Enable memory hotplugging for RISC-V

2024-05-14 Thread Björn Töpel
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

Re: [PATCH v2 6/8] riscv: Enable memory hotplugging for RISC-V

2024-05-14 Thread Alexandre Ghiti
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

Re: [PATCH v2 4/8] riscv: mm: Add memory hotplugging support

2024-05-14 Thread Alexandre Ghiti
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

Re: [PATCH v2 2/8] riscv: mm: Change attribute from __init to __meminit for page functions

2024-05-14 Thread Björn Töpel
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. >> >>

Re: [PATCH v2 3/8] riscv: mm: Refactor create_linear_mapping_range() for memory hot add

2024-05-14 Thread Alexandre Ghiti
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

Re: [PATCH v2 2/8] riscv: mm: Change attribute from __init to __meminit for page functions

2024-05-14 Thread Alexandre Ghiti
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,

Re: [PATCH v2 4/8] riscv: mm: Add memory hotplugging support

2024-05-14 Thread Björn Töpel
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

Re: [PATCH v2 1/8] riscv: mm: Pre-allocate vmemmap/direct map PGD entries

2024-05-14 Thread Björn Töpel
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

Re: [RFC PATCH v1 1/2] virt: memctl: control guest physical memory properties

2024-05-14 Thread Greg Kroah-Hartman
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, > +

Re: [RFC PATCH v1 1/2] virt: memctl: control guest physical memory properties

2024-05-14 Thread Greg Kroah-Hartman
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,

Re: [PATCH v1 1/1] Input: gpio-keys - expose wakeup keys in sysfs

2024-05-14 Thread Guido Günther
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

Re: [PATCH v2 4/8] riscv: mm: Add memory hotplugging support

2024-05-14 Thread David Hildenbrand
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

Re: [PATCH v2 3/8] riscv: mm: Refactor create_linear_mapping_range() for memory hot add

2024-05-14 Thread David Hildenbrand
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

Re: [PATCH v2 2/8] riscv: mm: Change attribute from __init to __meminit for page functions

2024-05-14 Thread David Hildenbrand
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

Re: [PATCH v2 7/8] virtio-mem: Enable virtio-mem for RISC-V

2024-05-14 Thread David Hildenbrand
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

Re: [PATCH v2 1/8] riscv: mm: Pre-allocate vmemmap/direct map PGD entries

2024-05-14 Thread Alexandre Ghiti
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

Re: [PATCH v3] module: create weak dependecies

2024-05-14 Thread Lucas De Marchi
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

Re: [PATCH] modules: Drop the .export_symbol section from the final modules

2024-05-13 Thread Masahiro Yamada
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. > > >

Re: [PATCH 1/1] x86/vector: Fix vector leak during CPU offline

2024-05-13 Thread Thomas Gleixner
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() >> ... >>

Re: [PATCH v1 1/1] Input: gpio-keys - expose wakeup keys in sysfs

2024-05-13 Thread Dmitry Torokhov
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

Re: [PATCHv5 bpf-next 7/8] selftests/x86: Add return uprobe shadow stack test

2024-05-13 Thread Jiri Olsa
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

Re: [PATCHv5 bpf-next 6/8] x86/shstk: Add return uprobe support

2024-05-13 Thread Jiri Olsa
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

Re: [PATCH RT 0/1] Linux v4.19.312-rt134-rc3

2024-05-13 Thread Daniel Wagner
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

Re: [PATCH 1/1] x86/vector: Fix vector leak during CPU offline

2024-05-13 Thread Dongli Zhang
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

Re: [PATCH 1/3] tracing: Remove dependency of saved_cmdlines_buffer on PID_MAX_DEFAULT

2024-05-13 Thread Michal Koutný
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

Re: [PATCH 2/3] kernel/pid: Remove default pid_max value

2024-05-13 Thread Michal Koutný
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

Re: [PATCHv5 bpf-next 6/8] x86/shstk: Add return uprobe support

2024-05-13 Thread Edgecombe, Rick P
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

Re: [PATCH 1/1] x86/vector: Fix vector leak during CPU offline

2024-05-13 Thread Thomas Gleixner
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

Re: [PATCH v1 1/1] Input: gpio-keys - expose wakeup keys in sysfs

2024-05-13 Thread Geert Uytterhoeven
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

Re: [RFC PATCH v4 0/5] DAMON based tiered memory management for CXL memory

2024-05-13 Thread Honggyu Kim
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

Re: [PATCH v2 6/6] module: add install target for modules.builtin.ranges

2024-05-13 Thread Masahiro Yamada
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 >

Re: [PATCHv5 bpf-next 6/8] x86/shstk: Add return uprobe support

2024-05-13 Thread Google
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

Re: [PATCHv5 bpf-next 7/8] selftests/x86: Add return uprobe shadow stack test

2024-05-13 Thread Google
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

Re: [PATCH RT 0/1] Linux v4.19.312-rt134-rc3

2024-05-13 Thread Sebastian Andrzej Siewior
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

Re: [PATCH v2 6/6] module: add install target for modules.builtin.ranges

2024-05-12 Thread Masahiro Yamada
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

Re: [PATCH v2 5/6] kbuild: generate modules.builtin.ranges when linking the kernel

2024-05-12 Thread Masahiro Yamada
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

Re: [PATCH v2 0/6] Generate address range data for built-in modules

2024-05-12 Thread Masahiro Yamada
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 >

Re: [PATCH] eventfs: Directly return NULL to avoid null point dereferenced

2024-05-12 Thread Hao Ge
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

Re: [PATCH v8 0/5] soc: qcom: add in-kernel pd-mapper implementation

2024-05-12 Thread Steev Klimaszewski
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

Re: [PATCH net-next] virtio_net: Fix error code in __virtnet_get_hw_stats()

2024-05-12 Thread Xuan Zhuo
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

Re: [RFC PATCH v3 1/7] mm/damon/paddr: refactor DAMOS_PAGEOUT with migration_mode

2024-05-12 Thread SeongJae Park
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

Re: [PATCH] eventfs: Directly return NULL to avoid null point dereferenced

2024-05-12 Thread 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 imperative wording for an improved change description?

Re: [PATCH net-next] virtio_net: Fix error code in __virtnet_get_hw_stats()

2024-05-12 Thread Michael S. Tsirkin
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

Re: [PATCH] modules: Drop the .export_symbol section from the final modules

2024-05-11 Thread Luis Chamberlain
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. > > Signed-off-by: Wang Yao Masahiro, commit ddb5cdbafaaa ("kbuild:

Re: [PATCH v7 1/6] soc: qcom: pdr: protect locator_addr with the main mutex

2024-05-11 Thread Dmitry Baryshkov
On Thu, 25 Apr 2024 at 22:30, Chris Lew wrote: > > > On 4/24/2024 2:27 AM, Dmitry Baryshkov wrote: > > If the service locator server is restarted fast enough, the PDR can > > rewrite locator_addr fields concurrently. Protect them by placing > > modification of those fields under the main

Re: [PATCHv5 bpf-next 6/8] x86/shstk: Add return uprobe support

2024-05-11 Thread Jiri Olsa
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 cannot happen without something with privileges taking an action.

Re: [RFC PATCH v3 1/7] mm/damon/paddr: refactor DAMOS_PAGEOUT with migration_mode

2024-05-11 Thread SeongJae Park
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 damon_pa_migrate and it receives an > > extra argument for

Re: [PATCH net-next] virtio_net: Fix error code in __virtnet_get_hw_stats()

2024-05-11 Thread Simon Horman
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

Re: [PATCH v3 2/2] virtiofs: use GFP_NOFS when enqueuing request through kworker

2024-05-10 Thread Hou Tao
Hi, On 5/10/2024 7:19 PM, Miklos Szeredi wrote: > On Fri, 26 Apr 2024 at 16:38, Hou Tao wrote: >> From: Hou Tao >> >> When invoking virtio_fs_enqueue_req() through kworker, both the >> allocation of the sg array and the bounce buffer still use GFP_ATOMIC. >> Considering the size of the sg array

Re: [PATCH] modules: Drop the .export_symbol section from the final modules

2024-05-10 Thread Ainux Wang
Hi, everyone: Could someone help to review this patch? Best regards, Ainux Wang. Ainux Wang 于2024年5月7日周二 13:15写道: > > Hi, everyone: > > Could someone review this patch? > > Best regards, > Ainux Wang. > > 于2024年4月17日周三 13:35写道: > > > > > From: Wang Yao > > > > Commit ddb5cdbafaaa ("kbuild:

Re: [PATCH 2/2] x86/sgx: Resolve EREMOVE page vs EAUG page data race

2024-05-10 Thread Reinette Chatre
ads 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 this race: >>> >>> 1. T1 performs page removal in sgx_encl_remove_pages() and stops right >>

Re: [PATCH 1/2] x86/sgx: Resolve EAUG race where losing thread returns SIGBUS

2024-05-10 Thread Reinette Chatre
Hi Dmitrii, Thank you so much for finding as well as fixing this issue. On 4/30/2024 7:37 AM, Dmitrii Kuvaiskii wrote: > On Mon, Apr 29, 2024 at 04:04:24PM +0300, Jarkko Sakkinen wrote: >> On Mon Apr 29, 2024 at 1:43 PM EEST, Dmitrii Kuvaiskii wrote: >>> Two enclave threads may try to access the

Re: [PATCH 1/1] x86/vector: Fix vector leak during CPU offline

2024-05-10 Thread Dave Hansen
On 5/10/24 12:06, Dongli Zhang wrote: > } else { > + /* > + * This call borrows from the comments and implementation > + * of apic_update_vector(): "If the target CPU is offline > + * then the regular release mechanism via the cleanup > +

Re: [PATCH v22 2/5] ring-buffer: Introducing ring-buffer mapping functions

2024-05-10 Thread Steven Rostedt
On Fri, 10 May 2024 12:03:12 +0100 Vincent Donnefort wrote: > > I'm not particularly happy about us calling vm_insert_pages with NULL > > pointers stored in pages. > > > > Should we instead do > > > > if (WARN_ON_ONCE(s >= nr_subbufs)) { > > err = -EINVAL; > > goto out; > > } > > > >

Re: [PATCH v9 2/5] remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem

2024-05-10 Thread Mathieu Poirier
On Thu, May 09, 2024 at 10:54:51AM -0500, Andrew Davis wrote: > On 5/9/24 10:22 AM, Mathieu Poirier wrote: > > On Wed, 8 May 2024 at 09:36, Andrew Davis wrote: > > > > > > On 5/6/24 3:46 PM, Mathieu Poirier wrote: > > > > Good day, > > > > > > > > I have started reviewing this patchset.

Re: [PATCH v23 2/5] ring-buffer: Introducing ring-buffer mapping functions

2024-05-10 Thread David Hildenbrand
On 10.05.24 16:04, Vincent Donnefort wrote: In preparation for allowing the user-space to map a ring-buffer, add a set of mapping functions: ring_buffer_{map,unmap}() And controls on the ring-buffer: ring_buffer_map_get_reader() /* swap reader and head */ Mapping the ring-buffer also

Re: [PATCH 0/2] Add basic APR sound support for SC7280 SoC

2024-05-10 Thread Rob Herring (Arm)
On Fri, 10 May 2024 14:27:07 +0200, Luca Weiss wrote: > Validated on Fairphone 5 (QCM6490) smartphone by using DisplayPort over > USB-C audio, connected to a TV, with a basic UCM to enable > 'DISPLAY_PORT_RX Audio Mixer MultiMedia1': >

Re: [PATCH v3 2/2] virtiofs: use GFP_NOFS when enqueuing request through kworker

2024-05-10 Thread Miklos Szeredi
On Fri, 26 Apr 2024 at 16:38, Hou Tao wrote: > > From: Hou Tao > > When invoking virtio_fs_enqueue_req() through kworker, both the > allocation of the sg array and the bounce buffer still use GFP_ATOMIC. > Considering the size of the sg array may be greater than PAGE_SIZE, use > GFP_NOFS instead

Re: [PATCH v22 2/5] ring-buffer: Introducing ring-buffer mapping functions

2024-05-10 Thread Vincent Donnefort
[...] > > > + > > > + while (s < nr_subbufs && p < nr_pages) { > > > + struct page *page = virt_to_page(cpu_buffer->subbuf_ids[s]); > > > + int off = 0; > > > + > > > + for (; off < (1 << (subbuf_order)); off++, page++) { > > > + if (p >= nr_pages) > > > +

Re: [PATCH v22 2/5] ring-buffer: Introducing ring-buffer mapping functions

2024-05-10 Thread Vincent Donnefort
On Fri, May 10, 2024 at 11:15:59AM +0200, David Hildenbrand wrote: > On 09.05.24 13:05, Vincent Donnefort wrote: > > On Tue, May 07, 2024 at 10:34:02PM -0400, Steven Rostedt wrote: > > > On Tue, 30 Apr 2024 12:13:51 +0100 > > > Vincent Donnefort wrote: > > > > > > > +#ifdef CONFIG_MMU > > > >

Re: [PATCH v22 2/5] ring-buffer: Introducing ring-buffer mapping functions

2024-05-10 Thread David Hildenbrand
On 08.05.24 04:34, Steven Rostedt wrote: On Tue, 30 Apr 2024 12:13:51 +0100 Vincent Donnefort wrote: +#ifdef CONFIG_MMU +static int __rb_map_vma(struct ring_buffer_per_cpu *cpu_buffer, + struct vm_area_struct *vma) +{ + unsigned long nr_subbufs, nr_pages,

Re: [PATCH v22 2/5] ring-buffer: Introducing ring-buffer mapping functions

2024-05-10 Thread David Hildenbrand
On 09.05.24 13:05, Vincent Donnefort wrote: On Tue, May 07, 2024 at 10:34:02PM -0400, Steven Rostedt wrote: On Tue, 30 Apr 2024 12:13:51 +0100 Vincent Donnefort wrote: +#ifdef CONFIG_MMU +static int __rb_map_vma(struct ring_buffer_per_cpu *cpu_buffer, + struct

Re: [PATCH 1/2] objpool: enable inlining objpool_push() and objpool_pop() operations

2024-05-10 Thread wuqiang.matt
On 2024/5/10 16:20, Vlastimil Babka wrote: On 5/10/24 9:59 AM, wuqiang.matt wrote: On 2024/5/7 21:55, Vlastimil Babka wrote: >> + } while (!try_cmpxchg_acquire(>tail, , tail + 1)); + + /* now the tail position is reserved for the given obj */ +

Re: [PATCH v2] module: create weak dependecies

2024-05-10 Thread Jose Ignacio Tornos Martinez
> I think it's important a note about backward compatibility. If a system > doesn't have a new-enough depmod, it will basically not create the new > weadep file and initrd generators won't be able to use that. Only > downside is not being able to use the new feature, but it should still > work as

Re: [PATCH 1/2] objpool: enable inlining objpool_push() and objpool_pop() operations

2024-05-10 Thread Vlastimil Babka
On 5/10/24 9:59 AM, wuqiang.matt wrote: > On 2024/5/7 21:55, Vlastimil Babka wrote: >> >>> + } while (!try_cmpxchg_acquire(>tail, , tail + 1)); >>> + >>> + /* now the tail position is reserved for the given obj */ >>> + WRITE_ONCE(slot->entries[tail & slot->mask], obj); >>> + /* update

Re: [PATCH 1/2] objpool: enable inlining objpool_push() and objpool_pop() operations

2024-05-10 Thread wuqiang.matt
On 2024/5/7 21:55, Vlastimil Babka wrote: On 4/24/24 11:52 PM, Andrii Nakryiko wrote: objpool_push() and objpool_pop() are very performance-critical functions and can be called very frequently in kretprobe triggering path. As such, it makes sense to allow compiler to inline them completely to

Re: kernel BUG in ptr_stale

2024-05-09 Thread Kent Overstreet
On Thu, May 09, 2024 at 02:26:24PM +0800, 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. This (and several of

Re: [PATCH v9 2/5] remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem

2024-05-09 Thread Andrew Davis
t)msg); I remember discussing this but can't recall the outcome. Still, I don't see why (uintptr_t) is needed here. Was discussed here: https://lkml.org/lkml/2024/3/28/974 Re-quoting my response from last time: Doing that in one step (u32 -> void*) causes a warning when void* is 64b

Re: [PATCHv5 bpf-next 6/8] x86/shstk: Add return uprobe support

2024-05-09 Thread Edgecombe, Rick P
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 cannot happen without something with privileges taking an action. But > > are > > uretprobes ever used for monitoring applications where security

Re: [PATCH v9 2/5] remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem

2024-05-09 Thread Andrew Davis
On 5/9/24 10:22 AM, Mathieu Poirier wrote: On Wed, 8 May 2024 at 09:36, Andrew Davis wrote: On 5/6/24 3:46 PM, Mathieu Poirier wrote: Good day, I have started reviewing this patchset. Comments will be scattered over multiple days and as such, I will explicitly inform you when am done with

Re: [PATCH v9 2/5] remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem

2024-05-09 Thread Mathieu Poirier
sg: 0x%x\n", msg); > >> + > >> +switch (msg) { > >> +case RP_MBOX_CRASH: > >> +/* > >> + * remoteproc detected an exception, but error recovery is not > >> + * supported. So, just log this for now

Re: [PATCH v9 2/5] remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem

2024-05-09 Thread Mathieu Poirier
On Wed, 8 May 2024 at 09:36, Andrew Davis wrote: > > On 5/6/24 3:46 PM, Mathieu Poirier wrote: > > Good day, > > > > I have started reviewing this patchset. Comments will be scattered over > > multiple days and as such, I will explicitly inform you when am done with > > the > > review. > > > >

  1   2   3   4   5   6   7   8   9   10   >