On 1/25/24 22:12, Alexandru Elisei wrote:
> A page can end up mapped in a MTE enabled VMA without the corresponding tag
> storage block reserved. Tag accesses made by ptrace in this case can lead
> to the wrong tags being read or memory corruption for the process that is
> using the tag storage
On 1/25/24 22:12, Alexandru Elisei wrote:
> copy_user_highpage() will do memory allocation if there are saved tags for
> the destination page, and the page is missing tag storage.
>
> After commit a349d72fd9ef ("mm/pgtable: add rcu_read_lock() and
> rcu_read_unlock()s"), collapse_huge_page()
On 1/25/24 22:12, Alexandru Elisei wrote:
> Introduce a mechanism that allows an architecture to trigger a page fault,
> and add the infrastructure to handle that fault accordingly. To use make> use
> of this, an arch is expected to mark the table entry as PAGE_NONE (which
> will cause a fault
On 1/25/24 22:12, Alexandru Elisei wrote:
> arm64 uses arch_swap_restore() to restore saved tags before the page is
> swapped in and it's called in atomic context (with the ptl lock held).
>
> Introduce arch_swap_prepare_to_restore() that will allow an architecture to
> perform extra work
l()---> cma_init_reserved_areas()---> cma_activate_area() chain
happens. Else cma_remove_mem() will miss out to clear cma->count and given
area will proceed to get activated like always.
>
> Ok Tue, Jan 30, 2024 at 11:20:56AM +0530, Anshuman Khandual wrote:
On 1/30/24 17:04, Alexandru Elisei wrote:
> Hi,
>
> On Tue, Jan 30, 2024 at 03:25:20PM +0530, Anshuman Khandual wrote:
>>
>> On 1/25/24 22:12, Alexandru Elisei wrote:
>>> arm64 uses VM_HIGH_ARCH_0 and VM_HIGH_ARCH_1 for enabling MTE for a VMA.
>>> W
On 1/30/24 17:05, Alexandru Elisei wrote:
> Hi,
>
> On Tue, Jan 30, 2024 at 10:50:00AM +0530, Anshuman Khandual wrote:
>>
>> On 1/25/24 22:12, Alexandru Elisei wrote:
>>> Today, cma_alloc() is used to allocate a contiguous memory region. The
>>> function
On 1/29/24 17:23, Alexandru Elisei wrote:
> Hi,
>
> On Mon, Jan 29, 2024 at 03:01:24PM +0530, Anshuman Khandual wrote:
>>
>> On 1/25/24 22:12, Alexandru Elisei wrote:
>>> Similar to the two events that relate to CMA allocations, add the
>>> CMA_RELE
On 1/30/24 17:28, Alexandru Elisei wrote:
> Hi,
>
> On Tue, Jan 30, 2024 at 10:22:11AM +0530, Anshuman Khandual wrote:
>>
>> On 1/29/24 17:21, Alexandru Elisei wrote:
>>> Hi,
>>>
>>> On Mon, Jan 29, 2024 at 02:54:20PM +0530, Anshuman Khandual wro
On 1/30/24 17:27, Alexandru Elisei wrote:
> Hi,
>
> On Tue, Jan 30, 2024 at 10:04:02AM +0530, Anshuman Khandual wrote:
>>
>>
>> On 1/29/24 17:16, Alexandru Elisei wrote:
>>> Hi,
>>>
>>> On Mon, Jan 29, 2024 at 02:31:23PM +0530, An
On 1/25/24 22:12, Alexandru Elisei wrote:
> arm64 uses VM_HIGH_ARCH_0 and VM_HIGH_ARCH_1 for enabling MTE for a VMA.
> When VM_HIGH_ARCH_0, which arm64 renames to VM_MTE, is set for a VMA, and
> the gfp flag __GFP_ZERO is present, the __GFP_ZEROTAGS gfp flag also gets
> set in
On 1/25/24 22:12, Alexandru Elisei wrote:
> If the pages to be allocated are free, take them directly off the buddy
> allocator, instead of going through alloc_contig_range() and avoiding
> costly calls to lru_cache_disable().
>
> Only allocations of the same size as the CMA region order are
On 1/25/24 22:12, Alexandru Elisei wrote:
> Memory is added to CMA with cma_declare_contiguous_nid() and
> cma_init_reserved_mem(). This memory is then put on the MIGRATE_CMA list in
> cma_init_reserved_areas(), where the page allocator can make use of it.
cma_declare_contiguous_nid() reserves
On 1/25/24 22:12, Alexandru Elisei wrote:
> Today, cma_alloc() is used to allocate a contiguous memory region. The
> function allows the caller to specify the number of pages to allocate, but
> not the starting address. cma_alloc() will walk over the entire CMA region
> trying to allocate the
On 1/29/24 17:21, Alexandru Elisei wrote:
> Hi,
>
> On Mon, Jan 29, 2024 at 02:54:20PM +0530, Anshuman Khandual wrote:
>>
>>
>> On 1/25/24 22:12, Alexandru Elisei wrote:
>>> The CMA_ALLOC_SUCCESS, respectively CMA_ALLOC_FAIL, are increased by one
>
On 1/29/24 17:16, Alexandru Elisei wrote:
> Hi,
>
> On Mon, Jan 29, 2024 at 02:31:23PM +0530, Anshuman Khandual wrote:
>>
>>
>> On 1/25/24 22:12, Alexandru Elisei wrote:
>>> The patch f945116e4e19 ("mm: page_alloc: remove stale CMA guard code")
&
On 1/29/24 17:11, Alexandru Elisei wrote:
> Hi,
>
> On Mon, Jan 29, 2024 at 11:18:59AM +0530, Anshuman Khandual wrote:
>> On 1/25/24 22:12, Alexandru Elisei wrote:
>>> Extend the usefulness of arch_alloc_page() by adding the gfp_flags
>>> parameter.
>&g
On 1/25/24 22:12, Alexandru Elisei wrote:
> Similar to the two events that relate to CMA allocations, add the
> CMA_RELEASE_SUCCESS and CMA_RELEASE_FAIL events that count when CMA pages
> are freed.
How is this is going to be beneficial towards analyzing CMA alloc/release
behaviour -
On 1/25/24 22:12, Alexandru Elisei wrote:
> The CMA_ALLOC_SUCCESS, respectively CMA_ALLOC_FAIL, are increased by one
> after each cma_alloc() function call. This is done even though cma_alloc()
> can allocate an arbitrary number of CMA pages. When looking at
> /proc/vmstat, the number of
e added
here in the commit message to demonstrate the problem better.
>
> Signed-off-by: Alexandru Elisei
> ---
Regardless, LGTM.
Reviewed-by: Anshuman Khandual
>
> Changes since rfc v2:
>
> * New patch. This is a fix, and can be merged independently of the other
> patches.
Ri
On 1/25/24 22:12, Alexandru Elisei wrote:
> The patch f945116e4e19 ("mm: page_alloc: remove stale CMA guard code")
> removed the CMA filter when allocating from the MIGRATE_MOVABLE pcp list
> because CMA is always allowed when __GFP_MOVABLE is set.
>
> With the introduction of the
On 1/25/24 22:12, Alexandru Elisei wrote:
> As an architecture might have specific requirements around the allocation
> of CMA pages, add an arch hook that can disable allocations from
> MIGRATE_CMA, if the allocation was otherwise allowed.
>
> This will be used by arm64, which will put tag
On 1/25/24 22:12, Alexandru Elisei wrote:
> The arm64 MTE code uses the PG_arch_2 page flag, which it renames to
> PG_mte_tagged, to track if a page has been mapped with tagging enabled.
> That flag is cleared by free_pages_prepare() by doing:
>
> page->flags &=
On 1/25/24 22:12, Alexandru Elisei wrote:
> Extend the usefulness of arch_alloc_page() by adding the gfp_flags
> parameter.
Although the change here is harmless in itself, it will definitely benefit
from some additional context explaining the rationale, taking into account
why-how
On 4/12/21 2:17 PM, David Hildenbrand wrote:
> On 12.04.21 10:06, Anshuman Khandual wrote:
>> + linuxppc-...@lists.ozlabs.org
>> + linux-i...@vger.kernel.org
>>
>> On 4/12/21 9:18 AM, Anshuman Khandual wrote:
>>> pageblock_order must always be less tha
On 4/9/21 9:35 AM, Anshuman Khandual wrote:
>
> On 4/6/21 10:18 AM, Shixin Liu wrote:
>> v1->v2:
>> Modified the commit message.
>
> Please avoid change log in the commit message, it should be after '---'
> below the SOB statement.
>
>>
>>
ew Morton
Cc: linux-a...@vger.kernel.org
Cc: linux...@kvack.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Anshuman Khandual
---
This applies on v5.12-rc7 and has been boot tested on arm64 platform.
But has been cross compiled on multiple other platforms.
Changes in V2:
- Dropped ARCH_HAS_FIRST_USER_ADDRES
On 4/14/21 11:40 AM, Christophe Leroy wrote:
>
>
> Le 14/04/2021 à 07:59, Anshuman Khandual a écrit :
>>
>>
>> On 4/14/21 10:52 AM, Christophe Leroy wrote:
>>>
>>>
>>> Le 14/04/2021 à 04:54, Anshuman Khandual a écrit :
>>>> Cur
On 4/14/21 10:52 AM, Christophe Leroy wrote:
>
>
> Le 14/04/2021 à 04:54, Anshuman Khandual a écrit :
>> Currently most platforms define FIRST_USER_ADDRESS as 0UL duplicating the
>> same code all over. Instead define a new option ARCH_HAS_FIRST_USER_ADDRESS
>> for
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Anshuman Khandual
---
arch/alpha/include/asm/pgtable.h | 1 -
arch/arc/include/asm/pgtable.h | 6 --
arch/arm/Kconfig | 1 +
arch/arm64/include/asm/pgtable.h | 2 --
arch/csky
On 4/12/21 5:29 PM, Oscar Salvador wrote:
> On Thu, Apr 01, 2021 at 12:14:06PM +0530, Anshuman Khandual wrote:
>> ARCH_ENABLE_[HUGEPAGE|THP]_MIGRATION configs have duplicate definitions on
>> platforms that subscribe them. Drop these reduntant definitions and instead
>
+ linuxppc-...@lists.ozlabs.org
+ linux-i...@vger.kernel.org
On 4/12/21 9:18 AM, Anshuman Khandual wrote:
> pageblock_order must always be less than MAX_ORDER, otherwise it might lead
> to an warning during boot. A similar problem got fixed on arm64 platform
> with the commit 79cc2ed5a71
PAGE_ORDER
gets assigned as pageblock_order. This will help detect the problem earlier
on platforms where HUGETLB_PAGE_SIZE_VARIABLE is enabled.
Cc: David Hildenbrand
Cc: Andrew Morton
Cc: linux...@kvack.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Anshuman Khandual
---
Changes in V2:
On 4/9/21 6:52 AM, Wei Yongjun wrote:
> In case of error, the function devm_kasprintf() returns NULL
> pointer not ERR_PTR(). The IS_ERR() test in the return value
> check should be replaced with NULL test.
Right.
>
> Fixes: 3fbf7f011f24 ("coresight: sink: Add TRBE driver")
Again, dont
On 4/9/21 7:02 AM, Wei Yongjun wrote:
> The sparse tool complains as follows:
>
> drivers/hwtracing/coresight/coresight-core.c:26:1: warning:
> symbol '__pcpu_scope_csdev_sink' was not declared. Should it be static?
>
> This symbol is not used outside of coresight-core.c, so this
> commit
On 4/9/21 1:54 PM, David Hildenbrand wrote:
> On 09.04.21 07:55, Anshuman Khandual wrote:
>> pageblock_order must always be less than MAX_ORDER, otherwise it might lead
>> to an warning during boot. A similar problem got fixed on arm64 platform
>> with the commit 79cc2ed5
PAGE_ORDER
gets assigned as pageblock_order. This will help detect the problem earlier
on platforms where HUGETLB_PAGE_SIZE_VARIABLE is enabled.
Cc: Andrew Morton
Cc: linux...@kvack.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Anshuman Khandual
---
mm/page_alloc.c | 11 +--
1 file
WRITE_ONCE(*pudp, __pud(0));
> + WARN_ON(!pud_set_huge(pudp, __pfn_to_phys(pfn), prot));
> + WARN_ON(!pud_clear_huge(pudp));
> + pud = READ_ONCE(*pudp);
> + WARN_ON(!pud_none(pud));
> }
> -static void __init pmd_savedwrite_tests(unsigned long pfn, pgprot_t prot) { }
&
SPARENT_HUGEPAGE */
> static void __init pmd_soft_dirty_tests(unsigned long pfn, pgprot_t prot) { }
> static void __init pmd_swap_soft_dirty_tests(unsigned long pfn, pgprot_t
> prot)
> {
> }
> -#endif /* CONFIG_ARCH_HAS_PTE_DEVMAP */
> +#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
>
> static void __init pte_swap_tests(unsigned long pfn, pgprot_t prot)
> {
>
With changes to the commit message as suggested earlier.
Reviewed-by: Anshuman Khandual
Adding James here.
+ James Morse
On 4/7/21 10:56 PM, Mike Rapoport wrote:
> From: Mike Rapoport
>
> Hi,
>
> These patches aim to remove CONFIG_HOLES_IN_ZONE and essentially hardwire
> pfn_valid_within() to 1.
That would be really great for arm64 platform as it will save CPU cycles on
many
On 4/7/21 10:56 PM, Mike Rapoport wrote:
> From: Mike Rapoport
>
> The struct pages representing a reserved memory region are initialized
> using reserve_bootmem_range() function. This function is called for each
> reserved region just before the memory is freed from memblock to the buddy
>
On 4/7/21 10:56 PM, Mike Rapoport wrote:
> From: Mike Rapoport
>
> The intended semantics of pfn_valid() is to verify whether there is a
> struct page for the pfn in question and nothing else.
Should there be a comment affirming this semantics interpretation, above the
generic pfn_valid() in
On 4/7/21 10:56 PM, Mike Rapoport wrote:
> From: Mike Rapoport
>
> The arm64's version of pfn_valid() differs from the generic because of two
> reasons:
>
> * Parts of the memory map are freed during boot. This makes it necessary to
> verify that there is actual physical memory that
On 4/1/21 7:53 AM, Shixin Liu wrote:
> The call to pfn_pmd() here is redundant.
>
> Signed-off-by: Shixin Liu
> ---
> mm/debug_vm_pgtable.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/mm/debug_vm_pgtable.c b/mm/debug_vm_pgtable.c
> index c379bbe42c2a..9f4c4a114229 100644
> ---
On 4/1/21 7:53 AM, Shixin Liu wrote:
> The branch condition should be CONFIG_TRANSPARENT_HUGEPAGE instead of
> CONFIG_ARCH_HAS_PTE_DEVMAP.
>
> Signed-off-by: Shixin Liu
> ---
> mm/debug_vm_pgtable.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git
On 4/1/21 7:53 AM, Shixin Liu wrote:
> The functions {pmd/pud}_set_huge and {pmd/pud}_clear_huge is not depend on
> THP.
s/is not depend/are not dependent/
> But now if we want to test these functions, we have to enable THP. So move
> {pmd/pud}_huge_tests out of CONFIG_TRANSPARENT_HUGEPAGE.
-...@lists.ozlabs.org
Cc: linux-xte...@linux-xtensa.org
Cc: linux...@kvack.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Catalin Marinas (arm64)
Reviewed-by: Max Filippov
Signed-off-by: Anshuman Khandual
---
This patch applies on v5.12-rc5 and has been tested on arm64 platform.
But it has been
: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Andrew Morton
Cc: x...@kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux...@kvack.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Catalin Marinas (arm64)
Signed-off-by: Anshuma
: linuxppc-...@lists.ozlabs.org
Cc: linux-s...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: linux...@kvack.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Catalin Marinas (arm64)
Acked-by: Heiko Carstens (s390)
Signed-off-by: Anshuman Khandual
---
arch/arm64/Kconfig | 8 ++--
arch/ia64/Kconf
Changes in V2:
- Rebased on 5.12-rc5
- Added tags from previous version
Changes in V1:
https://lore.kernel.org/linux-arm-kernel/1615278790-18053-1-git-send-email-anshuman.khand...@arm.com/
Anshuman Khandual (6):
mm: Generalize ARCH_HAS_CACHE_LINE_SIZE
mm: Generalize SYS_SUPPORTS_HUGETLBFS (rename
On 3/8/21 2:25 PM, Mike Rapoport wrote:
> Hi Anshuman,
>
> On Mon, Mar 08, 2021 at 08:57:53AM +0530, Anshuman Khandual wrote:
>> Platforms like arm and arm64 have redefined pfn_valid() because their early
>> memory sections might have contained memmap holes caused by mem
On 3/8/21 2:07 PM, David Hildenbrand wrote:
> On 08.03.21 04:27, Anshuman Khandual wrote:
>> Platforms like arm and arm64 have redefined pfn_valid() because their early
>> memory sections might have contained memmap holes caused by memblock areas
>> tagged with MEMBLOC
On 3/1/21 10:02 AM, Anshuman Khandual wrote:
> early_memtest() does not get called from all architectures. Hence enabling
> CONFIG_MEMTEST and providing a valid memtest=[1..N] kernel command line
> option might not trigger the memory pattern tests as would be expected in
> normal c
Morse
Cc: Suzuki K Poulose
Cc: Ard Biesheuvel
Cc: Mark Rutland
Cc: linux-arm-ker...@lists.infradead.org
Cc: kvm...@lists.cs.columbia.edu
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Marc Zyngier
Signed-off-by: James Morse
Signed-off-by: Anshuman Khandual
---
Changes
On 3/9/21 7:35 PM, Will Deacon wrote:
> On Mon, Mar 08, 2021 at 02:42:00PM +, Marc Zyngier wrote:
>> On Fri, 05 Mar 2021 14:36:09 +,
>> Anshuman Khandual wrote:
>>> - switch (cpuid_feature_extract_unsigned_field(mmfr0, tgran_2)) {
>>> - default
On 3/9/21 2:03 PM, Anshuman Khandual wrote:
> This series contains config cleanup patches which reduces code duplication
> across platforms and also improves maintainability. There is no functional
> change intended with this series. This has been boot tested on arm64 but
> only
: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Andrew Morton
Cc: x...@kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux...@kvack.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Anshuman Khandual
---
arch/arm
: linuxppc-...@lists.ozlabs.org
Cc: linux-s...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: linux...@kvack.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Anshuman Khandual
---
arch/arm64/Kconfig | 8 ++--
arch/ia64/Kconfig| 8 ++--
arch/powerpc/Kconfig | 8 ++--
arch/s3
...@vger.kernel.org
Cc: linux-fsde...@vger.kernel.org
Cc: linux...@kvack.org
Cc: linux-kernel@vger.kernel.org
Anshuman Khandual (6):
mm: Generalize ARCH_HAS_CACHE_LINE_SIZE
mm: Generalize SYS_SUPPORTS_HUGETLBFS (rename as ARCH_SUPPORTS_HUGETLBFS)
mm: Generalize ARCH_ENABLE_MEMORY_[HOTPLUG
On 3/8/21 12:11 PM, Anshuman Khandual wrote:
> This series contains config cleanup patches which reduces code duplication
> across platforms and also improves maintainability. There is no functional
> change intended with this series. This has been boot tested on arm64 but
> only
: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Andrew Morton
Cc: x...@kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux...@kvack.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Anshuman Khandual
---
arch/arm
: linuxppc-...@lists.ozlabs.org
Cc: linux-s...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: linux...@kvack.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Anshuman Khandual
---
arch/arm64/Kconfig | 8 ++--
arch/ia64/Kconfig| 8 ++--
arch/powerpc/Kconfig | 8 ++--
arch/s3
...@vger.kernel.org
Cc: linux-fsde...@vger.kernel.org
Cc: linux...@kvack.org
Cc: linux-kernel@vger.kernel.org
Anshuman Khandual (6):
mm: Generalize ARCH_HAS_CACHE_LINE_SIZE
mm: Generalize SYS_SUPPORTS_HUGETLBFS (rename as ARCH_SUPPORTS_HUGETLBFS)
mm: Generalize ARCH_ENABLE_MEMORY_[HOTPLUG
Cc: Mike Rapoport
Cc: David Hildenbrand
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux...@kvack.org
Suggested-by: David Hildenbrand
Signed-off-by: Anshuman Khandual
---
This applies on 5.12-rc2 along with arm64 pfn_valid() fix patches [1] and
has been ligh
On 3/5/21 8:21 PM, Mark Rutland wrote:
> On Fri, Mar 05, 2021 at 08:06:09PM +0530, Anshuman Khandual wrote:
>> From: James Morse
>>
>> As per ARM ARM DDI 0487G.a, when FEAT_LPA2 is implemented, ID_AA64MMFR0_EL1
>> might contain a range of values to describe sup
Morse
Cc: Suzuki K Poulose
Cc: Ard Biesheuvel
Cc: Mark Rutland
Cc: linux-arm-ker...@lists.infradead.org
Cc: kvm...@lists.cs.columbia.edu
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: James Morse
Signed-off-by: Anshuman Khandual
---
arch/arm64/include/asm/sysreg.h
On 3/5/21 10:54 AM, Anshuman Khandual wrote:
> This series fixes pfn_valid() for ZONE_DEVICE based memory and also improves
> its performance for normal hotplug memory. While here, it also reorganizes
> pfn_valid() on CONFIG_SPARSEMEM. This series is based on v5.12-rc1.
>
> Cc:
.
This does not cause any functional change.
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Ard Biesheuvel
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: David Hildenbrand
Signed-off-by: Anshuman Khandual
---
arch/arm64/mm/init.c | 21 -
1 file
for normal hotplug memory as well.
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Ard Biesheuvel
Cc: Robin Murphy
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Acked-by: David Hildenbrand
Fixes: 73b20c84d42d ("arm64: mm: implement pte_devmap support")
Signed-off-by
-4001-1-git-send-email-anshuman.khand...@arm.com/
Anshuman Khandual (2):
arm64/mm: Fix pfn_valid() for ZONE_DEVICE based memory
arm64/mm: Reorganize pfn_valid()
arch/arm64/mm/init.c | 29 ++---
1 file changed, 26 insertions(+), 3 deletions(-)
--
2.20.1
On 3/4/21 3:06 PM, Will Deacon wrote:
> On Thu, Mar 04, 2021 at 09:12:31AM +0100, David Hildenbrand wrote:
>> On 04.03.21 04:31, Anshuman Khandual wrote:
>>> On 3/4/21 2:54 AM, Will Deacon wrote:
>>>> On Wed, Mar 03, 2021 at 07:04:33PM +, Catalin Marinas wro
: linuxppc-...@lists.ozlabs.org
Cc: linux...@kvack.org
Cc: linux-kernel@vger.kernel.org
Suggested-by: Christoph Hellwig
Signed-off-by: Anshuman Khandual
---
This change was originally suggested in an earilier discussion. This
applies on v5.12-rc1 and has been build tested on all applicable
platforms i.e
On 3/2/21 10:43 AM, Anshuman Khandual wrote:
> HUGETLB_PAGE_SIZE_VARIABLE need not be defined for each individual
> platform subscribing it. Instead just make it generic.
>
> Cc: Michael Ellerman
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Andrew Morton
&g
On 3/4/21 2:54 AM, Will Deacon wrote:
> On Wed, Mar 03, 2021 at 07:04:33PM +, Catalin Marinas wrote:
>> On Thu, Feb 11, 2021 at 01:35:56PM +0100, David Hildenbrand wrote:
>>> On 11.02.21 13:10, Anshuman Khandual wrote:
>>>> On 2/11/21 5:23 PM, Will Deaco
On 3/1/21 7:24 PM, Suzuki K Poulose wrote:
> On 2/26/21 6:34 AM, kernel test robot wrote:
>> Hi Suzuki,
>>
>> Thank you for the patch! Yet something to improve:
>>
>> [auto build test ERROR on linus/master]
>> [also build test ERROR on next-20210226]
>> [cannot apply to kvmarm/next
On 3/2/21 11:13 AM, Christophe Leroy wrote:
>
>
> Le 02/03/2021 à 06:13, Anshuman Khandual a écrit :
>> HUGETLB_PAGE_SIZE_VARIABLE need not be defined for each individual
>> platform subscribing it. Instead just make it generic.
>>
>> Cc: Michael Ellerman
>
-...@lists.ozlabs.org
Cc: linux...@kvack.org
Cc: linux-kernel@vger.kernel.org
Suggested-by: Christoph Hellwig
Signed-off-by: Anshuman Khandual
---
This change was originally suggested in an earilier discussion. This
applies on v5.12-rc1 and has been build tested on all applicable
platforms i.e ia64 and powerpc
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Anshuman Khandual
---
This applies on v5.12-rc1 and does not seem to have any obvious problem
on 16K and 64K page size configurations. This is a simpler alternate to
a previous series [1] which tried to solve
On 3/1/21 1:23 PM, Christoph Hellwig wrote:
> On Mon, Mar 01, 2021 at 01:13:41PM +0530, Anshuman Khandual wrote:
>>> doesn't this need a 'if HUGETLB_PAGE'
>>
>> While making HUGETLB_PAGE_SIZE_VARIABLE a generic option, also made it
>> dependent on HUGE
On 3/1/21 11:53 AM, Christoph Hellwig wrote:
> On Mon, Mar 01, 2021 at 11:20:53AM +0530, Anshuman Khandual wrote:
>> HUGETLB_PAGE_SIZE_VARIABLE need not be defined for each individual
>> platform subscribing it. Instead just make it generic.
>>
>> Cc: Michae
-...@lists.ozlabs.org
Cc: linux...@kvack.org
Cc: linux-kernel@vger.kernel.org
Suggested-by: Christoph Hellwig
Signed-off-by: Anshuman Khandual
---
This change was originally suggested in an earilier discussion. This
applies on v5.12-rc1 and has been build tested on all applicable
platforms i.e ia64 and powerpc
There is already an ARCH_WANT_HUGE_PMD_SHARE which is being selected for
applicable configurations. Hence just drop the other redundant entry.
Cc: Catalin Marinas
Cc: Will Deacon
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Anshuman Khandual
-...@lists.ozlabs.org
Cc: linux-xte...@linux-xtensa.org
Cc: linux...@kvack.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Max Filippov
Signed-off-by: Anshuman Khandual
---
This patch applies on v5.12-rc1 and has been tested on arm64 platform.
But it has been just build tested on all other
54,8 +1470,9 @@ struct range arch_get_mappable_range(void)
>* range which can be mapped inside this linear mapping range, must
>* also be derived from its end points.
>*/
> - mhp_range.start = __pa(_PAGE_OFFSET(vabits_actual));
> - mhp_range.end = __pa(PAGE_END - 1);
> + mhp_range.start = start_linear_pa;
> + mhp_range.end = end_linear_pa;
> +
> return mhp_range;
> }
LGTM.
Reviewed-by: Anshuman Khandual
On 2/23/21 6:02 AM, Barry Song wrote:
> BATCHED_UNMAP_TLB_FLUSH is used on x86 to do batched tlb shootdown by
> sending one IPI to TLB flush all entries after unmapping pages rather
> than sending an IPI to flush each individual entry.
> On arm64, tlb shootdown is done by hardware. Flush
On 2/2/21 12:14 AM, Mathieu Poirier wrote:
> On Wed, Jan 27, 2021 at 02:25:24PM +0530, Anshuman Khandual wrote:
>> This series enables future IP trace features Embedded Trace Extension (ETE)
>> and Trace Buffer Extension (TRBE). This series depends on the ETM system
>>
On 1/27/21 6:30 PM, Al Grant wrote:
>>> +/* CoreSight PMU AUX buffer formats */
>>> +#define PERF_AUX_FLAG_CORESIGHT_FORMAT_CORESIGHT0x /*
>> Default for backward compatibility */
>>> +#define PERF_AUX_FLAG_CORESIGHT_FORMAT_RAW0x0100 /*
>> Raw format of the source */
>>
>> Would
On 2/5/21 12:04 AM, Mathieu Poirier wrote:
> On Thu, Jan 28, 2021 at 09:16:34AM +, Suzuki K Poulose wrote:
>> On 1/27/21 8:55 AM, Anshuman Khandual wrote:
>>> Add support for dedicated sinks that are bound to individual CPUs. (e.g,
>>> TRBE). To allow quicker acc
On 1/28/21 2:46 PM, Suzuki K Poulose wrote:
> On 1/27/21 8:55 AM, Anshuman Khandual wrote:
>> Add support for dedicated sinks that are bound to individual CPUs. (e.g,
>> TRBE). To allow quicker access to the sink for a given CPU bound source,
>> keep a percpu array of t
Hello Mike,
On 2/16/21 2:30 PM, Mike Leach wrote:
> Hi Anshuman,
>
> There have been plenty of detailed comments so I will restrict mine to
> a few general issues:-
>
> 1) Currently there appears to be no sysfs support (I cannot see the
> MODE_SYSFS constants running alongside the MODE_PERF
On 2/12/21 3:09 PM, David Hildenbrand wrote:
> On 12.02.21 08:02, Anshuman Khandual wrote:
>>
>> On 2/11/21 2:07 PM, David Hildenbrand wrote:
>>> On 11.02.21 07:22, Anshuman Khandual wrote:
>>>> The following warning gets triggered while trying to boot a 6
On 2/16/21 1:21 AM, Pavel Tatashin wrote:
> On Mon, Feb 15, 2021 at 2:34 PM Ard Biesheuvel wrote:
>>
>> On Mon, 15 Feb 2021 at 20:30, Pavel Tatashin
>> wrote:
>>>
Can't we simply use signed arithmetic here? This expression works fine
if the quantities are all interpreted as s64
On 2/16/21 12:57 AM, Ard Biesheuvel wrote:
> On Mon, 15 Feb 2021 at 20:22, Pavel Tatashin
> wrote:
>>
>> Memory hotplug may fail on systems with CONFIG_RANDOMIZE_BASE because the
>> linear map range is not checked correctly.
>>
>> The start physical address that linear map covers can be
On 2/13/21 1:56 AM, Mathieu Poirier wrote:
> On Wed, Jan 27, 2021 at 02:25:35PM +0530, Anshuman Khandual wrote:
>> Trace Buffer Extension (TRBE) implements a trace buffer per CPU which is
>> accessible via the system registers. The TRBE supports different addressing
>>
On 2/12/21 10:27 PM, Mathieu Poirier wrote:
> [...]
>
>>>
>>>
+ if (nr_pages < 2)
+ return NULL;
+
+ buf = kzalloc_node(sizeof(*buf), GFP_KERNEL, trbe_alloc_node(event));
+ if (IS_ERR(buf))
+ return ERR_PTR(-ENOMEM);
+
+ pglist =
Hello Pavel,
On 2/13/21 6:53 AM, Pavel Tatashin wrote:
> Memory hotplug may fail on systems with CONFIG_RANDOMIZE_BASE because the
> linear map range is not checked correctly.
>
> The start physical address that linear map covers can be actually at the
> end of the range because of
On 2/11/21 1:34 PM, Christoph Hellwig wrote:
> On Thu, Feb 11, 2021 at 11:52:11AM +0530, Anshuman Khandual wrote:
>> Type cast MAX_ORDER as unsigned int to fix the following build warning.
>>
>> In file included from ./include/linux/kernel.h:14,
>>
On 2/11/21 1:30 PM, Christoph Hellwig wrote:
>> -if (HPAGE_SHIFT > PAGE_SHIFT)
>> +if ((HPAGE_SHIFT > PAGE_SHIFT) && (HUGETLB_PAGE_ORDER < MAX_ORDER))
>
> No need for the braces.
Will drop them.
On 2/11/21 1:31 PM, Christoph Hellwig wrote:
> On Thu, Feb 11, 2021 at 11:52:10AM +0530, Anshuman Khandual wrote:
>> MAX_ORDER which invariably depends on FORCE_MAX_ZONEORDER can be a variable
>> for a given page size, depending on whether TRANSPARENT_HUGEPAGE is enabled
>&g
On 2/11/21 2:07 PM, David Hildenbrand wrote:
> On 11.02.21 07:22, Anshuman Khandual wrote:
>> The following warning gets triggered while trying to boot a 64K page size
>> without THP config kernel on arm64 platform.
>>
>> WARNING: CPU: 5 PID: 124 at mm/vmstat.c:1080
1 - 100 of 2971 matches
Mail list logo
