opal_prd_msg_notifier extracts the opal prd message size from the message
header and uses it for allocating opal_prd_msg_queue_item that includes
the correct message size to be copied. However, while running under
CONFIG_FORTIFY_SOURCE=y, it triggers following run-time warning:
[ 6458.234352]
Le 07/07/2023 à 04:20, Benjamin Gray a écrit :
> The inclusion of kasan_early_init() is conditional on CONFIG_KASAN, so
>
>if(IS_ENABLED(CONFIG_KASAN))
>kasan_early_init();
>
> wouldn't work.
See my comment on the main patch, just do like kasan_init() and others
in
Le 07/07/2023 à 03:31, Benjamin Gray a écrit :
> The KCOV handler __sanitizer_cov_trace_pc() uses the PACA, so initialise
> the PACA first. This fixes a hang during boot when KASAN and KCOV are
> both enabled, where the coverage tracer in kasan_early_init() tries to
> access a field of the
On Thu, 2023-07-06 at 11:08 +1000, Benjamin Gray wrote:
> The issue is pre-existing, but is surfaced by commit 721255b9826b
> ("genirq: Use a maple tree for interrupt descriptor management").
> It's not clear to me why this causes it to surface.
>From the thread chain in [1], it looks like the
The inclusion of kasan_early_init() is conditional on CONFIG_KASAN, so
if(IS_ENABLED(CONFIG_KASAN))
kasan_early_init();
wouldn't work.
On Fri, Jul 7, 2023 at 12:58 AM Isaku Yamahata wrote:
>
> On Thu, Jul 06, 2023 at 01:52:08PM +0900,
> David Stevens wrote:
>
> > On Wed, Jul 5, 2023 at 7:17 PM Yu Zhang wrote:
> > >
> > > On Tue, Jul 04, 2023 at 04:50:50PM +0900, David Stevens wrote:
> > > > From: David Stevens
> > > >
> > > >
The KCOV handler __sanitizer_cov_trace_pc() uses the PACA, so initialise
the PACA first. This fixes a hang during boot when KASAN and KCOV are
both enabled, where the coverage tracer in kasan_early_init() tries to
access a field of the (currently null) PACA.
Signed-off-by: Benjamin Gray
---
I
On Thu, 06 Jul 2023 15:20:25 PDT (-0700), eric.devol...@oracle.com wrote:
The kexec and crash kernel options are provided in the common
kernel/Kconfig.kexec. Utilize the common options and provide
the ARCH_SUPPORTS_ and ARCH_SELECTS_ entries to recreate the
equivalent set of KEXEC and CRASH
The kexec and crash kernel options are provided in the common
kernel/Kconfig.kexec. Utilize the common options and provide
the ARCH_SUPPORTS_ and ARCH_SELECTS_ entries to recreate the
equivalent set of KEXEC and CRASH options.
Signed-off-by: Eric DeVolder
Acked-by: John Paul Adrian Glaubitz
---
The kexec and crash kernel options are provided in the common
kernel/Kconfig.kexec. Utilize the common options and provide
the ARCH_SUPPORTS_ and ARCH_SELECTS_ entries to recreate the
equivalent set of KEXEC and CRASH options.
NOTE: The original Kconfig has a KEXEC_SIG which depends on
The kexec and crash kernel options are provided in the common
kernel/Kconfig.kexec. Utilize the common options and provide
the ARCH_SUPPORTS_ and ARCH_SELECTS_ entries to recreate the
equivalent set of KEXEC and CRASH options.
Signed-off-by: Eric DeVolder
---
arch/riscv/Kconfig | 44
The kexec and crash kernel options are provided in the common
kernel/Kconfig.kexec. Utilize the common options and provide
the ARCH_SUPPORTS_ and ARCH_SELECTS_ entries to recreate the
equivalent set of KEXEC and CRASH options.
Signed-off-by: Eric DeVolder
Reviewed-by: Sourabh Jain
---
The kexec and crash kernel options are provided in the common
kernel/Kconfig.kexec. Utilize the common options and provide
the ARCH_SUPPORTS_ and ARCH_SELECTS_ entries to recreate the
equivalent set of KEXEC and CRASH options.
Signed-off-by: Eric DeVolder
---
arch/parisc/Kconfig | 34
The kexec and crash kernel options are provided in the common
kernel/Kconfig.kexec. Utilize the common options and provide
the ARCH_SUPPORTS_ and ARCH_SELECTS_ entries to recreate the
equivalent set of KEXEC and CRASH options.
Signed-off-by: Eric DeVolder
Acked-by: Thomas Bogendoerfer
---
The kexec and crash kernel options are provided in the common
kernel/Kconfig.kexec. Utilize the common options and provide
the ARCH_SUPPORTS_ and ARCH_SELECTS_ entries to recreate the
equivalent set of KEXEC and CRASH options.
Signed-off-by: Eric DeVolder
Reviewed-by: Geert Uytterhoeven
The kexec and crash kernel options are provided in the common
kernel/Kconfig.kexec. Utilize the common options and provide
the ARCH_SUPPORTS_ and ARCH_SELECTS_ entries to recreate the
equivalent set of KEXEC and CRASH options.
Signed-off-by: Eric DeVolder
---
arch/loongarch/Kconfig | 26
The kexec and crash kernel options are provided in the common
kernel/Kconfig.kexec. Utilize the common options and provide
the ARCH_SUPPORTS_ and ARCH_SELECTS_ entries to recreate the
equivalent set of KEXEC and CRASH options.
Signed-off-by: Eric DeVolder
---
arch/arm64/Kconfig | 64
The config options for kexec and crash features are consolidated
into new file kernel/Kconfig.kexec. Under the "General Setup" submenu
is a new submenu "Kexec and crash handling". All the kexec and
crash options that were once in the arch-dependent submenu "Processor
type and features" are now
The Kconfig is refactored to consolidate KEXEC and CRASH options from
various arch//Kconfig files into new file kernel/Kconfig.kexec.
The Kconfig.kexec is now a submenu titled "Kexec and crash features"
located under "General Setup".
The following options are impacted:
- KEXEC
- KEXEC_FILE
-
The kexec and crash kernel options are provided in the common
kernel/Kconfig.kexec. Utilize the common options and provide
the ARCH_SUPPORTS_ and ARCH_SELECTS_ entries to recreate the
equivalent set of KEXEC and CRASH options.
Signed-off-by: Eric DeVolder
---
arch/ia64/Kconfig | 28
The kexec and crash kernel options are provided in the common
kernel/Kconfig.kexec. Utilize the common options and provide
the ARCH_SUPPORTS_ and ARCH_SELECTS_ entries to recreate the
equivalent set of KEXEC and CRASH options.
Signed-off-by: Eric DeVolder
---
arch/x86/Kconfig | 92
The kexec and crash kernel options are provided in the common
kernel/Kconfig.kexec. Utilize the common options and provide
the ARCH_SUPPORTS_ and ARCH_SELECTS_ entries to recreate the
equivalent set of KEXEC and CRASH options.
Signed-off-by: Eric DeVolder
---
arch/arm/Kconfig | 29
On Wed, Jul 05, 2023 at 08:04:41PM -0400, Jeff Layton wrote:
>
> I don't believe it's an issue. I've seen nothing in the POSIX spec that
> mandates that timestamp updates to different inodes involved in an
> operation be set to the _same_ value. It just says they must be updated.
>
> It's also
On Thu, 2023-07-06 at 10:16 -0500, Eric W. Biederman wrote:
> Jeff Layton writes:
>
> > On Wed, 2023-07-05 at 14:58 -0400, Jeff Layton wrote:
> > > v2:
> > > - prepend patches to add missing ctime updates
> > > - add simple_rename_timestamp helper function
> > > - rename ctime accessor functions
On 7/6/23 10:58, Alexander Gordeev wrote:
On Wed, Jul 05, 2023 at 08:49:58AM -0700, Nathan Chancellor wrote:
...
I just bisected the following build failure visible with 'ARCH=s390
allnoconfig' to this change as commit 842ce0e1dafa ("s390/kexec:
refactor for kernel/Kconfig.kexec") in -next.
Jeff Layton writes:
> On Wed, 2023-07-05 at 14:58 -0400, Jeff Layton wrote:
>> v2:
>> - prepend patches to add missing ctime updates
>> - add simple_rename_timestamp helper function
>> - rename ctime accessor functions as inode_get_ctime/inode_set_ctime_*
>> - drop individual
On Wed, Jul 05, 2023 at 08:49:58AM -0700, Nathan Chancellor wrote:
...
> I just bisected the following build failure visible with 'ARCH=s390
> allnoconfig' to this change as commit 842ce0e1dafa ("s390/kexec:
> refactor for kernel/Kconfig.kexec") in -next.
>
>
On Wed 05-07-23 14:58:12, Jeff Layton wrote:
> Now that everything in-tree is converted to use the accessor functions,
> rename the i_ctime field in the inode to discourage direct access.
>
> Signed-off-by: Jeff Layton
Looks good. Feel free to add:
Reviewed-by: Jan Kara
On Thu, Jul 6, 2023 at 8:19 AM Shengjiu Wang wrote:
> The clean way for fixing is to remove the code in fsl_sai_set_bclk()
> and add "fsl,sai-mclk-direction-output;" property in dts for some
> node.
Yes, after thinking more about it, I agree.
So what you are proposing is basically a revert of
On Thu, 6 Jul 2023, Gerald Schaefer wrote:
>
> Since none of my remarks on the comments seem valid or strictly necessary
> any more, and I also could not find functional issues, I think you can add
> this patch as new version for 07/12. And I can now give you this:
>
> Reviewed-by: Gerald
On 5/15/23 5:16 PM, Tobias Huschle wrote:
> The current load balancer implementation implies that scheduler groups,
> within the same domain, all host the same number of CPUs. This is
> reflected in the condition, that a scheduler group, which is load
> balancing and classified as having spare
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 06.07.23 10:50, Aneesh Kumar K.V wrote:
>> With
On Thu, Jul 06, 2023 at 01:52:08PM +0900,
David Stevens wrote:
> On Wed, Jul 5, 2023 at 7:17 PM Yu Zhang wrote:
> >
> > On Tue, Jul 04, 2023 at 04:50:50PM +0900, David Stevens wrote:
> > > From: David Stevens
> > >
> > > Stop passing FOLL_GET to __kvm_follow_pfn. This allows the host to map
>
From: Christophe Leroy
By taking GENERIC_IOREMAP method, the generic generic_ioremap_prot(),
generic_iounmap(), and their generic wrapper ioremap_prot(), ioremap()
and iounmap() are all visible and available to arch. Arch needs to
provide wrapper functions to override the generic versions if
On Wed, 5 Jul 2023 18:20:21 -0700 (PDT)
Hugh Dickins wrote:
> On Wed, 5 Jul 2023, Gerald Schaefer wrote:
> > On Tue, 4 Jul 2023 10:03:57 -0700 (PDT)
> > Hugh Dickins wrote:
> > > On Tue, 4 Jul 2023, Gerald Schaefer wrote:
> > > > On Sat, 1 Jul 2023 21:32:38 -0700 (PDT)
> > > > Hugh Dickins
On Thu, Jul 06, 2023 at 02:29:24PM +0900, David Stevens wrote:
> On Wed, Jul 5, 2023 at 7:53 PM Yu Zhang wrote:
> >
> > On Wed, Jul 05, 2023 at 06:22:59PM +0900, David Stevens wrote:
> > > On Wed, Jul 5, 2023 at 12:10 PM Yu Zhang
> > > wrote:
> > > >
> > > > > @@ -2514,35 +2512,26 @@ static
On 2023-07-05 11:06:46 Wed, Jordan Niethe wrote:
>
>
> On 26/6/23 5:04 pm, Mahesh Salgaonkar wrote:
> > opal_prd_msg_notifier extracts the opal prd message size from the message
> > header and uses it for allocating opal_prd_msg_queue_item that includes
> > the correct message size to be copied.
> Thanks for your patch, which is now commit 322dbe898f82fd8a
> ("ARM: dma-mapping: split out arch_dma_mark_clean() helper") in
> esmil/jh7100-dmapool.
Well, something is wrong with that branch then, and this series still
needs more work, and should eventually be merged through the dma-mapping
Hi Andreas,
On Thu, Jul 6, 2023 at 9:34 AM Andreas Henriksson wrote:
> I think your initial review comment was spot on Fabio. There probably
> needs to be a(n imx8mm) specific flag that says when this workaround
> should be applied and gate the code in bclk function on that.
> Atleast that's
Hello Fabio,
Maybe I shouldn't comment as I'm already on deep water, but...
On Thu, Jul 06, 2023 at 08:32:57AM -0300, Fabio Estevam wrote:
> On Thu, Jul 6, 2023 at 8:19 AM Shengjiu Wang wrote:
>
> > No, this is the code in probe().
> > The code with the issue is in fsl_sai_set_bclk().
>
>
On 7/6/23 07:18, Arnd Bergmann wrote:
On Wed, Jul 5, 2023, at 16:19, Eric DeVolder wrote:
+
+config CRASH_DUMP
+ bool "kernel crash dumps"
+ depends on ARCH_SUPPORTS_CRASH_DUMP
+ select CRASH_CORE
+ select KEXEC
Today's linux-next now runs into a warning on arm64
On Wed, Jul 5, 2023, at 16:19, Eric DeVolder wrote:
> +
> +config CRASH_DUMP
> + bool "kernel crash dumps"
> + depends on ARCH_SUPPORTS_CRASH_DUMP
> + select CRASH_CORE
> + select KEXEC
Today's linux-next now runs into a warning on arm64 and
presumably others, with the same
On Thu, Jul 6, 2023 at 7:08 PM Fabio Estevam wrote:
> Hi Andreas,
>
> On Thu, Jul 6, 2023 at 5:47 AM Andreas Henriksson
> wrote:
>
> > We've been working on an i.MX8MP where MCLK needs to be input and found
> > that this enables the MCLK as output despite not having set the
> >
On Thu, Jul 6, 2023 at 4:47 PM Andreas Henriksson wrote:
> Hello Shengjiu, Fabio,
>
> On Thu, May 19, 2022 at 10:23:06AM -0300, Fabio Estevam wrote:
> > Hi Shengjiu,
> >
> > On Thu, May 19, 2022 at 9:49 AM Shengjiu Wang
> wrote:
> >
> > > diff --git a/sound/soc/fsl/fsl_sai.c
On Wed 05-07-23 14:58:11, Jeff Layton wrote:
> A rename potentially involves updating 4 different inode timestamps. Add
> a function that handles the details sanely, and convert the libfs.c
> callers to use it.
>
> Signed-off-by: Jeff Layton
Looks good to me. Feel free to add:
Reviewed-by: Jan
Hello Shengjiu, Fabio,
On Thu, May 19, 2022 at 10:23:06AM -0300, Fabio Estevam wrote:
> Hi Shengjiu,
>
> On Thu, May 19, 2022 at 9:49 AM Shengjiu Wang wrote:
>
> > diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
> > index fa950dde5310..dae16a14f177 100644
> > ---
On 2023-07-06 11:41:38+0530, Sachin Sant wrote:
> While running LTP tests (madvise06) on IBM Power9 LPAR booted with
> 6.4.0-next-20230705 following crash is seen
>
> Injecting memory failure for pfn 0x3f79 at process virtual address
> 0x7fff9b74
> Memory failure: 0x3f79: recovery action for
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 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 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
such as base_pfn, end_pfn, etc
On Thu, Jul 6, 2023 at 9:50 AM Geert Uytterhoeven wrote:
> On Thu, Jul 6, 2023 at 8:14 AM Benjamin Gray wrote:
> > On Thu, 2023-07-06 at 05:13 +, Christophe Leroy wrote:
> > > Le 05/07/2023 à 02:30, Benjamin Gray a écrit :
> > > > The drivers/rtc/rtc-ds1307.c driver has a direct dependency
On Wed, Jul 5, 2023, at 21:00, Jeff Layton wrote:
> In later patches, we're going to change how the inode's ctime field is
> used. Switch to using accessor functions instead of raw accesses of
> inode->i_ctime.
>
> Acked-by: Jeremy Kerr
> Reviewed-by: Jan Kara
> Signed-off-by: Jeff Layton
On Thu, Jul 6, 2023 at 8:19 AM Shengjiu Wang wrote:
> No, this is the code in probe().
> The code with the issue is in fsl_sai_set_bclk().
Yes, I put it in the wrong place.
> The clean way for fixing is to remove the code in fsl_sai_set_bclk()
> and add "fsl,sai-mclk-direction-output;"
On 06.07.23 12:04, Aneesh Kumar K V wrote:
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
On 04/07/2023 11:11, Tobias Huschle wrote:
> On 2023-05-16 18:35, Dietmar Eggemann wrote:
>> On 15/05/2023 13:46, Tobias Huschle wrote:
>>> The current load balancer implementation implies that scheduler groups,
>>> within the same scheduler domain, all host the same number of CPUs.
>>>
>>> This
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
such as base_pfn, end_pfn, etc to unmap vmemmap memory.
Can you elaborate why ppc64 needs
Hi Andreas,
On Thu, Jul 6, 2023 at 5:47 AM Andreas Henriksson wrote:
> We've been working on an i.MX8MP where MCLK needs to be input and found
> that this enables the MCLK as output despite not having set the
> `fsl,sai-mclk-direction-output;` devicetree property in our DT.
> Reverting the
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 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 memmap on memory
feature if the hotplug flag request
On 06.07.23 10:50, Aneesh Kumar K.V wrote:
Some architectures like ppc64 wants to enable this feature only with radix
translation and their vemmap mappings have different alignment
requirements. Add overrider for mhp_supports_memmap_on_memory() and also
use altmap.reserve feature to adjust the
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?
IOW, why can't ppc64 simply allocate the vmemmap from
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 granularity. We can end up
loosing some pages in memory
With memmap on memory, some architecture needs more details w.r.t altmap
such as base_pfn, end_pfn, etc to unmap vmemmap memory.
Embed vmem_altmap data structure to memory_bock and use that instead of
nr_vmemmap_pages.
On memory unplug, if the kernel finds any memory block in the range to
be
Add some extra vmemmap pr_debug message that will indicate the type of
vmemmap allocations.
For ex: with DAX vmemmap optimization we can find the below details:
[ 187.166580] radix-mmu: PAGE_SIZE vmemmap mapping
[ 187.166587] radix-mmu: PAGE_SIZE vmemmap mapping
[ 187.166591] radix-mmu: Tail
This is not used by radix anymore.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/mm/book3s64/radix_pgtable.c | 11 ---
arch/powerpc/mm/init_64.c| 21 ++---
2 files changed, 14 insertions(+), 18 deletions(-)
diff --git
With 2M PMD-level mapping, we require 32 struct pages and a single vmemmap
page can contain 1024 struct pages (PAGE_SIZE/sizeof(struct page)). Hence
with 64K page size, we don't use vmemmap deduplication for PMD-level
mapping.
Signed-off-by: Aneesh Kumar K.V
---
This is in preparation to update radix to implement vmemmap optimization
for devdax. Below are the rules w.r.t radix vmemmap mapping
1. First try to map things using PMD (2M)
2. With altmap if altmap cross-boundary check returns true, fall back to
PAGE_SIZE
3. If we can't allocate PMD_SIZE
This is enabled only with radix translation and 1G hugepage size. This will
be used with devdax device memory with a namespace alignment of 1G.
Anon transparent hugepage is not supported even though we do have helpers
checking pud_trans_huge(). We should never find that return true. The only
A follow-up patch will add a pud variant for this same event.
Using event class makes that addition simpler.
No functional change in this patch.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/mm/book3s64/hash_pgtable.c | 2 +-
arch/powerpc/mm/book3s64/radix_pgtable.c | 2 +-
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 not
supported without unmapping of pte(marking it invalid) by some
architectures.
With
pudp_set_wrprotect and move_huge_pud helpers are only used when
CONFIG_TRANSPARENT_HUGEPAGE is enabled. Similar to pmdp_set_wrprotect and
move_huge_pmd_helpers use architecture override only if
CONFIG_TRANSPARENT_HUGEPAGE is set
Signed-off-by: Aneesh Kumar K.V
---
include/linux/pgtable.h | 2 ++
This helps architectures to override pmd_same and pud_same independently.
Signed-off-by: Aneesh Kumar K.V
---
include/linux/pgtable.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
index 6fd9b2831338..91def34f7784 100644
---
Architectures like powerpc will like to use different page table allocators
and mapping mechanisms to implement vmemmap optimization. Similar to
vmemmap_populate allow architectures to implement
vmemap_populate_compound_pages
Signed-off-by: Aneesh Kumar K.V
---
mm/sparse-vmemmap.c | 3 +++
1
dax vmemmap optimization requires a minimum of 2 PAGE_SIZE area within
vmemmap such that tail page mapping can point to the second PAGE_SIZE area.
Enforce that in vmemmap_can_optimize() function.
Architectures like powerpc also want to enable vmemmap optimization
conditionally (only with radix
Architectures like powerpc would like to enable transparent huge page pud
support only with radix translation. To support that add
has_transparent_pud_hugepage() helper that architectures can override.
Signed-off-by: Aneesh Kumar K.V
---
drivers/nvdimm/pfn_devs.c | 2 +-
include/linux/pgtable.h
We will use this in a later patch to do tlb flush when clearing pud entries
on powerpc. This is similar to commit 93a98695f2f9 ("mm: change
pmdp_huge_get_and_clear_full take vm_area_struct as arg")
Signed-off-by: Aneesh Kumar K.V
---
include/linux/pgtable.h | 4 ++--
mm/debug_vm_pgtable.c | 2
This patch series implements changes required to support DAX vmemmap
optimization for ppc64. The vmemmap optimization is only enabled with radix MMU
translation and 1GB PUD mapping with 64K page size. The patch series also split
hugetlb vmemmap optimization as a separate Kconfig variable so that
On 06.07.23 10:50, Aneesh Kumar K.V wrote:
Instead of adding menu entry with all supported architectures, add
mm/Kconfig variable and select the same from supported architectures.
No functional change in this patch.
Signed-off-by: Aneesh Kumar K.V
---
arch/arm64/Kconfig | 4 +---
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 granularity. We can end up
loosing some pages in memory with this. For ex: with 256MB memory block
size,
Instead of adding menu entry with all supported architectures, add
mm/Kconfig variable and select the same from supported architectures.
No functional change in this patch.
Signed-off-by: Aneesh Kumar K.V
---
arch/arm64/Kconfig | 4 +---
arch/x86/Kconfig | 4 +---
mm/Kconfig | 3 +++
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 memmap on memory
feature if the hotplug flag request for the same.
The ACPI code now can pass the
Some architectures like ppc64 wants to enable this feature only with radix
translation and their vemmap mappings have different alignment
requirements. Add overrider for mhp_supports_memmap_on_memory() and also
use altmap.reserve feature to adjust the pageblock alignment requirement.
The patch
This patch series update memmap on memory feature to fall back to
memmap allocation outside the memory block if the alignment rules are
not met. This makes the feature more useful on architectures like
ppc64 where alignment rules are different with 64K page size.
This patch series is dependent on
On Thu, Jul 6, 2023 at 3:09 PM Christophe Leroy
wrote:
>
>
>
> Le 21/11/2022 à 04:51, Zhouyi Zhou a écrit :
> > During CPU-hotplug torture (CONFIG_NO_HZ_FULL=y), if we try to
> > offline tick_do_timer_cpu, the operation will fail because in
> > function tick_nohz_cpu_down:
> > ```
> > if
On 30/6/23 3:56 pm, Gautam Menghani wrote:
Remove an unnecessary piece of code that does an endianness conversion but
does not use the result. The following warning was reported by Clang's
static analyzer:
arch/powerpc/sysdev/xics/ics-opal.c:114:2: warning: Value stored to
'server' is never
Hi Benjamin,
On Thu, Jul 6, 2023 at 8:14 AM Benjamin Gray wrote:
> On Thu, 2023-07-06 at 05:13 +, Christophe Leroy wrote:
> > Le 05/07/2023 à 02:30, Benjamin Gray a écrit :
> > > The drivers/rtc/rtc-ds1307.c driver has a direct dependency on
> > > struct regmap_config, which is guarded
On Thu, Jul 06, 2023 at 01:52:08PM +0900, David Stevens wrote:
> On Wed, Jul 5, 2023 at 7:17 PM Yu Zhang wrote:
> >
> > On Tue, Jul 04, 2023 at 04:50:50PM +0900, David Stevens wrote:
> > > From: David Stevens
> > >
> > > Stop passing FOLL_GET to __kvm_follow_pfn. This allows the host to map
> >
Le 24/11/2022 à 15:33, Yang Yingliang a écrit :
> The of node returned by of_find_compatible_node() with refcount
> decremented, of_node_put() need be called after using it to avoid
> refcount leak.
Is that patch still required ? If yes, please rebase and resend.
Thanks
Christophe
>
> Fixes:
Le 21/11/2022 à 04:51, Zhouyi Zhou a écrit :
> During CPU-hotplug torture (CONFIG_NO_HZ_FULL=y), if we try to
> offline tick_do_timer_cpu, the operation will fail because in
> function tick_nohz_cpu_down:
> ```
> if (tick_nohz_full_running && tick_do_timer_cpu == cpu)
>return -EBUSY;
>
On Wed, Jul 5, 2023 at 10:19 PM Zhi Wang wrote:
>
> On Tue, 4 Jul 2023 16:50:48 +0900
> David Stevens wrote:
>
> > From: David Stevens
> >
> > Make it so that __kvm_follow_pfn does not imply FOLL_GET. This allows
> > callers to resolve a gfn when the associated pfn has a valid struct page
> >
Le 06/07/2023 à 08:14, Benjamin Gray a écrit :
> On Thu, 2023-07-06 at 05:13 +, Christophe Leroy wrote:
>>
>>
>> Le 05/07/2023 à 02:30, Benjamin Gray a écrit :
>>> The drivers/rtc/rtc-ds1307.c driver has a direct dependency on
>>> struct regmap_config, which is guarded behind CONFIG_REGMAP.
On Thu, 2023-07-06 at 05:13 +, Christophe Leroy wrote:
>
>
> Le 05/07/2023 à 02:30, Benjamin Gray a écrit :
> > The drivers/rtc/rtc-ds1307.c driver has a direct dependency on
> > struct regmap_config, which is guarded behind CONFIG_REGMAP.
> >
> > Commit 70a640c0efa7 ("regmap: REGMAP_KUNIT
While running LTP tests (madvise06) on IBM Power9 LPAR booted with
6.4.0-next-20230705 following crash is seen
Injecting memory failure for pfn 0x3f79 at process virtual address
0x7fff9b74
Memory failure: 0x3f79: recovery action for clean LRU page: Recovered
madvise06 (133636): drop_caches:
On Wed, Jul 5, 2023 at 8:56 PM Yu Zhang wrote:
>
> On Tue, Jul 04, 2023 at 04:50:48PM +0900, David Stevens wrote:
> > From: David Stevens
> >
> > Make it so that __kvm_follow_pfn does not imply FOLL_GET. This allows
> > callers to resolve a gfn when the associated pfn has a valid struct page
> >
95 matches
Mail list logo
