* [PATCH RESEND] macintosh: convert to i2c_new_scanned_device
From: Wolfram Sang @ 2020-02-10 17:04 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-i2c, Wolfram Sang
Move from the deprecated i2c_new_probed_device() to the new
i2c_new_scanned_device(). No functional change for this driver because
it doesn't check the return code anyhow.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
I can take this via I2C tree if this makes things easier...
drivers/macintosh/therm_windtunnel.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/macintosh/therm_windtunnel.c b/drivers/macintosh/therm_windtunnel.c
index 8c744578122a..f15fec5e1cb6 100644
--- a/drivers/macintosh/therm_windtunnel.c
+++ b/drivers/macintosh/therm_windtunnel.c
@@ -321,10 +321,10 @@ do_attach( struct i2c_adapter *adapter )
memset(&info, 0, sizeof(struct i2c_board_info));
strlcpy(info.type, "therm_ds1775", I2C_NAME_SIZE);
- i2c_new_probed_device(adapter, &info, scan_ds1775, NULL);
+ i2c_new_scanned_device(adapter, &info, scan_ds1775, NULL);
strlcpy(info.type, "therm_adm1030", I2C_NAME_SIZE);
- i2c_new_probed_device(adapter, &info, scan_adm1030, NULL);
+ i2c_new_scanned_device(adapter, &info, scan_adm1030, NULL);
if( x.thermostat && x.fan ) {
x.running = 1;
--
2.20.1
^ permalink raw reply related
* Re: [PATCH V12] mm/debug: Add tests validating architecture page table helpers
From: Catalin Marinas @ 2020-02-10 15:37 UTC (permalink / raw)
To: Anshuman Khandual
Cc: Mark Rutland, linux-ia64, linux-sh, Peter Zijlstra, James Hogan,
Heiko Carstens, Michal Hocko, linux-mm, Paul Mackerras,
sparclinux, Ingo Molnar, linux-s390, Jason Gunthorpe,
Vlastimil Babka, x86, Russell King - ARM Linux, Matthew Wilcox,
Steven Price, Tetsuo Handa, linux-arm-kernel, linux-snps-arc,
Kees Cook, Masahiro Yamada, Dan Williams, Mark Brown,
Kirill A . Shutemov, Thomas Gleixner, Gerald Schaefer,
Sri Krishna chowdary, Dave Hansen, Greg Kroah-Hartman,
Ard Biesheuvel, linux-mips, Ralf Baechle, linux-kernel,
Paul Burton, Mike Rapoport, Vineet Gupta, Martin Schwidefsky,
Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <1580174873-18117-1-git-send-email-anshuman.khandual@arm.com>
On Tue, Jan 28, 2020 at 06:57:53AM +0530, Anshuman Khandual wrote:
> This gets build and run when CONFIG_DEBUG_VM_PGTABLE is selected along with
> CONFIG_VM_DEBUG. Architectures willing to subscribe this test also need to
> select CONFIG_ARCH_HAS_DEBUG_VM_PGTABLE which for now is limited to x86 and
> arm64. Going forward, other architectures too can enable this after fixing
> build or runtime problems (if any) with their page table helpers.
It may be worth posting the next version to linux-arch to reach out to
other arch maintainers.
Also I've seen that you posted a v13 but it hasn't reached
linux-arm-kernel (likely held in moderation because of the large amount
of addresses cc'ed) and I don't normally follow LKML. I'm not cc'ed to
this patch either (which is fine as long as you post to a list that I
read).
Since I started the reply on v12 about a week ago, I'll follow up here.
When you post a v14, please trim the people on cc only to those strictly
necessary (e.g. arch maintainers, linux-mm, linux-arch and lkml).
> diff --git a/Documentation/features/debug/debug-vm-pgtable/arch-support.txt b/Documentation/features/debug/debug-vm-pgtable/arch-support.txt
> new file mode 100644
> index 000000000000..f3f8111edbe3
> --- /dev/null
> +++ b/Documentation/features/debug/debug-vm-pgtable/arch-support.txt
> @@ -0,0 +1,35 @@
> +#
> +# Feature name: debug-vm-pgtable
> +# Kconfig: ARCH_HAS_DEBUG_VM_PGTABLE
> +# description: arch supports pgtable tests for semantics compliance
> +#
> + -----------------------
> + | arch |status|
> + -----------------------
> + | alpha: | TODO |
> + | arc: | ok |
> + | arm: | TODO |
I'm sure you can find some arm32 hardware around (or a VM) to give this
a try ;).
> diff --git a/arch/x86/include/asm/pgtable_64.h b/arch/x86/include/asm/pgtable_64.h
> index 0b6c4042942a..fb0e76d254b3 100644
> --- a/arch/x86/include/asm/pgtable_64.h
> +++ b/arch/x86/include/asm/pgtable_64.h
[...]
> @@ -1197,6 +1197,7 @@ static noinline void __init kernel_init_freeable(void)
> sched_init_smp();
>
> page_alloc_init_late();
> + debug_vm_pgtable();
> /* Initialize page ext after all struct pages are initialized. */
> page_ext_init();
I guess you could even make debug_vm_pgtable() an early_initcall(). I
don't have a strong opinion either way.
> diff --git a/mm/debug_vm_pgtable.c b/mm/debug_vm_pgtable.c
> new file mode 100644
> index 000000000000..0f37f32d15f1
> --- /dev/null
> +++ b/mm/debug_vm_pgtable.c
> @@ -0,0 +1,388 @@
[...]
> +/*
> + * Basic operations
> + *
> + * mkold(entry) = An old and not a young entry
> + * mkyoung(entry) = A young and not an old entry
> + * mkdirty(entry) = A dirty and not a clean entry
> + * mkclean(entry) = A clean and not a dirty entry
> + * mkwrite(entry) = A write and not a write protected entry
> + * wrprotect(entry) = A write protected and not a write entry
> + * pxx_bad(entry) = A mapped and non-table entry
> + * pxx_same(entry1, entry2) = Both entries hold the exact same value
> + */
> +#define VMFLAGS (VM_READ|VM_WRITE|VM_EXEC)
> +
> +/*
> + * On s390 platform, the lower 12 bits are used to identify given page table
> + * entry type and for other arch specific requirements. But these bits might
> + * affect the ability to clear entries with pxx_clear(). So while loading up
> + * the entries skip all lower 12 bits in order to accommodate s390 platform.
> + * It does not have affect any other platform.
> + */
> +#define RANDOM_ORVALUE (0xfffffffffffff000UL)
I'd suggest you generate this mask with something like
GENMASK(BITS_PER_LONG, PAGE_SHIFT).
> +#define RANDOM_NZVALUE (0xff)
> +
> +static void __init pte_basic_tests(unsigned long pfn, pgprot_t prot)
> +{
> + pte_t pte = pfn_pte(pfn, prot);
> +
> + WARN_ON(!pte_same(pte, pte));
> + WARN_ON(!pte_young(pte_mkyoung(pte)));
> + WARN_ON(!pte_dirty(pte_mkdirty(pte)));
> + WARN_ON(!pte_write(pte_mkwrite(pte)));
> + WARN_ON(pte_young(pte_mkold(pte)));
> + WARN_ON(pte_dirty(pte_mkclean(pte)));
> + WARN_ON(pte_write(pte_wrprotect(pte)));
Given that you start with rwx permissions set,
some of these ops would not have any effect. For example, on arm64 at
least, mkwrite clears a bit already cleared here. You could try with
multiple rwx combinations values (e.g. all set and all cleared) or maybe
something like below:
WARN_ON(!pte_write(pte_mkwrite(pte_wrprotect(pte))));
You could also try something like this:
WARN_ON(!pte_same(pte_wrprotect(pte), pte_wrprotect(pte_mkwrite(pte))));
though the above approach may not work for arm64 ptep_set_wrprotect() on
a dirty pte (if you extend these tests later).
> +}
> +
> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> +static void __init pmd_basic_tests(unsigned long pfn, pgprot_t prot)
> +{
> + pmd_t pmd = pfn_pmd(pfn, prot);
> +
> + WARN_ON(!pmd_same(pmd, pmd));
> + WARN_ON(!pmd_young(pmd_mkyoung(pmd)));
> + WARN_ON(!pmd_dirty(pmd_mkdirty(pmd)));
> + WARN_ON(!pmd_write(pmd_mkwrite(pmd)));
> + WARN_ON(pmd_young(pmd_mkold(pmd)));
> + WARN_ON(pmd_dirty(pmd_mkclean(pmd)));
> + WARN_ON(pmd_write(pmd_wrprotect(pmd)));
> + /*
> + * A huge page does not point to next level page table
> + * entry. Hence this must qualify as pmd_bad().
> + */
> + WARN_ON(!pmd_bad(pmd_mkhuge(pmd)));
> +}
> +
> +#ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
> +static void __init pud_basic_tests(unsigned long pfn, pgprot_t prot)
> +{
> + pud_t pud = pfn_pud(pfn, prot);
> +
> + WARN_ON(!pud_same(pud, pud));
> + WARN_ON(!pud_young(pud_mkyoung(pud)));
> + WARN_ON(!pud_write(pud_mkwrite(pud)));
> + WARN_ON(pud_write(pud_wrprotect(pud)));
> + WARN_ON(pud_young(pud_mkold(pud)));
> +
> + if (mm_pmd_folded(mm) || __is_defined(ARCH_HAS_4LEVEL_HACK))
> + return;
> +
> + /*
> + * A huge page does not point to next level page table
> + * entry. Hence this must qualify as pud_bad().
> + */
> + WARN_ON(!pud_bad(pud_mkhuge(pud)));
> +}
> +#else
> +static void __init pud_basic_tests(unsigned long pfn, pgprot_t prot) { }
> +#endif
> +#else
> +static void __init pmd_basic_tests(unsigned long pfn, pgprot_t prot) { }
> +static void __init pud_basic_tests(unsigned long pfn, pgprot_t prot) { }
> +#endif
> +
> +static void __init p4d_basic_tests(unsigned long pfn, pgprot_t prot)
> +{
> + p4d_t p4d;
> +
> + memset(&p4d, RANDOM_NZVALUE, sizeof(p4d_t));
> + WARN_ON(!p4d_same(p4d, p4d));
> +}
> +
> +static void __init pgd_basic_tests(unsigned long pfn, pgprot_t prot)
> +{
> + pgd_t pgd;
> +
> + memset(&pgd, RANDOM_NZVALUE, sizeof(pgd_t));
> + WARN_ON(!pgd_same(pgd, pgd));
> +}
> +
> +#ifndef __ARCH_HAS_4LEVEL_HACK
This macro doesn't exist in the kernel anymore (it's a 5LEVEL now). But
can you not use the __PAGETABLE_PUD_FOLDED instead?
> +static void __init pud_clear_tests(struct mm_struct *mm, pud_t *pudp)
> +{
> + pud_t pud = READ_ONCE(*pudp);
> +
> + if (mm_pmd_folded(mm))
> + return;
> +
> + pud = __pud(pud_val(pud) | RANDOM_ORVALUE);
> + WRITE_ONCE(*pudp, pud);
> + pud_clear(pudp);
> + pud = READ_ONCE(*pudp);
> + WARN_ON(!pud_none(pud));
> +}
> +
> +static void __init pud_populate_tests(struct mm_struct *mm, pud_t *pudp,
> + pmd_t *pmdp)
> +{
> + pud_t pud;
> +
> + if (mm_pmd_folded(mm))
> + return;
> + /*
> + * This entry points to next level page table page.
> + * Hence this must not qualify as pud_bad().
> + */
> + pmd_clear(pmdp);
> + pud_clear(pudp);
> + pud_populate(mm, pudp, pmdp);
> + pud = READ_ONCE(*pudp);
> + WARN_ON(pud_bad(pud));
> +}
> +#else
> +static void __init pud_clear_tests(struct mm_struct *mm, pud_t *pudp) { }
> +static void __init pud_populate_tests(struct mm_struct *mm, pud_t *pudp,
> + pmd_t *pmdp)
> +{
> +}
> +#endif
> +
> +#ifndef __ARCH_HAS_5LEVEL_HACK
Could you use __PAGETABLE_P4D_FOLDED instead?
> +static void __init p4d_clear_tests(struct mm_struct *mm, p4d_t *p4dp)
> +{
> + p4d_t p4d = READ_ONCE(*p4dp);
> +
> + if (mm_pud_folded(mm))
> + return;
> +
> + p4d = __p4d(p4d_val(p4d) | RANDOM_ORVALUE);
> + WRITE_ONCE(*p4dp, p4d);
> + p4d_clear(p4dp);
> + p4d = READ_ONCE(*p4dp);
> + WARN_ON(!p4d_none(p4d));
> +}
Otherwise the patch looks fine. As per the comment on v13, make sure you
don't break the build on any architecture, so this could either be an
opt-in or patch those architectures before this patch is applied.
Thanks.
--
Catalin
^ permalink raw reply
* Re: [PATCH 6/6] powerpc: powernv: no need to check return value of debugfs_create functions
From: Greg Kroah-Hartman @ 2020-02-10 15:19 UTC (permalink / raw)
To: Oliver O'Halloran
Cc: Paul Mackerras, Sukadev Bhattiprolu, linuxppc-dev,
Linux Kernel Mailing List, Anju T Sudhakar
In-Reply-To: <CAOSf1CEKwjDkp-=SMjmJfQirxdGCkadougZbdDS6FK1muNNCZw@mail.gmail.com>
On Tue, Feb 11, 2020 at 02:01:53AM +1100, Oliver O'Halloran wrote:
> On Mon, Feb 10, 2020 at 12:12 AM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > When calling debugfs functions, there is no need to ever check the
> > return value. The function can work or not, but the code logic should
> > never do something different based on this.
>
> For memtrace debugfs is the only way to actually use the feature. It'd
> be nice if it still printed out *something* if it failed to create the
> files rather than just being mysteriously absent, but maybe debugfs
> itself does that. Looks fine otherwise.
No, debugfs will only spit out an error message to the log if a
file/directory is attempted to be created for an already present
file/directory.
For other failures, no error will be printed, other than the normal
lower-level "out of memory" issues that might rarely happen.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 6/6] powerpc: powernv: no need to check return value of debugfs_create functions
From: Oliver O'Halloran @ 2020-02-10 15:01 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Paul Mackerras, Sukadev Bhattiprolu, linuxppc-dev,
Linux Kernel Mailing List, Anju T Sudhakar
In-Reply-To: <20200209105901.1620958-6-gregkh@linuxfoundation.org>
On Mon, Feb 10, 2020 at 12:12 AM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
For memtrace debugfs is the only way to actually use the feature. It'd
be nice if it still printed out *something* if it failed to create the
files rather than just being mysteriously absent, but maybe debugfs
itself does that. Looks fine otherwise.
Reviewed-by: Oliver O'Halloran <oohall@gmail.com>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> arch/powerpc/platforms/powernv/memtrace.c | 7 ----
> arch/powerpc/platforms/powernv/opal-imc.c | 24 ++++----------
> arch/powerpc/platforms/powernv/pci-ioda.c | 5 ---
> arch/powerpc/platforms/powernv/vas-debug.c | 37 ++--------------------
> 4 files changed, 10 insertions(+), 63 deletions(-)
>
> diff --git a/arch/powerpc/platforms/powernv/memtrace.c b/arch/powerpc/platforms/powernv/memtrace.c
> index eb2e75dac369..d6d64f8718e6 100644
> --- a/arch/powerpc/platforms/powernv/memtrace.c
> +++ b/arch/powerpc/platforms/powernv/memtrace.c
> @@ -187,11 +187,6 @@ static int memtrace_init_debugfs(void)
>
> snprintf(ent->name, 16, "%08x", ent->nid);
> dir = debugfs_create_dir(ent->name, memtrace_debugfs_dir);
> - if (!dir) {
> - pr_err("Failed to create debugfs directory for node %d\n",
> - ent->nid);
> - return -1;
> - }
>
> ent->dir = dir;
> debugfs_create_file("trace", 0400, dir, ent, &memtrace_fops);
> @@ -314,8 +309,6 @@ static int memtrace_init(void)
> {
> memtrace_debugfs_dir = debugfs_create_dir("memtrace",
> powerpc_debugfs_root);
> - if (!memtrace_debugfs_dir)
> - return -1;
>
> debugfs_create_file("enable", 0600, memtrace_debugfs_dir,
> NULL, &memtrace_init_fops);
> diff --git a/arch/powerpc/platforms/powernv/opal-imc.c b/arch/powerpc/platforms/powernv/opal-imc.c
> index 000b350d4060..968b9a4d1cd9 100644
> --- a/arch/powerpc/platforms/powernv/opal-imc.c
> +++ b/arch/powerpc/platforms/powernv/opal-imc.c
> @@ -35,11 +35,10 @@ static int imc_mem_set(void *data, u64 val)
> }
> DEFINE_DEBUGFS_ATTRIBUTE(fops_imc_x64, imc_mem_get, imc_mem_set, "0x%016llx\n");
>
> -static struct dentry *imc_debugfs_create_x64(const char *name, umode_t mode,
> - struct dentry *parent, u64 *value)
> +static void imc_debugfs_create_x64(const char *name, umode_t mode,
> + struct dentry *parent, u64 *value)
> {
> - return debugfs_create_file_unsafe(name, mode, parent,
> - value, &fops_imc_x64);
> + debugfs_create_file_unsafe(name, mode, parent, value, &fops_imc_x64);
> }
>
> /*
> @@ -59,9 +58,6 @@ static void export_imc_mode_and_cmd(struct device_node *node,
>
> imc_debugfs_parent = debugfs_create_dir("imc", powerpc_debugfs_root);
>
> - if (!imc_debugfs_parent)
> - return;
> -
> if (of_property_read_u32(node, "cb_offset", &cb_offset))
> cb_offset = IMC_CNTL_BLK_OFFSET;
>
> @@ -69,21 +65,15 @@ static void export_imc_mode_and_cmd(struct device_node *node,
> loc = (u64)(ptr->vbase) + cb_offset;
> imc_mode_addr = (u64 *)(loc + IMC_CNTL_BLK_MODE_OFFSET);
> sprintf(mode, "imc_mode_%d", (u32)(ptr->id));
> - if (!imc_debugfs_create_x64(mode, 0600, imc_debugfs_parent,
> - imc_mode_addr))
> - goto err;
> + imc_debugfs_create_x64(mode, 0600, imc_debugfs_parent,
> + imc_mode_addr);
>
> imc_cmd_addr = (u64 *)(loc + IMC_CNTL_BLK_CMD_OFFSET);
> sprintf(cmd, "imc_cmd_%d", (u32)(ptr->id));
> - if (!imc_debugfs_create_x64(cmd, 0600, imc_debugfs_parent,
> - imc_cmd_addr))
> - goto err;
> + imc_debugfs_create_x64(cmd, 0600, imc_debugfs_parent,
> + imc_cmd_addr);
> ptr++;
> }
> - return;
> -
> -err:
> - debugfs_remove_recursive(imc_debugfs_parent);
> }
>
> /*
> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
> index 22c22cd7bd82..57d3a6af1d52 100644
> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> @@ -3174,11 +3174,6 @@ static void pnv_pci_ioda_create_dbgfs(void)
>
> sprintf(name, "PCI%04x", hose->global_number);
> phb->dbgfs = debugfs_create_dir(name, powerpc_debugfs_root);
> - if (!phb->dbgfs) {
> - pr_warn("%s: Error on creating debugfs on PHB#%x\n",
> - __func__, hose->global_number);
> - continue;
> - }
>
> debugfs_create_file_unsafe("dump_diag_regs", 0200, phb->dbgfs,
> phb, &pnv_pci_diag_data_fops);
> diff --git a/arch/powerpc/platforms/powernv/vas-debug.c b/arch/powerpc/platforms/powernv/vas-debug.c
> index 09e63df53c30..44035a3d6414 100644
> --- a/arch/powerpc/platforms/powernv/vas-debug.c
> +++ b/arch/powerpc/platforms/powernv/vas-debug.c
> @@ -115,7 +115,7 @@ void vas_window_free_dbgdir(struct vas_window *window)
>
> void vas_window_init_dbgdir(struct vas_window *window)
> {
> - struct dentry *f, *d;
> + struct dentry *d;
>
> if (!window->vinst->dbgdir)
> return;
> @@ -127,28 +127,10 @@ void vas_window_init_dbgdir(struct vas_window *window)
> snprintf(window->dbgname, 16, "w%d", window->winid);
>
> d = debugfs_create_dir(window->dbgname, window->vinst->dbgdir);
> - if (IS_ERR(d))
> - goto free_name;
> -
> window->dbgdir = d;
>
> - f = debugfs_create_file("info", 0444, d, window, &info_fops);
> - if (IS_ERR(f))
> - goto remove_dir;
> -
> - f = debugfs_create_file("hvwc", 0444, d, window, &hvwc_fops);
> - if (IS_ERR(f))
> - goto remove_dir;
> -
> - return;
> -
> -remove_dir:
> - debugfs_remove_recursive(window->dbgdir);
> - window->dbgdir = NULL;
> -
> -free_name:
> - kfree(window->dbgname);
> - window->dbgname = NULL;
> + debugfs_create_file("info", 0444, d, window, &info_fops);
> + debugfs_create_file("hvwc", 0444, d, window, &hvwc_fops);
> }
>
> void vas_instance_init_dbgdir(struct vas_instance *vinst)
> @@ -156,8 +138,6 @@ void vas_instance_init_dbgdir(struct vas_instance *vinst)
> struct dentry *d;
>
> vas_init_dbgdir();
> - if (!vas_debugfs)
> - return;
>
> vinst->dbgname = kzalloc(16, GFP_KERNEL);
> if (!vinst->dbgname)
> @@ -166,16 +146,7 @@ void vas_instance_init_dbgdir(struct vas_instance *vinst)
> snprintf(vinst->dbgname, 16, "v%d", vinst->vas_id);
>
> d = debugfs_create_dir(vinst->dbgname, vas_debugfs);
> - if (IS_ERR(d))
> - goto free_name;
> -
> vinst->dbgdir = d;
> - return;
> -
> -free_name:
> - kfree(vinst->dbgname);
> - vinst->dbgname = NULL;
> - vinst->dbgdir = NULL;
> }
>
> /*
> @@ -191,6 +162,4 @@ void vas_init_dbgdir(void)
>
> first_time = false;
> vas_debugfs = debugfs_create_dir("vas", NULL);
> - if (IS_ERR(vas_debugfs))
> - vas_debugfs = NULL;
> }
> --
> 2.25.0
>
^ permalink raw reply
* Re: [PATCH v2] libnvdimm: Update persistence domain value for of_pmem and papr_scm device
From: Aneesh Kumar K.V @ 2020-02-10 14:20 UTC (permalink / raw)
To: Dan Williams; +Cc: linuxppc-dev, linux-nvdimm
In-Reply-To: <CAPcyv4hBAk-dwO4=AT7cQm5YUwCBg0AECsZsiCjRJ_ZGWvWUAw@mail.gmail.com>
Dan Williams <dan.j.williams@intel.com> writes:
> On Tue, Feb 4, 2020 at 9:21 PM Aneesh Kumar K.V
> <aneesh.kumar@linux.ibm.com> wrote:
>>
>> Currently, kernel shows the below values
>> "persistence_domain":"cpu_cache"
>> "persistence_domain":"memory_controller"
>> "persistence_domain":"unknown"
>>
>> "cpu_cache" indicates no extra instructions is needed to ensure the persistence
>> of data in the pmem media on power failure.
>>
>> "memory_controller" indicates platform provided instructions need to be issued
>
> No, it does not. The only requirement implied by "memory_controller"
> is global visibility outside the cpu cache. If there are special
> instructions beyond that then it isn't persistent memory, at least not
> pmem that is safe for dax. virtio-pmem is an example of pmem-like
> memory that is not enabled for userspace flushing (MAP_SYNC disabled).
>
Can you explain this more? The way I was expecting the application to
interpret the value was, a regular store instruction doesn't guarantee
persistence if you find the "memory_controller" value for
persistence_domain. Instead, we need to make sure we flush data to the
controller at which point the platform will take care of the persistence in
case of power loss. How we flush data to the controller will also be
defined by the platform.
>> as per documented sequence to make sure data get flushed so that it is
>> guaranteed to be on pmem media in case of system power loss.
>>
>> Based on the above use memory_controller for non volatile regions on ppc64.
>>
>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
>> ---
>> arch/powerpc/platforms/pseries/papr_scm.c | 7 ++++++-
>> drivers/nvdimm/of_pmem.c | 4 +++-
>> include/linux/libnvdimm.h | 1 -
>> 3 files changed, 9 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c
>> index 7525635a8536..ffcd0d7a867c 100644
>> --- a/arch/powerpc/platforms/pseries/papr_scm.c
>> +++ b/arch/powerpc/platforms/pseries/papr_scm.c
>> @@ -359,8 +359,13 @@ static int papr_scm_nvdimm_init(struct papr_scm_priv *p)
>>
>> if (p->is_volatile)
>> p->region = nvdimm_volatile_region_create(p->bus, &ndr_desc);
>> - else
>> + else {
>> + /*
>> + * We need to flush things correctly to guarantee persistance
>> + */
>
> There are never guarantees. If you're going to comment what does
> software need to flush, and how?
Can you explain why you say there are never guarantees? If you follow the platform
recommended instruction sequence to flush data, we can be sure of data
persistence in the pmem media.
>
>> + set_bit(ND_REGION_PERSIST_MEMCTRL, &ndr_desc.flags);
>> p->region = nvdimm_pmem_region_create(p->bus, &ndr_desc);
>> + }
>> if (!p->region) {
>> dev_err(dev, "Error registering region %pR from %pOF\n",
>> ndr_desc.res, p->dn);
>> diff --git a/drivers/nvdimm/of_pmem.c b/drivers/nvdimm/of_pmem.c
>> index 8224d1431ea9..6826a274a1f1 100644
>> --- a/drivers/nvdimm/of_pmem.c
>> +++ b/drivers/nvdimm/of_pmem.c
>> @@ -62,8 +62,10 @@ static int of_pmem_region_probe(struct platform_device *pdev)
>>
>> if (is_volatile)
>> region = nvdimm_volatile_region_create(bus, &ndr_desc);
>> - else
>> + else {
>> + set_bit(ND_REGION_PERSIST_MEMCTRL, &ndr_desc.flags);
>> region = nvdimm_pmem_region_create(bus, &ndr_desc);
>> + }
>>
>> if (!region)
>> dev_warn(&pdev->dev, "Unable to register region %pR from %pOF\n",
>> diff --git a/include/linux/libnvdimm.h b/include/linux/libnvdimm.h
>> index 0f366706b0aa..771d888a5ed7 100644
>> --- a/include/linux/libnvdimm.h
>> +++ b/include/linux/libnvdimm.h
>> @@ -54,7 +54,6 @@ enum {
>> /*
>> * Platform provides mechanisms to automatically flush outstanding
>> * write data from memory controler to pmem on system power loss.
>> - * (ADR)
>
> I'd rather not delete critical terminology for a developer / platform
> owner to be able to consult documentation, or their vendor. Can you
> instead add the PowerPC equivalent term for this capability? I.e. list
> (x86: ADR PowerPC: foo ...).
Power ISA doesn't clearly call out what mechanism will be used to ensure
that a load following power loss will return the previously flushed
data. Hence there is no description of details like Asynchronous DRAM
Refresh. Only details specified is with respect to flush sequence that ensures
that a load following power loss will return the value stored.
-aneesh
^ permalink raw reply
* [powerpc:merge] BUILD SUCCESS a5bc6e124219546a81ce334dc9b16483d55e9abf
From: kbuild test robot @ 2020-02-10 13:42 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge
branch HEAD: a5bc6e124219546a81ce334dc9b16483d55e9abf Automatic merge of branches 'master', 'next' and 'fixes' into merge
elapsed time: 2918m
configs tested: 177
configs skipped: 0
The following configs have been built successfully.
More configs may be tested in the coming days.
arm allmodconfig
arm allnoconfig
arm allyesconfig
arm at91_dt_defconfig
arm efm32_defconfig
arm exynos_defconfig
arm multi_v5_defconfig
arm multi_v7_defconfig
arm shmobile_defconfig
arm sunxi_defconfig
arm64 allmodconfig
arm64 allnoconfig
arm64 allyesconfig
arm64 defconfig
sparc allyesconfig
sh allmodconfig
riscv defconfig
arc defconfig
nds32 defconfig
um defconfig
xtensa common_defconfig
s390 debug_defconfig
sparc64 allnoconfig
um x86_64_defconfig
m68k m5475evb_defconfig
ia64 allmodconfig
ia64 allyesconfig
parisc b180_defconfig
i386 defconfig
sparc defconfig
sh rsk7269_defconfig
sparc64 allyesconfig
s390 allyesconfig
ia64 defconfig
powerpc ppc64_defconfig
nios2 3c120_defconfig
sh titan_defconfig
sparc64 allmodconfig
parisc allyesconfig
riscv allmodconfig
mips fuloong2e_defconfig
microblaze nommu_defconfig
m68k multi_defconfig
riscv allnoconfig
parisc allnoconfig
c6x allyesconfig
s390 defconfig
i386 allnoconfig
i386 allyesconfig
i386 alldefconfig
ia64 alldefconfig
ia64 allnoconfig
c6x evmc6678_defconfig
nios2 10m50_defconfig
openrisc or1ksim_defconfig
openrisc simple_smp_defconfig
xtensa iss_defconfig
alpha defconfig
csky defconfig
nds32 allnoconfig
h8300 edosk2674_defconfig
h8300 h8300h-sim_defconfig
h8300 h8s-sim_defconfig
m68k allmodconfig
m68k sun3_defconfig
arc allyesconfig
microblaze mmu_defconfig
powerpc allnoconfig
powerpc defconfig
powerpc rhel-kconfig
mips 32r2_defconfig
mips 64r6el_defconfig
mips allmodconfig
mips allnoconfig
mips allyesconfig
mips malta_kvm_defconfig
parisc c3000_defconfig
parisc defconfig
x86_64 randconfig-a001-20200210
x86_64 randconfig-a002-20200210
x86_64 randconfig-a003-20200210
i386 randconfig-a001-20200210
i386 randconfig-a002-20200210
i386 randconfig-a003-20200210
alpha randconfig-a001-20200208
parisc randconfig-a001-20200208
m68k randconfig-a001-20200208
nds32 randconfig-a001-20200208
mips randconfig-a001-20200208
riscv randconfig-a001-20200208
c6x randconfig-a001-20200210
h8300 randconfig-a001-20200210
microblaze randconfig-a001-20200210
nios2 randconfig-a001-20200210
sparc64 randconfig-a001-20200210
h8300 randconfig-a001-20200208
nios2 randconfig-a001-20200208
microblaze randconfig-a001-20200208
sparc64 randconfig-a001-20200208
c6x randconfig-a001-20200208
x86_64 randconfig-b001-20200210
x86_64 randconfig-b002-20200210
x86_64 randconfig-b003-20200210
i386 randconfig-b001-20200210
i386 randconfig-b002-20200210
i386 randconfig-b003-20200210
x86_64 randconfig-c001-20200210
x86_64 randconfig-c002-20200210
x86_64 randconfig-c003-20200210
i386 randconfig-c001-20200210
i386 randconfig-c002-20200210
i386 randconfig-c003-20200210
x86_64 randconfig-c001-20200209
x86_64 randconfig-c002-20200209
x86_64 randconfig-c003-20200209
i386 randconfig-c001-20200209
i386 randconfig-c002-20200209
i386 randconfig-c003-20200209
x86_64 randconfig-d001-20200210
x86_64 randconfig-d002-20200210
x86_64 randconfig-d003-20200210
i386 randconfig-d001-20200210
i386 randconfig-d002-20200210
i386 randconfig-d003-20200210
x86_64 randconfig-e001-20200210
x86_64 randconfig-e002-20200210
x86_64 randconfig-e003-20200210
i386 randconfig-e001-20200210
i386 randconfig-e002-20200210
i386 randconfig-e003-20200210
x86_64 randconfig-f001-20200210
x86_64 randconfig-f002-20200210
x86_64 randconfig-f003-20200210
i386 randconfig-f001-20200210
i386 randconfig-f002-20200210
i386 randconfig-f003-20200210
i386 randconfig-f002-20200208
i386 randconfig-f003-20200208
x86_64 randconfig-f002-20200208
i386 randconfig-f001-20200208
x86_64 randconfig-f001-20200208
x86_64 randconfig-f003-20200208
x86_64 randconfig-g001-20200210
x86_64 randconfig-g002-20200210
x86_64 randconfig-g003-20200210
i386 randconfig-g001-20200210
i386 randconfig-g002-20200210
i386 randconfig-g003-20200210
x86_64 randconfig-h001-20200210
x86_64 randconfig-h002-20200210
x86_64 randconfig-h003-20200210
i386 randconfig-h001-20200210
i386 randconfig-h002-20200210
i386 randconfig-h003-20200210
arc randconfig-a001-20200209
arm randconfig-a001-20200209
arm64 randconfig-a001-20200209
ia64 randconfig-a001-20200209
powerpc randconfig-a001-20200209
sparc randconfig-a001-20200209
riscv allyesconfig
riscv nommu_virt_defconfig
riscv rv32_defconfig
s390 alldefconfig
s390 allmodconfig
s390 allnoconfig
s390 zfcpdump_defconfig
sh sh7785lcr_32bit_defconfig
sh allnoconfig
sparc64 defconfig
um i386_defconfig
x86_64 fedora-25
x86_64 kexec
x86_64 lkp
x86_64 rhel
x86_64 rhel-7.2-clear
x86_64 rhel-7.6
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH V13] mm/debug: Add tests validating architecture page table helpers
From: Russell King - ARM Linux admin @ 2020-02-10 11:06 UTC (permalink / raw)
To: Christophe Leroy
Cc: Mark Rutland, uclinux-h8-devel, linux-m68k, linux-ia64, linux-sh,
Peter Zijlstra, James Hogan, Tetsuo Handa, Heiko Carstens,
Michal Hocko, linux-mm, Paul Mackerras, sparclinux, linux-hexagon,
linux-riscv, Thomas Gleixner, linux-s390, kbuild test robot,
Yoshinori Sato, Max Filippov, x86, Matthew Wilcox, Steven Price,
Jason Gunthorpe, Geert Uytterhoeven, Gerald Schaefer, Mark Salter,
Matt Turner, linux-snps-arc, Ingo Molnar, linux-xtensa, Kees Cook,
Anshuman Khandual, Masahiro Yamada, linux-alpha,
Aurelien Jacquiot, linux-c6x-dev, Mark Brown, Ivan Kokshaysky,
Paul Walmsley, Kirill A . Shutemov, Dan Williams, Guan Xuetao,
Vlastimil Babka, Richard Henderson, linux-arm-kernel,
Chris Zankel, Michal Simek, kbuild-all, Brian Cain,
Ard Biesheuvel, Greg Kroah-Hartman, Dave Hansen, linux-mips,
Ralf Baechle, linux-kernel, Paul Burton, Mike Rapoport,
Palmer Dabbelt, Vineet Gupta, Martin Schwidefsky, Qian Cai,
Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <7cb3a5bb-eaea-a01c-4047-e3c000b7ad1d@c-s.fr>
On Mon, Feb 10, 2020 at 11:46:23AM +0100, Christophe Leroy wrote:
>
>
> Le 10/02/2020 à 11:02, Russell King - ARM Linux admin a écrit :
> > On Mon, Feb 10, 2020 at 07:38:38AM +0100, Christophe Leroy wrote:
> > >
> > >
> > > Le 10/02/2020 à 06:35, Anshuman Khandual a écrit :
> > > >
> > > >
> > > > On 02/10/2020 10:22 AM, Andrew Morton wrote:
> > > > > On Thu, 6 Feb 2020 13:49:35 +0530 Anshuman Khandual <anshuman.khandual@arm.com> wrote:
> > > > >
> > > > > >
> > > > > > On 02/06/2020 04:40 AM, kbuild test robot wrote:
> > > > > > > Hi Anshuman,
> > > > > > >
> > > > > > > Thank you for the patch! Yet something to improve:
> > > > > > >
> > > > > > > [auto build test ERROR on powerpc/next]
> > > > > > > [also build test ERROR on s390/features linus/master arc/for-next v5.5]
> > > > > > > [cannot apply to mmotm/master tip/x86/core arm64/for-next/core next-20200205]
> > > > > > > [if your patch is applied to the wrong git tree, please drop us a note to help
> > > > > > > improve the system. BTW, we also suggest to use '--base' option to specify the
> > > > > > > base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
> > > > > > >
> > > > > > > url: https://github.com/0day-ci/linux/commits/Anshuman-Khandual/mm-debug-Add-tests-validating-architecture-page-table-helpers/20200205-215507
> > > > > > > base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
> > > > > > > config: ia64-allmodconfig (attached as .config)
> > > > > > > compiler: ia64-linux-gcc (GCC) 7.5.0
> > > > > > > reproduce:
> > > > > > > wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> > > > > > > chmod +x ~/bin/make.cross
> > > > > > > # save the attached .config to linux build tree
> > > > > > > GCC_VERSION=7.5.0 make.cross ARCH=ia64
> > > > > > >
> > > > > > > If you fix the issue, kindly add following tag
> > > > > > > Reported-by: kbuild test robot <lkp@intel.com>
> > > > > > >
> > > > > > > All error/warnings (new ones prefixed by >>):
> > > > > > >
> > > > > > > In file included from include/asm-generic/pgtable-nopud.h:8:0,
> > > > > > > from arch/ia64/include/asm/pgtable.h:586,
> > > > > > > from include/linux/mm.h:99,
> > > > > > > from include/linux/highmem.h:8,
> > > > > > > from mm/debug_vm_pgtable.c:14:
> > > > > > > mm/debug_vm_pgtable.c: In function 'pud_clear_tests':
> > > > > > > > > include/asm-generic/pgtable-nop4d-hack.h:47:32: error: implicit declaration of function '__pgd'; did you mean '__p4d'? [-Werror=implicit-function-declaration]
> > > > > > > #define __pud(x) ((pud_t) { __pgd(x) })
> > > > > > > ^
> > > > > > > > > mm/debug_vm_pgtable.c:141:8: note: in expansion of macro '__pud'
> > > > > > > pud = __pud(pud_val(pud) | RANDOM_ORVALUE);
> > > > > > > ^~~~~
> > > > > > > > > include/asm-generic/pgtable-nop4d-hack.h:47:22: warning: missing braces around initializer [-Wmissing-braces]
> > > > > > > #define __pud(x) ((pud_t) { __pgd(x) })
> > > > > > > ^
> > > > > > > > > mm/debug_vm_pgtable.c:141:8: note: in expansion of macro '__pud'
> > > > > > > pud = __pud(pud_val(pud) | RANDOM_ORVALUE);
> > > > > > > ^~~~~
> > > > > > > cc1: some warnings being treated as errors
> > > > > >
> > > > > > This build failure is expected now given that we have allowed DEBUG_VM_PGTABLE
> > > > > > with EXPERT without platform requiring ARCH_HAS_DEBUG_VM_PGTABLE. This problem
> > > > > > i.e build failure caused without a platform __pgd(), is known to exist both on
> > > > > > ia64 and arm (32bit) platforms. Please refer https://lkml.org/lkml/2019/9/24/314
> > > > > > for details where this was discussed earlier.
> > > > > >
> > > > >
> > > > > I'd prefer not to merge a patch which is known to cause build
> > > > > regressions. Is there some temporary thing we can do to prevent these
> > > > > errors until arch maintainers(?) get around to implementing the
> > > > > long-term fixes?
> > > >
> > > > We could explicitly disable CONFIG_DEBUG_VM_PGTABLE on ia64 and arm platforms
> > > > which will ensure that others can still use the EXPERT path.
> > > >
> > > > config DEBUG_VM_PGTABLE
> > > > bool "Debug arch page table for semantics compliance"
> > > > depends on MMU
> > > > depends on !(IA64 || ARM)
> > > > depends on ARCH_HAS_DEBUG_VM_PGTABLE || EXPERT
> > > > default n if !ARCH_HAS_DEBUG_VM_PGTABLE
> > > > default y if DEBUG_VM
> > > >
> > >
> > > On both ia32 and arm, the fix is trivial.
> > >
> > > Can we include the fix within this patch, just the same way as the
> > > mm_p4d_folded() fix for x86 ?
> >
> > Why should arm include a macro for something that nothing (apart from
> > this checker) requires? If the checker requires it but the rest of
> > the kernel does not, it suggests that the checker isn't actually
> > correct, and the results can't be relied upon.
> >
>
> As far as I can see, the problem is that arm opencodes part of the API
> instead of including asm-generic/pgtable-nopmd.h
>
> Here, the ARM has 2 levels, ie only PGD and PTE. But instead of defining
> __pgd and __pte and getting everything else from asm-generic, it defines a
> __pmd then redefines the folded levels like the pud, etc ...
>
> That's exactly what the checker aims at detecting: architectures than do not
> properly use the standard linux page table structures.
There are good reasons for the way ARM does stuff. The generic crap was
written without regard for the circumstances that ARM has, and thus is
entirely unsuitable for 32-bit ARM.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* Re: [PATCH] powerpc/vdso32: mark __kernel_datapage_offset as STV_PROTECTED
From: Michael Ellerman @ 2020-02-10 11:01 UTC (permalink / raw)
To: Fangrui Song, Benjamin Herrenschmidt, Paul Mackerras,
Christophe Leroy
Cc: clang-built-linux, linuxppc-dev, linux-kernel, Fangrui Song
In-Reply-To: <20200205005054.k72fuikf6rwrgfe4@google.com>
Fangrui Song <maskray@google.com> writes:
> A PC-relative relocation (R_PPC_REL16_LO in this case) referencing a
> preemptible symbol in a -shared link is not allowed. GNU ld's powerpc
> port is permissive and allows it [1], but lld will report an error after
> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?id=ec0895f08f99515194e9fcfe1338becf6f759d38
>
> Make the symbol protected so that it is non-preemptible but still
> exported.
"preemptible" means something different to me, and I assume we're not
using it to mean the same thing.
Can you explain it using small words that a kernel developer can
understand? :)
cheers
> [1]: https://sourceware.org/bugzilla/show_bug.cgi?id=25500
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/851
> Signed-off-by: Fangrui Song <maskray@google.com>
> ---
> arch/powerpc/kernel/vdso32/datapage.S | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kernel/vdso32/datapage.S b/arch/powerpc/kernel/vdso32/datapage.S
> index 217bb630f8f9..2831a8676365 100644
> --- a/arch/powerpc/kernel/vdso32/datapage.S
> +++ b/arch/powerpc/kernel/vdso32/datapage.S
> @@ -13,7 +13,8 @@
> #include <asm/vdso_datapage.h>
>
> .text
> - .global __kernel_datapage_offset;
> + .global __kernel_datapage_offset
> + .protected __kernel_datapage_offset
> __kernel_datapage_offset:
> .long 0
>
> --
> 2.25.0.341.g760bfbb309-goog
^ permalink raw reply
* Re: [PATCH V13] mm/debug: Add tests validating architecture page table helpers
From: Christophe Leroy @ 2020-02-10 10:46 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Mark Rutland, uclinux-h8-devel, linux-m68k, linux-ia64, linux-sh,
Peter Zijlstra, James Hogan, Tetsuo Handa, Heiko Carstens,
Michal Hocko, linux-mm, Paul Mackerras, sparclinux, linux-hexagon,
linux-riscv, Thomas Gleixner, linux-s390, kbuild test robot,
Yoshinori Sato, Max Filippov, x86, Matthew Wilcox, Steven Price,
Jason Gunthorpe, Geert Uytterhoeven, Gerald Schaefer, Mark Salter,
Matt Turner, linux-snps-arc, Ingo Molnar, linux-xtensa, Kees Cook,
Anshuman Khandual, Masahiro Yamada, linux-alpha,
Aurelien Jacquiot, linux-c6x-dev, Mark Brown, Ivan Kokshaysky,
Paul Walmsley, Kirill A . Shutemov, Dan Williams, Guan Xuetao,
Vlastimil Babka, Richard Henderson, linux-arm-kernel,
Chris Zankel, Michal Simek, kbuild-all, Brian Cain,
Ard Biesheuvel, Greg Kroah-Hartman, Dave Hansen, linux-mips,
Ralf Baechle, linux-kernel, Paul Burton, Mike Rapoport,
Palmer Dabbelt, Vineet Gupta, Martin Schwidefsky, Qian Cai,
Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <20200210100200.GB25745@shell.armlinux.org.uk>
Le 10/02/2020 à 11:02, Russell King - ARM Linux admin a écrit :
> On Mon, Feb 10, 2020 at 07:38:38AM +0100, Christophe Leroy wrote:
>>
>>
>> Le 10/02/2020 à 06:35, Anshuman Khandual a écrit :
>>>
>>>
>>> On 02/10/2020 10:22 AM, Andrew Morton wrote:
>>>> On Thu, 6 Feb 2020 13:49:35 +0530 Anshuman Khandual <anshuman.khandual@arm.com> wrote:
>>>>
>>>>>
>>>>> On 02/06/2020 04:40 AM, kbuild test robot wrote:
>>>>>> Hi Anshuman,
>>>>>>
>>>>>> Thank you for the patch! Yet something to improve:
>>>>>>
>>>>>> [auto build test ERROR on powerpc/next]
>>>>>> [also build test ERROR on s390/features linus/master arc/for-next v5.5]
>>>>>> [cannot apply to mmotm/master tip/x86/core arm64/for-next/core next-20200205]
>>>>>> [if your patch is applied to the wrong git tree, please drop us a note to help
>>>>>> improve the system. BTW, we also suggest to use '--base' option to specify the
>>>>>> base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
>>>>>>
>>>>>> url: https://github.com/0day-ci/linux/commits/Anshuman-Khandual/mm-debug-Add-tests-validating-architecture-page-table-helpers/20200205-215507
>>>>>> base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
>>>>>> config: ia64-allmodconfig (attached as .config)
>>>>>> compiler: ia64-linux-gcc (GCC) 7.5.0
>>>>>> reproduce:
>>>>>> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>>>>>> chmod +x ~/bin/make.cross
>>>>>> # save the attached .config to linux build tree
>>>>>> GCC_VERSION=7.5.0 make.cross ARCH=ia64
>>>>>>
>>>>>> If you fix the issue, kindly add following tag
>>>>>> Reported-by: kbuild test robot <lkp@intel.com>
>>>>>>
>>>>>> All error/warnings (new ones prefixed by >>):
>>>>>>
>>>>>> In file included from include/asm-generic/pgtable-nopud.h:8:0,
>>>>>> from arch/ia64/include/asm/pgtable.h:586,
>>>>>> from include/linux/mm.h:99,
>>>>>> from include/linux/highmem.h:8,
>>>>>> from mm/debug_vm_pgtable.c:14:
>>>>>> mm/debug_vm_pgtable.c: In function 'pud_clear_tests':
>>>>>>>> include/asm-generic/pgtable-nop4d-hack.h:47:32: error: implicit declaration of function '__pgd'; did you mean '__p4d'? [-Werror=implicit-function-declaration]
>>>>>> #define __pud(x) ((pud_t) { __pgd(x) })
>>>>>> ^
>>>>>>>> mm/debug_vm_pgtable.c:141:8: note: in expansion of macro '__pud'
>>>>>> pud = __pud(pud_val(pud) | RANDOM_ORVALUE);
>>>>>> ^~~~~
>>>>>>>> include/asm-generic/pgtable-nop4d-hack.h:47:22: warning: missing braces around initializer [-Wmissing-braces]
>>>>>> #define __pud(x) ((pud_t) { __pgd(x) })
>>>>>> ^
>>>>>>>> mm/debug_vm_pgtable.c:141:8: note: in expansion of macro '__pud'
>>>>>> pud = __pud(pud_val(pud) | RANDOM_ORVALUE);
>>>>>> ^~~~~
>>>>>> cc1: some warnings being treated as errors
>>>>>
>>>>> This build failure is expected now given that we have allowed DEBUG_VM_PGTABLE
>>>>> with EXPERT without platform requiring ARCH_HAS_DEBUG_VM_PGTABLE. This problem
>>>>> i.e build failure caused without a platform __pgd(), is known to exist both on
>>>>> ia64 and arm (32bit) platforms. Please refer https://lkml.org/lkml/2019/9/24/314
>>>>> for details where this was discussed earlier.
>>>>>
>>>>
>>>> I'd prefer not to merge a patch which is known to cause build
>>>> regressions. Is there some temporary thing we can do to prevent these
>>>> errors until arch maintainers(?) get around to implementing the
>>>> long-term fixes?
>>>
>>> We could explicitly disable CONFIG_DEBUG_VM_PGTABLE on ia64 and arm platforms
>>> which will ensure that others can still use the EXPERT path.
>>>
>>> config DEBUG_VM_PGTABLE
>>> bool "Debug arch page table for semantics compliance"
>>> depends on MMU
>>> depends on !(IA64 || ARM)
>>> depends on ARCH_HAS_DEBUG_VM_PGTABLE || EXPERT
>>> default n if !ARCH_HAS_DEBUG_VM_PGTABLE
>>> default y if DEBUG_VM
>>>
>>
>> On both ia32 and arm, the fix is trivial.
>>
>> Can we include the fix within this patch, just the same way as the
>> mm_p4d_folded() fix for x86 ?
>
> Why should arm include a macro for something that nothing (apart from
> this checker) requires? If the checker requires it but the rest of
> the kernel does not, it suggests that the checker isn't actually
> correct, and the results can't be relied upon.
>
As far as I can see, the problem is that arm opencodes part of the API
instead of including asm-generic/pgtable-nopmd.h
Here, the ARM has 2 levels, ie only PGD and PTE. But instead of defining
__pgd and __pte and getting everything else from asm-generic, it defines
a __pmd then redefines the folded levels like the pud, etc ...
That's exactly what the checker aims at detecting: architectures than do
not properly use the standard linux page table structures.
Christophe
^ permalink raw reply
* Re: [PATCH V13] mm/debug: Add tests validating architecture page table helpers
From: Russell King - ARM Linux admin @ 2020-02-10 10:02 UTC (permalink / raw)
To: Christophe Leroy
Cc: Mark Rutland, uclinux-h8-devel, linux-m68k, linux-ia64, linux-sh,
Peter Zijlstra, James Hogan, Tetsuo Handa, Heiko Carstens,
Michal Hocko, linux-mm, Paul Mackerras, sparclinux, linux-hexagon,
linux-riscv, Thomas Gleixner, linux-s390, kbuild test robot,
Yoshinori Sato, Max Filippov, x86, Matthew Wilcox, Steven Price,
Jason Gunthorpe, Geert Uytterhoeven, Gerald Schaefer, Mark Salter,
Matt Turner, linux-snps-arc, Ingo Molnar, linux-xtensa, Kees Cook,
Anshuman Khandual, Masahiro Yamada, linux-alpha,
Aurelien Jacquiot, linux-c6x-dev, Mark Brown, Ivan Kokshaysky,
Paul Walmsley, Kirill A . Shutemov, Dan Williams, Guan Xuetao,
Vlastimil Babka, Richard Henderson, linux-arm-kernel,
Chris Zankel, Michal Simek, kbuild-all, Brian Cain,
Ard Biesheuvel, Greg Kroah-Hartman, Dave Hansen, linux-mips,
Ralf Baechle, linux-kernel, Paul Burton, Mike Rapoport,
Palmer Dabbelt, Vineet Gupta, Martin Schwidefsky, Qian Cai,
Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <aef1048f-68c4-d14f-e669-8f288ba9ac7a@c-s.fr>
On Mon, Feb 10, 2020 at 07:38:38AM +0100, Christophe Leroy wrote:
>
>
> Le 10/02/2020 à 06:35, Anshuman Khandual a écrit :
> >
> >
> > On 02/10/2020 10:22 AM, Andrew Morton wrote:
> > > On Thu, 6 Feb 2020 13:49:35 +0530 Anshuman Khandual <anshuman.khandual@arm.com> wrote:
> > >
> > > >
> > > > On 02/06/2020 04:40 AM, kbuild test robot wrote:
> > > > > Hi Anshuman,
> > > > >
> > > > > Thank you for the patch! Yet something to improve:
> > > > >
> > > > > [auto build test ERROR on powerpc/next]
> > > > > [also build test ERROR on s390/features linus/master arc/for-next v5.5]
> > > > > [cannot apply to mmotm/master tip/x86/core arm64/for-next/core next-20200205]
> > > > > [if your patch is applied to the wrong git tree, please drop us a note to help
> > > > > improve the system. BTW, we also suggest to use '--base' option to specify the
> > > > > base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
> > > > >
> > > > > url: https://github.com/0day-ci/linux/commits/Anshuman-Khandual/mm-debug-Add-tests-validating-architecture-page-table-helpers/20200205-215507
> > > > > base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
> > > > > config: ia64-allmodconfig (attached as .config)
> > > > > compiler: ia64-linux-gcc (GCC) 7.5.0
> > > > > reproduce:
> > > > > wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> > > > > chmod +x ~/bin/make.cross
> > > > > # save the attached .config to linux build tree
> > > > > GCC_VERSION=7.5.0 make.cross ARCH=ia64
> > > > >
> > > > > If you fix the issue, kindly add following tag
> > > > > Reported-by: kbuild test robot <lkp@intel.com>
> > > > >
> > > > > All error/warnings (new ones prefixed by >>):
> > > > >
> > > > > In file included from include/asm-generic/pgtable-nopud.h:8:0,
> > > > > from arch/ia64/include/asm/pgtable.h:586,
> > > > > from include/linux/mm.h:99,
> > > > > from include/linux/highmem.h:8,
> > > > > from mm/debug_vm_pgtable.c:14:
> > > > > mm/debug_vm_pgtable.c: In function 'pud_clear_tests':
> > > > > > > include/asm-generic/pgtable-nop4d-hack.h:47:32: error: implicit declaration of function '__pgd'; did you mean '__p4d'? [-Werror=implicit-function-declaration]
> > > > > #define __pud(x) ((pud_t) { __pgd(x) })
> > > > > ^
> > > > > > > mm/debug_vm_pgtable.c:141:8: note: in expansion of macro '__pud'
> > > > > pud = __pud(pud_val(pud) | RANDOM_ORVALUE);
> > > > > ^~~~~
> > > > > > > include/asm-generic/pgtable-nop4d-hack.h:47:22: warning: missing braces around initializer [-Wmissing-braces]
> > > > > #define __pud(x) ((pud_t) { __pgd(x) })
> > > > > ^
> > > > > > > mm/debug_vm_pgtable.c:141:8: note: in expansion of macro '__pud'
> > > > > pud = __pud(pud_val(pud) | RANDOM_ORVALUE);
> > > > > ^~~~~
> > > > > cc1: some warnings being treated as errors
> > > >
> > > > This build failure is expected now given that we have allowed DEBUG_VM_PGTABLE
> > > > with EXPERT without platform requiring ARCH_HAS_DEBUG_VM_PGTABLE. This problem
> > > > i.e build failure caused without a platform __pgd(), is known to exist both on
> > > > ia64 and arm (32bit) platforms. Please refer https://lkml.org/lkml/2019/9/24/314
> > > > for details where this was discussed earlier.
> > > >
> > >
> > > I'd prefer not to merge a patch which is known to cause build
> > > regressions. Is there some temporary thing we can do to prevent these
> > > errors until arch maintainers(?) get around to implementing the
> > > long-term fixes?
> >
> > We could explicitly disable CONFIG_DEBUG_VM_PGTABLE on ia64 and arm platforms
> > which will ensure that others can still use the EXPERT path.
> >
> > config DEBUG_VM_PGTABLE
> > bool "Debug arch page table for semantics compliance"
> > depends on MMU
> > depends on !(IA64 || ARM)
> > depends on ARCH_HAS_DEBUG_VM_PGTABLE || EXPERT
> > default n if !ARCH_HAS_DEBUG_VM_PGTABLE
> > default y if DEBUG_VM
> >
>
> On both ia32 and arm, the fix is trivial.
>
> Can we include the fix within this patch, just the same way as the
> mm_p4d_folded() fix for x86 ?
Why should arm include a macro for something that nothing (apart from
this checker) requires? If the checker requires it but the rest of
the kernel does not, it suggests that the checker isn't actually
correct, and the results can't be relied upon.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* Re: [RESEND][PATCH] selftests/vm: Fix vm tests build and run
From: Michael Ellerman @ 2020-02-10 9:50 UTC (permalink / raw)
To: Harish, linuxppc-dev; +Cc: Harish
In-Reply-To: <20200210073521.14117-1-harish@linux.ibm.com>
Harish <harish@linux.ibm.com> writes:
> A recent change overrides the ARCH env variable and hence runs
> using make fails with the following.
>
> $ make -C vm/
> make: Entering directory '/home/harish/linux/tools/testing/selftests/vm'
> make --no-builtin-rules ARCH=ppc64le -C ../../../.. headers_install
> make[1]: Entering directory '/home/harish/linux'
> Makefile:652: arch/ppc64le/Makefile: No such file or directory
> make[1]: *** No rule to make target 'arch/ppc64le/Makefile'. Stop.
> make[1]: Leaving directory '/home/harish/linux'
> make: *** [../lib.mk:50: khdr] Error 2
> make: Leaving directory '/home/harish/linux/tools/testing/selftests/vm'
>
> Patch fixes this issue and also handles ppc64/ppc64le archs to enable
> few tests
>
> Signed-off-by: Harish <harish@linux.ibm.com>
> ---
> tools/testing/selftests/vm/Makefile | 4 ++--
> tools/testing/selftests/vm/run_vmtests | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
I don't maintain the vm tests. You need to send the patch to the right
people.
But as Christophe points out I think Sandipan has already done that.
cheers
^ permalink raw reply
* Re: [PATCH V5 09/14] powerpc/vas: Update CSB and notify process for fault CRBs
From: Michael Neuling @ 2020-02-10 9:25 UTC (permalink / raw)
To: Haren Myneni; +Cc: herbert, npiggin, hch, oohall, sukadev, linuxppc-dev
In-Reply-To: <1581311569.18705.18.camel@hbabu-laptop>
> > > +
> > > + csb.cc = CSB_CC_TRANSLATION;
> > > + csb.ce = CSB_CE_TERMINATION;
> > > + csb.cs = 0;
> > > + csb.count = 0;
> > > +
> > > + /*
> > > + * Returns the fault address in CPU format since it is passed with
> > > + * signal. But if the user space expects BE format, need changes.
> > > + * i.e either kernel (here) or user should convert to CPU format.
> > > + * Not both!
> > > + */
> > > + csb.address = be64_to_cpu(crb->stamp.nx.fault_storage_addr);
> >
> > This looks wrong and I don't understand the comment. You need to convert
> > this
> > back to be64 to write it to csb.address. ie.
> >
> > csb.address = cpu_to_be64(be64_to_cpu(crb->stamp.nx.fault_storage_addr));
> >
> > Which I think you can just avoid the endian conversion all together.
>
> NX pastes fault CRB in big-endian, so passing this address in CPU format
> to user space, otherwise the library has to convert.
OK, then please change the definition in struct coprocessor_status_block to just
__u64.
struct coprocessor_status_block {
u8 flags;
u8 cs;
u8 cc;
u8 ce;
__be32 count;
__be64 address;
} __packed __aligned(CSB_ALIGN);
Big but....
I thought "struct coprocessor_status_block" was also written by hardware. If
that's the case then it needs to be __be64 and you need the kernel to synthesize
exactly what the hardware is doing. Hence the struct definition is correct and
the kernel needs to convert to _be64 on writing.
> What is the standard way for passing to user space?
CPU endian.
> > > + * process will be polling on csb.flags after request is sent to
> > > + * NX. So generally CSB update should not fail except when an
> > > + * application does not follow the process properly. So an error
> > > + * message will be displayed and leave it to user space whether
> > > + * to ignore or handle this signal.
> > > + */
> > > + rcu_read_lock();
> > > + rc = kill_pid_info(SIGSEGV, &info, pid);
> > > + rcu_read_unlock();
> >
> > why the rcu_read_un/lock() here?
>
> Used same as in kill_proc_info()/kill_something_info()
Please document.
Mikey
^ permalink raw reply
* Re: [RESEND][PATCH] selftests/vm: Fix vm tests build and run
From: Christophe Leroy @ 2020-02-10 8:05 UTC (permalink / raw)
To: Harish, linuxppc-dev, mpe
In-Reply-To: <20200210073521.14117-1-harish@linux.ibm.com>
Le 10/02/2020 à 08:35, Harish a écrit :
> A recent change overrides the ARCH env variable and hence runs
> using make fails with the following.
>
> $ make -C vm/
> make: Entering directory '/home/harish/linux/tools/testing/selftests/vm'
> make --no-builtin-rules ARCH=ppc64le -C ../../../.. headers_install
> make[1]: Entering directory '/home/harish/linux'
> Makefile:652: arch/ppc64le/Makefile: No such file or directory
> make[1]: *** No rule to make target 'arch/ppc64le/Makefile'. Stop.
> make[1]: Leaving directory '/home/harish/linux'
> make: *** [../lib.mk:50: khdr] Error 2
> make: Leaving directory '/home/harish/linux/tools/testing/selftests/vm'
>
> Patch fixes this issue and also handles ppc64/ppc64le archs to enable
> few tests
Isn't it the same as
https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=155975 ?
Christophe
>
> Signed-off-by: Harish <harish@linux.ibm.com>
> ---
> tools/testing/selftests/vm/Makefile | 4 ++--
> tools/testing/selftests/vm/run_vmtests | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/tools/testing/selftests/vm/Makefile b/tools/testing/selftests/vm/Makefile
> index 7f9a8a8c31da..49bb15be1447 100644
> --- a/tools/testing/selftests/vm/Makefile
> +++ b/tools/testing/selftests/vm/Makefile
> @@ -1,7 +1,7 @@
> # SPDX-License-Identifier: GPL-2.0
> # Makefile for vm selftests
> uname_M := $(shell uname -m 2>/dev/null || echo not)
> -ARCH ?= $(shell echo $(uname_M) | sed -e 's/aarch64.*/arm64/')
> +ARCH_USED ?= $(shell echo $(uname_M) | sed -e 's/aarch64.*/arm64/' -e 's/ppc64.*/ppc64/')
>
> CFLAGS = -Wall -I ../../../../usr/include $(EXTRA_CFLAGS)
> LDLIBS = -lrt
> @@ -19,7 +19,7 @@ TEST_GEN_FILES += thuge-gen
> TEST_GEN_FILES += transhuge-stress
> TEST_GEN_FILES += userfaultfd
>
> -ifneq (,$(filter $(ARCH),arm64 ia64 mips64 parisc64 ppc64 riscv64 s390x sh64 sparc64 x86_64))
> +ifneq (,$(filter $(ARCH_USED),arm64 ia64 mips64 parisc64 ppc64 riscv64 s390x sh64 sparc64 x86_64))
> TEST_GEN_FILES += va_128TBswitch
> TEST_GEN_FILES += virtual_address_range
> endif
> diff --git a/tools/testing/selftests/vm/run_vmtests b/tools/testing/selftests/vm/run_vmtests
> index a692ea828317..da63dfb9713a 100755
> --- a/tools/testing/selftests/vm/run_vmtests
> +++ b/tools/testing/selftests/vm/run_vmtests
> @@ -61,7 +61,7 @@ fi
> #filter 64bit architectures
> ARCH64STR="arm64 ia64 mips64 parisc64 ppc64 riscv64 s390x sh64 sparc64 x86_64"
> if [ -z $ARCH ]; then
> - ARCH=`uname -m 2>/dev/null | sed -e 's/aarch64.*/arm64/'`
> + ARCH=`uname -m 2>/dev/null | sed -e 's/aarch64.*/arm64/' -e 's/ppc64.*/ppc64/'`
> fi
> VADDR64=0
> echo "$ARCH64STR" | grep $ARCH && VADDR64=1
>
^ permalink raw reply
* [RESEND][PATCH] selftests/vm: Fix vm tests build and run
From: Harish @ 2020-02-10 7:35 UTC (permalink / raw)
To: linuxppc-dev, mpe; +Cc: Harish
A recent change overrides the ARCH env variable and hence runs
using make fails with the following.
$ make -C vm/
make: Entering directory '/home/harish/linux/tools/testing/selftests/vm'
make --no-builtin-rules ARCH=ppc64le -C ../../../.. headers_install
make[1]: Entering directory '/home/harish/linux'
Makefile:652: arch/ppc64le/Makefile: No such file or directory
make[1]: *** No rule to make target 'arch/ppc64le/Makefile'. Stop.
make[1]: Leaving directory '/home/harish/linux'
make: *** [../lib.mk:50: khdr] Error 2
make: Leaving directory '/home/harish/linux/tools/testing/selftests/vm'
Patch fixes this issue and also handles ppc64/ppc64le archs to enable
few tests
Signed-off-by: Harish <harish@linux.ibm.com>
---
tools/testing/selftests/vm/Makefile | 4 ++--
tools/testing/selftests/vm/run_vmtests | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/testing/selftests/vm/Makefile b/tools/testing/selftests/vm/Makefile
index 7f9a8a8c31da..49bb15be1447 100644
--- a/tools/testing/selftests/vm/Makefile
+++ b/tools/testing/selftests/vm/Makefile
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
# Makefile for vm selftests
uname_M := $(shell uname -m 2>/dev/null || echo not)
-ARCH ?= $(shell echo $(uname_M) | sed -e 's/aarch64.*/arm64/')
+ARCH_USED ?= $(shell echo $(uname_M) | sed -e 's/aarch64.*/arm64/' -e 's/ppc64.*/ppc64/')
CFLAGS = -Wall -I ../../../../usr/include $(EXTRA_CFLAGS)
LDLIBS = -lrt
@@ -19,7 +19,7 @@ TEST_GEN_FILES += thuge-gen
TEST_GEN_FILES += transhuge-stress
TEST_GEN_FILES += userfaultfd
-ifneq (,$(filter $(ARCH),arm64 ia64 mips64 parisc64 ppc64 riscv64 s390x sh64 sparc64 x86_64))
+ifneq (,$(filter $(ARCH_USED),arm64 ia64 mips64 parisc64 ppc64 riscv64 s390x sh64 sparc64 x86_64))
TEST_GEN_FILES += va_128TBswitch
TEST_GEN_FILES += virtual_address_range
endif
diff --git a/tools/testing/selftests/vm/run_vmtests b/tools/testing/selftests/vm/run_vmtests
index a692ea828317..da63dfb9713a 100755
--- a/tools/testing/selftests/vm/run_vmtests
+++ b/tools/testing/selftests/vm/run_vmtests
@@ -61,7 +61,7 @@ fi
#filter 64bit architectures
ARCH64STR="arm64 ia64 mips64 parisc64 ppc64 riscv64 s390x sh64 sparc64 x86_64"
if [ -z $ARCH ]; then
- ARCH=`uname -m 2>/dev/null | sed -e 's/aarch64.*/arm64/'`
+ ARCH=`uname -m 2>/dev/null | sed -e 's/aarch64.*/arm64/' -e 's/ppc64.*/ppc64/'`
fi
VADDR64=0
echo "$ARCH64STR" | grep $ARCH && VADDR64=1
--
2.21.0
^ permalink raw reply related
* Re: [PATCH V13] mm/debug: Add tests validating architecture page table helpers
From: Christophe Leroy @ 2020-02-10 6:38 UTC (permalink / raw)
To: Anshuman Khandual, Andrew Morton
Cc: Mark Rutland, uclinux-h8-devel, linux-m68k, linux-ia64, linux-sh,
Peter Zijlstra, James Hogan, Tetsuo Handa, Heiko Carstens,
Michal Hocko, linux-mm, Dave Hansen, Paul Mackerras, sparclinux,
linux-hexagon, linux-riscv, Dan Williams, linux-s390,
kbuild test robot, Yoshinori Sato, Max Filippov, x86,
Russell King - ARM Linux, Matthew Wilcox, Steven Price,
Jason Gunthorpe, Geert Uytterhoeven, Gerald Schaefer, Mark Salter,
Matt Turner, linux-snps-arc, Ingo Molnar, linux-xtensa, Kees Cook,
Masahiro Yamada, linux-alpha, Aurelien Jacquiot, linux-c6x-dev,
Mark Brown, Ivan Kokshaysky, Paul Walmsley, Kirill A . Shutemov,
Thomas Gleixner, Guan Xuetao, Vlastimil Babka, Richard Henderson,
linux-arm-kernel, Chris Zankel, Michal Simek, kbuild-all,
Brian Cain, Ard Biesheuvel, Greg Kroah-Hartman, linux-mips,
Ralf Baechle, linux-kernel, Paul Burton, Mike Rapoport,
Palmer Dabbelt, Vineet Gupta, Martin Schwidefsky, Qian Cai,
linuxppc-dev, David S. Miller
In-Reply-To: <955229f7-f161-f720-0e75-a3163f63817d@arm.com>
Le 10/02/2020 à 06:35, Anshuman Khandual a écrit :
>
>
> On 02/10/2020 10:22 AM, Andrew Morton wrote:
>> On Thu, 6 Feb 2020 13:49:35 +0530 Anshuman Khandual <anshuman.khandual@arm.com> wrote:
>>
>>>
>>> On 02/06/2020 04:40 AM, kbuild test robot wrote:
>>>> Hi Anshuman,
>>>>
>>>> Thank you for the patch! Yet something to improve:
>>>>
>>>> [auto build test ERROR on powerpc/next]
>>>> [also build test ERROR on s390/features linus/master arc/for-next v5.5]
>>>> [cannot apply to mmotm/master tip/x86/core arm64/for-next/core next-20200205]
>>>> [if your patch is applied to the wrong git tree, please drop us a note to help
>>>> improve the system. BTW, we also suggest to use '--base' option to specify the
>>>> base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
>>>>
>>>> url: https://github.com/0day-ci/linux/commits/Anshuman-Khandual/mm-debug-Add-tests-validating-architecture-page-table-helpers/20200205-215507
>>>> base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
>>>> config: ia64-allmodconfig (attached as .config)
>>>> compiler: ia64-linux-gcc (GCC) 7.5.0
>>>> reproduce:
>>>> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>>>> chmod +x ~/bin/make.cross
>>>> # save the attached .config to linux build tree
>>>> GCC_VERSION=7.5.0 make.cross ARCH=ia64
>>>>
>>>> If you fix the issue, kindly add following tag
>>>> Reported-by: kbuild test robot <lkp@intel.com>
>>>>
>>>> All error/warnings (new ones prefixed by >>):
>>>>
>>>> In file included from include/asm-generic/pgtable-nopud.h:8:0,
>>>> from arch/ia64/include/asm/pgtable.h:586,
>>>> from include/linux/mm.h:99,
>>>> from include/linux/highmem.h:8,
>>>> from mm/debug_vm_pgtable.c:14:
>>>> mm/debug_vm_pgtable.c: In function 'pud_clear_tests':
>>>>>> include/asm-generic/pgtable-nop4d-hack.h:47:32: error: implicit declaration of function '__pgd'; did you mean '__p4d'? [-Werror=implicit-function-declaration]
>>>> #define __pud(x) ((pud_t) { __pgd(x) })
>>>> ^
>>>>>> mm/debug_vm_pgtable.c:141:8: note: in expansion of macro '__pud'
>>>> pud = __pud(pud_val(pud) | RANDOM_ORVALUE);
>>>> ^~~~~
>>>>>> include/asm-generic/pgtable-nop4d-hack.h:47:22: warning: missing braces around initializer [-Wmissing-braces]
>>>> #define __pud(x) ((pud_t) { __pgd(x) })
>>>> ^
>>>>>> mm/debug_vm_pgtable.c:141:8: note: in expansion of macro '__pud'
>>>> pud = __pud(pud_val(pud) | RANDOM_ORVALUE);
>>>> ^~~~~
>>>> cc1: some warnings being treated as errors
>>>
>>> This build failure is expected now given that we have allowed DEBUG_VM_PGTABLE
>>> with EXPERT without platform requiring ARCH_HAS_DEBUG_VM_PGTABLE. This problem
>>> i.e build failure caused without a platform __pgd(), is known to exist both on
>>> ia64 and arm (32bit) platforms. Please refer https://lkml.org/lkml/2019/9/24/314
>>> for details where this was discussed earlier.
>>>
>>
>> I'd prefer not to merge a patch which is known to cause build
>> regressions. Is there some temporary thing we can do to prevent these
>> errors until arch maintainers(?) get around to implementing the
>> long-term fixes?
>
> We could explicitly disable CONFIG_DEBUG_VM_PGTABLE on ia64 and arm platforms
> which will ensure that others can still use the EXPERT path.
>
> config DEBUG_VM_PGTABLE
> bool "Debug arch page table for semantics compliance"
> depends on MMU
> depends on !(IA64 || ARM)
> depends on ARCH_HAS_DEBUG_VM_PGTABLE || EXPERT
> default n if !ARCH_HAS_DEBUG_VM_PGTABLE
> default y if DEBUG_VM
>
On both ia32 and arm, the fix is trivial.
Can we include the fix within this patch, just the same way as the
mm_p4d_folded() fix for x86 ?
Christophe
^ permalink raw reply
* Re: [PATCH V13] mm/debug: Add tests validating architecture page table helpers
From: Anshuman Khandual @ 2020-02-10 5:35 UTC (permalink / raw)
To: Andrew Morton
Cc: Mark Rutland, uclinux-h8-devel, linux-m68k, linux-ia64, linux-sh,
Peter Zijlstra, James Hogan, Tetsuo Handa, Heiko Carstens,
Michal Hocko, linux-mm, Dave Hansen, Paul Mackerras, sparclinux,
linux-hexagon, linux-riscv, Dan Williams, linux-s390,
kbuild test robot, Yoshinori Sato, Max Filippov, x86,
Russell King - ARM Linux, Matthew Wilcox, Steven Price,
Jason Gunthorpe, Geert Uytterhoeven, Gerald Schaefer, Mark Salter,
Matt Turner, linux-snps-arc, linux-arm-kernel, Ingo Molnar,
linux-xtensa, Kees Cook, Masahiro Yamada, linux-alpha,
Aurelien Jacquiot, linux-c6x-dev, Mark Brown, Ivan Kokshaysky,
Paul Walmsley, Kirill A . Shutemov, Thomas Gleixner, Guan Xuetao,
Vlastimil Babka, Richard Henderson, Chris Zankel, Michal Simek,
kbuild-all, Brian Cain, Ard Biesheuvel, Greg Kroah-Hartman,
linux-mips, Ralf Baechle, linux-kernel, Paul Burton,
Mike Rapoport, Palmer Dabbelt, Vineet Gupta, Martin Schwidefsky,
Qian Cai, linuxppc-dev, David S. Miller
In-Reply-To: <20200209205231.44d098f8749e88190b8ba10c@linux-foundation.org>
On 02/10/2020 10:22 AM, Andrew Morton wrote:
> On Thu, 6 Feb 2020 13:49:35 +0530 Anshuman Khandual <anshuman.khandual@arm.com> wrote:
>
>>
>> On 02/06/2020 04:40 AM, kbuild test robot wrote:
>>> Hi Anshuman,
>>>
>>> Thank you for the patch! Yet something to improve:
>>>
>>> [auto build test ERROR on powerpc/next]
>>> [also build test ERROR on s390/features linus/master arc/for-next v5.5]
>>> [cannot apply to mmotm/master tip/x86/core arm64/for-next/core next-20200205]
>>> [if your patch is applied to the wrong git tree, please drop us a note to help
>>> improve the system. BTW, we also suggest to use '--base' option to specify the
>>> base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
>>>
>>> url: https://github.com/0day-ci/linux/commits/Anshuman-Khandual/mm-debug-Add-tests-validating-architecture-page-table-helpers/20200205-215507
>>> base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
>>> config: ia64-allmodconfig (attached as .config)
>>> compiler: ia64-linux-gcc (GCC) 7.5.0
>>> reproduce:
>>> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>>> chmod +x ~/bin/make.cross
>>> # save the attached .config to linux build tree
>>> GCC_VERSION=7.5.0 make.cross ARCH=ia64
>>>
>>> If you fix the issue, kindly add following tag
>>> Reported-by: kbuild test robot <lkp@intel.com>
>>>
>>> All error/warnings (new ones prefixed by >>):
>>>
>>> In file included from include/asm-generic/pgtable-nopud.h:8:0,
>>> from arch/ia64/include/asm/pgtable.h:586,
>>> from include/linux/mm.h:99,
>>> from include/linux/highmem.h:8,
>>> from mm/debug_vm_pgtable.c:14:
>>> mm/debug_vm_pgtable.c: In function 'pud_clear_tests':
>>>>> include/asm-generic/pgtable-nop4d-hack.h:47:32: error: implicit declaration of function '__pgd'; did you mean '__p4d'? [-Werror=implicit-function-declaration]
>>> #define __pud(x) ((pud_t) { __pgd(x) })
>>> ^
>>>>> mm/debug_vm_pgtable.c:141:8: note: in expansion of macro '__pud'
>>> pud = __pud(pud_val(pud) | RANDOM_ORVALUE);
>>> ^~~~~
>>>>> include/asm-generic/pgtable-nop4d-hack.h:47:22: warning: missing braces around initializer [-Wmissing-braces]
>>> #define __pud(x) ((pud_t) { __pgd(x) })
>>> ^
>>>>> mm/debug_vm_pgtable.c:141:8: note: in expansion of macro '__pud'
>>> pud = __pud(pud_val(pud) | RANDOM_ORVALUE);
>>> ^~~~~
>>> cc1: some warnings being treated as errors
>>
>> This build failure is expected now given that we have allowed DEBUG_VM_PGTABLE
>> with EXPERT without platform requiring ARCH_HAS_DEBUG_VM_PGTABLE. This problem
>> i.e build failure caused without a platform __pgd(), is known to exist both on
>> ia64 and arm (32bit) platforms. Please refer https://lkml.org/lkml/2019/9/24/314
>> for details where this was discussed earlier.
>>
>
> I'd prefer not to merge a patch which is known to cause build
> regressions. Is there some temporary thing we can do to prevent these
> errors until arch maintainers(?) get around to implementing the
> long-term fixes?
We could explicitly disable CONFIG_DEBUG_VM_PGTABLE on ia64 and arm platforms
which will ensure that others can still use the EXPERT path.
config DEBUG_VM_PGTABLE
bool "Debug arch page table for semantics compliance"
depends on MMU
depends on !(IA64 || ARM)
depends on ARCH_HAS_DEBUG_VM_PGTABLE || EXPERT
default n if !ARCH_HAS_DEBUG_VM_PGTABLE
default y if DEBUG_VM
^ permalink raw reply
* Re: [PATCH V13] mm/debug: Add tests validating architecture page table helpers
From: Andrew Morton @ 2020-02-10 4:52 UTC (permalink / raw)
To: Anshuman Khandual
Cc: Mark Rutland, uclinux-h8-devel, linux-m68k, linux-ia64, linux-sh,
Peter Zijlstra, James Hogan, Tetsuo Handa, Heiko Carstens,
Michal Hocko, linux-mm, Dave Hansen, Paul Mackerras, sparclinux,
linux-hexagon, linux-riscv, Dan Williams, linux-s390,
kbuild test robot, Yoshinori Sato, Max Filippov, x86,
Russell King - ARM Linux, Matthew Wilcox, Steven Price,
Jason Gunthorpe, Geert Uytterhoeven, Gerald Schaefer, Mark Salter,
Matt Turner, linux-snps-arc, linux-arm-kernel, Ingo Molnar,
linux-xtensa, Kees Cook, Masahiro Yamada, linux-alpha,
Aurelien Jacquiot, linux-c6x-dev, Mark Brown, Ivan Kokshaysky,
Paul Walmsley, Kirill A . Shutemov, Thomas Gleixner, Guan Xuetao,
Vlastimil Babka, Richard Henderson, Chris Zankel, Michal Simek,
kbuild-all, Brian Cain, Ard Biesheuvel, Greg Kroah-Hartman,
linux-mips, Ralf Baechle, linux-kernel, Paul Burton,
Mike Rapoport, Palmer Dabbelt, Vineet Gupta, Martin Schwidefsky,
Qian Cai, linuxppc-dev, David S. Miller
In-Reply-To: <78d3ce6b-e100-2561-6b09-124c29731d1a@arm.com>
On Thu, 6 Feb 2020 13:49:35 +0530 Anshuman Khandual <anshuman.khandual@arm.com> wrote:
>
> On 02/06/2020 04:40 AM, kbuild test robot wrote:
> > Hi Anshuman,
> >
> > Thank you for the patch! Yet something to improve:
> >
> > [auto build test ERROR on powerpc/next]
> > [also build test ERROR on s390/features linus/master arc/for-next v5.5]
> > [cannot apply to mmotm/master tip/x86/core arm64/for-next/core next-20200205]
> > [if your patch is applied to the wrong git tree, please drop us a note to help
> > improve the system. BTW, we also suggest to use '--base' option to specify the
> > base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
> >
> > url: https://github.com/0day-ci/linux/commits/Anshuman-Khandual/mm-debug-Add-tests-validating-architecture-page-table-helpers/20200205-215507
> > base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
> > config: ia64-allmodconfig (attached as .config)
> > compiler: ia64-linux-gcc (GCC) 7.5.0
> > reproduce:
> > wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> > chmod +x ~/bin/make.cross
> > # save the attached .config to linux build tree
> > GCC_VERSION=7.5.0 make.cross ARCH=ia64
> >
> > If you fix the issue, kindly add following tag
> > Reported-by: kbuild test robot <lkp@intel.com>
> >
> > All error/warnings (new ones prefixed by >>):
> >
> > In file included from include/asm-generic/pgtable-nopud.h:8:0,
> > from arch/ia64/include/asm/pgtable.h:586,
> > from include/linux/mm.h:99,
> > from include/linux/highmem.h:8,
> > from mm/debug_vm_pgtable.c:14:
> > mm/debug_vm_pgtable.c: In function 'pud_clear_tests':
> >>> include/asm-generic/pgtable-nop4d-hack.h:47:32: error: implicit declaration of function '__pgd'; did you mean '__p4d'? [-Werror=implicit-function-declaration]
> > #define __pud(x) ((pud_t) { __pgd(x) })
> > ^
> >>> mm/debug_vm_pgtable.c:141:8: note: in expansion of macro '__pud'
> > pud = __pud(pud_val(pud) | RANDOM_ORVALUE);
> > ^~~~~
> >>> include/asm-generic/pgtable-nop4d-hack.h:47:22: warning: missing braces around initializer [-Wmissing-braces]
> > #define __pud(x) ((pud_t) { __pgd(x) })
> > ^
> >>> mm/debug_vm_pgtable.c:141:8: note: in expansion of macro '__pud'
> > pud = __pud(pud_val(pud) | RANDOM_ORVALUE);
> > ^~~~~
> > cc1: some warnings being treated as errors
>
> This build failure is expected now given that we have allowed DEBUG_VM_PGTABLE
> with EXPERT without platform requiring ARCH_HAS_DEBUG_VM_PGTABLE. This problem
> i.e build failure caused without a platform __pgd(), is known to exist both on
> ia64 and arm (32bit) platforms. Please refer https://lkml.org/lkml/2019/9/24/314
> for details where this was discussed earlier.
>
I'd prefer not to merge a patch which is known to cause build
regressions. Is there some temporary thing we can do to prevent these
errors until arch maintainers(?) get around to implementing the
long-term fixes?
^ permalink raw reply
* Re: [PATCH V5 06/14] powerpc/vas: Setup thread IRQ handler per VAS instance
From: Haren Myneni @ 2020-02-10 5:17 UTC (permalink / raw)
To: Michael Neuling; +Cc: herbert, npiggin, hch, oohall, sukadev, linuxppc-dev
In-Reply-To: <71427c6b8d8e00461fa27e603db2012e8215f467.camel@neuling.org>
On Fri, 2020-02-07 at 16:57 +1100, Michael Neuling wrote:
> > /*
> > + * Process CRBs that we receive on the fault window.
> > + */
> > +irqreturn_t vas_fault_handler(int irq, void *data)
> > +{
> > + struct vas_instance *vinst = data;
> > + struct coprocessor_request_block buf, *crb;
> > + struct vas_window *window;
> > + void *fifo;
> > +
> > + /*
> > + * VAS can interrupt with multiple page faults. So process all
> > + * valid CRBs within fault FIFO until reaches invalid CRB.
> > + * NX updates nx_fault_stamp in CRB and pastes in fault FIFO.
> > + * kernel retrives send window from parition send window ID
> > + * (pswid) in nx_fault_stamp. So pswid should be non-zero and
> > + * use this to check whether CRB is valid.
> > + * After reading CRB entry, it is reset with 0's in fault FIFO.
> > + *
> > + * In case kernel receives another interrupt with different page
> > + * fault and CRBs are processed by the previous handling, will be
> > + * returned from this function when it sees invalid CRB (means 0's).
> > + */
> > + do {
> > + mutex_lock(&vinst->mutex);
>
> This isn't going to work.
>
> From Documentation/locking/mutex-design.rst
>
> - Mutexes may not be used in hardware or software interrupt
> contexts such as tasklets and timers.
Initially used kernel thread per VAS instance and later using IRQ
thread.
vas_fault_handler() is IRQ thread function, not IRQ handler. I thought
we can use mutex_lock() in thread function.
>
> Mikey
>
^ permalink raw reply
* Re: [PATCH V5 09/14] powerpc/vas: Update CSB and notify process for fault CRBs
From: Haren Myneni @ 2020-02-10 5:12 UTC (permalink / raw)
To: Michael Neuling; +Cc: herbert, npiggin, hch, oohall, sukadev, linuxppc-dev
In-Reply-To: <67467b52ddd8fcd6ccd8390f9b1f0ed7c09bb3bf.camel@neuling.org>
Mikey, Thanks for your review comments.
On Fri, 2020-02-07 at 16:46 +1100, Michael Neuling wrote:
> On Wed, 2020-01-22 at 00:17 -0800, Haren Myneni wrote:
> > For each fault CRB, update fault address in CRB (fault_storage_addr)
> > and translation error status in CSB so that user space can touch the
> > fault address and resend the request. If the user space passed invalid
> > CSB address send signal to process with SIGSEGV.
> >
> > Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
> > Signed-off-by: Haren Myneni <haren@linux.ibm.com>
> > ---
> > arch/powerpc/platforms/powernv/vas-fault.c | 116
> > +++++++++++++++++++++++++++++
> > 1 file changed, 116 insertions(+)
> >
> > diff --git a/arch/powerpc/platforms/powernv/vas-fault.c
> > b/arch/powerpc/platforms/powernv/vas-fault.c
> > index 5c2cada..2cfab0c 100644
> > --- a/arch/powerpc/platforms/powernv/vas-fault.c
> > +++ b/arch/powerpc/platforms/powernv/vas-fault.c
> > @@ -11,6 +11,7 @@
> > #include <linux/slab.h>
> > #include <linux/uaccess.h>
> > #include <linux/kthread.h>
> > +#include <linux/sched/signal.h>
> > #include <linux/mmu_context.h>
> > #include <asm/icswx.h>
> >
> > @@ -26,6 +27,120 @@
> > #define VAS_FAULT_WIN_FIFO_SIZE (4 << 20)
> >
> > /*
> > + * Update the CSB to indicate a translation error.
> > + *
> > + * If the fault is in the CSB address itself or if we are unable to
> > + * update the CSB, send a signal to the process, because we have no
> > + * other way of notifying the user process.
> > + *
> > + * Remaining settings in the CSB are based on wait_for_csb() of
> > + * NX-GZIP.
> > + */
> > +static void update_csb(struct vas_window *window,
> > + struct coprocessor_request_block *crb)
> > +{
> > + int rc;
> > + struct pid *pid;
> > + void __user *csb_addr;
> > + struct task_struct *tsk;
> > + struct kernel_siginfo info;
> > + struct coprocessor_status_block csb;
> > +
> > + /*
> > + * NX user space windows can not be opened for task->mm=NULL
> > + * and faults will not be generated for kernel requests.
> > + */
> > + if (!window->mm || !window->user_win)
> > + return;
> > +
> > + csb_addr = (void *)be64_to_cpu(crb->csb_addr);
> > +
> > + csb.cc = CSB_CC_TRANSLATION;
> > + csb.ce = CSB_CE_TERMINATION;
> > + csb.cs = 0;
> > + csb.count = 0;
> > +
> > + /*
> > + * Returns the fault address in CPU format since it is passed with
> > + * signal. But if the user space expects BE format, need changes.
> > + * i.e either kernel (here) or user should convert to CPU format.
> > + * Not both!
> > + */
> > + csb.address = be64_to_cpu(crb->stamp.nx.fault_storage_addr);
>
> This looks wrong and I don't understand the comment. You need to convert this
> back to be64 to write it to csb.address. ie.
>
> csb.address = cpu_to_be64(be64_to_cpu(crb->stamp.nx.fault_storage_addr));
>
> Which I think you can just avoid the endian conversion all together.
NX pastes fault CRB in big-endian, so passing this address in CPU format
to user space, otherwise the library has to convert.
What is the standard way for passing to user space?
>
> > + csb.flags = 0;
> > +
> > + pid = window->pid;
> > + tsk = get_pid_task(pid, PIDTYPE_PID);
> > + /*
> > + * Send window will be closed after processing all NX requests
> > + * and process exits after closing all windows. In multi-thread
> > + * applications, thread may not exists, but does not close FD
> > + * (means send window) upon exit. Parent thread (tgid) can use
> > + * and close the window later.
> > + * pid and mm references are taken when window is opened by
> > + * process (pid). So tgid is used only when child thread opens
> > + * a window and exits without closing it in multithread tasks.
> > + */
> > + if (!tsk) {
> > + pid = window->tgid;
> > + tsk = get_pid_task(pid, PIDTYPE_PID);
> > + /*
> > + * Parent thread will be closing window during its exit.
> > + * So should not get here.
> > + */
> > + if (!tsk)
> > + return;
> > + }
> > +
> > + /* Return if the task is exiting. */
> > + if (tsk->flags & PF_EXITING) {
> > + put_task_struct(tsk);
> > + return;
> > + }
> > +
> > + use_mm(window->mm);
> > + rc = copy_to_user(csb_addr, &csb, sizeof(csb));
> > + /*
> > + * User space polls on csb.flags (first byte). So add barrier
> > + * then copy first byte with csb flags update.
> > + */
> > + smp_mb();
> > + if (!rc) {
> > + csb.flags = CSB_V;
> > + rc = copy_to_user(csb_addr, &csb, sizeof(u8));
> > + }
> > + unuse_mm(window->mm);
> > + put_task_struct(tsk);
> > +
> > + /* Success */
> > + if (!rc)
> > + return;
> > +
> > + pr_err("Invalid CSB address 0x%p signalling pid(%d)\n",
> > + csb_addr, pid_vnr(pid));
>
> This is a userspace error, not a kernel error. This should not be a pr_err().
>
> Userspace could spam the console with this.
Will change it to pr_debug/info. Added pr_err() during development and
missed to remove.
>
> > +
> > + clear_siginfo(&info);
> > + info.si_signo = SIGSEGV;
> > + info.si_errno = EFAULT;
> > + info.si_code = SEGV_MAPERR;
> > + info.si_addr = csb_addr;
> > +
> > + /*
> > + * process will be polling on csb.flags after request is sent to
> > + * NX. So generally CSB update should not fail except when an
> > + * application does not follow the process properly. So an error
> > + * message will be displayed and leave it to user space whether
> > + * to ignore or handle this signal.
> > + */
> > + rcu_read_lock();
> > + rc = kill_pid_info(SIGSEGV, &info, pid);
> > + rcu_read_unlock();
>
> why the rcu_read_un/lock() here?
Used same as in kill_proc_info()/kill_something_info()
>
> > +
> > + pr_devel("%s(): pid %d kill_proc_info() rc %d\n", __func__,
> > + pid_vnr(pid), rc);
> > +}
> > +
> > +/*
> > * Process CRBs that we receive on the fault window.
> > */
> > irqreturn_t vas_fault_handler(int irq, void *data)
> > @@ -104,6 +219,7 @@ irqreturn_t vas_fault_handler(int irq, void *data)
> > return IRQ_HANDLED;
> > }
> >
> > + update_csb(window, crb);
> > } while (true);
> >
> > return IRQ_HANDLED;
>
^ permalink raw reply
* Re: [PATCH v6 2/6] sysfs: wrap __compat_only_sysfs_link_entry_to_kobj function to change the symlink name
From: Michael Ellerman @ 2020-02-10 4:44 UTC (permalink / raw)
To: Sourabh Jain
Cc: corbet, mahesh, linux-doc, linux-kernel, Sourabh Jain,
linuxppc-dev, gregkh, hbathini
In-Reply-To: <20191211160910.21656-3-sourabhjain@linux.ibm.com>
Sourabh Jain <sourabhjain@linux.ibm.com> writes:
> The __compat_only_sysfs_link_entry_to_kobj function creates a symlink to a
> kobject but doesn't provide an option to change the symlink file name.
>
> This patch adds a wrapper function compat_only_sysfs_link_entry_to_kobj
> that extends the __compat_only_sysfs_link_entry_to_kobj functionality
> which allows function caller to customize the symlink name.
>
> Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
> ---
> fs/sysfs/group.c | 28 +++++++++++++++++++++++++---
> include/linux/sysfs.h | 12 ++++++++++++
> 2 files changed, 37 insertions(+), 3 deletions(-)
I'll assume no one has any objections to this and merge it via the
powerpc tree with the rest of the series.
cheers
> diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c
> index d41c21fef138..0993645f0b59 100644
> --- a/fs/sysfs/group.c
> +++ b/fs/sysfs/group.c
> @@ -424,6 +424,25 @@ EXPORT_SYMBOL_GPL(sysfs_remove_link_from_group);
> int __compat_only_sysfs_link_entry_to_kobj(struct kobject *kobj,
> struct kobject *target_kobj,
> const char *target_name)
> +{
> + return compat_only_sysfs_link_entry_to_kobj(kobj, target_kobj,
> + target_name, NULL);
> +}
> +EXPORT_SYMBOL_GPL(__compat_only_sysfs_link_entry_to_kobj);
> +
> +/**
> + * compat_only_sysfs_link_entry_to_kobj - add a symlink to a kobject pointing
> + * to a group or an attribute
> + * @kobj: The kobject containing the group.
> + * @target_kobj: The target kobject.
> + * @target_name: The name of the target group or attribute.
> + * @symlink_name: The name of the symlink file (target_name will be
> + * considered if symlink_name is NULL).
> + */
> +int compat_only_sysfs_link_entry_to_kobj(struct kobject *kobj,
> + struct kobject *target_kobj,
> + const char *target_name,
> + const char *symlink_name)
> {
> struct kernfs_node *target;
> struct kernfs_node *entry;
> @@ -448,12 +467,15 @@ int __compat_only_sysfs_link_entry_to_kobj(struct kobject *kobj,
> return -ENOENT;
> }
>
> - link = kernfs_create_link(kobj->sd, target_name, entry);
> + if (!symlink_name)
> + symlink_name = target_name;
> +
> + link = kernfs_create_link(kobj->sd, symlink_name, entry);
> if (IS_ERR(link) && PTR_ERR(link) == -EEXIST)
> - sysfs_warn_dup(kobj->sd, target_name);
> + sysfs_warn_dup(kobj->sd, symlink_name);
>
> kernfs_put(entry);
> kernfs_put(target);
> return PTR_ERR_OR_ZERO(link);
> }
> -EXPORT_SYMBOL_GPL(__compat_only_sysfs_link_entry_to_kobj);
> +EXPORT_SYMBOL_GPL(compat_only_sysfs_link_entry_to_kobj);
> diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
> index 5420817ed317..15b195a4529d 100644
> --- a/include/linux/sysfs.h
> +++ b/include/linux/sysfs.h
> @@ -300,6 +300,10 @@ void sysfs_remove_link_from_group(struct kobject *kobj, const char *group_name,
> int __compat_only_sysfs_link_entry_to_kobj(struct kobject *kobj,
> struct kobject *target_kobj,
> const char *target_name);
> +int compat_only_sysfs_link_entry_to_kobj(struct kobject *kobj,
> + struct kobject *target_kobj,
> + const char *target_name,
> + const char *symlink_name);
>
> void sysfs_notify(struct kobject *kobj, const char *dir, const char *attr);
>
> @@ -508,6 +512,14 @@ static inline int __compat_only_sysfs_link_entry_to_kobj(
> return 0;
> }
>
> +static int compat_only_sysfs_link_entry_to_kobj(struct kobject *kobj,
> + struct kobject *target_kobj,
> + const char *target_name,
> + const char *symlink_name)
> +{
> + return 0;
> +}
> +
> static inline void sysfs_notify(struct kobject *kobj, const char *dir,
> const char *attr)
> {
> --
> 2.17.2
^ permalink raw reply
* [PATCH] powerpc/8xx: Fix clearing of bits 20-23 in ITLB miss
From: Christophe Leroy @ 2020-02-09 18:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In ITLB miss handled the line supposed to clear bits 20-23 on the
L2 ITLB entry is buggy and does indeed nothing, leading to undefined
value which could allow execution when it shouldn't.
Properly do the clearing with the relevant instruction.
Fixes: 74fabcadfd43 ("powerpc/8xx: don't use r12/SPRN_SPRG_SCRATCH2 in TLB Miss handlers")
Cc: stable@vger.kernel.org
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
arch/powerpc/kernel/head_8xx.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
index 9922306ae512..073a651787df 100644
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S
@@ -256,7 +256,7 @@ InstructionTLBMiss:
* set. All other Linux PTE bits control the behavior
* of the MMU.
*/
- rlwimi r10, r10, 0, 0x0f00 /* Clear bits 20-23 */
+ rlwinm r10, r10, 0, ~0x0f00 /* Clear bits 20-23 */
rlwimi r10, r10, 4, 0x0400 /* Copy _PAGE_EXEC into bit 21 */
ori r10, r10, RPN_PATTERN | 0x200 /* Set 22 and 24-27 */
mtspr SPRN_MI_RPN, r10 /* Update TLB entry */
--
2.25.0
^ permalink raw reply related
* Re: [PATCH v2] libnvdimm: Update persistence domain value for of_pmem and papr_scm device
From: Dan Williams @ 2020-02-09 16:12 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev, linux-nvdimm
In-Reply-To: <20200205052056.74604-1-aneesh.kumar@linux.ibm.com>
On Tue, Feb 4, 2020 at 9:21 PM Aneesh Kumar K.V
<aneesh.kumar@linux.ibm.com> wrote:
>
> Currently, kernel shows the below values
> "persistence_domain":"cpu_cache"
> "persistence_domain":"memory_controller"
> "persistence_domain":"unknown"
>
> "cpu_cache" indicates no extra instructions is needed to ensure the persistence
> of data in the pmem media on power failure.
>
> "memory_controller" indicates platform provided instructions need to be issued
No, it does not. The only requirement implied by "memory_controller"
is global visibility outside the cpu cache. If there are special
instructions beyond that then it isn't persistent memory, at least not
pmem that is safe for dax. virtio-pmem is an example of pmem-like
memory that is not enabled for userspace flushing (MAP_SYNC disabled).
> as per documented sequence to make sure data get flushed so that it is
> guaranteed to be on pmem media in case of system power loss.
>
> Based on the above use memory_controller for non volatile regions on ppc64.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> ---
> arch/powerpc/platforms/pseries/papr_scm.c | 7 ++++++-
> drivers/nvdimm/of_pmem.c | 4 +++-
> include/linux/libnvdimm.h | 1 -
> 3 files changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c
> index 7525635a8536..ffcd0d7a867c 100644
> --- a/arch/powerpc/platforms/pseries/papr_scm.c
> +++ b/arch/powerpc/platforms/pseries/papr_scm.c
> @@ -359,8 +359,13 @@ static int papr_scm_nvdimm_init(struct papr_scm_priv *p)
>
> if (p->is_volatile)
> p->region = nvdimm_volatile_region_create(p->bus, &ndr_desc);
> - else
> + else {
> + /*
> + * We need to flush things correctly to guarantee persistance
> + */
There are never guarantees. If you're going to comment what does
software need to flush, and how?
> + set_bit(ND_REGION_PERSIST_MEMCTRL, &ndr_desc.flags);
> p->region = nvdimm_pmem_region_create(p->bus, &ndr_desc);
> + }
> if (!p->region) {
> dev_err(dev, "Error registering region %pR from %pOF\n",
> ndr_desc.res, p->dn);
> diff --git a/drivers/nvdimm/of_pmem.c b/drivers/nvdimm/of_pmem.c
> index 8224d1431ea9..6826a274a1f1 100644
> --- a/drivers/nvdimm/of_pmem.c
> +++ b/drivers/nvdimm/of_pmem.c
> @@ -62,8 +62,10 @@ static int of_pmem_region_probe(struct platform_device *pdev)
>
> if (is_volatile)
> region = nvdimm_volatile_region_create(bus, &ndr_desc);
> - else
> + else {
> + set_bit(ND_REGION_PERSIST_MEMCTRL, &ndr_desc.flags);
> region = nvdimm_pmem_region_create(bus, &ndr_desc);
> + }
>
> if (!region)
> dev_warn(&pdev->dev, "Unable to register region %pR from %pOF\n",
> diff --git a/include/linux/libnvdimm.h b/include/linux/libnvdimm.h
> index 0f366706b0aa..771d888a5ed7 100644
> --- a/include/linux/libnvdimm.h
> +++ b/include/linux/libnvdimm.h
> @@ -54,7 +54,6 @@ enum {
> /*
> * Platform provides mechanisms to automatically flush outstanding
> * write data from memory controler to pmem on system power loss.
> - * (ADR)
I'd rather not delete critical terminology for a developer / platform
owner to be able to consult documentation, or their vendor. Can you
instead add the PowerPC equivalent term for this capability? I.e. list
(x86: ADR PowerPC: foo ...).
^ permalink raw reply
* [PATCH v2] powerpc/hugetlb: Fix 8M hugepages on 8xx
From: Christophe Leroy @ 2020-02-09 16:02 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
aneesh.kumar
Cc: linuxppc-dev, linux-kernel
With HW assistance all page tables must be 4k aligned, the 8xx
drops the last 12 bits during the walk.
Redefine HUGEPD_SHIFT_MASK to mask last 12 bits out.
HUGEPD_SHIFT_MASK is used to for alignment of page table cache.
Fixes: 22569b881d37 ("powerpc/8xx: Enable 8M hugepage support with HW assistance")
Cc: stable@vger.kernel.org
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
v2: Only do the fix of alignment which is the only vital fix.
---
arch/powerpc/include/asm/page.h | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
index 86332080399a..080a0bf8e54b 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -295,8 +295,13 @@ static inline bool pfn_valid(unsigned long pfn)
/*
* Some number of bits at the level of the page table that points to
* a hugepte are used to encode the size. This masks those bits.
+ * On 8xx, HW assistance requires 4k alignment for the hugepte.
*/
+#ifdef CONFIG_PPC_8xx
+#define HUGEPD_SHIFT_MASK 0xfff
+#else
#define HUGEPD_SHIFT_MASK 0x3f
+#endif
#ifndef __ASSEMBLY__
--
2.25.0
^ permalink raw reply related
* [PATCH 1/6] powerpc: kernel: no need to check return value of debugfs_create functions
From: Greg Kroah-Hartman @ 2020-02-09 10:58 UTC (permalink / raw)
To: linuxppc-dev
Cc: linux-kernel, Paul Mackerras, Greg Kroah-Hartman, Hari Bathini
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Hari Bathini <hbathini@linux.ibm.com>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/kernel/fadump.c | 9 ++-------
arch/powerpc/kernel/setup-common.c | 3 +--
arch/powerpc/kernel/traps.c | 25 +++++--------------------
3 files changed, 8 insertions(+), 29 deletions(-)
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index ff0114aeba9b..b83fa42c19e1 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -1432,7 +1432,6 @@ DEFINE_SHOW_ATTRIBUTE(fadump_region);
static void fadump_init_files(void)
{
- struct dentry *debugfs_file;
int rc = 0;
rc = sysfs_create_file(kernel_kobj, &fadump_attr.attr);
@@ -1445,12 +1444,8 @@ static void fadump_init_files(void)
printk(KERN_ERR "fadump: unable to create sysfs file"
" fadump_registered (%d)\n", rc);
- debugfs_file = debugfs_create_file("fadump_region", 0444,
- powerpc_debugfs_root, NULL,
- &fadump_region_fops);
- if (!debugfs_file)
- printk(KERN_ERR "fadump: unable to create debugfs file"
- " fadump_region\n");
+ debugfs_create_file("fadump_region", 0444, powerpc_debugfs_root, NULL,
+ &fadump_region_fops);
if (fw_dump.dump_active) {
rc = sysfs_create_file(kernel_kobj, &fadump_release_attr.attr);
diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
index 7f8c890360fe..f9c0d888ce8a 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -787,8 +787,7 @@ EXPORT_SYMBOL(powerpc_debugfs_root);
static int powerpc_debugfs_init(void)
{
powerpc_debugfs_root = debugfs_create_dir("powerpc", NULL);
-
- return powerpc_debugfs_root == NULL;
+ return 0;
}
arch_initcall(powerpc_debugfs_init);
#endif
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 82a3438300fd..3fca22276bb1 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -2278,35 +2278,20 @@ void ppc_warn_emulated_print(const char *type)
static int __init ppc_warn_emulated_init(void)
{
- struct dentry *dir, *d;
+ struct dentry *dir;
unsigned int i;
struct ppc_emulated_entry *entries = (void *)&ppc_emulated;
- if (!powerpc_debugfs_root)
- return -ENODEV;
-
dir = debugfs_create_dir("emulated_instructions",
powerpc_debugfs_root);
- if (!dir)
- return -ENOMEM;
- d = debugfs_create_u32("do_warn", 0644, dir,
- &ppc_warn_emulated);
- if (!d)
- goto fail;
+ debugfs_create_u32("do_warn", 0644, dir, &ppc_warn_emulated);
- for (i = 0; i < sizeof(ppc_emulated)/sizeof(*entries); i++) {
- d = debugfs_create_u32(entries[i].name, 0644, dir,
- (u32 *)&entries[i].val.counter);
- if (!d)
- goto fail;
- }
+ for (i = 0; i < sizeof(ppc_emulated)/sizeof(*entries); i++)
+ debugfs_create_u32(entries[i].name, 0644, dir,
+ (u32 *)&entries[i].val.counter);
return 0;
-
-fail:
- debugfs_remove_recursive(dir);
- return -ENOMEM;
}
device_initcall(ppc_warn_emulated_init);
--
2.25.0
^ permalink raw reply related
* [PATCH 6/6] powerpc: powernv: no need to check return value of debugfs_create functions
From: Greg Kroah-Hartman @ 2020-02-09 10:59 UTC (permalink / raw)
To: linuxppc-dev
Cc: linux-kernel, Paul Mackerras, Greg Kroah-Hartman,
Sukadev Bhattiprolu
In-Reply-To: <20200209105901.1620958-1-gregkh@linuxfoundation.org>
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/platforms/powernv/memtrace.c | 7 ----
arch/powerpc/platforms/powernv/opal-imc.c | 24 ++++----------
arch/powerpc/platforms/powernv/pci-ioda.c | 5 ---
arch/powerpc/platforms/powernv/vas-debug.c | 37 ++--------------------
4 files changed, 10 insertions(+), 63 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/memtrace.c b/arch/powerpc/platforms/powernv/memtrace.c
index eb2e75dac369..d6d64f8718e6 100644
--- a/arch/powerpc/platforms/powernv/memtrace.c
+++ b/arch/powerpc/platforms/powernv/memtrace.c
@@ -187,11 +187,6 @@ static int memtrace_init_debugfs(void)
snprintf(ent->name, 16, "%08x", ent->nid);
dir = debugfs_create_dir(ent->name, memtrace_debugfs_dir);
- if (!dir) {
- pr_err("Failed to create debugfs directory for node %d\n",
- ent->nid);
- return -1;
- }
ent->dir = dir;
debugfs_create_file("trace", 0400, dir, ent, &memtrace_fops);
@@ -314,8 +309,6 @@ static int memtrace_init(void)
{
memtrace_debugfs_dir = debugfs_create_dir("memtrace",
powerpc_debugfs_root);
- if (!memtrace_debugfs_dir)
- return -1;
debugfs_create_file("enable", 0600, memtrace_debugfs_dir,
NULL, &memtrace_init_fops);
diff --git a/arch/powerpc/platforms/powernv/opal-imc.c b/arch/powerpc/platforms/powernv/opal-imc.c
index 000b350d4060..968b9a4d1cd9 100644
--- a/arch/powerpc/platforms/powernv/opal-imc.c
+++ b/arch/powerpc/platforms/powernv/opal-imc.c
@@ -35,11 +35,10 @@ static int imc_mem_set(void *data, u64 val)
}
DEFINE_DEBUGFS_ATTRIBUTE(fops_imc_x64, imc_mem_get, imc_mem_set, "0x%016llx\n");
-static struct dentry *imc_debugfs_create_x64(const char *name, umode_t mode,
- struct dentry *parent, u64 *value)
+static void imc_debugfs_create_x64(const char *name, umode_t mode,
+ struct dentry *parent, u64 *value)
{
- return debugfs_create_file_unsafe(name, mode, parent,
- value, &fops_imc_x64);
+ debugfs_create_file_unsafe(name, mode, parent, value, &fops_imc_x64);
}
/*
@@ -59,9 +58,6 @@ static void export_imc_mode_and_cmd(struct device_node *node,
imc_debugfs_parent = debugfs_create_dir("imc", powerpc_debugfs_root);
- if (!imc_debugfs_parent)
- return;
-
if (of_property_read_u32(node, "cb_offset", &cb_offset))
cb_offset = IMC_CNTL_BLK_OFFSET;
@@ -69,21 +65,15 @@ static void export_imc_mode_and_cmd(struct device_node *node,
loc = (u64)(ptr->vbase) + cb_offset;
imc_mode_addr = (u64 *)(loc + IMC_CNTL_BLK_MODE_OFFSET);
sprintf(mode, "imc_mode_%d", (u32)(ptr->id));
- if (!imc_debugfs_create_x64(mode, 0600, imc_debugfs_parent,
- imc_mode_addr))
- goto err;
+ imc_debugfs_create_x64(mode, 0600, imc_debugfs_parent,
+ imc_mode_addr);
imc_cmd_addr = (u64 *)(loc + IMC_CNTL_BLK_CMD_OFFSET);
sprintf(cmd, "imc_cmd_%d", (u32)(ptr->id));
- if (!imc_debugfs_create_x64(cmd, 0600, imc_debugfs_parent,
- imc_cmd_addr))
- goto err;
+ imc_debugfs_create_x64(cmd, 0600, imc_debugfs_parent,
+ imc_cmd_addr);
ptr++;
}
- return;
-
-err:
- debugfs_remove_recursive(imc_debugfs_parent);
}
/*
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
index 22c22cd7bd82..57d3a6af1d52 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -3174,11 +3174,6 @@ static void pnv_pci_ioda_create_dbgfs(void)
sprintf(name, "PCI%04x", hose->global_number);
phb->dbgfs = debugfs_create_dir(name, powerpc_debugfs_root);
- if (!phb->dbgfs) {
- pr_warn("%s: Error on creating debugfs on PHB#%x\n",
- __func__, hose->global_number);
- continue;
- }
debugfs_create_file_unsafe("dump_diag_regs", 0200, phb->dbgfs,
phb, &pnv_pci_diag_data_fops);
diff --git a/arch/powerpc/platforms/powernv/vas-debug.c b/arch/powerpc/platforms/powernv/vas-debug.c
index 09e63df53c30..44035a3d6414 100644
--- a/arch/powerpc/platforms/powernv/vas-debug.c
+++ b/arch/powerpc/platforms/powernv/vas-debug.c
@@ -115,7 +115,7 @@ void vas_window_free_dbgdir(struct vas_window *window)
void vas_window_init_dbgdir(struct vas_window *window)
{
- struct dentry *f, *d;
+ struct dentry *d;
if (!window->vinst->dbgdir)
return;
@@ -127,28 +127,10 @@ void vas_window_init_dbgdir(struct vas_window *window)
snprintf(window->dbgname, 16, "w%d", window->winid);
d = debugfs_create_dir(window->dbgname, window->vinst->dbgdir);
- if (IS_ERR(d))
- goto free_name;
-
window->dbgdir = d;
- f = debugfs_create_file("info", 0444, d, window, &info_fops);
- if (IS_ERR(f))
- goto remove_dir;
-
- f = debugfs_create_file("hvwc", 0444, d, window, &hvwc_fops);
- if (IS_ERR(f))
- goto remove_dir;
-
- return;
-
-remove_dir:
- debugfs_remove_recursive(window->dbgdir);
- window->dbgdir = NULL;
-
-free_name:
- kfree(window->dbgname);
- window->dbgname = NULL;
+ debugfs_create_file("info", 0444, d, window, &info_fops);
+ debugfs_create_file("hvwc", 0444, d, window, &hvwc_fops);
}
void vas_instance_init_dbgdir(struct vas_instance *vinst)
@@ -156,8 +138,6 @@ void vas_instance_init_dbgdir(struct vas_instance *vinst)
struct dentry *d;
vas_init_dbgdir();
- if (!vas_debugfs)
- return;
vinst->dbgname = kzalloc(16, GFP_KERNEL);
if (!vinst->dbgname)
@@ -166,16 +146,7 @@ void vas_instance_init_dbgdir(struct vas_instance *vinst)
snprintf(vinst->dbgname, 16, "v%d", vinst->vas_id);
d = debugfs_create_dir(vinst->dbgname, vas_debugfs);
- if (IS_ERR(d))
- goto free_name;
-
vinst->dbgdir = d;
- return;
-
-free_name:
- kfree(vinst->dbgname);
- vinst->dbgname = NULL;
- vinst->dbgdir = NULL;
}
/*
@@ -191,6 +162,4 @@ void vas_init_dbgdir(void)
first_time = false;
vas_debugfs = debugfs_create_dir("vas", NULL);
- if (IS_ERR(vas_debugfs))
- vas_debugfs = NULL;
}
--
2.25.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox