Michael Ellerman writes:
> Aneesh is stepping down from powerpc maintenance.
>
> Signed-off-by: Michael Ellerman
Acked-by: Aneesh Kumar K.V (Arm)
> ---
> MAINTAINERS | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 7c121493f43d..93af33ee8541 100644
>
Michael Ellerman writes:
> Aneesh's IBM address no longer works, switch to his preferred kernel.org
> address.
>
> Signed-off-by: Michael Ellerman
Acked-by: Aneesh Kumar K.V (Arm)
> ---
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS
Joel Savitz writes:
> On 64-bit powerpc, usage of a non-16MB-aligned value for the mem= kernel
> cmdline parameter results in a system hang at boot.
>
> For example, using 'mem=4198400K' will always reproduce this issue.
>
> This patch fixes the problem by aligning any argument to mem= to 16MB
>
On 3/7/24 5:13 PM, Michael Ellerman wrote:
> Hi Mahesh,
>
> Mahesh Salgaonkar writes:
>> nmi_enter()/nmi_exit() touches per cpu variables which can lead to kernel
>> crash when invoked during real mode interrupt handling (e.g. early HMI/MCE
>> interrupt handler) if percpu allocation comes from
Michael Ellerman writes:
> Kunwu Chan writes:
>> Thanks for the reply.
>>
>> On 2024/2/26 18:49, Michael Ellerman wrote:
>>> Kunwu Chan writes:
This part was commented from commit 6d492ecc6489
("powerpc/THP: Add code to handle HPTE faults for hugepages")
in about 11 years
Amit Machhiwal writes:
> Currently, rebooting a pseries nested qemu-kvm guest (L2) results in
> below error as L1 qemu sends PVR value 'arch_compat' == 0 via
> ppc_set_compat ioctl. This triggers a condition failure in
> kvmppc_set_arch_compat() resulting in an EINVAL.
>
> qemu-system-ppc64:
Madhavan Srinivasan writes:
> reg.h is updated with Power11 pvr. pvr_mask value of 0x0F07
> means we are arch v3.1 compliant.
>
If it is called arch v3.1, it will conflict with.
#define PVR_ARCH_31 0x0f06
>This is used by phyp and
> kvm when booting as a pseries guest to detect
Amit Machhiwal writes:
> Currently, rebooting a pseries nested qemu-kvm guest (L2) results in
> below error as L1 qemu sends PVR value 'arch_compat' == 0 via
> ppc_set_compat ioctl. This triggers a condition failure in
> kvmppc_set_arch_compat() resulting in an EINVAL.
>
> qemu-system-ppc64:
David Hildenbrand writes:
>>>
If high bits are used for
something else, then we might produce a garbage PTE on overflow, but that
shouldn't really matter I concluded for folio_pte_batch() purposes, we'd
not
detect "belongs to this folio batch" either way.
>>>
>>>
David Hildenbrand writes:
> On 23.01.24 12:38, Ryan Roberts wrote:
>> On 23/01/2024 11:31, David Hildenbrand wrote:
>
>> If high bits are used for
>> something else, then we might produce a garbage PTE on overflow, but that
>> shouldn't really matter I concluded for
Michael Ellerman writes:
> #ifdef CONFIG_PPC64
> int boot_cpu_hwid = -1;
> @@ -492,12 +493,26 @@ void __init smp_setup_cpu_maps(void)
> avail = !of_property_match_string(dn,
> "enable-method", "spin-table");
>
> -
Michael Ellerman writes:
> +static int assign_threads(unsigned cpu, unsigned int nthreads, bool avail,
>
May be rename 'avail' to 'present'
> + const __be32 *hw_ids)
> +{
> + for (int i = 0; i < nthreads && cpu < nr_cpu_ids; i++) {
> + __be32
Haren Myneni writes:
> VAS allocate, modify and deallocate HCALLs returns
> H_LONG_BUSY_ORDER_1_MSEC or H_LONG_BUSY_ORDER_10_MSEC for busy
> delay and expects OS to reissue HCALL after that delay. But using
> msleep() will often sleep at least 20 msecs even though the
> hypervisor suggests OS
Luming Yu writes:
> Before we have powerpc to use the generic entry infrastructure,
> the call to fire user return notifier is made temporarily in powerpc
> entry code.
>
It is still not clear what will be registered as user return notifier.
Can you summarize that here?
>
> Signed-off-by:
Vaibhav Jain writes:
> Hi Aneesh,
>
> "Aneesh Kumar K.V" writes:
>
>
>>> Yes, Agreed and thats a nice suggestion. However ATM the hypervisor
>>> supporting Nestedv2 doesnt have support for this hcall. In future
>>> once we have support for this hcall for nestedv2 from the hypervisor
>>> we
Vaibhav Jain writes:
> Hi Aneesh,
>
> Thanks for looking into this patch. My responses inline below:
>
> "Aneesh Kumar K.V (IBM)" writes:
>
>> Vaibhav Jain writes:
>>
>>> From: Jordan Niethe
>>>
>>> An L0 must invalidate the L2's RPT during H_GUEST_DELETE if this has not
>>> already been
Nicholas Miehlbradt writes:
> Splits the vmalloc region into four. The first quarter is the new
> vmalloc region, the second is used to store shadow metadata and the
> third is used to store origin metadata. The fourth quarter is unused.
>
Do we support KMSAN for both hash and radix? If hash is
Nicholas Miehlbradt writes:
> Functions which walk the stack read parts of the stack which cannot be
> instrumented by KMSAN e.g. the backchain. Disable KMSAN sanitization of
> these functions to prevent false positives.
>
Is the annotation needed to avoid uninitialized access check when
Srikar Dronamraju writes:
> If there are shared processor LPARs, underlying Hypervisor can have more
> virtual cores to handle than actual physical cores.
>
> Starting with Power 9, a big core (aka SMT8 core) has 2 nearly
> independent thread groups. On a shared processors LPARs, it helps to
>
Gaurav Batra writes:
> When kdump kernel tries to copy dump data over SR-IOV, LPAR panics due to
> NULL pointer execption.
>
> Here is the complete stack
>
> [ 19.944378] Kernel attempted to read user page (0) - exploit attempt?
> (uid: 0)^M
> [ 19.944388] BUG: Kernel NULL pointer
Srikar Dronamraju writes:
> * Srikar Dronamraju [2023-11-09 11:19:28]:
>
> Hi Michael,
>
>> PowerVM systems configured in shared processors mode have some unique
>> challenges. Some device-tree properties will be missing on a shared
>> processor. Hence some sched domains may not make sense for
On 11/22/23 4:05 PM, Sourabh Jain wrote:
> Hello Michael,
>
>
> On 22/11/23 10:47, Michael Ellerman wrote:
>> Aneesh Kumar K V writes:
>> ...
>>> I am not sure whether we need to add all the complexity to enable
>>> supporting different fadump kerne
een set to 'N'
>
> Reported-by: Srikar Dronamraju
> Suggested-by: Aneesh Kumar K V
> Suggested-by: Michael Ellerman
> Signed-off-by: Vishal Chourasia
>
> v1: https://lore.kernel.org/all/20231114082046.6018-1-vish...@linux.ibm.com
> ---
> During the configuration process wit
On 11/17/23 10:03 AM, Sourabh Jain wrote:
> Hi Aneesh,
>
> Thanks for reviewing the patch.
>
> On 15/11/23 10:14, Aneesh Kumar K.V wrote:
>> Sourabh Jain writes:
>>
>>
>>
>>> diff --git a/arch/powerpc/include/asm/fadump-internal.h
>>> b/arch/powerpc/include/asm/fadump-internal.h
>>> index
On 11/15/23 5:23 PM, Vishal Chourasia wrote:
>
> On 15/11/23 1:39 pm, Aneesh Kumar K.V wrote:
>> Vishal Chourasia writes:
>>
>>> This patch modifies the ARCH_HIBERNATION_POSSIBLE option to ensure that it
>>> correctly depends on these PowerPC configurations being enabled. As a
>>> result,
>>>
On 11/14/23 3:16 PM, Srikar Dronamraju wrote:
> * Aneesh Kumar K.V [2023-11-14 12:42:19]:
>
>> No functional change in this patch. A helper is added to find if
>> vcpu is dispatched by hypervisor. Use that instead of opencoding.
>> Also clarify some of the comments.
>>
>> Signed-off-by: Aneesh
On 11/14/23 2:53 PM, Shrikanth Hegde wrote:
>
>
> On 11/14/23 12:42 PM, Aneesh Kumar K.V wrote:
>> No functional change in this patch. A helper is added to find if
>> vcpu is dispatched by hypervisor. Use that instead of opencoding.
>> Also clarify some of the comments.
>>
>> Signed-off-by:
On 11/13/23 5:17 PM, Nicholas Piggin wrote:
> On Mon Nov 13, 2023 at 8:45 PM AEST, Aneesh Kumar K V wrote:
>>>> diff --git a/arch/powerpc/mm/book3s64/hash_utils.c
>>>> b/arch/powerpc/mm/book3s64/hash_utils.c
>>>> index ad2afa08e62e..b2eda22195f0 100
On 11/13/23 3:46 PM, Nicholas Piggin wrote:
> On Thu Nov 2, 2023 at 11:23 PM AEST, Aneesh Kumar K.V wrote:
>> There used to be a dependency on _PAGE_PRIVILEGED with pte_savedwrite.
>> But that got dropped by
>> commit 6a56ccbcf6c6 ("mm/autonuma: use can_change_(pte|pmd)_writable() to
>> replace
On 11/10/23 8:23 PM, Jason Gunthorpe wrote:
> On Fri, Nov 10, 2023 at 08:19:23PM +0530, Aneesh Kumar K.V wrote:
>>
>> Hello,
>>
>> Some architectures can now support EXEC_ONLY mappings and I am wondering
>> what get_user_pages() on those addresses should return.
>
> -EPERM
>
>> Earlier
On 11/6/23 6:53 PM, Christophe Leroy wrote:
>
>
> Le 02/11/2023 à 06:39, Aneesh Kumar K.V a écrit :
>> Christophe Leroy writes:
>>
>>> Introduce PAGE_EXECONLY_X macro which provides exec-only rights.
>>> The _X may be seen as redundant with the EXECONLY but it helps
>>> keep consistancy, all
On 10/18/23 11:25 AM, Christophe Leroy wrote:
>
>
> Le 18/10/2023 à 06:55, Aneesh Kumar K.V a écrit :
>> With commit 9fee28baa601 ("powerpc: implement the new page table range
>> API") we added set_ptes to powerpc architecture but the implementation
>> missed calling the pte filter for all the
On 8/28/23 1:16 PM, Aneesh Kumar K.V wrote:
> With CONFIG_SPARSEMEM disabled the below kernel build error is observed.
>
> arch/powerpc/mm/init_64.c:477:38: error: use of undeclared identifier
> 'SECTION_SIZE_BITS'
>
> CONFIG_MEMORY_HOTPLUG depends on CONFIG_SPARSEMEM and it is more clear
> to
On 8/25/23 12:39 PM, kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
> head: b9bbbf4979073d5536b7650decd37fcb901e6556
> commit: 4d15721177d539d743fcf31d7bb376fb3b81aeb6 [84/128] powerpc/mm: Cleanup
> memory block size probing
> config:
On 8/8/23 12:05 AM, David Hildenbrand wrote:
> On 07.08.23 14:41, David Hildenbrand wrote:
>> On 07.08.23 14:27, Michal Hocko wrote:
>>> On Sat 05-08-23 19:54:23, Aneesh Kumar K V wrote:
>>> [...]
>>>> Do you see a need for firmware-managed memory to be h
On 8/8/23 12:05 AM, David Hildenbrand wrote:
> On 07.08.23 14:41, David Hildenbrand wrote:
>> On 07.08.23 14:27, Michal Hocko wrote:
>>> On Sat 05-08-23 19:54:23, Aneesh Kumar K V wrote:
>>> [...]
>>>> Do you see a need for firmware-managed memory to be h
On 8/3/23 5:00 PM, Michal Hocko wrote:
> On Thu 03-08-23 11:24:08, David Hildenbrand wrote:
> [...]
>>> would be readable only when the block is offline and it would reallocate
>>> vmemmap on the change. Makes sense? Are there any risks? Maybe pfn
>>> walkers?
>>
>> The question is: is it of any
On 8/2/23 9:24 PM, David Hildenbrand wrote:
> On 02.08.23 17:50, Michal Hocko wrote:
>> On Wed 02-08-23 10:15:04, Aneesh Kumar K V wrote:
>>> On 8/1/23 4:20 PM, Michal Hocko wrote:
>>>> On Tue 01-08-23 14:58:29, Aneesh Kumar K V wrote:
>>>>> On 8/1/23
On 8/2/23 4:40 AM, Verma, Vishal L wrote:
> On Tue, 2023-08-01 at 10:11 +0530, Aneesh Kumar K.V wrote:
>> With memmap on memory, some architecture needs more details w.r.t altmap
>> such as base_pfn, end_pfn, etc to unmap vmemmap memory. Instead of
>> computing them again when we remove a memory
On 8/1/23 4:20 PM, Michal Hocko wrote:
> On Tue 01-08-23 14:58:29, Aneesh Kumar K V wrote:
>> On 8/1/23 2:28 PM, Michal Hocko wrote:
>>> On Tue 01-08-23 10:11:16, Aneesh Kumar K.V wrote:
>>>> Allow updating memmap_on_memory mode after the kernel boot. Memory
>>&
On 8/1/23 2:28 PM, Michal Hocko wrote:
> On Tue 01-08-23 10:11:16, Aneesh Kumar K.V wrote:
>> Allow updating memmap_on_memory mode after the kernel boot. Memory
>> hotplug done after the mode update will use the new mmemap_on_memory
>> value.
>
> Well, this is a user space kABI extension and as
On 7/29/23 3:25 AM, Reza Arbab wrote:
> On Fri, Jul 28, 2023 at 04:05:55PM +0530, Aneesh Kumar K.V wrote:
>> --- a/arch/powerpc/mm/init_64.c
>> +++ b/arch/powerpc/mm/init_64.c
> [snip]
>> + /*
>> + * "ibm,coherent-device-memory with linux,usable-memory = 0
>> + * Force 256MiB block
On 7/27/23 2:55 PM, Michal Hocko wrote:
> On Thu 27-07-23 13:32:31, Aneesh Kumar K.V wrote:
>> With memmap on memory, some architecture needs more details w.r.t altmap
>> such as base_pfn, end_pfn, etc to unmap vmemmap memory. Instead of
>> computing them again when we remove a memory block, embed
On 7/27/23 2:53 PM, Michal Hocko wrote:
> On Thu 27-07-23 13:32:29, Aneesh Kumar K.V wrote:
> [...]
>> +if (mode == MEMMAP_ON_MEMORY_FORCE) {
>> +unsigned long memmap_pages =
>> memory_block_memmap_on_memory_pages();
>> +
>> +pr_info_once("Memory hotplug will reserve
On 7/26/23 2:34 PM, David Hildenbrand wrote:
>
/*
@@ -1310,7 +1400,10 @@ int __ref add_memory_resource(int nid, struct
resource *res, mhp_t mhp_flags)
{
struct mhp_params params = { .pgprot = pgprot_mhp(PAGE_KERNEL) };
enum memblock_flags
On 7/26/23 12:59 AM, Andrew Morton wrote:
> On Tue, 25 Jul 2023 00:37:46 +0530 "Aneesh Kumar K.V"
> wrote:
>
>> This patch series implements changes required to support DAX vmemmap
>> optimization for ppc64.
>
> Do we have any measurements to help us understand the magnitude
> of this
On 7/24/23 9:11 PM, David Hildenbrand wrote:
> On 24.07.23 17:16, Aneesh Kumar K V wrote:
>
>>>
>>> /*
>>> * In "forced" memmap_on_memory mode, we always align the vmemmap size up
>>> to cover
>>> * full pageblocks. That way, we
On 7/24/23 8:03 PM, David Hildenbrand wrote:
> On 18.07.23 04:44, Aneesh Kumar K.V wrote:
>> Add a new kconfig option that can be selected if we want to allow
>
> That description seems outdated.
>
Will update
>> pageblock alignment by reserving pages in the vmemmap altmap area.
>> This
On 7/24/23 8:04 PM, David Hildenbrand wrote:
> On 18.07.23 04:44, Aneesh Kumar K.V wrote:
>> Radix vmemmap mapping can map things correctly at the PMD level or PTE
>> level based on different device boundary checks. Hence we skip the
>> restrictions w.r.t vmemmap size to be multiple of PMD_SIZE.
On 7/19/23 10:34 AM, Hugh Dickins wrote:
> On Tue, 18 Jul 2023, Aneesh Kumar K.V wrote:
>> Hugh Dickins writes:
>>
>>> Instead of pte_lockptr(), use the recently added pte_offset_map_nolock()
>>> in assert_pte_locked(). BUG if pte_offset_map_nolock() fails: this is
>>> stricter than the previous
On 7/11/23 10:49 PM, David Hildenbrand wrote:
> On 11.07.23 06:48, Aneesh Kumar K.V wrote:
>> Add a new kconfig option that can be selected if we want to allow
>> pageblock alignment by reserving pages in the vmemmap altmap area.
>> This implies we will be reserving some pages for every
On 7/11/23 4:06 PM, David Hildenbrand wrote:
> On 11.07.23 06:48, Aneesh Kumar K.V wrote:
>> Some architectures would want different restrictions. Hence add an
>> architecture-specific override.
>>
>> Both the PMD_SIZE check and pageblock alignment check are moved there.
>>
>> Signed-off-by:
On 7/11/23 3:53 PM, David Hildenbrand wrote:
>> -bool mhp_supports_memmap_on_memory(unsigned long size)
>> +static bool mhp_supports_memmap_on_memory(unsigned long size)
>> {
>> unsigned long nr_vmemmap_pages = size / PAGE_SIZE;
>> unsigned long vmemmap_size = nr_vmemmap_pages *
On 7/11/23 9:14 PM, David Hildenbrand wrote:
> On 11.07.23 17:40, Aneesh Kumar K V wrote:
>> On 7/11/23 8:56 PM, David Hildenbrand wrote:
>>> On 11.07.23 06:48, Aneesh Kumar K.V wrote:
>>>> Radix vmemmap mapping can map things correctly at the PMD level or PTE
>&g
On 7/11/23 8:56 PM, David Hildenbrand wrote:
> On 11.07.23 06:48, Aneesh Kumar K.V wrote:
>> Radix vmemmap mapping can map things correctly at the PMD level or PTE
>> level based on different device boundary checks. Hence we skip the
>> restrictions w.r.t vmemmap size to be multiple of PMD_SIZE.
On 7/11/23 11:51 AM, Huang, Ying wrote:
> "Aneesh Kumar K.V" writes:
>
>> Add a new kconfig option that can be selected if we want to allow
>> pageblock alignment by reserving pages in the vmemmap altmap area.
>> This implies we will be reserving some pages for every memoryblock
>> This also
On 7/7/23 9:12 PM, David Hildenbrand wrote:
> On 07.07.23 15:30, Aneesh Kumar K V wrote:
>> On 7/7/23 5:47 PM, David Hildenbrand wrote:
>>> On 06.07.23 18:06, Aneesh Kumar K V wrote:
>>>> On 7/6/23 6:29 PM, David Hildenbrand wrote:
>>>>> On 06.07.23 14
On 7/7/23 5:47 PM, David Hildenbrand wrote:
> On 06.07.23 18:06, Aneesh Kumar K V wrote:
>> On 7/6/23 6:29 PM, David Hildenbrand wrote:
>>> On 06.07.23 14:32, Aneesh Kumar K V wrote:
>>>> On 7/6/23 4:44 PM, David Hildenbrand wrote:
>>>>> On 06.07.23 11
On 7/6/23 6:29 PM, David Hildenbrand wrote:
> On 06.07.23 14:32, Aneesh Kumar K V wrote:
>> On 7/6/23 4:44 PM, David Hildenbrand wrote:
>>> On 06.07.23 11:36, Aneesh Kumar K V wrote:
>>>> On 7/6/23 2:48 PM, David Hildenbrand wrote:
>>>>&
On 7/6/23 4:44 PM, David Hildenbrand wrote:
> On 06.07.23 11:36, Aneesh Kumar K V wrote:
>> On 7/6/23 2:48 PM, David Hildenbrand wrote:
>>> On 06.07.23 10:50, Aneesh Kumar K.V wrote:
>>>> With memmap on memory, some architecture needs more details w.r.t altmap
>&
On 7/6/23 2:54 PM, David Hildenbrand wrote:
> On 06.07.23 10:50, Aneesh Kumar K.V wrote:
>> Instead of checking for memmap on memory feature enablement within the
>> functions checking for alignment, use the kernel parameter to control the
>> memory hotplug flags. The generic kernel now enables
On 7/6/23 2:48 PM, David Hildenbrand wrote:
> On 06.07.23 10:50, Aneesh Kumar K.V wrote:
>> With memmap on memory, some architecture needs more details w.r.t altmap
>> such as base_pfn, end_pfn, etc to unmap vmemmap memory.
>
> Can you elaborate why ppc64 needs that and x86-64 + aarch64 don't?
>
On 7/6/23 2:37 PM, David Hildenbrand wrote:
> On 06.07.23 10:50, Aneesh Kumar K.V wrote:
>> Radix vmemmap mapping can map things correctly at the PMD level or PTE
>> level based on different device boundary checks. We also use altmap.reserve
>> feature to align things correctly at pageblock
On 6/28/23 7:03 AM, Ritesh Harjani (IBM) wrote:
> "Aneesh Kumar K.V" writes:
>> +int __meminit vmemmap_check_pmd(pmd_t *pmd, int node,
>> +unsigned long addr, unsigned long next)
>> +{
>> +int large = pmd_large(*pmd);
>> +
>> +if (pmd_large(*pmd))
>
>
On 6/28/23 6:53 AM, Ritesh Harjani (IBM) wrote:
> "Aneesh Kumar K.V" writes:
>>
>> static inline pmd_t radix__pmd_mkdevmap(pmd_t pmd)
>> @@ -292,9 +320,18 @@ static inline pmd_t radix__pmd_mkdevmap(pmd_t pmd)
>> return __pmd(pmd_val(pmd) | (_PAGE_PTE | _PAGE_DEVMAP));
>> }
>>
>>
On 6/28/23 6:39 AM, Ritesh Harjani (IBM) wrote:
> "Aneesh Kumar K.V" writes:
>
>> Arm disabled hugetlb vmemmap optimization [1] because hugetlb vmemmap
>> optimization includes an update of both the permissions (writeable to
>> read-only) and the output address (pfn) of the vmemmap ptes. That is
On 6/21/23 9:38 AM, Michael Ellerman wrote:
> "Aneesh Kumar K.V" writes:
>> This should not be within CONFIG_PPC_64S_HASHS_MMU. We use mmu_vmemmap_psize
>> on radix while mapping the vmemmap area.
>>
>> Signed-off-by: Aneesh Kumar K.V
>> ---
>> arch/powerpc/mm/book3s64/radix_pgtable.c | 2 --
>>
On 9/8/22 10:23 PM, Matthew Wilcox wrote:
> On Thu, Sep 08, 2022 at 12:56:59PM +0530, Aneesh Kumar K.V wrote:
>> +++ b/fs/dax.c
>> @@ -1304,7 +1304,7 @@ EXPORT_SYMBOL_GPL(dax_zero_range);
>> int dax_truncate_page(struct inode *inode, loff_t pos, bool *did_zero,
>> const struct
On 9/7/22 12:37 AM, Yang Shi wrote:
> On Mon, Sep 5, 2022 at 1:56 AM Aneesh Kumar K.V
> wrote:
>>
>> Yang Shi writes:
>>
>>>
>>> On Fri, Sep 2, 2022 at 9:00 AM Peter Xu wrote:
On Thu, Sep 01, 2022 at 04:50:45PM -0700, Yang Shi wrote:
> On Thu, Sep 1, 2022 at 4:26 PM Peter Xu
On 8/9/22 11:21 AM, Christophe Leroy wrote:
> Le 09/08/2022 à 04:44, Russell Currey a écrit :
>> The Hash MMU already supports XOM (i.e. mmap with PROT_EXEC only)
>> through the execute-only pkey. A PROT_EXEC-only mapping will actually
>> map to RX, and then the pkey will be applied on top of it.
On 8/8/22 6:31 PM, Russell Currey wrote:
> The Hash MMU already supports XOM (i.e. mmap with PROT_EXEC only)
> through the execute-only pkey. A PROT_EXEC-only mapping will actually
> map to RX, and then the pkey will be applied on top of it.
>
> Radix doesn't have pkeys, but it does have execute
On 8/8/22 5:28 PM, Russell Currey wrote:
> The Hash MMU already supports XOM (i.e. mmap with PROT_EXEC only)
> through the execute-only pkey. A PROT_ONLY mapping will actually map to
> RX, and then the pkey will be applied on top of it.
>
> Radix doesn't have pkeys, but it does have execute
On 7/4/22 12:43 PM, Christophe Leroy wrote:
>
>
> Le 04/07/2022 à 08:39, Aneesh Kumar K.V a écrit :
>> Instead of high_memory use is_vmalloc_addr to validate that the address is
>> not in the vmalloc range.
>
>
> Do we really need even more extra checks, and a function that is not
> inlined
On 6/29/22 12:00 PM, Kefeng Wang wrote:
> Hi,
>
> On 2022/6/29 13:09, Aneesh Kumar K.V wrote:
>> With commit ffa0b64e3be5 ("powerpc: Fix virt_addr_valid() for 64-bit Book3E
>> & 32-bit")
>> the kernel now validate the addr against high_memory value. This results
>> in the below BUG_ON with dax
On 6/28/22 6:26 PM, Michael Ellerman wrote:
> "Aneesh Kumar K.V" writes:
>> With commit ffa0b64e3be5 ("powerpc: Fix virt_addr_valid() for 64-bit Book3E
>> & 32-bit")
>> the kernel now validate the addr against high_memory value. This results
>> in the below BUG_ON with dax pfns.
>>
>> [
On 3/22/22 10:02 PM, Dan Williams wrote:
On Tue, Mar 22, 2022 at 7:30 AM kajoljain wrote:
On 3/22/22 03:09, Dan Williams wrote:
On Fri, Mar 18, 2022 at 4:42 AM Kajol Jain wrote:
The following build failure occures when CONFIG_PERF_EVENTS is not set
as generic pmu functions are not
On Fri, 2022-02-25 at 12:08 +0530, kajoljain wrote:
>
>
> On 2/25/22 11:25, Nageswara Sastry wrote:
> >
> >
> > On 17/02/22 10:03 pm, Kajol Jain wrote:
> > >
> > >
> > > Changelog
> >
> > Tested these patches with the automated tests at
> > avocado-misc-tests/perf/perf_nmem.py
> > URL:
On 2/11/22 18:58, Mike Rapoport wrote:
Hi Aneesh,
On Fri, Feb 11, 2022 at 05:22:13PM +0530, Aneesh Kumar K V wrote:
On 2/11/22 16:03, Mike Rapoport wrote:
On Fri, Feb 11, 2022 at 12:03:28PM +0530, Aneesh Kumar K.V wrote:
Keep it simple by using a #define and limiting hugepage size to 2M
On 2/11/22 16:03, Mike Rapoport wrote:
On Fri, Feb 11, 2022 at 12:03:28PM +0530, Aneesh Kumar K.V wrote:
Keep it simple by using a #define and limiting hugepage size to 2M.
This keeps the test simpler instead of dynamically finding the page size
and huge page size.
Without this tests are
On 2/11/22 14:00, David Hildenbrand wrote:
On 11.02.22 07:52, Aneesh Kumar K.V wrote:
commit: d9c234005227 ("Do not depend on MAX_ORDER when grouping pages by
mobility")
introduced pageblock_order which will be used to group pages better.
The kernel now groups pages based on the value of
On 2/10/22 20:09, Shuah Khan wrote:
On 2/9/22 9:12 PM, Aneesh Kumar K.V wrote:
Shuah Khan writes:
On 2/9/22 8:43 AM, Aneesh Kumar K.V wrote:
Keep it simple by using a #define and limiting hugepage size to 2M.
This keeps the test simpler instead of dynamically finding the page
size
and
81 matches
Mail list logo
