On Thu, Aug 29, 2024 at 12:15:57AM -0700, Charlie Jenkins wrote:
> Some applications rely on placing data in free bits addresses allocated
> by mmap. Various architectures (eg. x86, arm64, powerpc) restrict the
> address returned by mmap to be less than the 48-bit address space,
> unless the hint a
> On Sep 5, 2024, at 14:41, Qi Zheng wrote:
>
>
>
> On 2024/9/5 14:32, Muchun Song wrote:
>>> On Aug 30, 2024, at 14:54, Qi Zheng wrote:
>>>
>>>
>>>
>>> On 2024/8/29 16:10, Muchun Song wrote:
On 2024/8/22 15:13, Qi Zheng wrote:
> In collapse_pte_mapped_thp(), we may modify the p
When TSA is compiled as module the following error is reported:
"ucc_mux_set_grant_tsa_bkpt" [drivers/soc/fsl/qe/tsa.ko] undefined!
Indeed, the ucc_mux_set_grant_tsa_bkpt symbol is not exported.
Simply export ucc_mux_set_grant_tsa_bkpt.
Reported-by: kernel test robot
Closes:
https://lore.ker
Le 05/09/2024 à 09:22, Herve Codina a écrit :
When TSA is compiled as module the following error is reported:
"ucc_mux_set_grant_tsa_bkpt" [drivers/soc/fsl/qe/tsa.ko] undefined!
Indeed, the ucc_mux_set_grant_tsa_bkpt symbol is not exported.
Simply export ucc_mux_set_grant_tsa_bkpt.
Repor
Hello Yicong,
Wondering if we can avoid this 2nd loop. Greg express the worries of looping
twice on large scale
system in v1. Maybe we could use the hetero_id and get the necessary
information in one loop, I need
further think.
I found this comments (not sure this is what you are refering to
Hello Baoquan,
On 05/09/24 08:53, Baoquan He wrote:
On 09/04/24 at 02:55pm, Sourabh Jain wrote:
Hello Baoquan,
On 30/08/24 16:47, Baoquan He wrote:
On 08/20/24 at 12:10pm, Sourabh Jain wrote:
Hello Baoquan,
..snip...
2. A patch to return early from the `crash_handle_hotplug_event()` f
On 2024/9/4 16:40, Qi Zheng wrote:
In copy_pte_range(), we may modify the src_pte entry after holding the
src_ptl, so convert it to using pte_offset_map_rw_nolock(). Since we may
free the PTE page in retract_page_tables() without holding the read lock
of mmap_lock, so we still need to get pmdv
* Colton Lewis wrote:
> Break the assignment logic for misc flags into their own respective
> functions to reduce the complexity of the nested logic.
>
> Signed-off-by: Colton Lewis
> ---
> arch/x86/events/core.c| 31 +++
> arch/x86/include/asm/perf_ev
On Thu, Sep 5, 2024, at 07:31, Christophe Leroy wrote:
> Le 05/09/2024 à 09:22, Herve Codina a écrit :
>> When TSA is compiled as module the following error is reported:
>>"ucc_mux_set_grant_tsa_bkpt" [drivers/soc/fsl/qe/tsa.ko] undefined!
>>
>> Indeed, the ucc_mux_set_grant_tsa_bkpt symbol is
Commit 08d08e2e9f0a ("tpm: ibmvtpm: Call tpm2_sessions_init() to
initialize session support") adds call to tpm2_sessions_init() in ibmvtpm,
which could be built as a module. However, tpm2_sessions_init() wasn't
exported, causing libmvtpm to fail to build as a module:
ERROR: modpost: "tpm2_sessions
On 2024/9/4 16:40, Qi Zheng wrote:
In move_ptes(), we may modify the new_pte after acquiring the new_ptl, so
convert it to using pte_offset_map_rw_nolock(). Since we may free the PTE
page in retract_page_tables() without holding the read lock of mmap_lock,
so we still need to do a pmd_same() c
* Colton Lewis wrote:
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -6915,6 +6915,16 @@ void perf_unregister_guest_info_callbacks(struct
> perf_guest_info_callbacks *cbs)
> EXPORT_SYMBOL_GPL(perf_unregister_guest_info_callbacks);
> #endif
>
> +unsigned long perf_misc_flags
On Wed, Sep 04, 2024 at 08:41:29PM +, Colton Lewis wrote:
> perf_instruction_pointer() and perf_misc_flags() aren't used anywhere
> in this particular perf implementation. Drop them.
I think it'd be better to say that arch/arm's implementation of these is
equivalent to the generic versions in
On Wed, Sep 04, 2024 at 11:33:43PM +, Yosry Ahmed wrote:
> The z3fold compressed pages allocator is rarely used, most users use
> zsmalloc. The only disadvantage of zsmalloc in comparison is the
> dependency on MMU, and zbud is a more common option for !MMU as it was
> the default zswap allocat
On Thu, Sep 5, 2024 at 1:33 AM Yosry Ahmed wrote:
>
> The z3fold compressed pages allocator is rarely used, most users use
> zsmalloc. The only disadvantage of zsmalloc in comparison is the
> dependency on MMU, and zbud is a more common option for !MMU as it was
> the default zswap allocator for a
On Wed, Sep 04, 2024 at 05:17:58PM +0100, Will Deacon wrote:
> On Wed, Sep 04, 2024 at 01:55:03PM +0100, Joey Gouly wrote:
> > On Wed, Sep 04, 2024 at 12:43:02PM +0100, Will Deacon wrote:
> > > Right, there's quite a lot I need to do:
> > >
> > > - Uncorrupt your patches
> > > - Fix the conflict i
On 2024/9/5 16:57, Muchun Song wrote:
On 2024/9/4 16:40, Qi Zheng wrote:
In copy_pte_range(), we may modify the src_pte entry after holding the
src_ptl, so convert it to using pte_offset_map_rw_nolock(). Since we may
free the PTE page in retract_page_tables() without holding the read lock
o
On Wed, Sep 04, 2024 at 08:41:33PM +, Colton Lewis wrote:
> Previously any PMU overflow interrupt that fired while a VCPU was
> loaded was recorded as a guest event whether it truly was or not. This
> resulted in nonsense perf recordings that did not honor
> perf_event_attr.exclude_guest and re
On 2024/9/5 17:25, Muchun Song wrote:
On 2024/9/4 16:40, Qi Zheng wrote:
In move_ptes(), we may modify the new_pte after acquiring the new_ptl, so
convert it to using pte_offset_map_rw_nolock(). Since we may free the PTE
page in retract_page_tables() without holding the read lock of mmap_lo
On 2024/9/5 16:34, Pierre Gondois wrote:
> Hello Yicong,
>
Wondering if we can avoid this 2nd loop. Greg express the worries of
looping twice on large scale
system in v1. Maybe we could use the hetero_id and get the necessary
information in one loop, I need
further think
On 2024/9/4 16:40, Qi Zheng wrote:
In the caller of map_pte(), we may modify the pvmw->pte after acquiring
the pvmw->ptl, so convert it to using pte_offset_map_rw_nolock(). At
this time, the pte_same() check is not performed after the pvmw->ptl held,
so we should get pmdval and do pmd_same() c
"Jason A. Donenfeld" writes:
> Hi Christophe, Michael,
>
> On Mon, Sep 02, 2024 at 09:17:17PM +0200, Christophe Leroy wrote:
>> This series wires up getrandom() vDSO implementation on powerpc.
>>
>> Tested on PPC32 on real hardware.
>> Tested on PPC64 (both BE and LE) on QEMU:
>>
>> Performance
> On Sep 4, 2024, at 16:40, Qi Zheng wrote:
>
> In move_pages_pte(), we may modify the dst_pte and src_pte after acquiring
> the ptl, so convert it to using pte_offset_map_rw_nolock(). But since we
> already do the pte_same() check, there is no need to get pmdval to do
> pmd_same() check, just
> On Sep 4, 2024, at 16:40, Qi Zheng wrote:
>
> In walk_pte_range(), we may modify the pte entry after holding the ptl, so
> convert it to using pte_offset_map_rw_nolock(). At this time, the
> pte_same() check is not performed after the ptl held, so we should get
> pmdval and do pmd_same() che
Anna-Maria Behnsen writes:
> When commit 38f7b7067dae ("powerpc/rtas: rtas_busy_delay() improvements")
> was introduced, documentation about proper usage of sleep realted functions
> was outdated.
>
...
> Use fsleep() directly instead of using an own heuristic for the best
> sleeping mechanism to
> On Sep 4, 2024, at 16:40, Qi Zheng wrote:
>
> Now no users are using the pte_offset_map_nolock(), remove it.
>
> Signed-off-by: Qi Zheng
Reviewed-by: Muchun Song
Thanks.
On Thu, Sep 05, 2024 at 10:18:40PM +1000, Michael Ellerman wrote:
> There is an existing comment in the a/p/vdso/Makefile about the
> fixed-r30 thing, tldr is it's a workaround to avoid breaking old
> versions of Go.
Thanks. Indeed, following Christophe's links yesterday, I tumbled down
that rabbi
Narayana Murty N writes:
> VFIO_EEH_PE_INJECT_ERR ioctl is currently failing on pseries
> due to missing implementation of err_inject eeh_ops for pseries.
> This patch implements pseries_eeh_err_inject in eeh_ops/pseries
> eeh_ops. Implements support for injecting MMIO load/store error
> for testi
On Thu Sep 5, 2024 at 11:52 AM EEST, Kexy Biscuit wrote:
> Commit 08d08e2e9f0a ("tpm: ibmvtpm: Call tpm2_sessions_init() to
> initialize session support") adds call to tpm2_sessions_init() in ibmvtpm,
> which could be built as a module. However, tpm2_sessions_init() wasn't
> exported, causing libmv
> +/*
> + * The macro sets two stack frames, one for the caller and one for the callee
> + * because there are no requirement for the caller to set a stack frame when
> + * calling VDSO so it may have omitted to set one, especially on PPC64
> + */
> +
> +.macro cvdso_call funct
> + .cfi_startproc
On Thu, Sep 05, 2024 at 06:13:29PM +0200, Jason A. Donenfeld wrote:
> > +/*
> > + * The macro sets two stack frames, one for the caller and one for the
> > callee
> > + * because there are no requirement for the caller to set a stack frame
> > when
> > + * calling VDSO so it may have omitted to s
Le 05/09/2024 à 18:13, Jason A. Donenfeld a écrit :
+/*
+ * The macro sets two stack frames, one for the caller and one for the callee
+ * because there are no requirement for the caller to set a stack frame when
+ * calling VDSO so it may have omitted to set one, especially on PPC64
+ */
+
+.
On Thu, Sep 05, 2024 at 06:55:27PM +0200, Christophe Leroy wrote:
>
>
> Le 05/09/2024 à 18:13, Jason A. Donenfeld a écrit :
> >> +/*
> >> + * The macro sets two stack frames, one for the caller and one for the
> >> callee
> >> + * because there are no requirement for the caller to set a stack fr
On Thu, Sep 05, 2024 at 07:03:34PM +0200, Jason A. Donenfeld wrote:
> On Thu, Sep 05, 2024 at 06:55:27PM +0200, Christophe Leroy wrote:
> >
> >
> > Le 05/09/2024 à 18:13, Jason A. Donenfeld a écrit :
> > >> +/*
> > >> + * The macro sets two stack frames, one for the caller and one for the
> > >>
On Thu, Sep 05, 2024 at 09:47:47AM +0300, Kirill A. Shutemov wrote:
> On Thu, Aug 29, 2024 at 12:15:57AM -0700, Charlie Jenkins wrote:
> > Some applications rely on placing data in free bits addresses allocated
> > by mmap. Various architectures (eg. x86, arm64, powerpc) restrict the
> > address re
On Thu, Sep 05, 2024 at 06:13:29PM +0200, Jason A. Donenfeld wrote:
> > +/*
> > + * The macro sets two stack frames, one for the caller and one for the
> > callee
> > + * because there are no requirement for the caller to set a stack frame
> > when
> > + * calling VDSO so it may have omitted to s
Some applications rely on placing data in free bits addresses allocated
by mmap. Various architectures (eg. x86, arm64, powerpc) restrict the
address returned by mmap to be less than the 48-bit address space,
unless the hint address uses more than 47 bits (the 48th bit is reserved
for the kernel ad
Create a personality flag ADDR_LIMIT_47BIT to support applications
that wish to transition from running in environments that support at
most 47-bit VAs to environments that support larger VAs. This
personality can be set to cause all allocations to be below the 47-bit
boundary. Using MAP_FIXED with
Add a selftest for the ADDR_LIMIT_47BIT personality flag that mmaps
until it runs out of space and ensures no addresses are allocated above
47 bits.
Signed-off-by: Charlie Jenkins
---
tools/testing/selftests/mm/.gitignore | 1 +
tools/testing/selftests/mm/Makefile|
On Thu, 2024-09-05 at 18:55 +0200, Christophe Leroy wrote:
> > Normal single thread
> > vdso: 2500 times in 12.494133131 seconds
> > libc: 2500 times in 69.594625188 seconds
> > syscall: 2500 times in 67.349243972 seconds
> > Time namespace single thread
> > vdso: 250
On Thu, Sep 05, 2024 at 10:41:40PM +0200, Jason A. Donenfeld wrote:
> On Thu, Sep 05, 2024 at 06:13:29PM +0200, Jason A. Donenfeld wrote:
> > > +/*
> > > + * The macro sets two stack frames, one for the caller and one for the
> > > callee
> > > + * because there are no requirement for the caller t
On Fri, Sep 06, 2024 at 04:48:28AM +0200, Jason A. Donenfeld wrote:
> On Thu, Sep 05, 2024 at 10:41:40PM +0200, Jason A. Donenfeld wrote:
> > On Thu, Sep 05, 2024 at 06:13:29PM +0200, Jason A. Donenfeld wrote:
> > > > +/*
> > > > + * The macro sets two stack frames, one for the caller and one for t
On 2024/9/5 7:33, Yosry Ahmed wrote:
> The z3fold compressed pages allocator is rarely used, most users use
> zsmalloc. The only disadvantage of zsmalloc in comparison is the
> dependency on MMU, and zbud is a more common option for !MMU as it was
> the default zswap allocator for a long time.
>
>
Hi Jason,
Le 06/09/2024 à 05:24, Jason A. Donenfeld a écrit :
On Fri, Sep 06, 2024 at 04:48:28AM +0200, Jason A. Donenfeld wrote:
On Thu, Sep 05, 2024 at 10:41:40PM +0200, Jason A. Donenfeld wrote:
On Thu, Sep 05, 2024 at 06:13:29PM +0200, Jason A. Donenfeld wrote:
+/*
+ * The macro sets two
On Fri, Sep 6, 2024 at 5:16 AM Charlie Jenkins wrote:
>
> Some applications rely on placing data in free bits addresses allocated
> by mmap. Various architectures (eg. x86, arm64, powerpc) restrict the
> address returned by mmap to be less than the 48-bit address space,
> unless the hint address u
Christoph Hellwig writes:
>> diff --git a/drivers/dax/device.c b/drivers/dax/device.c
>> index eb61598..b7a31ae 100644
>> --- a/drivers/dax/device.c
>> +++ b/drivers/dax/device.c
>> @@ -126,11 +126,11 @@ static vm_fault_t __dev_dax_pte_fault(struct dev_dax
>> *dev_dax,
>> return V
Hi Charlie,
On Thu, 2024-09-05 at 14:15 -0700, Charlie Jenkins wrote:
> Some applications rely on placing data in free bits addresses allocated
> by mmap. Various architectures (eg. x86, arm64, powerpc) restrict the
> address returned by mmap to be less than the 48-bit address space,
> unless the
Jan Kara writes:
> On Thu 27-06-24 10:54:21, Alistair Popple wrote:
>> Currently to map a DAX page the DAX driver calls vmf_insert_pfn. This
>> creates a special devmap PTE entry for the pfn but does not take a
>> reference on the underlying struct page for the mapping. This is
>> because DAX p
Charlie Jenkins writes:
> Create a personality flag ADDR_LIMIT_47BIT to support applications
> that wish to transition from running in environments that support at
> most 47-bit VAs to environments that support larger VAs. This
> personality can be set to cause all allocations to be below the 47-b
49 matches
Mail list logo
