* [PATCH] powerpc: Move a dereference below a NULL test
From: zhong jiang @ 2018-09-26 11:46 UTC (permalink / raw)
To: paulus, benh, mpe; +Cc: linuxppc-dev, linux-kernel
It is safe to move dereference below a NULL test.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
arch/powerpc/kernel/cacheinfo.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/cacheinfo.c b/arch/powerpc/kernel/cacheinfo.c
index a8f20e5..7f19714 100644
--- a/arch/powerpc/kernel/cacheinfo.c
+++ b/arch/powerpc/kernel/cacheinfo.c
@@ -401,14 +401,13 @@ static struct cache *cache_lookup_or_instantiate(struct device_node *node,
struct cache *cache;
cache = cache_lookup_by_node(node);
+ if (!cache)
+ cache = cache_do_one_devnode(node, level);
WARN_ONCE(cache && cache->level != level,
"cache level mismatch on lookup (got %d, expected %d)\n",
cache->level, level);
- if (!cache)
- cache = cache_do_one_devnode(node, level);
-
return cache;
}
--
1.7.12.4
^ permalink raw reply related
* [PATCH] powerpc/64s: consolidate MCE counter increment.
From: Michal Suchanek @ 2018-09-26 12:24 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Murilo Opsfelder Araujo, Cyril Bur, Eric W. Biederman,
Nicholas Piggin, Michael Neuling, Anshuman Khandual,
Michal Suchanek, Haren Myneni, Mahesh Salgaonkar, Balbir Singh,
linuxppc-dev, linux-kernel
The code in machine_check_exception excludes 64s hvmode when
incrementing the MCE counter only to call opal_machine_check to
increment it specifically for this case.
Remove the exclusion and special case.
Fixes: a43c1590426c ("powerpc/pseries: Flush SLB contents on SLB MCE
errors.")
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
---
arch/powerpc/kernel/traps.c | 4 +---
arch/powerpc/platforms/powernv/opal.c | 2 --
2 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 6ab66a88db14..e5bc413c7d53 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -741,9 +741,7 @@ void machine_check_exception(struct pt_regs *regs)
if (!nested)
nmi_enter();
- /* 64s accounts the mce in machine_check_early when in HVMODE */
- if (!IS_ENABLED(CONFIG_PPC_BOOK3S_64) || !cpu_has_feature(CPU_FTR_HVMODE))
- __this_cpu_inc(irq_stat.mce_exceptions);
+ __this_cpu_inc(irq_stat.mce_exceptions);
add_taint(TAINT_MACHINE_CHECK, LOCKDEP_NOW_UNRELIABLE);
diff --git a/arch/powerpc/platforms/powernv/opal.c b/arch/powerpc/platforms/powernv/opal.c
index 62c291e23dbe..38fe4087484a 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -578,8 +578,6 @@ int opal_machine_check(struct pt_regs *regs)
{
struct machine_check_event evt;
- __this_cpu_inc(irq_stat.mce_exceptions);
-
if (!get_mce_event(&evt, MCE_EVENT_RELEASE))
return 0;
--
2.13.7
^ permalink raw reply related
* Re: [PATCH 14/30] memblock: add align parameter to memblock_alloc_node()
From: Mike Rapoport @ 2018-09-26 13:43 UTC (permalink / raw)
To: Michal Hocko
Cc: linux-mm, Andrew Morton, Catalin Marinas, Chris Zankel,
David S. Miller, Geert Uytterhoeven, Greentime Hu,
Greg Kroah-Hartman, Guan Xuetao, Ingo Molnar,
James E.J. Bottomley, Jonas Bonn, Jonathan Corbet, Ley Foon Tan,
Mark Salter, Martin Schwidefsky, Matt Turner, Michael Ellerman,
Michal Simek, Palmer Dabbelt, Paul Burton, Richard Kuo,
Richard Weinberger, Rich Felker, Russell King, Serge Semin,
Thomas Gleixner, Tony Luck, Vineet Gupta, Yoshinori Sato,
linux-alpha, linux-arm-kernel, linux-c6x-dev, linux-hexagon,
linux-ia64, linux-kernel, linux-m68k, linux-mips, linux-parisc,
linuxppc-dev, linux-riscv, linux-s390, linux-sh, linux-snps-arc,
linux-um, nios2-dev, openrisc, sparclinux, uclinux-h8-devel
In-Reply-To: <20180926093648.GP6278@dhcp22.suse.cz>
On Wed, Sep 26, 2018 at 11:36:48AM +0200, Michal Hocko wrote:
> On Wed 26-09-18 11:31:27, Michal Hocko wrote:
> > On Fri 14-09-18 15:10:29, Mike Rapoport wrote:
> > > With the align parameter memblock_alloc_node() can be used as drop in
> > > replacement for alloc_bootmem_pages_node() and __alloc_bootmem_node(),
> > > which is done in the following patches.
> >
> > /me confused. Why do we need this patch at all? Maybe it should be
> > folded into the later patch you are refereing here?
>
> OK, I can see 1536927045-23536-17-git-send-email-rppt@linux.vnet.ibm.com
> now. If you are going to repost for whatever reason please merge those
> two. Also I would get rid of the implicit "0 implies SMP_CACHE_BYTES"
> behavior. It is subtle and you have to dig deep to find that out. Why
> not make it explicit?
Agree. I'd just prefer to make it a separate patch rather then resend the
whole series.
> --
> Michal Hocko
> SUSE Labs
>
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH] powerpc: Move a dereference below a NULL test
From: Christophe LEROY @ 2018-09-26 13:58 UTC (permalink / raw)
To: zhong jiang, paulus, benh, mpe; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1537962368-14019-1-git-send-email-zhongjiang@huawei.com>
Le 26/09/2018 à 13:46, zhong jiang a écrit :
> It is safe to move dereference below a NULL test.
>
> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
> ---
> arch/powerpc/kernel/cacheinfo.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/kernel/cacheinfo.c b/arch/powerpc/kernel/cacheinfo.c
> index a8f20e5..7f19714 100644
> --- a/arch/powerpc/kernel/cacheinfo.c
> +++ b/arch/powerpc/kernel/cacheinfo.c
> @@ -401,14 +401,13 @@ static struct cache *cache_lookup_or_instantiate(struct device_node *node,
> struct cache *cache;
>
> cache = cache_lookup_by_node(node);
> + if (!cache)
> + cache = cache_do_one_devnode(node, level);
But by doing this, you change the meaning of the following warning. Is
that what you want ? In that case the text of the WARN_ONCE() should be
changed, because the mismatch is not only on lookup now.
Christophe
>
> WARN_ONCE(cache && cache->level != level,
> "cache level mismatch on lookup (got %d, expected %d)\n",
> cache->level, level);
>
> - if (!cache)
> - cache = cache_do_one_devnode(node, level);
> -
> return cache;
> }
>
>
^ permalink raw reply
* Re: [PATCH] powerpc: Move a dereference below a NULL test
From: zhong jiang @ 2018-09-26 14:06 UTC (permalink / raw)
To: Christophe LEROY; +Cc: paulus, benh, mpe, linuxppc-dev, linux-kernel
In-Reply-To: <fb8bc993-2adc-6a70-2643-6195ba5f020f@c-s.fr>
On 2018/9/26 21:58, Christophe LEROY wrote:
>
>
> Le 26/09/2018 à 13:46, zhong jiang a écrit :
>> It is safe to move dereference below a NULL test.
>>
>> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
>> ---
>> arch/powerpc/kernel/cacheinfo.c | 5 ++---
>> 1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/powerpc/kernel/cacheinfo.c b/arch/powerpc/kernel/cacheinfo.c
>> index a8f20e5..7f19714 100644
>> --- a/arch/powerpc/kernel/cacheinfo.c
>> +++ b/arch/powerpc/kernel/cacheinfo.c
>> @@ -401,14 +401,13 @@ static struct cache *cache_lookup_or_instantiate(struct device_node *node,
>> struct cache *cache;
>> cache = cache_lookup_by_node(node);
>> + if (!cache)
>> + cache = cache_do_one_devnode(node, level);
>
> But by doing this, you change the meaning of the following warning. Is that what you want ? In that case the text of the WARN_ONCE() should be changed, because the mismatch is not only on lookup now.
>
Yep, I forget the WARN_ONCE. I think we should just remove it. Thought?
Thanks,
zhong jiang
> Christophe
>
>> WARN_ONCE(cache && cache->level != level,
>> "cache level mismatch on lookup (got %d, expected %d)\n",
>> cache->level, level);
>> - if (!cache)
>> - cache = cache_do_one_devnode(node, level);
>> -
>> return cache;
>> }
>>
>
> .
>
^ permalink raw reply
* Re: [PATCH v4] powerpc/64s: reimplement book3s idle code in C
From: Akshay Adiga @ 2018-09-26 14:09 UTC (permalink / raw)
To: Nicholas Piggin
Cc: linuxppc-dev, kvm-ppc, Gautham R . Shenoy,
Mahesh Jagannath Salgaonkar, Aneesh Kumar K.V
In-Reply-To: <20180914015240.1506-1-npiggin@gmail.com>
On Fri, Sep 14, 2018 at 11:52:40AM +1000, Nicholas Piggin wrote:
> +
> + /*
> + * On POWER9, SRR1 bits do not match exactly as expected.
> + * SRR1_WS_GPRLOSS (10b) can also result in SPR loss, so
> + * always test PSSCR if there is any state loss.
> + */
> + if (likely((psscr & PSSCR_RL_MASK) < pnv_first_hv_loss_level)) {
Shouldn't we check PLS field to see if the cpu/core woke up from hv loss ?
Currently, a cpu requested stop4 (RL=4) and exited from a shallower state
(PLS=2), SPR's are unecessarily restored.
We can do something like :
#define PSSCR_PLS_SHIFT 60
if (likely((psscr & PSSCR_PLS) >> PSSCR_PLS_SHIFT) < pnv_first_hv_loss_level)
> + if (sprs_saved)
> + atomic_stop_thread_idle();
> + goto out;
> + }
> +
> + /* HV state loss */
> + BUG_ON(!sprs_saved);
> +
> + atomic_lock_thread_idle();
> +
> + if ((*state & ((1 << threads_per_core) - 1)) != 0)
> + goto core_woken;
> +
> + /* Per-core SPRs */
> + mtspr(SPRN_PTCR, sprs.ptcr);
> + mtspr(SPRN_RPR, sprs.rpr);
> + mtspr(SPRN_TSCR, sprs.tscr);
> + mtspr(SPRN_LDBAR, sprs.ldbar);
> + mtspr(SPRN_AMOR, sprs.amor);
> +
> + if ((psscr & PSSCR_RL_MASK) >= pnv_first_tb_loss_level) {
> + /* TB loss */
> + if (opal_resync_timebase() != OPAL_SUCCESS)
> + BUG();
> + }
^ permalink raw reply
* [PATCH 1/1] powerpc/config: Enable CONFIG_PRINTK_TIME
From: Petr Vorel @ 2018-09-26 14:10 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Petr Vorel
for 64bit configs which use for CONFIG_LOG_BUF_SHIFT the same
or higher value than the default (currently 17).
Signed-off-by: Petr Vorel <pvorel@suse.cz>
---
arch/powerpc/configs/g5_defconfig | 1 +
arch/powerpc/configs/maple_defconfig | 1 +
arch/powerpc/configs/powernv_defconfig | 1 +
arch/powerpc/configs/ppc64_defconfig | 1 +
arch/powerpc/configs/ps3_defconfig | 1 +
arch/powerpc/configs/pseries_defconfig | 1 +
6 files changed, 6 insertions(+)
diff --git a/arch/powerpc/configs/g5_defconfig b/arch/powerpc/configs/g5_defconfig
index 67c39f4acede..f686cc1eac0b 100644
--- a/arch/powerpc/configs/g5_defconfig
+++ b/arch/powerpc/configs/g5_defconfig
@@ -262,3 +262,4 @@ CONFIG_CRYPTO_SERPENT=m
CONFIG_CRYPTO_TEA=m
CONFIG_CRYPTO_TWOFISH=m
# CONFIG_CRYPTO_HW is not set
+CONFIG_PRINTK_TIME=y
diff --git a/arch/powerpc/configs/maple_defconfig b/arch/powerpc/configs/maple_defconfig
index 59e47ec85336..f71eddafb02f 100644
--- a/arch/powerpc/configs/maple_defconfig
+++ b/arch/powerpc/configs/maple_defconfig
@@ -112,3 +112,4 @@ CONFIG_PPC_EARLY_DEBUG=y
CONFIG_CRYPTO_ECB=m
CONFIG_CRYPTO_PCBC=m
# CONFIG_CRYPTO_HW is not set
+CONFIG_PRINTK_TIME=y
diff --git a/arch/powerpc/configs/powernv_defconfig b/arch/powerpc/configs/powernv_defconfig
index 6ab34e60495f..75f6e78b41c7 100644
--- a/arch/powerpc/configs/powernv_defconfig
+++ b/arch/powerpc/configs/powernv_defconfig
@@ -350,3 +350,4 @@ CONFIG_VIRTUALIZATION=y
CONFIG_KVM_BOOK3S_64=m
CONFIG_KVM_BOOK3S_64_HV=m
CONFIG_VHOST_NET=m
+CONFIG_PRINTK_TIME=y
diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/configs/ppc64_defconfig
index 5033e630afea..db6a0d8f525f 100644
--- a/arch/powerpc/configs/ppc64_defconfig
+++ b/arch/powerpc/configs/ppc64_defconfig
@@ -365,3 +365,4 @@ CONFIG_VIRTUALIZATION=y
CONFIG_KVM_BOOK3S_64=m
CONFIG_KVM_BOOK3S_64_HV=m
CONFIG_VHOST_NET=m
+CONFIG_PRINTK_TIME=y
diff --git a/arch/powerpc/configs/ps3_defconfig b/arch/powerpc/configs/ps3_defconfig
index 187e2f7c12c8..cf8d55f67272 100644
--- a/arch/powerpc/configs/ps3_defconfig
+++ b/arch/powerpc/configs/ps3_defconfig
@@ -171,3 +171,4 @@ CONFIG_CRYPTO_PCBC=m
CONFIG_CRYPTO_MICHAEL_MIC=m
CONFIG_CRYPTO_SALSA20=m
CONFIG_CRYPTO_LZO=m
+CONFIG_PRINTK_TIME=y
diff --git a/arch/powerpc/configs/pseries_defconfig b/arch/powerpc/configs/pseries_defconfig
index 0dd5cf7b566d..5e09a40cbcbf 100644
--- a/arch/powerpc/configs/pseries_defconfig
+++ b/arch/powerpc/configs/pseries_defconfig
@@ -325,3 +325,4 @@ CONFIG_VIRTUALIZATION=y
CONFIG_KVM_BOOK3S_64=m
CONFIG_KVM_BOOK3S_64_HV=m
CONFIG_VHOST_NET=m
+CONFIG_PRINTK_TIME=y
--
2.12.3
^ permalink raw reply related
* Re: [PATCH] powerpc: Move a dereference below a NULL test
From: Michal Suchánek @ 2018-09-26 14:22 UTC (permalink / raw)
To: zhong jiang; +Cc: paulus, benh, mpe, linuxppc-dev, linux-kernel
In-Reply-To: <1537962368-14019-1-git-send-email-zhongjiang@huawei.com>
On Wed, 26 Sep 2018 19:46:08 +0800
zhong jiang <zhongjiang@huawei.com> wrote:
> It is safe to move dereference below a NULL test.
>
> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
> ---
> arch/powerpc/kernel/cacheinfo.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/kernel/cacheinfo.c
> b/arch/powerpc/kernel/cacheinfo.c index a8f20e5..7f19714 100644
> --- a/arch/powerpc/kernel/cacheinfo.c
> +++ b/arch/powerpc/kernel/cacheinfo.c
> @@ -401,14 +401,13 @@ static struct cache
> *cache_lookup_or_instantiate(struct device_node *node, struct cache
> *cache;
> cache = cache_lookup_by_node(node);
> + if (!cache)
> + cache = cache_do_one_devnode(node, level);
>
> WARN_ONCE(cache && cache->level != level,
This has also null test so cache should be dereferenced only when
non-null here.
Thanks
Michal
^ permalink raw reply
* Re: [PATCH 14/30] memblock: add align parameter to memblock_alloc_node()
From: Michal Hocko @ 2018-09-26 14:23 UTC (permalink / raw)
To: Mike Rapoport
Cc: linux-mm, Andrew Morton, Catalin Marinas, Chris Zankel,
David S. Miller, Geert Uytterhoeven, Greentime Hu,
Greg Kroah-Hartman, Guan Xuetao, Ingo Molnar,
James E.J. Bottomley, Jonas Bonn, Jonathan Corbet, Ley Foon Tan,
Mark Salter, Martin Schwidefsky, Matt Turner, Michael Ellerman,
Michal Simek, Palmer Dabbelt, Paul Burton, Richard Kuo,
Richard Weinberger, Rich Felker, Russell King, Serge Semin,
Thomas Gleixner, Tony Luck, Vineet Gupta, Yoshinori Sato,
linux-alpha, linux-arm-kernel, linux-c6x-dev, linux-hexagon,
linux-ia64, linux-kernel, linux-m68k, linux-mips, linux-parisc,
linuxppc-dev, linux-riscv, linux-s390, linux-sh, linux-snps-arc,
linux-um, nios2-dev, openrisc, sparclinux, uclinux-h8-devel
In-Reply-To: <20180926134335.GF4628@rapoport-lnx>
On Wed 26-09-18 16:43:35, Mike Rapoport wrote:
> On Wed, Sep 26, 2018 at 11:36:48AM +0200, Michal Hocko wrote:
> > On Wed 26-09-18 11:31:27, Michal Hocko wrote:
> > > On Fri 14-09-18 15:10:29, Mike Rapoport wrote:
> > > > With the align parameter memblock_alloc_node() can be used as drop in
> > > > replacement for alloc_bootmem_pages_node() and __alloc_bootmem_node(),
> > > > which is done in the following patches.
> > >
> > > /me confused. Why do we need this patch at all? Maybe it should be
> > > folded into the later patch you are refereing here?
> >
> > OK, I can see 1536927045-23536-17-git-send-email-rppt@linux.vnet.ibm.com
> > now. If you are going to repost for whatever reason please merge those
> > two. Also I would get rid of the implicit "0 implies SMP_CACHE_BYTES"
> > behavior. It is subtle and you have to dig deep to find that out. Why
> > not make it explicit?
>
> Agree. I'd just prefer to make it a separate patch rather then resend the
> whole series.
Sure, no objection from me.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [PATCH] powerpc: Move a dereference below a NULL test
From: zhong jiang @ 2018-09-26 14:42 UTC (permalink / raw)
To: Michal Suchánek; +Cc: paulus, benh, mpe, linuxppc-dev, linux-kernel
In-Reply-To: <20180926162232.250c0090@naga>
On 2018/9/26 22:22, Michal Suchánek wrote:
> On Wed, 26 Sep 2018 19:46:08 +0800
> zhong jiang <zhongjiang@huawei.com> wrote:
>
>> It is safe to move dereference below a NULL test.
>>
>> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
>> ---
>> arch/powerpc/kernel/cacheinfo.c | 5 ++---
>> 1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/powerpc/kernel/cacheinfo.c
>> b/arch/powerpc/kernel/cacheinfo.c index a8f20e5..7f19714 100644
>> --- a/arch/powerpc/kernel/cacheinfo.c
>> +++ b/arch/powerpc/kernel/cacheinfo.c
>> @@ -401,14 +401,13 @@ static struct cache
>> *cache_lookup_or_instantiate(struct device_node *node, struct cache
>> *cache;
>> cache = cache_lookup_by_node(node);
>> + if (!cache)
>> + cache = cache_do_one_devnode(node, level);
>>
>> WARN_ONCE(cache && cache->level != level,
> This has also null test so cache should be dereferenced only when
> non-null here.
:-[ , you're right. I forget WARN_ONCE. please ignore the patch.
Sincerely,
zhong jiang
> Thanks
>
> Michal
>
> .
>
^ permalink raw reply
* Re: [v02] REPOST powerpc/migration: Handle unitialized timer reset
From: Michael Bringmann @ 2018-09-26 14:44 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev
Cc: Nathan Fontenot, minkim, Thomas Falcon, Tyrel Datwyler
In-Reply-To: <42KxfY2bFQz9s4Z@ozlabs.org>
Hello, Michael:
Please look at v03 of the patch set which was posted
just on 09/25/2018. We had a last minute brainstorm of how
to simplify the code after the v02 REPOST.
Also, note that we would like to invalidate the set,
[PATCH v08 0/5] powerpc/hotplug: Update affinity for migrated CPUs
https://lists.ozlabs.org/pipermail/linuxppc-dev/2018-July/176301.html
as we think it is covered now by other code.
Thanks for your attention and assistance.
Michael
On 09/26/2018 07:13 AM, Michael Ellerman wrote:
> On Thu, 2018-09-20 at 16:45:13 UTC, Michael Bringmann wrote:
>> After migration of a powerpc LPAR, the kernel executes code to
>> update the system state to reflect new platform characteristics.
>> Such changes include modifications to device tree properties
>> provided to the system by PHYP. Property notifications received
>> by the powerpc 'migration_store' code are passed along to the
>> kernel in general through a call to 'of_update_property' which
>> in turn passes such events back to all modules through entries like
>> the '.notifier_call' function within the NUMA module. When the
>> NUMA module updates its state, it resets its event timer. If this
>> occurs after a previous call to 'stop_topology_update' or on a
>> system without VPHN enabled, the code runs into an unitialized
>> timer structure and crashes. This patch adds a safety check
>> along this path toward the problem code.
>>
>> Note: This crash was observed on every LPM in the 4.17-rc7 kernel
>> (and in the 4.18 kernel) of a system with dedicated CPUs enabled.
>> An example crash log without the patch is as follows.
>>
> ...
>>
>> Signed-off-by: Michael Bringmann <mwb@linux.vnet.ibm.com>
>
> Applied to powerpc fixes, thanks.
>
> https://git.kernel.org/powerpc/c/8604895a34d92f5e186ceb931b0d1b
>
> cheers
>
>
--
Michael W. Bringmann
Linux Technology Center
IBM Corporation
Tie-Line 363-5196
External: (512) 286-5196
Cell: (512) 466-0650
mwb@linux.vnet.ibm.com
^ permalink raw reply
* RESCIND Re: [v02] REPOST powerpc/migration: Handle unitialized timer reset
From: Michael Bringmann @ 2018-09-26 14:54 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev
Cc: Nathan Fontenot, minkim, Thomas Falcon, Tyrel Datwyler
In-Reply-To: <3b78a11a-296e-00ac-3648-b26ce7c8aaac@linux.vnet.ibm.com>
Hello, Michael:
I am an idiot this morning. Not enough coffee.
I confused this posting with another. Please forget the request.
We do want to omit
[PATCH v08 0/5] powerpc/hotplug: Update affinity for migrated CPUs
https://lists.ozlabs.org/pipermail/linuxppc-dev/2018-July/176301.html
though.
Very sorry for the inconvenience.
Michael
On 09/26/2018 09:44 AM, Michael Bringmann wrote:
> Hello, Michael:
> Please look at v03 of the patch set which was posted
> just on 09/25/2018. We had a last minute brainstorm of how
> to simplify the code after the v02 REPOST.
> Also, note that we would like to invalidate the set,
>
> [PATCH v08 0/5] powerpc/hotplug: Update affinity for migrated CPUs
> https://lists.ozlabs.org/pipermail/linuxppc-dev/2018-July/176301.html
>
> as we think it is covered now by other code.
>
> Thanks for your attention and assistance.
>
> Michael
>
> On 09/26/2018 07:13 AM, Michael Ellerman wrote:
>> On Thu, 2018-09-20 at 16:45:13 UTC, Michael Bringmann wrote:
>>> After migration of a powerpc LPAR, the kernel executes code to
>>> update the system state to reflect new platform characteristics.
>>> Such changes include modifications to device tree properties
>>> provided to the system by PHYP. Property notifications received
>>> by the powerpc 'migration_store' code are passed along to the
>>> kernel in general through a call to 'of_update_property' which
>>> in turn passes such events back to all modules through entries like
>>> the '.notifier_call' function within the NUMA module. When the
>>> NUMA module updates its state, it resets its event timer. If this
>>> occurs after a previous call to 'stop_topology_update' or on a
>>> system without VPHN enabled, the code runs into an unitialized
>>> timer structure and crashes. This patch adds a safety check
>>> along this path toward the problem code.
>>>
>>> Note: This crash was observed on every LPM in the 4.17-rc7 kernel
>>> (and in the 4.18 kernel) of a system with dedicated CPUs enabled.
>>> An example crash log without the patch is as follows.
>>>
>> ...
>>>
>>> Signed-off-by: Michael Bringmann <mwb@linux.vnet.ibm.com>
>>
>> Applied to powerpc fixes, thanks.
>>
>> https://git.kernel.org/powerpc/c/8604895a34d92f5e186ceb931b0d1b
>>
>> cheers
>>
>>
>
--
Michael W. Bringmann
Linux Technology Center
IBM Corporation
Tie-Line 363-5196
External: (512) 286-5196
Cell: (512) 466-0650
mwb@linux.vnet.ibm.com
^ permalink raw reply
* Re: [PATCH 03/30] mm: remove CONFIG_HAVE_MEMBLOCK
From: Alexander Duyck @ 2018-09-26 16:58 UTC (permalink / raw)
To: rppt
Cc: linux-mm, Andrew Morton, Catalin Marinas, chris, David Miller,
Geert Uytterhoeven, green.hu, Greg KH, gxt, Ingo Molnar, jejb,
jonas, Jonathan Corbet, lftan, msalter, Martin Schwidefsky,
mattst88, mpe, Michal Hocko, monstr, palmer, paul.burton, rkuo,
richard, dalias, Russell King - ARM Linux, fancer.lancer,
Thomas Gleixner, Tony Luck, vgupta, Yoshinori Sato, linux-alpha,
linux-arm-kernel, linux-c6x-dev, linux-hexagon, linux-ia64, LKML,
linux-m68k, linux-mips, linux-parisc,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT), linux-riscv,
linux-s390, linux-sh, linux-snps-arc, linux-um, nios2-dev,
openrisc, sparclinux, uclinux-h8-devel
In-Reply-To: <1536927045-23536-4-git-send-email-rppt@linux.vnet.ibm.com>
On Fri, Sep 14, 2018 at 5:11 AM Mike Rapoport <rppt@linux.vnet.ibm.com> wrote:
>
> All architecures use memblock for early memory management. There is no need
> for the CONFIG_HAVE_MEMBLOCK configuration option.
>
> Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com>
<snip>
> diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> index 5169205..4ae91fc 100644
> --- a/include/linux/memblock.h
> +++ b/include/linux/memblock.h
> @@ -2,7 +2,6 @@
> #define _LINUX_MEMBLOCK_H
> #ifdef __KERNEL__
>
> -#ifdef CONFIG_HAVE_MEMBLOCK
> /*
> * Logical memory blocks.
> *
> @@ -460,7 +459,6 @@ static inline phys_addr_t memblock_alloc(phys_addr_t size, phys_addr_t align)
> {
> return 0;
> }
> -#endif /* CONFIG_HAVE_MEMBLOCK */
>
> #endif /* __KERNEL__ */
There was an #else above this section and I believe it and the code
after it needs to be stripped as well.
^ permalink raw reply
* Re: [PATCH 1/2] soc: fsl: qbman: qman_portal: defer probing when qman is not available
From: Li Yang @ 2018-09-26 18:15 UTC (permalink / raw)
To: alexandre.belloni
Cc: Olof Johansson, Roy Pledge, linuxppc-dev,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE, lkml
In-Reply-To: <20180926092706.GA16644@piout.net>
On Wed, Sep 26, 2018 at 4:28 AM Alexandre Belloni
<alexandre.belloni@bootlin.com> wrote:
>
> On 25/09/2018 21:45:56+0200, Olof Johansson wrote:
> > Hi,
> >
> >
> > On Thu, Aug 23, 2018 at 11:36 PM Alexandre Belloni
> > <alexandre.belloni@bootlin.com> wrote:
> > >
> > > If the qman driver (qman_ccsr) doesn't probe or fail to probe before
> > > qman_portal, qm_ccsr_start will be either NULL or a stale pointer to an
> > > unmapped page.
> > >
> > > This leads to a crash when probing qman_portal as the init_pcfg function
> > > calls qman_liodn_fixup that tries to read qman registers.
> > >
> > > Assume that qman didn't probe when the pool mask is 0.
> > >
> > > Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> > > ---
> > > drivers/soc/fsl/qbman/qman_portal.c | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/drivers/soc/fsl/qbman/qman_portal.c b/drivers/soc/fsl/qbman/qman_portal.c
> > > index a120002b630e..4fc80d2c8feb 100644
> > > --- a/drivers/soc/fsl/qbman/qman_portal.c
> > > +++ b/drivers/soc/fsl/qbman/qman_portal.c
> > > @@ -277,6 +277,8 @@ static int qman_portal_probe(struct platform_device *pdev)
> > > }
> > >
> > > pcfg->pools = qm_get_pools_sdqcr();
> > > + if (pcfg->pools == 0)
> > > + return -EPROBE_DEFER;
> >
> > This is quite late in the probe, after a bunch of resources have been claimed.
> >
> > Note that the ioremaps above this are doing unwinds, and you'll end up
> > doing duplicate ioremaps if you come in and probe again.
> >
> > You should probably unwind those allocations, or move them to devm_*
> > or do this check earlier in the function.
> >
>
> The actual chance of having that happen is quite small (this was coming
> from a non working DT) and I mainly wanted to avoid a crash so the
> platform could still boot. I would think moving to devm_ would be the
> right thing to do.
Even if it is not failing with the upstreamed device trees, it is
still good to harden the driver for possible issues. Moving to devm_
is definitely a right thing to do. But I also think checking if the
qman is already probed should be the first thing to do before starting
to allocate resources and etc and rolling back later. Probably we can
move the qm_get_pools_sdqcr() to the begining of the probe to
determine if qman is probed as it doesn't seem to depend on any of the
setups done right now.
Regards,
Leo
^ permalink raw reply
* Re: [PATCH 03/30] mm: remove CONFIG_HAVE_MEMBLOCK
From: Mike Rapoport @ 2018-09-26 18:31 UTC (permalink / raw)
To: Alexander Duyck
Cc: linux-mm, Andrew Morton, Catalin Marinas, chris, David Miller,
Geert Uytterhoeven, green.hu, Greg KH, gxt, Ingo Molnar, jejb,
jonas, Jonathan Corbet, lftan, msalter, Martin Schwidefsky,
mattst88, mpe, Michal Hocko, monstr, palmer, paul.burton, rkuo,
richard, dalias, Russell King - ARM Linux, fancer.lancer,
Thomas Gleixner, Tony Luck, vgupta, Yoshinori Sato, linux-alpha,
linux-arm-kernel, linux-c6x-dev, linux-hexagon, linux-ia64, LKML,
linux-m68k, linux-mips, linux-parisc,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT), linux-riscv,
linux-s390, linux-sh, linux-snps-arc, linux-um, nios2-dev,
openrisc, sparclinux, uclinux-h8-devel
In-Reply-To: <CAKgT0UdP=78RsWHMxFu4PD8a3AhA3eNcG68Z_9aGY0vhOKf7xA@mail.gmail.com>
On Wed, Sep 26, 2018 at 09:58:41AM -0700, Alexander Duyck wrote:
> On Fri, Sep 14, 2018 at 5:11 AM Mike Rapoport <rppt@linux.vnet.ibm.com> wrote:
> >
> > All architecures use memblock for early memory management. There is no need
> > for the CONFIG_HAVE_MEMBLOCK configuration option.
> >
> > Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com>
>
> <snip>
>
> > diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> > index 5169205..4ae91fc 100644
> > --- a/include/linux/memblock.h
> > +++ b/include/linux/memblock.h
> > @@ -2,7 +2,6 @@
> > #define _LINUX_MEMBLOCK_H
> > #ifdef __KERNEL__
> >
> > -#ifdef CONFIG_HAVE_MEMBLOCK
> > /*
> > * Logical memory blocks.
> > *
> > @@ -460,7 +459,6 @@ static inline phys_addr_t memblock_alloc(phys_addr_t size, phys_addr_t align)
> > {
> > return 0;
> > }
> > -#endif /* CONFIG_HAVE_MEMBLOCK */
> >
> > #endif /* __KERNEL__ */
>
> There was an #else above this section and I believe it and the code
> after it needs to be stripped as well.
Right, I've already sent the fix [1] and it's in mmots.
[1] https://lkml.org/lkml/2018/9/19/416
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH v3 2/2] powerpc/64: add stack protector support
From: Segher Boessenkool @ 2018-09-26 17:37 UTC (permalink / raw)
To: Christophe LEROY
Cc: Russell Currey, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, Andrew Donnellan, linuxppc-dev, linux-kernel
In-Reply-To: <284752d1-6c32-bdca-72d3-4d8616b26fbf@c-s.fr>
On Wed, Sep 26, 2018 at 11:41:26AM +0200, Christophe LEROY wrote:
> Le 26/09/2018 à 11:28, Segher Boessenkool a écrit :
> >On Wed, Sep 26, 2018 at 09:58:30AM +0200, Christophe LEROY wrote:
> >>Segher, any idea about this problem ?
> >
> >>>>arch/powerpc/platforms/powermac/bootx_init.o: In function
> >>>>`bootx_printf':
> >>>>/var/lib/jenkins-slave/workspace/snowpatch/snowpatch-linux-
> >>>>sparse/linux/arch/powerpc/platforms/powermac/bootx_init.c:88:
> >>>>undefined reference to `__stack_chk_fail_local'
> >
> >Are you building as PIC? Are you linking libssp_nonshared.a? Why not?
>
> Spotted, thanks.
>
> arch/powerpc/platforms/powermac/Makefile contains:
>
> CFLAGS_bootx_init.o += -fPIC
>
> Does it mean we should add -lssp_nonshared to LDFLAGS_vmlinux ?
Something like that.
> Or maybe stack protection on bootx_init doesn't make much sense and we
> could just do the following ?
>
> CFLAGS_bootx_init.o += -fPIC $(call cc-option,
> -fno-stack-protector)
But more likely this. Why does it use -fPIC?
If it is only boot-time init (which the name suggests) then disabling
ssp makes a lot of sense.
Segher
^ permalink raw reply
* Re: [PATCH v4 1/2] powerpc/32: add stack protector support
From: Segher Boessenkool @ 2018-09-26 19:16 UTC (permalink / raw)
To: Christophe Leroy
Cc: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
linuxppc-dev, linux-kernel
In-Reply-To: <d6c43ab708bf9ae1266c745fece457ed2da43d7c.1537961921.git.christophe.leroy@c-s.fr>
On Wed, Sep 26, 2018 at 11:40:38AM +0000, Christophe Leroy wrote:
> +static __always_inline void boot_init_stack_canary(void)
> +{
> + unsigned long canary;
> +
> + /* Try to get a semi random initial value. */
> + get_random_bytes(&canary, sizeof(canary));
> + canary ^= mftb();
> + canary ^= LINUX_VERSION_CODE;
> +
> + current->stack_canary = canary;
> +}
I still think you should wait until there is entropy available. You
haven't answered my questions about that (or I didn't see them): what
does the kernel do in other similar cases?
Looks great otherwise!
Segher
^ permalink raw reply
* Re: [PATCH -next] PCI/AER: Remove duplicated include from err.c
From: Bjorn Helgaas @ 2018-09-26 19:24 UTC (permalink / raw)
To: YueHaibing
Cc: Russell Currey, Sam Bobroff, Oliver O'Halloran, Bjorn Helgaas,
linuxppc-dev, linux-pci, kernel-janitors
In-Reply-To: <1537959610-71713-1-git-send-email-yuehaibing@huawei.com>
On Wed, Sep 26, 2018 at 11:00:10AM +0000, YueHaibing wrote:
> Remove duplicated include.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied to pci/hotplug for v4.20, thanks!
> ---
> drivers/pci/pcie/err.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/pci/pcie/err.c b/drivers/pci/pcie/err.c
> index 4da2a62b..773197a 100644
> --- a/drivers/pci/pcie/err.c
> +++ b/drivers/pci/pcie/err.c
> @@ -12,7 +12,6 @@
>
> #include <linux/pci.h>
> #include <linux/module.h>
> -#include <linux/pci.h>
> #include <linux/kernel.h>
> #include <linux/errno.h>
> #include <linux/aer.h>
>
>
>
^ permalink raw reply
* Re: [PATCH v3 3/3] dt-bindings: watchdog: add mpc8xxx-wdt support
From: Rob Herring @ 2018-09-26 22:35 UTC (permalink / raw)
To: Christophe Leroy
Cc: Wim Van Sebroeck, Guenter Roeck, Radu Rendec, Mark Rutland,
linux-kernel, linuxppc-dev, linux-watchdog, devicetree
In-Reply-To: <e3e0bcfd7b779b978d07e088a8bd667ea9ddf4aa.1537163780.git.christophe.leroy@c-s.fr>
On Mon, 17 Sep 2018 06:22:53 +0000 (UTC), Christophe Leroy wrote:
> Add description of DT bindings for mpc8xxx-wdt driver which
> handles the CPU watchdog timer on the mpc83xx, mpc86xx and mpc8xx.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> ---
> .../devicetree/bindings/watchdog/mpc8xxx-wdt.txt | 25 ++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/watchdog/mpc8xxx-wdt.txt
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 03/30] mm: remove CONFIG_HAVE_MEMBLOCK
From: Alexander Duyck @ 2018-09-27 0:34 UTC (permalink / raw)
To: rppt
Cc: linux-mm, Andrew Morton, Catalin Marinas, chris, David Miller,
Geert Uytterhoeven, green.hu, Greg KH, gxt, Ingo Molnar, jejb,
jonas, Jonathan Corbet, lftan, msalter, Martin Schwidefsky,
mattst88, mpe, Michal Hocko, monstr, palmer, paul.burton, rkuo,
richard, dalias, Russell King - ARM Linux, fancer.lancer,
Thomas Gleixner, Tony Luck, vgupta, Yoshinori Sato, linux-alpha,
linux-arm-kernel, linux-c6x-dev, linux-hexagon, linux-ia64, LKML,
linux-m68k, linux-mips, linux-parisc,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT), linux-riscv,
linux-s390, linux-sh, linux-snps-arc, linux-um, nios2-dev,
openrisc, sparclinux, uclinux-h8-devel
In-Reply-To: <20180926183152.GA4597@rapoport-lnx>
On Wed, Sep 26, 2018 at 11:32 AM Mike Rapoport <rppt@linux.vnet.ibm.com> wrote:
>
> On Wed, Sep 26, 2018 at 09:58:41AM -0700, Alexander Duyck wrote:
> > On Fri, Sep 14, 2018 at 5:11 AM Mike Rapoport <rppt@linux.vnet.ibm.com> wrote:
> > >
> > > All architecures use memblock for early memory management. There is no need
> > > for the CONFIG_HAVE_MEMBLOCK configuration option.
> > >
> > > Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com>
> >
> > <snip>
> >
> > > diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> > > index 5169205..4ae91fc 100644
> > > --- a/include/linux/memblock.h
> > > +++ b/include/linux/memblock.h
> > > @@ -2,7 +2,6 @@
> > > #define _LINUX_MEMBLOCK_H
> > > #ifdef __KERNEL__
> > >
> > > -#ifdef CONFIG_HAVE_MEMBLOCK
> > > /*
> > > * Logical memory blocks.
> > > *
> > > @@ -460,7 +459,6 @@ static inline phys_addr_t memblock_alloc(phys_addr_t size, phys_addr_t align)
> > > {
> > > return 0;
> > > }
> > > -#endif /* CONFIG_HAVE_MEMBLOCK */
> > >
> > > #endif /* __KERNEL__ */
> >
> > There was an #else above this section and I believe it and the code
> > after it needs to be stripped as well.
>
> Right, I've already sent the fix [1] and it's in mmots.
>
> [1] https://lkml.org/lkml/2018/9/19/416
>
Are you sure? The patch you reference appears to be for
drivers/of/fdt.c, and the bit I pointed out here is in
include/linux/memblock.h.
- Alex
^ permalink raw reply
* Re: [PATCH 2/5] dma-direct: add an explicit dma_direct_get_required_mask
From: Benjamin Herrenschmidt @ 2018-09-27 1:31 UTC (permalink / raw)
To: Christoph Hellwig, iommu
Cc: Marek Szyprowski, Robin Murphy, Greg Kroah-Hartman, linux-kernel,
linuxppc-dev
In-Reply-To: <20180920185247.20037-3-hch@lst.de>
On Thu, 2018-09-20 at 20:52 +0200, Christoph Hellwig wrote:
> This is somewhat modelled after the powerpc version, and differs from
> the legacy fallback in use fls64 instead of pointlessly splitting up the
> address into low and high dwords and in that it takes (__)phys_to_dma
> into account.
This looks like it will be usable if/when we switch powerpc to
dma/direct.c
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> include/linux/dma-direct.h | 1 +
> kernel/dma/direct.c | 21 ++++++++++++++++++---
> 2 files changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h
> index 86a59ba5a7f3..b79496d8c75b 100644
> --- a/include/linux/dma-direct.h
> +++ b/include/linux/dma-direct.h
> @@ -55,6 +55,7 @@ static inline void dma_mark_clean(void *addr, size_t size)
> }
> #endif /* CONFIG_ARCH_HAS_DMA_MARK_CLEAN */
>
> +u64 dma_direct_get_required_mask(struct device *dev);
> void *dma_direct_alloc(struct device *dev, size_t size, dma_addr_t *dma_handle,
> gfp_t gfp, unsigned long attrs);
> void dma_direct_free(struct device *dev, size_t size, void *cpu_addr,
> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> index c954f0a6dc62..81b73a5bba54 100644
> --- a/kernel/dma/direct.c
> +++ b/kernel/dma/direct.c
> @@ -53,11 +53,25 @@ check_addr(struct device *dev, dma_addr_t dma_addr, size_t size,
> return true;
> }
>
> +static inline dma_addr_t phys_to_dma_direct(struct device *dev,
> + phys_addr_t phys)
> +{
> + if (force_dma_unencrypted())
> + return __phys_to_dma(dev, phys);
> + return phys_to_dma(dev, phys);
> +}
> +
> +u64 dma_direct_get_required_mask(struct device *dev)
> +{
> + u64 max_dma = phys_to_dma_direct(dev, (max_pfn - 1) << PAGE_SHIFT);
> +
> + return (1ULL << (fls64(max_dma) - 1)) * 2 - 1;
> +}
> +
> static bool dma_coherent_ok(struct device *dev, phys_addr_t phys, size_t size)
> {
> - dma_addr_t addr = force_dma_unencrypted() ?
> - __phys_to_dma(dev, phys) : phys_to_dma(dev, phys);
> - return addr + size - 1 <= dev->coherent_dma_mask;
> + return phys_to_dma_direct(dev, phys) + size - 1 <=
> + dev->coherent_dma_mask;
> }
>
> void *dma_direct_alloc_pages(struct device *dev, size_t size,
> @@ -296,6 +310,7 @@ const struct dma_map_ops dma_direct_ops = {
> .unmap_page = dma_direct_unmap_page,
> .unmap_sg = dma_direct_unmap_sg,
> #endif
> + .get_required_mask = dma_direct_get_required_mask,
> .dma_supported = dma_direct_supported,
> .mapping_error = dma_direct_mapping_error,
> .cache_sync = arch_dma_cache_sync,
^ permalink raw reply
* Re: [PATCH 3/5] dma-direct: refine dma_direct_alloc zone selection
From: Benjamin Herrenschmidt @ 2018-09-27 1:45 UTC (permalink / raw)
To: Christoph Hellwig, iommu
Cc: Marek Szyprowski, Robin Murphy, Greg Kroah-Hartman, linux-kernel,
linuxppc-dev
In-Reply-To: <20180920185247.20037-4-hch@lst.de>
On Thu, 2018-09-20 at 20:52 +0200, Christoph Hellwig wrote:
> +static gfp_t __dma_direct_optimal_gfp_mask(struct device *dev, u64 dma_mask,
> + u64 *phys_mask)
> +{
> + if (force_dma_unencrypted())
> + *phys_mask = __dma_to_phys(dev, dma_mask);
> + else
> + *phys_mask = dma_to_phys(dev, dma_mask);
> +
> + /* GFP_DMA32 and GFP_DMA are no ops without the corresponding zones: */
> + if (*phys_mask <= DMA_BIT_MASK(ARCH_ZONE_DMA_BITS))
> + return GFP_DMA;
> + if (*phys_mask <= DMA_BIT_MASK(32))
> + return GFP_DMA32;
> + return 0;
> +}
I'm not sure this is entirely right.
Let's say the mask is 30 bits. You will return GFP_DMA32, which will
fail if you allocate something above 1G (which is legit for
ZONE_DMA32).
I think the logic should be:
if (mask < ZONE_DMA)
fail;
else if (mask < ZONE_DMA32)
use ZONE_DMA or fail if doesn't exist
else if (mask < top_of_ram)
use ZONE_DMA32 or fail if doesn't exist
else
use ZONE_NORMAL
Additionally, we want to fold-in the top-of-ram test such that we don't
fail the second case if the mask is 31-bits (smaller than ZONE_DMA32)
but top of ram is also small enough.
So the top of ram test should take precendence.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 5/5] dma-direct: always allow dma mask <= physiscal memory size
From: Benjamin Herrenschmidt @ 2018-09-27 1:50 UTC (permalink / raw)
To: Christoph Hellwig, iommu
Cc: Marek Szyprowski, Robin Murphy, Greg Kroah-Hartman, linux-kernel,
linuxppc-dev
In-Reply-To: <20180920185247.20037-6-hch@lst.de>
On Thu, 2018-09-20 at 20:52 +0200, Christoph Hellwig wrote:
> This way an architecture with less than 4G of RAM can support dma_mask
> smaller than 32-bit without a ZONE_DMA. Apparently that is a common
> case on powerpc.
Anything that uses a b43 wifi adapter which has a 31-bit limitation
actually :-)
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> kernel/dma/direct.c | 28 ++++++++++++++++------------
> 1 file changed, 16 insertions(+), 12 deletions(-)
>
> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> index 64466b7ef67b..d1e103c6b107 100644
> --- a/kernel/dma/direct.c
> +++ b/kernel/dma/direct.c
> @@ -4,6 +4,7 @@
> *
> * DMA operations that map physical memory directly without using an IOMMU.
> */
> +#include <linux/bootmem.h> /* for max_pfn */
> #include <linux/export.h>
> #include <linux/mm.h>
> #include <linux/dma-direct.h>
> @@ -283,21 +284,24 @@ int dma_direct_map_sg(struct device *dev, struct scatterlist *sgl, int nents,
> return nents;
> }
>
> +/*
> + * Because 32-bit DMA masks are so common we expect every architecture to be
> + * able to satisfy them - either by not supporting more physical memory, or by
> + * providing a ZONE_DMA32. If neither is the case, the architecture needs to
> + * use an IOMMU instead of the direct mapping.
> + */
> int dma_direct_supported(struct device *dev, u64 mask)
> {
> -#ifdef CONFIG_ZONE_DMA
> - if (mask < phys_to_dma(dev, DMA_BIT_MASK(ARCH_ZONE_DMA_BITS)))
> - return 0;
> -#else
> - /*
> - * Because 32-bit DMA masks are so common we expect every architecture
> - * to be able to satisfy them - either by not supporting more physical
> - * memory, or by providing a ZONE_DMA32. If neither is the case, the
> - * architecture needs to use an IOMMU instead of the direct mapping.
> - */
> - if (mask < phys_to_dma(dev, DMA_BIT_MASK(32)))
> + u64 min_mask;
> +
> + if (IS_ENABLED(CONFIG_ZONE_DMA))
> + min_mask = DMA_BIT_MASK(ARCH_ZONE_DMA_BITS);
> + else
> + min_mask = min_t(u64, DMA_BIT_MASK(32),
> + (max_pfn - 1) << PAGE_SHIFT);
> +
> + if (mask >= phys_to_dma(dev, min_mask))
> return 0;
nitpick ... to be completely "correct", I would have written
if (IS_ENABLED(CONFIG_ZONE_DMA))
min_mask = DMA_BIT_MASK(ARCH_ZONE_DMA_BITS);
else
min_mask = DMA_BIT_MASK(32);
min_mask = min_t(u64, min_mask, (max_pfn - 1) << PAGE_SHIFT);
In "theory" it's also ok to have a mask < ZONE_DMA_BITS as long as it's
big enough to fit all memory :-)
> -#endif
> return 1;
> }
>
^ permalink raw reply
* Re: [PATCH 1/5] dma-mapping: make the get_required_mask method available unconditionally
From: Benjamin Herrenschmidt @ 2018-09-27 1:28 UTC (permalink / raw)
To: Christoph Hellwig, iommu
Cc: Marek Szyprowski, Robin Murphy, Greg Kroah-Hartman, linux-kernel,
linuxppc-dev
In-Reply-To: <20180920185247.20037-2-hch@lst.de>
On Thu, 2018-09-20 at 20:52 +0200, Christoph Hellwig wrote:
> This save some duplication for ia64, and makes the interface more
> general. In the long run we want each dma_map_ops instance to fill this
> out, but this will take a little more prep work.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
(For powerpc)
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> arch/ia64/include/asm/dma-mapping.h | 2 --
> arch/ia64/include/asm/machvec.h | 7 -------
> arch/ia64/include/asm/machvec_init.h | 1 -
> arch/ia64/include/asm/machvec_sn2.h | 2 --
> arch/ia64/pci/pci.c | 26 --------------------------
> arch/ia64/sn/pci/pci_dma.c | 4 ++--
> drivers/base/platform.c | 13 +++++++++++--
> drivers/pci/controller/vmd.c | 4 ----
> include/linux/dma-mapping.h | 2 --
> 9 files changed, 13 insertions(+), 48 deletions(-)
>
> diff --git a/arch/ia64/include/asm/dma-mapping.h b/arch/ia64/include/asm/dma-mapping.h
> index 76e4d6632d68..522745ae67bb 100644
> --- a/arch/ia64/include/asm/dma-mapping.h
> +++ b/arch/ia64/include/asm/dma-mapping.h
> @@ -10,8 +10,6 @@
> #include <linux/scatterlist.h>
> #include <linux/dma-debug.h>
>
> -#define ARCH_HAS_DMA_GET_REQUIRED_MASK
> -
> extern const struct dma_map_ops *dma_ops;
> extern struct ia64_machine_vector ia64_mv;
> extern void set_iommu_machvec(void);
> diff --git a/arch/ia64/include/asm/machvec.h b/arch/ia64/include/asm/machvec.h
> index 267f4f170191..5133739966bc 100644
> --- a/arch/ia64/include/asm/machvec.h
> +++ b/arch/ia64/include/asm/machvec.h
> @@ -44,7 +44,6 @@ typedef void ia64_mv_kernel_launch_event_t(void);
>
> /* DMA-mapping interface: */
> typedef void ia64_mv_dma_init (void);
> -typedef u64 ia64_mv_dma_get_required_mask (struct device *);
> typedef const struct dma_map_ops *ia64_mv_dma_get_ops(struct device *);
>
> /*
> @@ -127,7 +126,6 @@ extern void machvec_tlb_migrate_finish (struct mm_struct *);
> # define platform_global_tlb_purge ia64_mv.global_tlb_purge
> # define platform_tlb_migrate_finish ia64_mv.tlb_migrate_finish
> # define platform_dma_init ia64_mv.dma_init
> -# define platform_dma_get_required_mask ia64_mv.dma_get_required_mask
> # define platform_dma_get_ops ia64_mv.dma_get_ops
> # define platform_irq_to_vector ia64_mv.irq_to_vector
> # define platform_local_vector_to_irq ia64_mv.local_vector_to_irq
> @@ -171,7 +169,6 @@ struct ia64_machine_vector {
> ia64_mv_global_tlb_purge_t *global_tlb_purge;
> ia64_mv_tlb_migrate_finish_t *tlb_migrate_finish;
> ia64_mv_dma_init *dma_init;
> - ia64_mv_dma_get_required_mask *dma_get_required_mask;
> ia64_mv_dma_get_ops *dma_get_ops;
> ia64_mv_irq_to_vector *irq_to_vector;
> ia64_mv_local_vector_to_irq *local_vector_to_irq;
> @@ -211,7 +208,6 @@ struct ia64_machine_vector {
> platform_global_tlb_purge, \
> platform_tlb_migrate_finish, \
> platform_dma_init, \
> - platform_dma_get_required_mask, \
> platform_dma_get_ops, \
> platform_irq_to_vector, \
> platform_local_vector_to_irq, \
> @@ -286,9 +282,6 @@ extern const struct dma_map_ops *dma_get_ops(struct device *);
> #ifndef platform_dma_get_ops
> # define platform_dma_get_ops dma_get_ops
> #endif
> -#ifndef platform_dma_get_required_mask
> -# define platform_dma_get_required_mask ia64_dma_get_required_mask
> -#endif
> #ifndef platform_irq_to_vector
> # define platform_irq_to_vector __ia64_irq_to_vector
> #endif
> diff --git a/arch/ia64/include/asm/machvec_init.h b/arch/ia64/include/asm/machvec_init.h
> index 2b32fd06b7c6..2aafb69a3787 100644
> --- a/arch/ia64/include/asm/machvec_init.h
> +++ b/arch/ia64/include/asm/machvec_init.h
> @@ -4,7 +4,6 @@
>
> extern ia64_mv_send_ipi_t ia64_send_ipi;
> extern ia64_mv_global_tlb_purge_t ia64_global_tlb_purge;
> -extern ia64_mv_dma_get_required_mask ia64_dma_get_required_mask;
> extern ia64_mv_irq_to_vector __ia64_irq_to_vector;
> extern ia64_mv_local_vector_to_irq __ia64_local_vector_to_irq;
> extern ia64_mv_pci_get_legacy_mem_t ia64_pci_get_legacy_mem;
> diff --git a/arch/ia64/include/asm/machvec_sn2.h b/arch/ia64/include/asm/machvec_sn2.h
> index ece9fa85be88..b5153d300289 100644
> --- a/arch/ia64/include/asm/machvec_sn2.h
> +++ b/arch/ia64/include/asm/machvec_sn2.h
> @@ -55,7 +55,6 @@ extern ia64_mv_readb_t __sn_readb_relaxed;
> extern ia64_mv_readw_t __sn_readw_relaxed;
> extern ia64_mv_readl_t __sn_readl_relaxed;
> extern ia64_mv_readq_t __sn_readq_relaxed;
> -extern ia64_mv_dma_get_required_mask sn_dma_get_required_mask;
> extern ia64_mv_dma_init sn_dma_init;
> extern ia64_mv_migrate_t sn_migrate;
> extern ia64_mv_kernel_launch_event_t sn_kernel_launch_event;
> @@ -100,7 +99,6 @@ extern ia64_mv_pci_fixup_bus_t sn_pci_fixup_bus;
> #define platform_pci_get_legacy_mem sn_pci_get_legacy_mem
> #define platform_pci_legacy_read sn_pci_legacy_read
> #define platform_pci_legacy_write sn_pci_legacy_write
> -#define platform_dma_get_required_mask sn_dma_get_required_mask
> #define platform_dma_init sn_dma_init
> #define platform_migrate sn_migrate
> #define platform_kernel_launch_event sn_kernel_launch_event
> diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
> index 7ccc64d5fe3e..5d71800df431 100644
> --- a/arch/ia64/pci/pci.c
> +++ b/arch/ia64/pci/pci.c
> @@ -568,32 +568,6 @@ static void __init set_pci_dfl_cacheline_size(void)
> pci_dfl_cache_line_size = (1 << cci.pcci_line_size) / 4;
> }
>
> -u64 ia64_dma_get_required_mask(struct device *dev)
> -{
> - u32 low_totalram = ((max_pfn - 1) << PAGE_SHIFT);
> - u32 high_totalram = ((max_pfn - 1) >> (32 - PAGE_SHIFT));
> - u64 mask;
> -
> - if (!high_totalram) {
> - /* convert to mask just covering totalram */
> - low_totalram = (1 << (fls(low_totalram) - 1));
> - low_totalram += low_totalram - 1;
> - mask = low_totalram;
> - } else {
> - high_totalram = (1 << (fls(high_totalram) - 1));
> - high_totalram += high_totalram - 1;
> - mask = (((u64)high_totalram) << 32) + 0xffffffff;
> - }
> - return mask;
> -}
> -EXPORT_SYMBOL_GPL(ia64_dma_get_required_mask);
> -
> -u64 dma_get_required_mask(struct device *dev)
> -{
> - return platform_dma_get_required_mask(dev);
> -}
> -EXPORT_SYMBOL_GPL(dma_get_required_mask);
> -
> static int __init pcibios_init(void)
> {
> set_pci_dfl_cacheline_size();
> diff --git a/arch/ia64/sn/pci/pci_dma.c b/arch/ia64/sn/pci/pci_dma.c
> index 74c934a997bb..96eb2567718a 100644
> --- a/arch/ia64/sn/pci/pci_dma.c
> +++ b/arch/ia64/sn/pci/pci_dma.c
> @@ -344,11 +344,10 @@ static int sn_dma_mapping_error(struct device *dev, dma_addr_t dma_addr)
> return 0;
> }
>
> -u64 sn_dma_get_required_mask(struct device *dev)
> +static u64 sn_dma_get_required_mask(struct device *dev)
> {
> return DMA_BIT_MASK(64);
> }
> -EXPORT_SYMBOL_GPL(sn_dma_get_required_mask);
>
> char *sn_pci_get_legacy_mem(struct pci_bus *bus)
> {
> @@ -473,6 +472,7 @@ static struct dma_map_ops sn_dma_ops = {
> .sync_sg_for_device = sn_dma_sync_sg_for_device,
> .mapping_error = sn_dma_mapping_error,
> .dma_supported = sn_dma_supported,
> + .get_required_mask = sn_dma_get_required_mask,
> };
>
> void sn_dma_init(void)
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index dff82a3c2caa..709ed36026a1 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -1179,8 +1179,7 @@ int __init platform_bus_init(void)
> return error;
> }
>
> -#ifndef ARCH_HAS_DMA_GET_REQUIRED_MASK
> -u64 dma_get_required_mask(struct device *dev)
> +static u64 __dma_get_required_mask(struct device *dev)
> {
> u32 low_totalram = ((max_pfn - 1) << PAGE_SHIFT);
> u32 high_totalram = ((max_pfn - 1) >> (32 - PAGE_SHIFT));
> @@ -1198,6 +1197,16 @@ u64 dma_get_required_mask(struct device *dev)
> }
> return mask;
> }
> +
> +#ifndef ARCH_HAS_DMA_GET_REQUIRED_MASK
> +u64 dma_get_required_mask(struct device *dev)
> +{
> + const struct dma_map_ops *ops = get_dma_ops(dev);
> +
> + if (ops->get_required_mask)
> + return ops->get_required_mask(dev);
> + return __dma_get_required_mask(dev);
> +}
> EXPORT_SYMBOL_GPL(dma_get_required_mask);
> #endif
>
> diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c
> index fd2dbd7eed7b..f31ed62d518c 100644
> --- a/drivers/pci/controller/vmd.c
> +++ b/drivers/pci/controller/vmd.c
> @@ -404,12 +404,10 @@ static int vmd_dma_supported(struct device *dev, u64 mask)
> return vmd_dma_ops(dev)->dma_supported(to_vmd_dev(dev), mask);
> }
>
> -#ifdef ARCH_HAS_DMA_GET_REQUIRED_MASK
> static u64 vmd_get_required_mask(struct device *dev)
> {
> return vmd_dma_ops(dev)->get_required_mask(to_vmd_dev(dev));
> }
> -#endif
>
> static void vmd_teardown_dma_ops(struct vmd_dev *vmd)
> {
> @@ -450,9 +448,7 @@ static void vmd_setup_dma_ops(struct vmd_dev *vmd)
> ASSIGN_VMD_DMA_OPS(source, dest, sync_sg_for_device);
> ASSIGN_VMD_DMA_OPS(source, dest, mapping_error);
> ASSIGN_VMD_DMA_OPS(source, dest, dma_supported);
> -#ifdef ARCH_HAS_DMA_GET_REQUIRED_MASK
> ASSIGN_VMD_DMA_OPS(source, dest, get_required_mask);
> -#endif
> add_dma_domain(domain);
> }
> #undef ASSIGN_VMD_DMA_OPS
> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
> index bd81e74cca7b..bddafc2513d8 100644
> --- a/include/linux/dma-mapping.h
> +++ b/include/linux/dma-mapping.h
> @@ -130,9 +130,7 @@ struct dma_map_ops {
> enum dma_data_direction direction);
> int (*mapping_error)(struct device *dev, dma_addr_t dma_addr);
> int (*dma_supported)(struct device *dev, u64 mask);
> -#ifdef ARCH_HAS_DMA_GET_REQUIRED_MASK
> u64 (*get_required_mask)(struct device *dev);
> -#endif
> };
>
> extern const struct dma_map_ops dma_direct_ops;
^ permalink raw reply
* Re: [PATCH 03/30] mm: remove CONFIG_HAVE_MEMBLOCK
From: Mike Rapoport @ 2018-09-27 4:50 UTC (permalink / raw)
To: Alexander Duyck
Cc: linux-mm, Andrew Morton, Catalin Marinas, chris, David Miller,
Geert Uytterhoeven, green.hu, Greg KH, gxt, Ingo Molnar, jejb,
jonas, Jonathan Corbet, lftan, msalter, Martin Schwidefsky,
mattst88, mpe, Michal Hocko, monstr, palmer, paul.burton, rkuo,
richard, dalias, Russell King - ARM Linux, fancer.lancer,
Thomas Gleixner, Tony Luck, vgupta, Yoshinori Sato, linux-alpha,
linux-arm-kernel, linux-c6x-dev, linux-hexagon, linux-ia64, LKML,
linux-m68k, linux-mips, linux-parisc,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT), linux-riscv,
linux-s390, linux-sh, linux-snps-arc, linux-um, nios2-dev,
openrisc, sparclinux, uclinux-h8-devel
In-Reply-To: <CAKgT0UcC-GTtyPK9ynvj6r3YFqy8kE40iMJxzPowbNoXGf9iWg@mail.gmail.com>
On Wed, Sep 26, 2018 at 05:34:32PM -0700, Alexander Duyck wrote:
> On Wed, Sep 26, 2018 at 11:32 AM Mike Rapoport <rppt@linux.vnet.ibm.com> wrote:
> >
> > On Wed, Sep 26, 2018 at 09:58:41AM -0700, Alexander Duyck wrote:
> > > On Fri, Sep 14, 2018 at 5:11 AM Mike Rapoport <rppt@linux.vnet.ibm.com> wrote:
> > > >
> > > > All architecures use memblock for early memory management. There is no need
> > > > for the CONFIG_HAVE_MEMBLOCK configuration option.
> > > >
> > > > Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com>
> > >
> > > <snip>
> > >
> > > > diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> > > > index 5169205..4ae91fc 100644
> > > > --- a/include/linux/memblock.h
> > > > +++ b/include/linux/memblock.h
> > > > @@ -2,7 +2,6 @@
> > > > #define _LINUX_MEMBLOCK_H
> > > > #ifdef __KERNEL__
> > > >
> > > > -#ifdef CONFIG_HAVE_MEMBLOCK
> > > > /*
> > > > * Logical memory blocks.
> > > > *
> > > > @@ -460,7 +459,6 @@ static inline phys_addr_t memblock_alloc(phys_addr_t size, phys_addr_t align)
> > > > {
> > > > return 0;
> > > > }
> > > > -#endif /* CONFIG_HAVE_MEMBLOCK */
> > > >
> > > > #endif /* __KERNEL__ */
> > >
> > > There was an #else above this section and I believe it and the code
> > > after it needs to be stripped as well.
> >
> > Right, I've already sent the fix [1] and it's in mmots.
> >
> > [1] https://lkml.org/lkml/2018/9/19/416
> >
>
> Are you sure? The patch you reference appears to be for
> drivers/of/fdt.c, and the bit I pointed out here is in
> include/linux/memblock.h.
Ah, sorry. You are right, will fix. Thanks for spotting it!
> - Alex
>
--
Sincerely yours,
Mike.
^ 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