* [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
* [PATCH 5/6] powerpc: cell: axon_msi: 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: Arnd Bergmann, linux-kernel, Paul Mackerras, Greg Kroah-Hartman
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: Arnd Bergmann <arnd@arndb.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/platforms/cell/axon_msi.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/powerpc/platforms/cell/axon_msi.c b/arch/powerpc/platforms/cell/axon_msi.c
index 57c4e0e86c88..ca2555b8a0c2 100644
--- a/arch/powerpc/platforms/cell/axon_msi.c
+++ b/arch/powerpc/platforms/cell/axon_msi.c
@@ -480,10 +480,6 @@ void axon_msi_debug_setup(struct device_node *dn, struct axon_msic *msic)
snprintf(name, sizeof(name), "msic_%d", of_node_to_nid(dn));
- if (!debugfs_create_file(name, 0600, powerpc_debugfs_root,
- msic, &fops_msic)) {
- pr_devel("axon_msi: debugfs_create_file failed!\n");
- return;
- }
+ debugfs_create_file(name, 0600, powerpc_debugfs_root, msic, &fops_msic);
}
#endif /* DEBUG */
--
2.25.0
^ permalink raw reply related
* [PATCH 4/6] powerpc: mm: ptdump: 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
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: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/mm/ptdump/bats.c | 8 +++-----
arch/powerpc/mm/ptdump/hashpagetable.c | 7 ++-----
arch/powerpc/mm/ptdump/ptdump.c | 8 +++-----
arch/powerpc/mm/ptdump/segment_regs.c | 8 +++-----
4 files changed, 11 insertions(+), 20 deletions(-)
diff --git a/arch/powerpc/mm/ptdump/bats.c b/arch/powerpc/mm/ptdump/bats.c
index 4154feac1da3..d3a5d6b318d1 100644
--- a/arch/powerpc/mm/ptdump/bats.c
+++ b/arch/powerpc/mm/ptdump/bats.c
@@ -164,10 +164,8 @@ static const struct file_operations bats_fops = {
static int __init bats_init(void)
{
- struct dentry *debugfs_file;
-
- debugfs_file = debugfs_create_file("block_address_translation", 0400,
- powerpc_debugfs_root, NULL, &bats_fops);
- return debugfs_file ? 0 : -ENOMEM;
+ debugfs_create_file("block_address_translation", 0400,
+ powerpc_debugfs_root, NULL, &bats_fops);
+ return 0;
}
device_initcall(bats_init);
diff --git a/arch/powerpc/mm/ptdump/hashpagetable.c b/arch/powerpc/mm/ptdump/hashpagetable.c
index a07278027c6f..b6ed9578382f 100644
--- a/arch/powerpc/mm/ptdump/hashpagetable.c
+++ b/arch/powerpc/mm/ptdump/hashpagetable.c
@@ -527,13 +527,10 @@ static const struct file_operations ptdump_fops = {
static int ptdump_init(void)
{
- struct dentry *debugfs_file;
-
if (!radix_enabled()) {
populate_markers();
- debugfs_file = debugfs_create_file("kernel_hash_pagetable",
- 0400, NULL, NULL, &ptdump_fops);
- return debugfs_file ? 0 : -ENOMEM;
+ debugfs_create_file("kernel_hash_pagetable", 0400, NULL, NULL,
+ &ptdump_fops);
}
return 0;
}
diff --git a/arch/powerpc/mm/ptdump/ptdump.c b/arch/powerpc/mm/ptdump/ptdump.c
index 206156255247..d92bb8ea229c 100644
--- a/arch/powerpc/mm/ptdump/ptdump.c
+++ b/arch/powerpc/mm/ptdump/ptdump.c
@@ -417,12 +417,10 @@ void ptdump_check_wx(void)
static int ptdump_init(void)
{
- struct dentry *debugfs_file;
-
populate_markers();
build_pgtable_complete_mask();
- debugfs_file = debugfs_create_file("kernel_page_tables", 0400, NULL,
- NULL, &ptdump_fops);
- return debugfs_file ? 0 : -ENOMEM;
+ debugfs_create_file("kernel_page_tables", 0400, NULL, NULL,
+ &ptdump_fops);
+ return 0;
}
device_initcall(ptdump_init);
diff --git a/arch/powerpc/mm/ptdump/segment_regs.c b/arch/powerpc/mm/ptdump/segment_regs.c
index 501843664bb9..dde2fe8de4b2 100644
--- a/arch/powerpc/mm/ptdump/segment_regs.c
+++ b/arch/powerpc/mm/ptdump/segment_regs.c
@@ -55,10 +55,8 @@ static const struct file_operations sr_fops = {
static int __init sr_init(void)
{
- struct dentry *debugfs_file;
-
- debugfs_file = debugfs_create_file("segment_registers", 0400,
- powerpc_debugfs_root, NULL, &sr_fops);
- return debugfs_file ? 0 : -ENOMEM;
+ debugfs_create_file("segment_registers", 0400, powerpc_debugfs_root,
+ NULL, &sr_fops);
+ return 0;
}
device_initcall(sr_init);
--
2.25.0
^ permalink raw reply related
* [PATCH 3/6] powerpc: mm: book3s64: hash_utils: 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, Nicholas Piggin, Paul Mackerras, Aneesh Kumar K.V,
Greg Kroah-Hartman
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: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
Cc: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/mm/book3s64/hash_utils.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/mm/book3s64/hash_utils.c b/arch/powerpc/mm/book3s64/hash_utils.c
index 523d4d39d11e..7e5714a69a58 100644
--- a/arch/powerpc/mm/book3s64/hash_utils.c
+++ b/arch/powerpc/mm/book3s64/hash_utils.c
@@ -2018,11 +2018,8 @@ DEFINE_DEBUGFS_ATTRIBUTE(fops_hpt_order, hpt_order_get, hpt_order_set, "%llu\n")
static int __init hash64_debugfs(void)
{
- if (!debugfs_create_file_unsafe("hpt_order", 0600, powerpc_debugfs_root,
- NULL, &fops_hpt_order)) {
- pr_err("lpar: unable to create hpt_order debugsfs file\n");
- }
-
+ debugfs_create_file("hpt_order", 0600, powerpc_debugfs_root, NULL,
+ &fops_hpt_order);
return 0;
}
machine_device_initcall(pseries, hash64_debugfs);
--
2.25.0
^ permalink raw reply related
* [PATCH 2/6] powerpc: kvm: 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: Greg Kroah-Hartman, linux-kernel, kvm-ppc
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.
Because of this cleanup, we get to remove a few fields in struct
kvm_arch that are now unused.
Cc: Paul Mackerras <paulus@ozlabs.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: kvm-ppc@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/include/asm/kvm_host.h | 3 ---
arch/powerpc/kvm/book3s_64_mmu_hv.c | 5 ++---
arch/powerpc/kvm/book3s_64_mmu_radix.c | 5 ++---
arch/powerpc/kvm/book3s_hv.c | 9 ++-------
arch/powerpc/kvm/timing.c | 13 +++----------
5 files changed, 9 insertions(+), 26 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
index 6e8b8ffd06ad..877f8aa2bc1e 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -308,8 +308,6 @@ struct kvm_arch {
pgd_t *pgtable;
u64 process_table;
struct dentry *debugfs_dir;
- struct dentry *htab_dentry;
- struct dentry *radix_dentry;
struct kvm_resize_hpt *resize_hpt; /* protected by kvm->lock */
#endif /* CONFIG_KVM_BOOK3S_HV_POSSIBLE */
#ifdef CONFIG_KVM_BOOK3S_PR_POSSIBLE
@@ -830,7 +828,6 @@ struct kvm_vcpu_arch {
struct kvmhv_tb_accumulator cede_time; /* time napping inside guest */
struct dentry *debugfs_dir;
- struct dentry *debugfs_timings;
#endif /* CONFIG_KVM_BOOK3S_HV_EXIT_TIMING */
};
diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c b/arch/powerpc/kvm/book3s_64_mmu_hv.c
index 6c372f5c61b6..8b4eac0c9dcd 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
@@ -2138,9 +2138,8 @@ static const struct file_operations debugfs_htab_fops = {
void kvmppc_mmu_debugfs_init(struct kvm *kvm)
{
- kvm->arch.htab_dentry = debugfs_create_file("htab", 0400,
- kvm->arch.debugfs_dir, kvm,
- &debugfs_htab_fops);
+ debugfs_create_file("htab", 0400, kvm->arch.debugfs_dir, kvm,
+ &debugfs_htab_fops);
}
void kvmppc_mmu_book3s_hv_init(struct kvm_vcpu *vcpu)
diff --git a/arch/powerpc/kvm/book3s_64_mmu_radix.c b/arch/powerpc/kvm/book3s_64_mmu_radix.c
index 803940d79b73..1d75ed684b53 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_radix.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_radix.c
@@ -1376,9 +1376,8 @@ static const struct file_operations debugfs_radix_fops = {
void kvmhv_radix_debugfs_init(struct kvm *kvm)
{
- kvm->arch.radix_dentry = debugfs_create_file("radix", 0400,
- kvm->arch.debugfs_dir, kvm,
- &debugfs_radix_fops);
+ debugfs_create_file("radix", 0400, kvm->arch.debugfs_dir, kvm,
+ &debugfs_radix_fops);
}
int kvmppc_radix_init(void)
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 2cefd071b848..33be4d93248a 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -2258,14 +2258,9 @@ static void debugfs_vcpu_init(struct kvm_vcpu *vcpu, unsigned int id)
struct kvm *kvm = vcpu->kvm;
snprintf(buf, sizeof(buf), "vcpu%u", id);
- if (IS_ERR_OR_NULL(kvm->arch.debugfs_dir))
- return;
vcpu->arch.debugfs_dir = debugfs_create_dir(buf, kvm->arch.debugfs_dir);
- if (IS_ERR_OR_NULL(vcpu->arch.debugfs_dir))
- return;
- vcpu->arch.debugfs_timings =
- debugfs_create_file("timings", 0444, vcpu->arch.debugfs_dir,
- vcpu, &debugfs_timings_ops);
+ debugfs_create_file("timings", 0444, vcpu->arch.debugfs_dir, vcpu,
+ &debugfs_timings_ops);
}
#else /* CONFIG_KVM_BOOK3S_HV_EXIT_TIMING */
diff --git a/arch/powerpc/kvm/timing.c b/arch/powerpc/kvm/timing.c
index bfe4f106cffc..8e4791c6f2af 100644
--- a/arch/powerpc/kvm/timing.c
+++ b/arch/powerpc/kvm/timing.c
@@ -207,19 +207,12 @@ static const struct file_operations kvmppc_exit_timing_fops = {
void kvmppc_create_vcpu_debugfs(struct kvm_vcpu *vcpu, unsigned int id)
{
static char dbg_fname[50];
- struct dentry *debugfs_file;
snprintf(dbg_fname, sizeof(dbg_fname), "vm%u_vcpu%u_timing",
current->pid, id);
- debugfs_file = debugfs_create_file(dbg_fname, 0666,
- kvm_debugfs_dir, vcpu,
- &kvmppc_exit_timing_fops);
-
- if (!debugfs_file) {
- printk(KERN_ERR"%s: error creating debugfs file %s\n",
- __func__, dbg_fname);
- return;
- }
+ debugfs_create_file(dbg_fname, 0666, kvm_debugfs_dir, vcpu,
+ &kvmppc_exit_timing_fops);
+
vcpu->arch.debugfs_exit_timing = debugfs_file;
}
--
2.25.0
^ permalink raw reply related
* Re: [PATCH] powerpc/hugetlb: Fix 8M hugepages on 8xx
From: Christophe Leroy @ 2020-02-09 11:05 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
aneesh.kumar
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <e744db1529271d11a3fdcdf641617846907b6ffd.1580997012.git.christophe.leroy@c-s.fr>
Le 06/02/2020 à 14:50, Christophe Leroy a écrit :
> Commit 55c8fc3f4930 ("powerpc/8xx: reintroduce 16K pages with HW
> assistance") redefined pte_t as a struct of 4 pte_basic_t, because
> in 16K pages mode there are four identical entries in the page table.
> But hugepd entries for 8k pages require only one entrie of size
> pte_basic_t. So there is no point in creating a cache for 4 entries
> page tables.
>
> Also, with HW assistance the entries must be 4k aligned, the 8xx
> drops the last 12 bits. Redefine HUGEPD_SHIFT_MASK to mask them out.
>
> Calculate PTE_T_ORDER using the size of pte_basic_t instead of pte_t.
>
> In 16k mode, define a specific set_huge_pte_at() function which writes
> the pte in a single entry instead of using set_pte_at() which writes
> 4 identical entries. Define set_pte_filter() inline otherwise GCC
> doesn't inline it anymore because it is now used twice, and that gives
> a pretty suboptimal code because of pte_t being a struct of 4 entries.
> This function is also used for 512k pages which only require one entry
> as well allthough replicating it four times is harmless as 512k pages
> entries are spread every 128 bytes in the table.
That's not enough. We also need to change huge_ptep_set_access_flags(),
huge_pte_clear(), huge_ptep_set_wrprotect() and huge_ptep_get_and_clear()
Will leave it as is at the time being, in parallele I'm working on
getting rid of CONFIG_PPC_MM_SLICES for the 8xx and that fix that.
Christophe
>
> 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>
> ---
> arch/powerpc/include/asm/hugetlb.h | 5 +++++
> arch/powerpc/include/asm/page.h | 5 +++++
> arch/powerpc/mm/hugetlbpage.c | 3 ++-
> arch/powerpc/mm/pgtable.c | 19 ++++++++++++++++++-
> 4 files changed, 30 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/hugetlb.h b/arch/powerpc/include/asm/hugetlb.h
> index bd6504c28c2f..f43cfbcf014f 100644
> --- a/arch/powerpc/include/asm/hugetlb.h
> +++ b/arch/powerpc/include/asm/hugetlb.h
> @@ -64,6 +64,11 @@ static inline void arch_clear_hugepage_flags(struct page *page)
> {
> }
>
> +#if defined(CONFIG_PPC_8xx) && defined(CONFIG_PPC_16K_PAGES)
> +#define __HAVE_ARCH_HUGE_SET_HUGE_PTE_AT
> +void set_huge_pte_at(struct mm_struct *mm, unsigned long addr, pte_t *ptep, pte_t pte);
> +#endif
> +
> #include <asm-generic/hugetlb.h>
>
> #else /* ! CONFIG_HUGETLB_PAGE */
> 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__
>
> diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
> index 73d4873fc7f8..c61032580185 100644
> --- a/arch/powerpc/mm/hugetlbpage.c
> +++ b/arch/powerpc/mm/hugetlbpage.c
> @@ -30,7 +30,8 @@ bool hugetlb_disabled = false;
>
> #define hugepd_none(hpd) (hpd_val(hpd) == 0)
>
> -#define PTE_T_ORDER (__builtin_ffs(sizeof(pte_t)) - __builtin_ffs(sizeof(void *)))
> +#define PTE_T_ORDER (__builtin_ffs(sizeof(pte_basic_t)) - \
> + __builtin_ffs(sizeof(void *)))
>
> pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr, unsigned long sz)
> {
> diff --git a/arch/powerpc/mm/pgtable.c b/arch/powerpc/mm/pgtable.c
> index e3759b69f81b..7a38eaa6ca72 100644
> --- a/arch/powerpc/mm/pgtable.c
> +++ b/arch/powerpc/mm/pgtable.c
> @@ -100,7 +100,7 @@ static pte_t set_pte_filter_hash(pte_t pte) { return pte; }
> * as we don't have two bits to spare for _PAGE_EXEC and _PAGE_HWEXEC so
> * instead we "filter out" the exec permission for non clean pages.
> */
> -static pte_t set_pte_filter(pte_t pte)
> +static inline pte_t set_pte_filter(pte_t pte)
> {
> struct page *pg;
>
> @@ -259,6 +259,23 @@ int huge_ptep_set_access_flags(struct vm_area_struct *vma,
> return changed;
> #endif
> }
> +
> +#if defined(CONFIG_PPC_8xx) && defined(CONFIG_PPC_16K_PAGES)
> +void set_huge_pte_at(struct mm_struct *mm, unsigned long addr, pte_t *ptep, pte_t pte)
> +{
> + /*
> + * Make sure hardware valid bit is not set. We don't do
> + * tlb flush for this update.
> + */
> + VM_WARN_ON(pte_hw_valid(*ptep) && !pte_protnone(*ptep));
> +
> + pte = pte_mkpte(pte);
> +
> + pte = set_pte_filter(pte);
> +
> + ptep->pte = pte_val(pte);
> +}
> +#endif
> #endif /* CONFIG_HUGETLB_PAGE */
>
> #ifdef CONFIG_DEBUG_VM
>
^ permalink raw reply
* [powerpc:fixes-test] BUILD SUCCESS d4bf905307a1c90a27714ff7a9fd29b0a2ceed98
From: kbuild test robot @ 2020-02-09 6:18 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git fixes-test
branch HEAD: d4bf905307a1c90a27714ff7a9fd29b0a2ceed98 powerpc: Fix CONFIG_TRACE_IRQFLAGS with CONFIG_VMAP_STACK
elapsed time: 1025m
configs tested: 45
configs skipped: 143
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
mips allyesconfig
powerpc defconfig
ia64 allyesconfig
parisc b180_defconfig
csky defconfig
sh rsk7269_defconfig
arc allyesconfig
s390 defconfig
powerpc ppc64_defconfig
openrisc or1ksim_defconfig
arc defconfig
microblaze mmu_defconfig
microblaze nommu_defconfig
powerpc allnoconfig
powerpc rhel-kconfig
parisc allnoconfig
parisc allyesconfig
parisc c3000_defconfig
parisc defconfig
s390 alldefconfig
s390 allmodconfig
s390 allnoconfig
s390 allyesconfig
s390 debug_defconfig
s390 zfcpdump_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: [GIT PULL] Please pull powerpc/linux.git powerpc-5.6-2 tag
From: pr-tracker-bot @ 2020-02-08 22:35 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Linus Torvalds, linux-kernel
In-Reply-To: <87ftfl1bs4.fsf@mpe.ellerman.id.au>
The pull request you sent on Sat, 08 Feb 2020 23:52:43 +1100:
> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.6-2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/d4f309ca411887cd61ea389c7abfb70c2eb1e532
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
^ permalink raw reply
* Re: Latest Git kernel: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device
From: Christian Zigotzky @ 2020-02-08 16:08 UTC (permalink / raw)
To: Arnd Bergmann
Cc: DTML, Darren Stevens, mad skateman, Linux Kernel Mailing List,
linuxppc-dev, contact@a-eon.com, R.T.Dickinson,
netdev@vger.kernel.org, Jakub Kicinski, Christoph Hellwig,
Christian Zigotzky
In-Reply-To: <834D35CA-F0D5-43EC-97B2-2E97B4DA7703@xenosoft.de>
On 08 February 2020 at 07:59 am, Christian Zigotzky wrote:
>
>> On 7. Feb 2020, at 18:08, Arnd Bergmann <arnd@arndb.de> wrote:
>>
>> On Fri, Feb 7, 2020 at 3:34 PM Christian Zigotzky
>> <chzigotzky@xenosoft.de> wrote:
>>> Hello Arnd,
>>>
>>> We regularly compile and test Linux kernels every day during the merge
>>> window. Since Thursday last week we have very high CPU usage because of
>>> the avahi daemon on our desktop Linux systems (Ubuntu, Debian etc). The
>>> avahi daemon produces a lot of the following log message. This generates
>>> high CPU usage.
>>>
>>> Error message: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device
>>>
>>> strace /usr/sbin/avahi-daemon:
>>>
>> Thanks a lot for the detailed analysis, with this I immediately saw
>> what went wrong in my
>> original commit and I sent you a fix. Please test to ensure that this
>> correctly addresses
>> the problem.
>>
>> Arnd
> Hi Arnd,
>
> Thanks a lot for your patch! I will test it as soon as possible.
>
> Cheers,
> Christian
Hi Arnd,
I successfully compiled the latest Git kernel with your patch today. The
avahi daemon works fine now. That means your patch has solved the avahi
issue.
Thanks for your patch and have a nice weekend!
Cheers,
Christian
^ permalink raw reply
* [PATCH 2/2] powerpc/83xx: Add some error handling in 'quirk_mpc8360e_qe_enet10()'
From: Christophe JAILLET @ 2020-02-08 14:09 UTC (permalink / raw)
To: oss, galak, benh, paulus, mpe
Cc: kernel-janitors, Christophe JAILLET, linuxppc-dev, linux-kernel
In some error handling path, we should call "of_node_put(np_par)" or
some resource may be leaking in case of error.
Fixes: 8159df72d43e ("83xx: add support for the kmeter1 board.")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
arch/powerpc/platforms/83xx/km83xx.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/83xx/km83xx.c b/arch/powerpc/platforms/83xx/km83xx.c
index 306be75faec7..bcdc2c203ec9 100644
--- a/arch/powerpc/platforms/83xx/km83xx.c
+++ b/arch/powerpc/platforms/83xx/km83xx.c
@@ -60,10 +60,12 @@ static void quirk_mpc8360e_qe_enet10(void)
ret = of_address_to_resource(np_par, 0, &res);
if (ret) {
pr_warn("%s couldn't map par_io registers\n", __func__);
- return;
+ goto out;
}
base = ioremap(res.start, resource_size(&res));
+ if (!base)
+ goto out;
/*
* set output delay adjustments to default values according
@@ -111,6 +113,7 @@ static void quirk_mpc8360e_qe_enet10(void)
setbits32((base + 0xac), 0x0000c000);
}
iounmap(base);
+out:
of_node_put(np_par);
}
--
2.20.1
^ permalink raw reply related
* [PATCH 1/2] powerpc/83xx: Fix some typo in some warning message
From: Christophe JAILLET @ 2020-02-08 14:09 UTC (permalink / raw)
To: oss, galak, benh, paulus, mpe
Cc: kernel-janitors, Christophe JAILLET, linuxppc-dev, linux-kernel
"couldn;t" should be "couldn't".
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
arch/powerpc/platforms/83xx/km83xx.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/83xx/km83xx.c b/arch/powerpc/platforms/83xx/km83xx.c
index ada42f03915a..306be75faec7 100644
--- a/arch/powerpc/platforms/83xx/km83xx.c
+++ b/arch/powerpc/platforms/83xx/km83xx.c
@@ -53,13 +53,13 @@ static void quirk_mpc8360e_qe_enet10(void)
np_par = of_find_node_by_name(NULL, "par_io");
if (np_par == NULL) {
- pr_warn("%s couldn;t find par_io node\n", __func__);
+ pr_warn("%s couldn't find par_io node\n", __func__);
return;
}
/* Map Parallel I/O ports registers */
ret = of_address_to_resource(np_par, 0, &res);
if (ret) {
- pr_warn("%s couldn;t map par_io registers\n", __func__);
+ pr_warn("%s couldn't map par_io registers\n", __func__);
return;
}
--
2.20.1
^ permalink raw reply related
* [GIT PULL] Please pull powerpc/linux.git powerpc-5.6-2 tag
From: Michael Ellerman @ 2020-02-08 12:52 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev, linux-kernel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi Linus,
Please pull two powerpc fixes for 5.6:
The following changes since commit 71c3a888cbcaf453aecf8d2f8fb003271d28073f:
Merge tag 'powerpc-5.6-1' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux (2020-02-04 13:06:46 +0000)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.6-2
for you to fetch changes up to d4bf905307a1c90a27714ff7a9fd29b0a2ceed98:
powerpc: Fix CONFIG_TRACE_IRQFLAGS with CONFIG_VMAP_STACK (2020-02-08 21:49:06 +1100)
- ------------------------------------------------------------------
powerpc fixes for 5.6 #2
Fix an existing bug in our user access handling, exposed by one of the bug fixes
we merged this cycle.
A fix for a boot hang on 32-bit with CONFIG_TRACE_IRQFLAGS and the recently
added CONFIG_VMAP_STACK.
Thanks to:
Christophe Leroy, Guenter Roeck.
- ------------------------------------------------------------------
Christophe Leroy (1):
powerpc: Fix CONFIG_TRACE_IRQFLAGS with CONFIG_VMAP_STACK
Michael Ellerman (1):
powerpc/futex: Fix incorrect user access blocking
arch/powerpc/include/asm/futex.h | 10 ++++++----
arch/powerpc/kernel/entry_32.S | 2 +-
2 files changed, 7 insertions(+), 5 deletions(-)
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAl4+rucACgkQUevqPMjh
pYBy4Q/+OHH+G3jPH2sCPycqXNh3e0XbAymtAH7v01Lj6c1BSiWhvq1vP58mEeUM
TwssxNgQC7ZeltOHwZc/0GA7WPp4cYuHIU0XVuxKmj8LvWM3gqC0WUbaMkbz1uvz
mM5IN+WA9ENvzEX4A4y5vKzM/pEMVkyyXOluaUmFWCT+94bapYqlKUjeQqYySxwu
js4qBAuMULl4qr3zgMAa4WS3v3XgJ+Zj5v3Rh0O/ITpV/qv+/lQrBYlI6Q48/L5x
hYmQa+3ahCaVtxLnsDpZHrvfiv8UKpgZMjNYPgDfv0nPjTsngTXGB2RtLlD63a4t
Ve2uHLxoSvHGn2TTgUJ7N+VDuqGEYzHv0Ulg72SQBGz5kUKGeS8h0EdDI2naUNTS
OTicNI/DaGv9zCTChSXHEgrLc6mR+qLaamgqwjljF9iIxlKhr2cyD9/02d3XtrHH
2EKm8LCy+5pCtFjReUk+fENU9MZQ5+bYHtk/svcHCC63XXquHzwE+NdB6Whz/QPz
iV5NQW8EtU74u+wkPjdsmqta1IMmYzoisc4IULGEXgFJSjgYdYchkpKd0mf49QMG
Wmd4HQR5iMi2w2YiE25hyqa3nxWjHY2y3TV+b1JZZ4sAKOKCNLLZ6ey989SZKraw
xP9G/r7H7/TtMVA0aC1fcjVnxPzU4d+ygpVBtqL8u7T3/pul9dg=
=mWQt
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH] powerpc: Fix CONFIG_TRACE_IRQFLAGS with CONFIG_VMAP_STACK
From: Michael Ellerman @ 2020-02-08 12:50 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras,
Guenter Roeck
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <daeacdc0dec0416d1c587cc9f9e7191ad3068dc0.1581095957.git.christophe.leroy@c-s.fr>
On Fri, 2020-02-07 at 17:20:57 UTC, Christophe Leroy wrote:
> When CONFIG_PROVE_LOCKING is selected together with (now default)
> CONFIG_VMAP_STACK, kernel enter deadlock during boot.
>
> At the point of checking whether interrupts are enabled or not, the
> value of MSR saved on stack is read using the physical address of the
> stack. But at this point, when using VMAP stack the DATA MMU
> translation has already been re-enabled, leading to deadlock.
>
> Don't use the physical address of the stack when
> CONFIG_VMAP_STACK is set.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> Reported-by: Guenter Roeck <linux@roeck-us.net>
> Fixes: 028474876f47 ("powerpc/32: prepare for CONFIG_VMAP_STACK")
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/d4bf905307a1c90a27714ff7a9fd29b0a2ceed98
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/futex: Fix incorrect user access blocking
From: Michael Ellerman @ 2020-02-08 12:50 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: dja
In-Reply-To: <20200207122145.11928-1-mpe@ellerman.id.au>
On Fri, 2020-02-07 at 12:21:45 UTC, Michael Ellerman wrote:
> The early versions of our kernel user access prevention (KUAP) were
> written by Russell and Christophe, and didn't have separate
> read/write access.
>
> At some point I picked up the series and added the read/write access,
> but I failed to update the usages in futex.h to correctly allow read
> and write.
>
> However we didn't notice because of another bug which was causing the
> low-level code to always enable read and write. That bug was fixed
> recently in commit 1d8f739b07bd ("powerpc/kuap: Fix set direction in
> allow/prevent_user_access()").
>
> futex_atomic_cmpxchg_inatomic() is passed the user address as %3 and
> does:
>
> 1: lwarx %1, 0, %3
> cmpw 0, %1, %4
> bne- 3f
> 2: stwcx. %5, 0, %3
>
> Which clearly loads and stores from/to %3. The logic in
> arch_futex_atomic_op_inuser() is similar, so fix both of them to use
> allow_read_write_user().
>
> Without this fix, and with PPC_KUAP_DEBUG=y, we see eg:
>
> Bug: Read fault blocked by AMR!
> WARNING: CPU: 94 PID: 149215 at arch/powerpc/include/asm/book3s/64/kup-radix.h:126 __do_page_fault+0x600/0xf30
> CPU: 94 PID: 149215 Comm: futex_requeue_p Tainted: G W 5.5.0-rc7-gcc9x-g4c25df5640ae #1
> ...
> NIP [c000000000070680] __do_page_fault+0x600/0xf30
> LR [c00000000007067c] __do_page_fault+0x5fc/0xf30
> Call Trace:
> [c00020138e5637e0] [c00000000007067c] __do_page_fault+0x5fc/0xf30 (unreliable)
> [c00020138e5638c0] [c00000000000ada8] handle_page_fault+0x10/0x30
> --- interrupt: 301 at cmpxchg_futex_value_locked+0x68/0xd0
> LR = futex_lock_pi_atomic+0xe0/0x1f0
> [c00020138e563bc0] [c000000000217b50] futex_lock_pi_atomic+0x80/0x1f0 (unreliable)
> [c00020138e563c30] [c00000000021b668] futex_requeue+0x438/0xb60
> [c00020138e563d60] [c00000000021c6cc] do_futex+0x1ec/0x2b0
> [c00020138e563d90] [c00000000021c8b8] sys_futex+0x128/0x200
> [c00020138e563e20] [c00000000000b7ac] system_call+0x5c/0x68
>
> Fixes: de78a9c42a79 ("powerpc: Add a framework for Kernel Userspace Access Protection")
> Cc: stable@vger.kernel.org # v5.2+
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Applied to powerpc fixes.
https://git.kernel.org/powerpc/c/9dc086f1e9ef39dd823bd27954b884b2062f9e70
cheers
^ permalink raw reply
* Re: Latest Git kernel: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device
From: Michael Ellerman @ 2020-02-08 12:36 UTC (permalink / raw)
To: Christian Zigotzky, Jakub Kicinski
Cc: DTML, Darren Stevens, mad skateman, netdev@vger.kernel.org,
Linux Kernel Mailing List, linuxppc-dev, contact@a-eon.com,
R.T.Dickinson, Christoph Hellwig
In-Reply-To: <f438e4ed-7746-1d80-6d72-455281884a1e@xenosoft.de>
Christian Zigotzky <chzigotzky@xenosoft.de> writes:
> On 06 February 2020 at 05:35 am, Michael Ellerman wrote:
>> Christian Zigotzky <chzigotzky@xenosoft.de> writes:
>>> Kernel 5.5 PowerPC is also affected.
>> I don't know what you mean by that. What sha are you talking about?
>>
>> I have a system with avahi running and everything's fine.
>>
>> # grep use- /etc/avahi/avahi-daemon.conf
>> use-ipv4=yes
>> use-ipv6=yes
>>
>> # systemctl status -l --no-pager avahi-daemon
>> ● avahi-daemon.service - Avahi mDNS/DNS-SD Stack
>> Loaded: loaded (/lib/systemd/system/avahi-daemon.service; enabled; vendor preset: enabled)
>> Active: active (running) since Thu 2020-02-06 14:55:34 AEDT; 38min ago
>> Main PID: 1884 (avahi-daemon)
>> Status: "avahi-daemon 0.7 starting up."
>> CGroup: /system.slice/avahi-daemon.service
>> ├─1884 avahi-daemon: running [mpe-ubuntu-le.local]
>> └─1888 avahi-daemon: chroot helper
>>
>> Feb 06 14:55:34 mpe-ubuntu-le avahi-daemon[1884]: Registering new address record for fe80::5054:ff:fe66:2a19 on eth0.*.
>> Feb 06 14:55:34 mpe-ubuntu-le avahi-daemon[1884]: Registering new address record for 10.61.141.81 on eth0.IPv4.
>> Feb 06 14:55:34 mpe-ubuntu-le avahi-daemon[1884]: Registering new address record for ::1 on lo.*.
>> Feb 06 14:55:34 mpe-ubuntu-le avahi-daemon[1884]: Registering new address record for 127.0.0.1 on lo.IPv4.
>> Feb 06 14:55:34 mpe-ubuntu-le systemd[1]: Started Avahi mDNS/DNS-SD Stack.
>> Feb 06 14:55:35 mpe-ubuntu-le avahi-daemon[1884]: Server startup complete. Host name is mpe-ubuntu-le.local. Local service cookie is 3972418141.
>> Feb 06 14:55:38 mpe-ubuntu-le avahi-daemon[1884]: Leaving mDNS multicast group on interface eth0.IPv6 with address fe80::5054:ff:fe66:2a19.
>> Feb 06 14:55:38 mpe-ubuntu-le avahi-daemon[1884]: Joining mDNS multicast group on interface eth0.IPv6 with address fd69:d75f:b8b5:61:5054:ff:fe66:2a19.
>> Feb 06 14:55:38 mpe-ubuntu-le avahi-daemon[1884]: Registering new address record for fd69:d75f:b8b5:61:5054:ff:fe66:2a19 on eth0.*.
>> Feb 06 14:55:38 mpe-ubuntu-le avahi-daemon[1884]: Withdrawing address record for fe80::5054:ff:fe66:2a19 on eth0.
>>
>> # uname -r
>> 5.5.0-gcc-8.2.0
>>
>>
>> The key question is what ioctl is it complaining about. You should be
>> able to find that via strace.
>>
>> cheers
>>
> Hello Michael,
>
> Sorry it isn't true that the kernel 5.5 is also affected. A Power Mac G5
> user told me that but this isn't correct. I compiled and tested the
> stable kernel 5.5.1 and 5.5.2 today and both kernels don't have the
> issue with the avahi daemon.
OK good to know.
> Could you please also test the latest Git kernel?
That's literally all I ever do.
The problem here is you didn't tell me you were running a big endian
distro, which uses compat mode.
In hindsight I should have thought of that.
Now that I know that, I can reproduce the bug:
Feb 08 23:31:12 mpe-ubuntu-be avahi-daemon[24819]: ioctl(): Inappropriate ioctl for device
Feb 08 23:31:12 mpe-ubuntu-be avahi-daemon[24819]: ioctl(): Inappropriate ioctl for device
Feb 08 23:31:12 mpe-ubuntu-be avahi-daemon[24819]: ioctl(): Inappropriate ioctl for device
Feb 08 23:31:12 mpe-ubuntu-be avahi-daemon[24819]: ioctl(): Inappropriate ioctl for device
But it seems you've already identified the problem commit, thanks for
bisecting.
I'm sure Arnd will be able to fix it now that you've identified the
problematic commit.
cheers
> strace /usr/sbin/avahi-daemon
>
> ...
> poll([{fd=4, events=POLLIN}, {fd=16, events=POLLIN}, {fd=15,
> events=POLLIN}, {fd=14, events=POLLIN}, {fd=13, events=POLLIN}, {fd=12,
> events=POLLIN}, {fd=11, events=POLLIN}, {fd=10, events=POLLIN}, {fd=9,
> events=POLLIN}, {fd=8, events=POLLIN}, {fd=6, events=POLLIN}], 11, 65) =
> 2 ([{fd=12, revents=POLLIN}, {fd=9, revents=POLLIN}])
> ioctl(12, FIONREAD, 0xffba6f24) = -1 ENOTTY (Inappropriate ioctl
> for device)
> write(2, "ioctl(): Inappropriate ioctl for"..., 39ioctl(): Inappropriate
> ioctl for device) = 39
> write(2, "\n", 1
> ) = 1
> ...
>
> Thanks,
> Christian
^ permalink raw reply
* Re: Latest Git kernel: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device
From: Christian Zigotzky @ 2020-02-08 6:59 UTC (permalink / raw)
To: Arnd Bergmann
Cc: DTML, Darren Stevens, mad skateman, Linux Kernel Mailing List,
linuxppc-dev, contact@a-eon.com, R.T.Dickinson,
netdev@vger.kernel.org, Jakub Kicinski, Christoph Hellwig,
Christian Zigotzky
In-Reply-To: <CAK8P3a39L5i4aEbKe9CiW6unbioL=T8GqXC007mXxUu+_j84FA@mail.gmail.com>
> On 7. Feb 2020, at 18:08, Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Fri, Feb 7, 2020 at 3:34 PM Christian Zigotzky
> <chzigotzky@xenosoft.de> wrote:
>>
>> Hello Arnd,
>>
>> We regularly compile and test Linux kernels every day during the merge
>> window. Since Thursday last week we have very high CPU usage because of
>> the avahi daemon on our desktop Linux systems (Ubuntu, Debian etc). The
>> avahi daemon produces a lot of the following log message. This generates
>> high CPU usage.
>>
>> Error message: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device
>>
>> strace /usr/sbin/avahi-daemon:
>>
>
> Thanks a lot for the detailed analysis, with this I immediately saw
> what went wrong in my
> original commit and I sent you a fix. Please test to ensure that this
> correctly addresses
> the problem.
>
> Arnd
Hi Arnd,
Thanks a lot for your patch! I will test it as soon as possible.
Cheers,
Christian
^ permalink raw reply
* Re: [PATCH 18/18] powerpc/fault: Use analyse_instr() to check for store with updates to sp
From: Jordan Niethe @ 2020-02-08 0:28 UTC (permalink / raw)
To: Greg Kurz; +Cc: Alistair Popple, linuxppc-dev, Daniel Axtens
In-Reply-To: <20200207091555.59442fac@bahia.lan>
On Fri, Feb 7, 2020 at 7:16 PM Greg Kurz <groug@kaod.org> wrote:
>
> On Thu, 19 Dec 2019 01:11:33 +1100
> Daniel Axtens <dja@axtens.net> wrote:
>
> > Jordan Niethe <jniethe5@gmail.com> writes:
> >
> > > A user-mode access to an address a long way below the stack pointer is
> > > only valid if the instruction is one that would update the stack pointer
> > > to the address accessed. This is checked by directly looking at the
> > > instructions op-code. As a result is does not take into account prefixed
> > > instructions. Instead of looking at the instruction our self, use
> > > analyse_instr() determine if this a store instruction that will update
> > > the stack pointer.
> > >
> > > Something to note is that there currently are not any store with update
> > > prefixed instructions. Actually there is no plan for prefixed
> > > update-form loads and stores. So this patch is probably not needed but
> > > it might be preferable to use analyse_instr() rather than open coding
> > > the test anyway.
> >
> > Yes please. I was looking through this code recently and was
> > horrified. This improves things a lot and I think is justification
> > enough as-is.
> >
>
> Except it doesn't work... I'm now experiencing a systematic crash of
> systemd at boot in my fedora31 guest:
>
> [ 3.322912] systemd[1]: segfault (11) at 7ffff3eaf550 nip 7ce4d42f8d78 lr 9d82c098fc0 code 1 in libsystemd-shared-243.so[7ce4d4150000+2e0000]
> [ 3.323112] systemd[1]: code: 00000480 60420000 3c4c001e 3842edb0 7c0802a6 3d81fff0 fb81ffe0 fba1ffe8
> [ 3.323244] systemd[1]: code: fbc1fff0 fbe1fff8 f8010010 7c200b78 <f801f001> 7c216000 4082fff8 f801ff71
>
> f801f001 is
>
> 0x1a8d78 <serialize_item_format+40>: stdu r0,-4096(r1)
>
> which analyse_instr() is supposed to decode as a STORE that
> updates r1 so we should be good... Unfortunately analyse_instr()
> forbids partial register sets, since it might return op->val
> based on some register content depending on the instruction:
>
> /* Following cases refer to regs->gpr[], so we need all regs */
> if (!FULL_REGS(regs))
> return -1;
>
> analyse_instr() was introduced with instruction emulation in mind, which
> goes far beyond the need we have in store_updates_sp(). Especially the
> fault path doesn't care for the register content at all...
>
> Not sure how to cope with that correctly (refactor analyse_instr() ? ) but
> until someone comes up with a solution, please don't merge this patch.
>
> Cheers,
>
> --
> Greg
Thank you this information. I agree analyse_instr() is overkill for
the situation
especially as there are no prefixed store-with-updates. I am going to drop this
patch from the series.
>
> > Regards,
> > Daniel
> > >
> > > Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
> > > ---
> > > arch/powerpc/mm/fault.c | 39 +++++++++++----------------------------
> > > 1 file changed, 11 insertions(+), 28 deletions(-)
> > >
> > > diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
> > > index b5047f9b5dec..cb78b3ca1800 100644
> > > --- a/arch/powerpc/mm/fault.c
> > > +++ b/arch/powerpc/mm/fault.c
> > > @@ -41,37 +41,17 @@
> > > #include <asm/siginfo.h>
> > > #include <asm/debug.h>
> > > #include <asm/kup.h>
> > > +#include <asm/sstep.h>
> > >
> > > /*
> > > * Check whether the instruction inst is a store using
> > > * an update addressing form which will update r1.
> > > */
> > > -static bool store_updates_sp(unsigned int inst)
> > > +static bool store_updates_sp(struct instruction_op *op)
> > > {
> > > - /* check for 1 in the rA field */
> > > - if (((inst >> 16) & 0x1f) != 1)
> > > - return false;
> > > - /* check major opcode */
> > > - switch (inst >> 26) {
> > > - case OP_STWU:
> > > - case OP_STBU:
> > > - case OP_STHU:
> > > - case OP_STFSU:
> > > - case OP_STFDU:
> > > - return true;
> > > - case OP_STD: /* std or stdu */
> > > - return (inst & 3) == 1;
> > > - case OP_31:
> > > - /* check minor opcode */
> > > - switch ((inst >> 1) & 0x3ff) {
> > > - case OP_31_XOP_STDUX:
> > > - case OP_31_XOP_STWUX:
> > > - case OP_31_XOP_STBUX:
> > > - case OP_31_XOP_STHUX:
> > > - case OP_31_XOP_STFSUX:
> > > - case OP_31_XOP_STFDUX:
> > > + if (GETTYPE(op->type) == STORE) {
> > > + if ((op->type & UPDATE) && (op->update_reg == 1))
> > > return true;
> > > - }
> > > }
> > > return false;
> > > }
> > > @@ -278,14 +258,17 @@ static bool bad_stack_expansion(struct pt_regs *regs, unsigned long address,
> > >
> > > if ((flags & FAULT_FLAG_WRITE) && (flags & FAULT_FLAG_USER) &&
> > > access_ok(nip, sizeof(*nip))) {
> > > - unsigned int inst;
> > > + unsigned int inst, sufx;
> > > + struct instruction_op op;
> > > int res;
> > >
> > > pagefault_disable();
> > > - res = __get_user_inatomic(inst, nip);
> > > + res = __get_user_instr_inatomic(inst, sufx, nip);
> > > pagefault_enable();
> > > - if (!res)
> > > - return !store_updates_sp(inst);
> > > + if (!res) {
> > > + analyse_instr(&op, uregs, inst, sufx);
> > > + return !store_updates_sp(&op);
> > > + }
> > > *must_retry = true;
> > > }
> > > return true;
> > > --
> > > 2.20.1
>
^ permalink raw reply
* Re: [PATCH v6 02/11] mm/gup: Use functions to track lockless pgtbl walks on gup_pgd_range
From: John Hubbard @ 2020-02-07 22:54 UTC (permalink / raw)
To: Leonardo Bras, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, Arnd Bergmann, Andrew Morton, Aneesh Kumar K.V,
Nicholas Piggin, Christophe Leroy, Steven Price, Robin Murphy,
Mahesh Salgaonkar, Balbir Singh, Reza Arbab, Thomas Gleixner,
Allison Randal, Greg Kroah-Hartman, Mike Rapoport,
Michal Suchanek
Cc: linux-arch, linux-mm, linuxppc-dev, linux-kernel, kvm-ppc
In-Reply-To: <760c238043196e0628c8c0eff48a8e938ef539ba.camel@linux.ibm.com>
On 2/5/20 7:25 PM, Leonardo Bras wrote:
> On Thu, 2020-02-06 at 00:08 -0300, Leonardo Bras wrote:
>> gup_pgd_range(addr, end, gup_flags, pages, &nr);
>> - local_irq_enable();
>> + end_lockless_pgtbl_walk(IRQS_ENABLED);
>> ret = nr;
>> }
>>
>
> Just noticed IRQS_ENABLED is not available on other archs than ppc64.
> I will fix this for v7.
>
What's the fix going to look like, approximately?
thanks,
--
John Hubbard
NVIDIA
^ permalink raw reply
* Re: [PATCH] powerpc: Fix CONFIG_TRACE_IRQFLAGS with CONFIG_VMAP_STACK
From: Guenter Roeck @ 2020-02-07 17:38 UTC (permalink / raw)
To: Christophe Leroy; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <daeacdc0dec0416d1c587cc9f9e7191ad3068dc0.1581095957.git.christophe.leroy@c-s.fr>
On Fri, Feb 07, 2020 at 05:20:57PM +0000, Christophe Leroy wrote:
> When CONFIG_PROVE_LOCKING is selected together with (now default)
> CONFIG_VMAP_STACK, kernel enter deadlock during boot.
>
> At the point of checking whether interrupts are enabled or not, the
> value of MSR saved on stack is read using the physical address of the
> stack. But at this point, when using VMAP stack the DATA MMU
> translation has already been re-enabled, leading to deadlock.
>
> Don't use the physical address of the stack when
> CONFIG_VMAP_STACK is set.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> Reported-by: Guenter Roeck <linux@roeck-us.net>
> Fixes: 028474876f47 ("powerpc/32: prepare for CONFIG_VMAP_STACK")
Tested-by: Guenter Roeck <linux@roeck-us.net>
> ---
> arch/powerpc/kernel/entry_32.S | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
> index 77abbc34bbe0..0713daa651d9 100644
> --- a/arch/powerpc/kernel/entry_32.S
> +++ b/arch/powerpc/kernel/entry_32.S
> @@ -214,7 +214,7 @@ transfer_to_handler_cont:
> * To speed up the syscall path where interrupts stay on, let's check
> * first if we are changing the MSR value at all.
> */
> - tophys(r12, r1)
> + tophys_novmstack r12, r1
> lwz r12,_MSR(r12)
> andi. r12,r12,MSR_EE
> bne 1f
> --
> 2.25.0
>
^ permalink raw reply
* [PATCH] powerpc: Fix CONFIG_TRACE_IRQFLAGS with CONFIG_VMAP_STACK
From: Christophe Leroy @ 2020-02-07 17:20 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Guenter Roeck
Cc: linuxppc-dev, linux-kernel
When CONFIG_PROVE_LOCKING is selected together with (now default)
CONFIG_VMAP_STACK, kernel enter deadlock during boot.
At the point of checking whether interrupts are enabled or not, the
value of MSR saved on stack is read using the physical address of the
stack. But at this point, when using VMAP stack the DATA MMU
translation has already been re-enabled, leading to deadlock.
Don't use the physical address of the stack when
CONFIG_VMAP_STACK is set.
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Reported-by: Guenter Roeck <linux@roeck-us.net>
Fixes: 028474876f47 ("powerpc/32: prepare for CONFIG_VMAP_STACK")
---
arch/powerpc/kernel/entry_32.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index 77abbc34bbe0..0713daa651d9 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -214,7 +214,7 @@ transfer_to_handler_cont:
* To speed up the syscall path where interrupts stay on, let's check
* first if we are changing the MSR value at all.
*/
- tophys(r12, r1)
+ tophys_novmstack r12, r1
lwz r12,_MSR(r12)
andi. r12,r12,MSR_EE
bne 1f
--
2.25.0
^ permalink raw reply related
* Re: [PATCH v5 17/17] powerpc/32s: Enable CONFIG_VMAP_STACK
From: Christophe Leroy @ 2020-02-07 17:16 UTC (permalink / raw)
To: Guenter Roeck; +Cc: linux-mm, linuxppc-dev, Paul Mackerras, linux-kernel, dja
In-Reply-To: <d6158967-fde3-1a87-44b6-07638bd2b5b0@roeck-us.net>
On 02/07/2020 01:44 PM, Guenter Roeck wrote:
> On 2/7/20 5:29 AM, Christophe Leroy wrote:
>>
>>
>> On 02/07/2020 01:08 PM, Guenter Roeck wrote:
>>> On 2/7/20 12:28 AM, Christophe Leroy wrote:
>>>>
>>>>
>>>> On 02/07/2020 06:13 AM, Christophe Leroy wrote:
>>>>>
>>>>>
>>>>> Le 06/02/2020 à 21:31, Guenter Roeck a écrit :
>>>>>> On Sat, Dec 21, 2019 at 08:32:38AM +0000, Christophe Leroy wrote:
>>>>>>> A few changes to retrieve DAR and DSISR from struct regs
>>>>>>> instead of retrieving them directly, as they may have
>>>>>>> changed due to a TLB miss.
>>>>>>>
>>>>>>> Also modifies hash_page() and friends to work with virtual
>>>>>>> data addresses instead of physical ones. Same on load_up_fpu()
>>>>>>> and load_up_altivec().
>>>>>>>
>>>>>>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
>>>>>>
>>>>>> This patch results in qemu boot failures (mac99 with
>>>>>> pmac32_defconfig).
>>>>>> Images fail silently; there is no console output. Reverting the patch
>>>>>> fixes the problem. Bisect log is attached below.
>>>>>>
>>>>>> Assuming this was tested on real hardware, am I correct to assume
>>>>>> that qemu
>>>>>> for ppc32 (more specifically, qemu's mac99 and g3beige machines)
>>>>>> no longer
>>>>>> works with the upstream kernel ?
>>>>>
>>>>> Before submitting the series, I successfully tested:
>>>>> - Real HW with powerpc 8xx
>>>>> - Real HW with powerpc 832x
>>>>> - Qemu's mac99
>>>>>
>>>>> I'll re-check the upstream kernel.
>>>>>
>>>>
>>>> This is still working for me with the upstream kernel:
>>>>
>>>
>>> Interesting. What is your kernel configuration, your qemu version, and
>>> your qemu command line ?
>>
>> Config is pmac32_defconfig + CONFIG_DEVTMPFS (But kernel also boots
>> without CONFIG_DEVTMPFS)
>>
>> QEMU emulator version 2.11.2
>>
>> qemu-system-ppc -kernel vmlinux -M mac99 -initrd rootfs.cpio.gz -s -m
>> 1024
>>
>> Works with both GCC 5.5 and GCC 8.1
>>
> Actually, the problem is that I have locking selftest options enabled
> in my tests. Everything works if I disable those. The "culprit" seems
> to be CONFIG_PROVE_LOCKING. Can you retest with CONFIG_PROVE_LOCKING=y ?
>
With CONFIG_PROVE_LOCKING, I get a deadlock after:
[...]
Kernel virtual memory layout:
* 0xffbcf000..0xfffff000 : fixmap
* 0xff400000..0xff800000 : highmem PTEs
* 0xfeb36000..0xff400000 : early ioremap
* 0xf1000000..0xfeb36000 : vmalloc & ioremap
SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Running RCU self tests
NR_IRQS: 512, nr_irqs: 512, preallocated irqs: 16
mpic: Resetting
mpic: Setting up MPIC " MPIC 1 " version 1.2 at 80040000, max 1 CPUs
mpic: ISU size: 64, shift: 6, mask: 3f
mpic: Initializing for 64 sources
GMT Delta read from XPRAM: 0 minutes, DST: on
time_init: decrementer frequency = 100.000000 MHz
time_init: processor frequency = 900.000000 MHz
clocksource: timebase: mask: 0xffffffffffffffff max_cycles:
0x171024e7e0, max_idle_ns: 440795205315 ns
clocksource: timebase mult[a000000] shift[24] registered
clockevent: decrementer mult[1999999a] shift[32] cpu[0]
Console: colour dummy device 80x25
Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
Please test the patch I'll send out in a few minutes.
Thanks
Christophe
^ permalink raw reply
* Re: Latest Git kernel: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device
From: Arnd Bergmann @ 2020-02-07 17:08 UTC (permalink / raw)
To: Christian Zigotzky
Cc: DTML, Darren Stevens, mad skateman, Linux Kernel Mailing List,
linuxppc-dev, contact@a-eon.com, R.T.Dickinson,
netdev@vger.kernel.org, Jakub Kicinski, Christoph Hellwig,
Christian Zigotzky
In-Reply-To: <42888ad2-71e0-6d03-ddff-3de6f0ee5d43@xenosoft.de>
On Fri, Feb 7, 2020 at 3:34 PM Christian Zigotzky
<chzigotzky@xenosoft.de> wrote:
>
> Hello Arnd,
>
> We regularly compile and test Linux kernels every day during the merge
> window. Since Thursday last week we have very high CPU usage because of
> the avahi daemon on our desktop Linux systems (Ubuntu, Debian etc). The
> avahi daemon produces a lot of the following log message. This generates
> high CPU usage.
>
> Error message: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device
>
> strace /usr/sbin/avahi-daemon:
>
Thanks a lot for the detailed analysis, with this I immediately saw
what went wrong in my
original commit and I sent you a fix. Please test to ensure that this
correctly addresses
the problem.
Arnd
^ permalink raw reply
* Re: [PATCH] powerpc/futex: Fix incorrect user access blocking
From: Christophe Leroy @ 2020-02-07 16:03 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: dja
In-Reply-To: <20200207122145.11928-1-mpe@ellerman.id.au>
Le 07/02/2020 à 13:21, Michael Ellerman a écrit :
> The early versions of our kernel user access prevention (KUAP) were
> written by Russell and Christophe, and didn't have separate
> read/write access.
>
> At some point I picked up the series and added the read/write access,
> but I failed to update the usages in futex.h to correctly allow read
> and write.
>
> However we didn't notice because of another bug which was causing the
> low-level code to always enable read and write. That bug was fixed
> recently in commit 1d8f739b07bd ("powerpc/kuap: Fix set direction in
> allow/prevent_user_access()").
>
> futex_atomic_cmpxchg_inatomic() is passed the user address as %3 and
> does:
>
> 1: lwarx %1, 0, %3
> cmpw 0, %1, %4
> bne- 3f
> 2: stwcx. %5, 0, %3
>
> Which clearly loads and stores from/to %3. The logic in
> arch_futex_atomic_op_inuser() is similar, so fix both of them to use
> allow_read_write_user().
>
> Without this fix, and with PPC_KUAP_DEBUG=y, we see eg:
>
> Bug: Read fault blocked by AMR!
> WARNING: CPU: 94 PID: 149215 at arch/powerpc/include/asm/book3s/64/kup-radix.h:126 __do_page_fault+0x600/0xf30
> CPU: 94 PID: 149215 Comm: futex_requeue_p Tainted: G W 5.5.0-rc7-gcc9x-g4c25df5640ae #1
> ...
> NIP [c000000000070680] __do_page_fault+0x600/0xf30
> LR [c00000000007067c] __do_page_fault+0x5fc/0xf30
> Call Trace:
> [c00020138e5637e0] [c00000000007067c] __do_page_fault+0x5fc/0xf30 (unreliable)
> [c00020138e5638c0] [c00000000000ada8] handle_page_fault+0x10/0x30
> --- interrupt: 301 at cmpxchg_futex_value_locked+0x68/0xd0
> LR = futex_lock_pi_atomic+0xe0/0x1f0
> [c00020138e563bc0] [c000000000217b50] futex_lock_pi_atomic+0x80/0x1f0 (unreliable)
> [c00020138e563c30] [c00000000021b668] futex_requeue+0x438/0xb60
> [c00020138e563d60] [c00000000021c6cc] do_futex+0x1ec/0x2b0
> [c00020138e563d90] [c00000000021c8b8] sys_futex+0x128/0x200
> [c00020138e563e20] [c00000000000b7ac] system_call+0x5c/0x68
>
> Fixes: de78a9c42a79 ("powerpc: Add a framework for Kernel Userspace Access Protection")
> Cc: stable@vger.kernel.org # v5.2+
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
> ---
> arch/powerpc/include/asm/futex.h | 10 ++++++----
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/futex.h b/arch/powerpc/include/asm/futex.h
> index eea28ca679db..bc7d9d06a6d9 100644
> --- a/arch/powerpc/include/asm/futex.h
> +++ b/arch/powerpc/include/asm/futex.h
> @@ -35,7 +35,7 @@ static inline int arch_futex_atomic_op_inuser(int op, int oparg, int *oval,
> {
> int oldval = 0, ret;
>
> - allow_write_to_user(uaddr, sizeof(*uaddr));
> + allow_read_write_user(uaddr, uaddr, sizeof(*uaddr));
> pagefault_disable();
>
> switch (op) {
> @@ -62,7 +62,7 @@ static inline int arch_futex_atomic_op_inuser(int op, int oparg, int *oval,
>
> *oval = oldval;
>
> - prevent_write_to_user(uaddr, sizeof(*uaddr));
> + prevent_read_write_user(uaddr, uaddr, sizeof(*uaddr));
> return ret;
> }
>
> @@ -76,7 +76,8 @@ futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr,
> if (!access_ok(uaddr, sizeof(u32)))
> return -EFAULT;
>
> - allow_write_to_user(uaddr, sizeof(*uaddr));
> + allow_read_write_user(uaddr, uaddr, sizeof(*uaddr));
> +
> __asm__ __volatile__ (
> PPC_ATOMIC_ENTRY_BARRIER
> "1: lwarx %1,0,%3 # futex_atomic_cmpxchg_inatomic\n\
> @@ -97,7 +98,8 @@ futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr,
> : "cc", "memory");
>
> *uval = prev;
> - prevent_write_to_user(uaddr, sizeof(*uaddr));
> + prevent_read_write_user(uaddr, uaddr, sizeof(*uaddr));
> +
> return ret;
> }
>
>
^ permalink raw reply
* Latest Git kernel: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device
From: Christian Zigotzky @ 2020-02-07 14:34 UTC (permalink / raw)
To: arnd
Cc: DTML, Darren Stevens, mad skateman, Linux Kernel Mailing List,
linuxppc-dev, contact@a-eon.com, R.T.Dickinson,
netdev@vger.kernel.org, Jakub Kicinski, Christoph Hellwig,
Christian Zigotzky
In-Reply-To: <87tv441gg1.fsf@mpe.ellerman.id.au>
[-- Attachment #1: Type: text/plain, Size: 3295 bytes --]
Hello Arnd,
We regularly compile and test Linux kernels every day during the merge
window. Since Thursday last week we have very high CPU usage because of
the avahi daemon on our desktop Linux systems (Ubuntu, Debian etc). The
avahi daemon produces a lot of the following log message. This generates
high CPU usage.
Error message: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device
strace /usr/sbin/avahi-daemon:
poll([{fd=4, events=POLLIN}, {fd=16, events=POLLIN}, {fd=15,
events=POLLIN}, {fd=14, events=POLLIN}, {fd=13, events=POLLIN}, {fd=12,
events=POLLIN}, {fd=11, events=POLLIN}, {fd=10, events=POLLIN}, {fd=9,
events=POLLIN}, {fd=8, events=POLLIN}, {fd=6, events=POLLIN}], 11, 65) =
2 ([{fd=12, revents=POLLIN}, {fd=9, revents=POLLIN}])
ioctl(12, FIONREAD, 0xffba6f24) = -1 ENOTTY (Inappropriate ioctl
for device)
write(2, "ioctl(): Inappropriate ioctl for"..., 39ioctl(): Inappropriate
ioctl for device) = 39
write(2, "\n", 1
) = 1
----------------------
I bisected the latest kernel source code today.
Result:
77b9040195dea3fcddf19e136c9e99a501351778 is the first bad commit
commit 77b9040195dea3fcddf19e136c9e99a501351778
Author: Arnd Bergmann <arnd@arndb.de>
Date: Wed Nov 27 21:25:36 2019 +0100
compat_ioctl: simplify the implementation
Now that both native and compat ioctl syscalls are
in the same file, a couple of simplifications can
be made, bringing the implementation closer together:
- do_vfs_ioctl(), ioctl_preallocate(), and compat_ioctl_preallocate()
can become static, allowing the compiler to optimize better
- slightly update the coding style for consistency between
the functions.
- rather than listing each command in two switch statements
for the compat case, just call a single function that has
all the common commands.
As a side-effect, FS_IOC_RESVSP/FS_IOC_RESVSP64 are now available
to x86 compat tasks, along with FS_IOC_RESVSP_32/FS_IOC_RESVSP64_32.
This is harmless for i386 emulation, and can be considered a bugfix
for x32 emulation, which never supported these in the past.
Reviewed-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
:040000 040000 5c4b62f4d1bfe643d3bbf9d9a3b50ee50ae0f159
5ca610e3197df96adfcae4f94fceeb496756609b M fs
:040000 040000 086f2e2ac49384988733cbb706243943748c4ce7
b906926e53dfa2e8927629e77a0708dda6f49d31 M include
----------------------
Link to the first bad commit:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=77b9040195dea3fcddf19e136c9e99a501351778
I was able to revert the first bad commit.
git revert 77b9040195dea3fcddf19e136c9e99a501351778
[master a91dcf9dc14c] Revert "compat_ioctl: simplify the implementation"
4 files changed, 105 insertions(+), 64 deletions(-)
After that the avahi daemon works without any problems again.
I created a patch today. (attached)
It is also possible to deactivate the avahi daemon with the following lines
in the file "/etc/avahi/avahi-daemon.conf":
use-ipv4=no
use-ipv6=no
Could you please check your commit?
Thanks,
Christian
[-- Attachment #2: compat_ioctl-v1.patch --]
[-- Type: text/x-patch, Size: 9092 bytes --]
diff -rupN a/fs/internal.h b/fs/internal.h
--- a/fs/internal.h 2020-02-07 13:20:46.294317088 +0100
+++ b/fs/internal.h 2020-02-07 13:16:06.731416797 +0100
@@ -182,6 +182,12 @@ extern void mnt_pin_kill(struct mount *m
*/
extern const struct dentry_operations ns_dentry_operations;
+/*
+ * fs/ioctl.c
+ */
+extern int do_vfs_ioctl(struct file *file, unsigned int fd, unsigned int cmd,
+ unsigned long arg);
+
/* direct-io.c: */
int sb_init_dio_done_wq(struct super_block *sb);
diff -rupN a/fs/ioctl.c b/fs/ioctl.c
--- a/fs/ioctl.c 2020-02-07 13:20:46.294317088 +0100
+++ b/fs/ioctl.c 2020-02-07 13:16:06.331418365 +0100
@@ -467,7 +467,7 @@ EXPORT_SYMBOL(generic_block_fiemap);
* Only the l_start, l_len and l_whence fields of the 'struct space_resv'
* are used here, rest are ignored.
*/
-static int ioctl_preallocate(struct file *filp, int mode, void __user *argp)
+int ioctl_preallocate(struct file *filp, int mode, void __user *argp)
{
struct inode *inode = file_inode(filp);
struct space_resv sr;
@@ -495,8 +495,8 @@ static int ioctl_preallocate(struct file
/* on ia32 l_start is on a 32-bit boundary */
#if defined CONFIG_COMPAT && defined(CONFIG_X86_64)
/* just account for different alignment */
-static int compat_ioctl_preallocate(struct file *file, int mode,
- struct space_resv_32 __user *argp)
+int compat_ioctl_preallocate(struct file *file, int mode,
+ struct space_resv_32 __user *argp)
{
struct inode *inode = file_inode(file);
struct space_resv_32 sr;
@@ -521,9 +521,11 @@ static int compat_ioctl_preallocate(stru
}
#endif
-static int file_ioctl(struct file *filp, unsigned int cmd, int __user *p)
+static int file_ioctl(struct file *filp, unsigned int cmd,
+ unsigned long arg)
{
struct inode *inode = file_inode(filp);
+ int __user *p = (int __user *)arg;
switch (cmd) {
case FIBMAP:
@@ -540,7 +542,7 @@ static int file_ioctl(struct file *filp,
return ioctl_preallocate(filp, FALLOC_FL_ZERO_RANGE, p);
}
- return -ENOIOCTLCMD;
+ return vfs_ioctl(filp, cmd, arg);
}
static int ioctl_fionbio(struct file *filp, int __user *argp)
@@ -659,48 +661,53 @@ out:
}
/*
+ * When you add any new common ioctls to the switches above and below
+ * please update compat_sys_ioctl() too.
+ *
* do_vfs_ioctl() is not for drivers and not intended to be EXPORT_SYMBOL()'d.
* It's just a simple helper for sys_ioctl and compat_sys_ioctl.
- *
- * When you add any new common ioctls to the switches above and below,
- * please ensure they have compatible arguments in compat mode.
*/
-static int do_vfs_ioctl(struct file *filp, unsigned int fd,
- unsigned int cmd, unsigned long arg)
+int do_vfs_ioctl(struct file *filp, unsigned int fd, unsigned int cmd,
+ unsigned long arg)
{
+ int error = 0;
void __user *argp = (void __user *)arg;
struct inode *inode = file_inode(filp);
switch (cmd) {
case FIOCLEX:
set_close_on_exec(fd, 1);
- return 0;
+ break;
case FIONCLEX:
set_close_on_exec(fd, 0);
- return 0;
+ break;
case FIONBIO:
- return ioctl_fionbio(filp, argp);
+ error = ioctl_fionbio(filp, argp);
+ break;
case FIOASYNC:
- return ioctl_fioasync(fd, filp, argp);
+ error = ioctl_fioasync(fd, filp, argp);
+ break;
case FIOQSIZE:
if (S_ISDIR(inode->i_mode) || S_ISREG(inode->i_mode) ||
S_ISLNK(inode->i_mode)) {
loff_t res = inode_get_bytes(inode);
- return copy_to_user(argp, &res, sizeof(res)) ?
- -EFAULT : 0;
- }
-
- return -ENOTTY;
+ error = copy_to_user(argp, &res, sizeof(res)) ?
+ -EFAULT : 0;
+ } else
+ error = -ENOTTY;
+ break;
case FIFREEZE:
- return ioctl_fsfreeze(filp);
+ error = ioctl_fsfreeze(filp);
+ break;
case FITHAW:
- return ioctl_fsthaw(filp);
+ error = ioctl_fsthaw(filp);
+ break;
case FS_IOC_FIEMAP:
return ioctl_fiemap(filp, argp);
@@ -709,7 +716,6 @@ static int do_vfs_ioctl(struct file *fil
/* anon_bdev filesystems may not have a block size */
if (!inode->i_sb->s_blocksize)
return -EINVAL;
-
return put_user(inode->i_sb->s_blocksize, (int __user *)argp);
case FICLONE:
@@ -723,30 +729,24 @@ static int do_vfs_ioctl(struct file *fil
default:
if (S_ISREG(inode->i_mode))
- return file_ioctl(filp, cmd, argp);
+ error = file_ioctl(filp, cmd, arg);
+ else
+ error = vfs_ioctl(filp, cmd, arg);
break;
}
-
- return -ENOIOCTLCMD;
+ return error;
}
int ksys_ioctl(unsigned int fd, unsigned int cmd, unsigned long arg)
{
- struct fd f = fdget(fd);
int error;
+ struct fd f = fdget(fd);
if (!f.file)
return -EBADF;
-
error = security_file_ioctl(f.file, cmd, arg);
- if (error)
- goto out;
-
- error = do_vfs_ioctl(f.file, fd, cmd, arg);
- if (error == -ENOIOCTLCMD)
- error = vfs_ioctl(f.file, cmd, arg);
-
-out:
+ if (!error)
+ error = do_vfs_ioctl(f.file, fd, cmd, arg);
fdput(f);
return error;
}
@@ -790,63 +790,92 @@ long compat_ptr_ioctl(struct file *file,
EXPORT_SYMBOL(compat_ptr_ioctl);
COMPAT_SYSCALL_DEFINE3(ioctl, unsigned int, fd, unsigned int, cmd,
- compat_ulong_t, arg)
+ compat_ulong_t, arg32)
{
+ unsigned long arg = arg32;
struct fd f = fdget(fd);
- int error;
-
+ int error = -EBADF;
if (!f.file)
- return -EBADF;
+ goto out;
/* RED-PEN how should LSM module know it's handling 32bit? */
error = security_file_ioctl(f.file, cmd, arg);
if (error)
- goto out;
+ goto out_fput;
switch (cmd) {
- /* FICLONE takes an int argument, so don't use compat_ptr() */
+ /* these are never seen by ->ioctl(), no argument or int argument */
+ case FIOCLEX:
+ case FIONCLEX:
+ case FIFREEZE:
+ case FITHAW:
case FICLONE:
- error = ioctl_file_clone(f.file, arg, 0, 0, 0);
- break;
-
-#if defined(CONFIG_X86_64)
+ goto do_ioctl;
+ /* these are never seen by ->ioctl(), pointer argument */
+ case FIONBIO:
+ case FIOASYNC:
+ case FIOQSIZE:
+ case FS_IOC_FIEMAP:
+ case FIGETBSZ:
+ case FICLONERANGE:
+ case FIDEDUPERANGE:
+ goto found_handler;
+ /*
+ * The next group is the stuff handled inside file_ioctl().
+ * For regular files these never reach ->ioctl(); for
+ * devices, sockets, etc. they do and one (FIONREAD) is
+ * even accepted in some cases. In all those cases
+ * argument has the same type, so we can handle these
+ * here, shunting them towards do_vfs_ioctl().
+ * ->compat_ioctl() will never see any of those.
+ */
+ /* pointer argument, never actually handled by ->ioctl() */
+ case FIBMAP:
+ goto found_handler;
+ /* handled by some ->ioctl(); always a pointer to int */
+ case FIONREAD:
+ goto found_handler;
/* these get messy on amd64 due to alignment differences */
+#if defined(CONFIG_X86_64)
case FS_IOC_RESVSP_32:
case FS_IOC_RESVSP64_32:
error = compat_ioctl_preallocate(f.file, 0, compat_ptr(arg));
- break;
+ goto out_fput;
case FS_IOC_UNRESVSP_32:
case FS_IOC_UNRESVSP64_32:
error = compat_ioctl_preallocate(f.file, FALLOC_FL_PUNCH_HOLE,
compat_ptr(arg));
- break;
+ goto out_fput;
case FS_IOC_ZERO_RANGE_32:
error = compat_ioctl_preallocate(f.file, FALLOC_FL_ZERO_RANGE,
compat_ptr(arg));
- break;
+ goto out_fput;
+#else
+ case FS_IOC_RESVSP:
+ case FS_IOC_RESVSP64:
+ case FS_IOC_UNRESVSP:
+ case FS_IOC_UNRESVSP64:
+ case FS_IOC_ZERO_RANGE:
+ goto found_handler;
#endif
- /*
- * everything else in do_vfs_ioctl() takes either a compatible
- * pointer argument or no argument -- call it with a modified
- * argument.
- */
default:
- error = do_vfs_ioctl(f.file, fd, cmd,
- (unsigned long)compat_ptr(arg));
- if (error != -ENOIOCTLCMD)
- break;
-
- if (f.file->f_op->compat_ioctl)
+ if (f.file->f_op->compat_ioctl) {
error = f.file->f_op->compat_ioctl(f.file, cmd, arg);
- if (error == -ENOIOCTLCMD)
- error = -ENOTTY;
- break;
+ if (error != -ENOIOCTLCMD)
+ goto out_fput;
+ }
+ error = -ENOTTY;
+ goto out_fput;
}
- out:
+ found_handler:
+ arg = (unsigned long)compat_ptr(arg);
+ do_ioctl:
+ error = do_vfs_ioctl(f.file, fd, cmd, arg);
+ out_fput:
fdput(f);
-
+ out:
return error;
}
#endif
diff -rupN a/include/linux/falloc.h b/include/linux/falloc.h
--- a/include/linux/falloc.h 2020-02-07 13:20:46.382316741 +0100
+++ b/include/linux/falloc.h 2020-02-07 13:16:06.331418365 +0100
@@ -51,6 +51,8 @@ struct space_resv_32 {
#define FS_IOC_UNRESVSP64_32 _IOW ('X', 43, struct space_resv_32)
#define FS_IOC_ZERO_RANGE_32 _IOW ('X', 57, struct space_resv_32)
+int compat_ioctl_preallocate(struct file *, int, struct space_resv_32 __user *);
+
#endif
#endif /* _FALLOC_H_ */
diff -rupN a/include/linux/fs.h b/include/linux/fs.h
--- a/include/linux/fs.h 2020-02-07 13:20:46.382316741 +0100
+++ b/include/linux/fs.h 2020-02-07 13:16:06.731416797 +0100
@@ -2563,6 +2563,10 @@ extern int finish_open(struct file *file
int (*open)(struct inode *, struct file *));
extern int finish_no_open(struct file *file, struct dentry *dentry);
+/* fs/ioctl.c */
+
+extern int ioctl_preallocate(struct file *filp, int mode, void __user *argp);
+
/* fs/dcache.c */
extern void __init vfs_caches_init_early(void);
extern void __init vfs_caches_init(void);
^ permalink raw reply
* Re: [PATCH v5 17/17] powerpc/32s: Enable CONFIG_VMAP_STACK
From: Guenter Roeck @ 2020-02-07 13:44 UTC (permalink / raw)
To: Christophe Leroy
Cc: linux-mm, linuxppc-dev, Paul Mackerras, linux-kernel, dja
In-Reply-To: <29bd8702-9b8f-6931-2bbc-db7e444907d5@c-s.fr>
On 2/7/20 5:29 AM, Christophe Leroy wrote:
>
>
> On 02/07/2020 01:08 PM, Guenter Roeck wrote:
>> On 2/7/20 12:28 AM, Christophe Leroy wrote:
>>>
>>>
>>> On 02/07/2020 06:13 AM, Christophe Leroy wrote:
>>>>
>>>>
>>>> Le 06/02/2020 à 21:31, Guenter Roeck a écrit :
>>>>> On Sat, Dec 21, 2019 at 08:32:38AM +0000, Christophe Leroy wrote:
>>>>>> A few changes to retrieve DAR and DSISR from struct regs
>>>>>> instead of retrieving them directly, as they may have
>>>>>> changed due to a TLB miss.
>>>>>>
>>>>>> Also modifies hash_page() and friends to work with virtual
>>>>>> data addresses instead of physical ones. Same on load_up_fpu()
>>>>>> and load_up_altivec().
>>>>>>
>>>>>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
>>>>>
>>>>> This patch results in qemu boot failures (mac99 with pmac32_defconfig).
>>>>> Images fail silently; there is no console output. Reverting the patch
>>>>> fixes the problem. Bisect log is attached below.
>>>>>
>>>>> Assuming this was tested on real hardware, am I correct to assume that qemu
>>>>> for ppc32 (more specifically, qemu's mac99 and g3beige machines) no longer
>>>>> works with the upstream kernel ?
>>>>
>>>> Before submitting the series, I successfully tested:
>>>> - Real HW with powerpc 8xx
>>>> - Real HW with powerpc 832x
>>>> - Qemu's mac99
>>>>
>>>> I'll re-check the upstream kernel.
>>>>
>>>
>>> This is still working for me with the upstream kernel:
>>>
>>
>> Interesting. What is your kernel configuration, your qemu version, and
>> your qemu command line ?
>
> Config is pmac32_defconfig + CONFIG_DEVTMPFS (But kernel also boots without CONFIG_DEVTMPFS)
>
> QEMU emulator version 2.11.2
>
> qemu-system-ppc -kernel vmlinux -M mac99 -initrd rootfs.cpio.gz -s -m 1024
>
> Works with both GCC 5.5 and GCC 8.1
>
Actually, the problem is that I have locking selftest options enabled
in my tests. Everything works if I disable those. The "culprit" seems
to be CONFIG_PROVE_LOCKING. Can you retest with CONFIG_PROVE_LOCKING=y ?
Thanks,
Guenter
^ permalink raw reply
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