* Re: [PATCH] powerpc/kup: Mark the kuap/keup function non __init
From: Christophe Leroy @ 2020-12-14 7:22 UTC (permalink / raw)
To: Aneesh Kumar K.V, linuxppc-dev, mpe
In-Reply-To: <20201214071306.346399-1-aneesh.kumar@linux.ibm.com>
Le 14/12/2020 à 08:13, Aneesh Kumar K.V a écrit :
> Kernel call these functions on cpu online and hence they should
> not be marked __init.
This is PPC64 only.
See commit
https://github.com/linuxppc/linux/commit/67d53f30e23ec66aa7bbdd1592d5e64d46876190#diff-9799ddc8e77e666295031a560afc2a754d2f5fa0ddfb96335495b26a07511ad4
Christophe
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> ---
> arch/powerpc/mm/book3s32/mmu.c | 4 ++--
> arch/powerpc/mm/book3s64/pkeys.c | 4 ++--
> arch/powerpc/mm/init-common.c | 2 +-
> arch/powerpc/mm/nohash/8xx.c | 4 ++--
> 4 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/arch/powerpc/mm/book3s32/mmu.c b/arch/powerpc/mm/book3s32/mmu.c
> index 23f60e97196e..8d9e90a99b51 100644
> --- a/arch/powerpc/mm/book3s32/mmu.c
> +++ b/arch/powerpc/mm/book3s32/mmu.c
> @@ -449,7 +449,7 @@ void __init print_system_hash_info(void)
> }
>
> #ifdef CONFIG_PPC_KUEP
> -void __init setup_kuep(bool disabled)
> +void setup_kuep(bool disabled)
> {
> pr_info("Activating Kernel Userspace Execution Prevention\n");
>
> @@ -459,7 +459,7 @@ void __init setup_kuep(bool disabled)
> #endif
>
> #ifdef CONFIG_PPC_KUAP
> -void __init setup_kuap(bool disabled)
> +void setup_kuap(bool disabled)
> {
> pr_info("Activating Kernel Userspace Access Protection\n");
>
> diff --git a/arch/powerpc/mm/book3s64/pkeys.c b/arch/powerpc/mm/book3s64/pkeys.c
> index 2b7ded396db4..f1c6f264ed91 100644
> --- a/arch/powerpc/mm/book3s64/pkeys.c
> +++ b/arch/powerpc/mm/book3s64/pkeys.c
> @@ -251,7 +251,7 @@ void __init pkey_early_init_devtree(void)
> }
>
> #ifdef CONFIG_PPC_KUEP
> -void __init setup_kuep(bool disabled)
> +void setup_kuep(bool disabled)
> {
> if (disabled)
> return;
> @@ -277,7 +277,7 @@ void __init setup_kuep(bool disabled)
> #endif
>
> #ifdef CONFIG_PPC_KUAP
> -void __init setup_kuap(bool disabled)
> +void setup_kuap(bool disabled)
> {
> if (disabled)
> return;
> diff --git a/arch/powerpc/mm/init-common.c b/arch/powerpc/mm/init-common.c
> index afdebb95bcae..c71af3978496 100644
> --- a/arch/powerpc/mm/init-common.c
> +++ b/arch/powerpc/mm/init-common.c
> @@ -47,7 +47,7 @@ static int __init parse_nosmap(char *p)
> }
> early_param("nosmap", parse_nosmap);
>
> -void __ref setup_kup(void)
> +void setup_kup(void)
> {
> setup_kuep(disable_kuep);
> setup_kuap(disable_kuap);
> diff --git a/arch/powerpc/mm/nohash/8xx.c b/arch/powerpc/mm/nohash/8xx.c
> index 231ca95f9ffb..9fba29b95b5a 100644
> --- a/arch/powerpc/mm/nohash/8xx.c
> +++ b/arch/powerpc/mm/nohash/8xx.c
> @@ -245,7 +245,7 @@ void set_context(unsigned long id, pgd_t *pgd)
> }
>
> #ifdef CONFIG_PPC_KUEP
> -void __init setup_kuep(bool disabled)
> +void setup_kuep(bool disabled)
> {
> if (disabled)
> return;
> @@ -257,7 +257,7 @@ void __init setup_kuep(bool disabled)
> #endif
>
> #ifdef CONFIG_PPC_KUAP
> -void __init setup_kuap(bool disabled)
> +void setup_kuap(bool disabled)
> {
> pr_info("Activating Kernel Userspace Access Protection\n");
>
>
^ permalink raw reply
* [PATCH v2] powerpc/book3s/kup: Mark the kuap/keup function non __init
From: Aneesh Kumar K.V @ 2020-12-14 8:01 UTC (permalink / raw)
To: linuxppc-dev, mpe; +Cc: Aneesh Kumar K.V
The kernel call these functions on cpu online and hence they should
not be marked __init.
Fixes: 3b47b7549ead ("powerpc/book3s64/kuap: Move KUAP related function outside radix")
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
arch/powerpc/mm/book3s64/pkeys.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/book3s64/pkeys.c b/arch/powerpc/mm/book3s64/pkeys.c
index 2b7ded396db4..f1c6f264ed91 100644
--- a/arch/powerpc/mm/book3s64/pkeys.c
+++ b/arch/powerpc/mm/book3s64/pkeys.c
@@ -251,7 +251,7 @@ void __init pkey_early_init_devtree(void)
}
#ifdef CONFIG_PPC_KUEP
-void __init setup_kuep(bool disabled)
+void setup_kuep(bool disabled)
{
if (disabled)
return;
@@ -277,7 +277,7 @@ void __init setup_kuep(bool disabled)
#endif
#ifdef CONFIG_PPC_KUAP
-void __init setup_kuap(bool disabled)
+void setup_kuap(bool disabled)
{
if (disabled)
return;
--
2.28.0
^ permalink raw reply related
* [PATCH kernel v3] powerpc/kuap: Restore AMR after replaying soft interrupts
From: Alexey Kardashevskiy @ 2020-12-14 8:39 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Alexey Kardashevskiy, Nicholas Piggin
Since de78a9c "powerpc: Add a framework for Kernel Userspace Access
Protection", user access helpers call user_{read|write}_access_{begin|end}
when user space access is allowed.
890274c "powerpc/64s: Implement KUAP for Radix MMU" made the mentioned
helpers program a AMR special register to allow such access for a short
period of time, most of the time AMR is expected to block user memory
access by the kernel.
Since the code accesses the user space memory, unsafe_get_user()
calls might_fault() which calls arch_local_irq_restore() if either
CONFIG_PROVE_LOCKING or CONFIG_DEBUG_ATOMIC_SLEEP is enabled.
arch_local_irq_restore() then attempts to replay pending soft interrupts
as KUAP regions have hardware interrupts enabled.
If a pending interrupt happens to do user access (performance interrupts
do that), it enables access for a short period of time so after returning
from the replay, the user access state remains blocked and if a user page
fault happens - "Bug: Read fault blocked by AMR!" appears and SIGSEGV is
sent.
This saves/restores AMR when replaying interrupts.
This adds a check if AMR was not blocked when before replaying interrupts.
Found by syzkaller. The call stack for the bug is:
copy_from_user_nofault+0xf8/0x250
perf_callchain_user_64+0x3d8/0x8d0
perf_callchain_user+0x38/0x50
get_perf_callchain+0x28c/0x300
perf_callchain+0xb0/0x130
perf_prepare_sample+0x364/0xbf0
perf_event_output_forward+0xe0/0x280
__perf_event_overflow+0xa4/0x240
perf_swevent_hrtimer+0x1d4/0x1f0
__hrtimer_run_queues+0x328/0x900
hrtimer_interrupt+0x128/0x350
timer_interrupt+0x180/0x600
replay_soft_interrupts+0x21c/0x4f0
arch_local_irq_restore+0x94/0x150
lock_is_held_type+0x140/0x200
___might_sleep+0x220/0x330
__might_fault+0x88/0x120
do_strncpy_from_user+0x108/0x2b0
strncpy_from_user+0x1d0/0x2a0
getname_flags+0x88/0x2c0
do_sys_openat2+0x2d4/0x5f0
do_sys_open+0xcc/0x140
system_call_exception+0x160/0x240
system_call_common+0xf0/0x27c
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
---
Changes:
v3:
* do not block/unblock if AMR was blocked
* reverted move of AMR_KUAP_***
* added kuap_check_amr
v2:
* fixed compile on hash
* moved get/set to arch_local_irq_restore
* block KUAP before replaying
---
This is an example:
------------[ cut here ]------------
Bug: Read fault blocked by AMR!
WARNING: CPU: 0 PID: 1603 at /home/aik/p/kernel/arch/powerpc/include/asm/book3s/64/kup-radix.h:145 __do_page_fau
Modules linked in:
CPU: 0 PID: 1603 Comm: amr Not tainted 5.10.0-rc6_v5.10-rc6_a+fstn1 #24
NIP: c00000000009ece8 LR: c00000000009ece4 CTR: 0000000000000000
REGS: c00000000dc63560 TRAP: 0700 Not tainted (5.10.0-rc6_v5.10-rc6_a+fstn1)
MSR: 8000000000021033 <SF,ME,IR,DR,RI,LE> CR: 28002888 XER: 20040000
CFAR: c0000000001fa928 IRQMASK: 1
GPR00: c00000000009ece4 c00000000dc637f0 c000000002397600 000000000000001f
GPR04: c0000000020eb318 0000000000000000 c00000000dc63494 0000000000000027
GPR08: c00000007fe4de68 c00000000dfe9180 0000000000000000 0000000000000001
GPR12: 0000000000002000 c0000000030a0000 0000000000000000 0000000000000000
GPR16: 0000000000000000 0000000000000000 0000000000000000 bfffffffffffffff
GPR20: 0000000000000000 c0000000134a4020 c0000000019c2218 0000000000000fe0
GPR24: 0000000000000000 0000000000000000 c00000000d106200 0000000040000000
GPR28: 0000000000000000 0000000000000300 c00000000dc63910 c000000001946730
NIP [c00000000009ece8] __do_page_fault+0xb38/0xde0
LR [c00000000009ece4] __do_page_fault+0xb34/0xde0
Call Trace:
[c00000000dc637f0] [c00000000009ece4] __do_page_fault+0xb34/0xde0 (unreliable)
[c00000000dc638a0] [c00000000000c968] handle_page_fault+0x10/0x2c
--- interrupt: 300 at strncpy_from_user+0x290/0x440
LR = strncpy_from_user+0x284/0x440
[c00000000dc63ba0] [c000000000c3dcb0] strncpy_from_user+0x2f0/0x440 (unreliable)
[c00000000dc63c30] [c00000000068b888] getname_flags+0x88/0x2c0
[c00000000dc63c90] [c000000000662a44] do_sys_openat2+0x2d4/0x5f0
[c00000000dc63d30] [c00000000066560c] do_sys_open+0xcc/0x140
[c00000000dc63dc0] [c000000000045e10] system_call_exception+0x160/0x240
[c00000000dc63e20] [c00000000000da60] system_call_common+0xf0/0x27c
Instruction dump:
409c0048 3fe2ff5b 3bfff128 fac10060 fae10068 482f7a85 60000000 3c62ff5b
7fe4fb78 3863f250 4815bbd9 60000000 <0fe00000> 3c62ff5b 3863f2b8 4815c8b5
irq event stamp: 254
hardirqs last enabled at (253): [<c000000000019550>] arch_local_irq_restore+0xa0/0x150
hardirqs last disabled at (254): [<c000000000008a10>] data_access_common_virt+0x1b0/0x1d0
softirqs last enabled at (0): [<c0000000001f6d5c>] copy_process+0x78c/0x2120
softirqs last disabled at (0): [<0000000000000000>] 0x0
---[ end trace ba98aec5151f3aeb ]---
---
arch/powerpc/kernel/irq.c | 27 ++++++++++++++++++++++++++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 7d0f7682d01d..92f28ad78d6d 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -311,6 +311,23 @@ void replay_soft_interrupts(void)
}
}
+#if defined(CONFIG_PPC_BOOK3S_64) && defined(CONFIG_PPC_KUAP)
+static inline void replay_soft_interrupts_irqrestore(void)
+{
+ unsigned long kuap_state = get_kuap();
+
+ if (kuap_state != AMR_KUAP_BLOCKED)
+ set_kuap(AMR_KUAP_BLOCKED);
+
+ replay_soft_interrupts();
+
+ if (kuap_state != AMR_KUAP_BLOCKED)
+ set_kuap(kuap_state);
+}
+#else
+#define replay_soft_interrupts_irqrestore() replay_soft_interrupts()
+#endif
+
notrace void arch_local_irq_restore(unsigned long mask)
{
unsigned char irq_happened;
@@ -320,6 +337,14 @@ notrace void arch_local_irq_restore(unsigned long mask)
if (mask)
return;
+ /*
+ * It fires if anything calls local_irq_enable or restore when
+ * KUAP is enabled, and the code handles that just fine by saving
+ * and re-locking AMR but we would like to remove those calls,
+ * hence the warning.
+ */
+ kuap_check_amr();
+
/*
* From this point onward, we can take interrupts, preempt,
* etc... unless we got hard-disabled. We check if an event
@@ -373,7 +398,7 @@ notrace void arch_local_irq_restore(unsigned long mask)
irq_soft_mask_set(IRQS_ALL_DISABLED);
trace_hardirqs_off();
- replay_soft_interrupts();
+ replay_soft_interrupts_irqrestore();
local_paca->irq_happened = 0;
trace_hardirqs_on();
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v1 1/2] KVM: PPC: Book3S HV: Add support for H_RPT_INVALIDATE (nested case only)
From: David Gibson @ 2020-12-14 6:05 UTC (permalink / raw)
To: Paul Mackerras
Cc: npiggin, Bharata B Rao, kvm-ppc, aneesh.kumar, linuxppc-dev
In-Reply-To: <20201211052744.GB69862@thinks.paulus.ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 4042 bytes --]
On Fri, Dec 11, 2020 at 04:27:44PM +1100, Paul Mackerras wrote:
> On Fri, Dec 11, 2020 at 12:16:39PM +1100, David Gibson wrote:
> > On Thu, Dec 10, 2020 at 09:54:18AM +0530, Bharata B Rao wrote:
> > > On Wed, Dec 09, 2020 at 03:15:42PM +1100, Paul Mackerras wrote:
> > > > On Mon, Oct 19, 2020 at 04:56:41PM +0530, Bharata B Rao wrote:
> > > > > Implements H_RPT_INVALIDATE hcall and supports only nested case
> > > > > currently.
> > > > >
> > > > > A KVM capability KVM_CAP_RPT_INVALIDATE is added to indicate the
> > > > > support for this hcall.
> > > >
> > > > I have a couple of questions about this patch:
> > > >
> > > > 1. Is this something that is useful today, or is it something that may
> > > > become useful in the future depending on future product plans? In
> > > > other words, what advantage is there to forcing L2 guests to use this
> > > > hcall instead of doing tlbie themselves?
> > >
> > > H_RPT_INVALIDATE will replace the use of the existing H_TLB_INVALIDATE
> > > for nested partition scoped invalidations. Implementations that want to
> > > off-load invalidations to the host (when GTSE=0) would have to bother
> > > about only one hcall (H_RPT_INVALIDATE)
> > >
> > > >
> > > > 2. Why does it need to be added to the default-enabled hcall list?
> > > >
> > > > There is a concern that if this is enabled by default we could get the
> > > > situation where a guest using it gets migrated to a host that doesn't
> > > > support it, which would be bad. That is the reason that all new
> > > > things like this are disabled by default and only enabled by userspace
> > > > (i.e. QEMU) in situations where we can enforce that it is available on
> > > > all hosts to which the VM might be migrated.
> > >
> > > As you suggested privately, I am thinking of falling back to
> > > H_TLB_INVALIDATE in case where this new hcall fails due to not being
> > > present. That should address the migration case that you mention
> > > above. With that and leaving the new hcall enabled by default
> > > is good okay?
> >
> > No. Assuming that guests will have some fallback is not how the qemu
> > migration compatibility model works. If we specify an old machine
> > type, we need to provide the same environment that the older host
> > would have.
>
> I misunderstood what this patchset is about when I first looked at
> it. H_RPT_INVALIDATE has two separate functions; one is to do
> process-scoped invalidations for a guest when LPCR[GTSE] = 0 (i.e.,
> when the guest is not permitted to do tlbie itself), and the other is
> to do partition-scoped invalidations that an L1 hypervisor needs to do
> on behalf of an L2 guest. The second function is a replacement and
> standardization of the existing H_TLB_INVALIDATE which was introduced
> with the nested virtualization code (using a hypercall number from the
> platform-specific range).
>
> This patchset only implements the second function, not the first. The
> first function remains unimplemented in KVM at present.
>
> Given that QEMU will need changes for a guest to be able to exploit
> H_RPT_INVALIDATE (at a minimum, adding a device tree property), it
> doesn't seem onerous for QEMU to have to enable the hcall with
> KVM_CAP_PPC_ENABLE_HCALL. I think that the control on whether the
> hcall is handled in KVM along with the control on nested hypervisor
> function provides adequate control for QEMU without needing a writable
> capability. The read-only capability to say whether the hcall exists
> does seem useful.
>
> Given all that, I'm veering towards taking Bharata's patchset pretty
> much as-is, minus the addition of H_RPT_INVALIDATE to the
> default-enabled set.
Yes, that's fine. I was only the suggestion that it be on the
default-enabled set I was objecting to.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v1 1/2] KVM: PPC: Book3S HV: Add support for H_RPT_INVALIDATE (nested case only)
From: David Gibson @ 2020-12-14 6:05 UTC (permalink / raw)
To: Bharata B Rao; +Cc: aneesh.kumar, npiggin, kvm-ppc, linuxppc-dev
In-Reply-To: <20201211103336.GB775394@in.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1457 bytes --]
On Fri, Dec 11, 2020 at 04:03:36PM +0530, Bharata B Rao wrote:
> On Mon, Oct 19, 2020 at 04:56:41PM +0530, Bharata B Rao wrote:
> > Implements H_RPT_INVALIDATE hcall and supports only nested case
> > currently.
> >
> > A KVM capability KVM_CAP_RPT_INVALIDATE is added to indicate the
> > support for this hcall.
>
> As Paul mentioned in the thread, this hcall does both process scoped
> invalidations and partition scoped invalidations for L2 guest.
> I am adding KVM_CAP_RPT_INVALIDATE capability with only partition
> scoped invalidations (nested case) implemented in the hcall as we
> don't see the need for KVM to implement process scoped invalidation
> function as KVM may never run with LPCR[GTSE]=0.
>
> I am wondering if enabling the capability with only partial
> implementation of the hcall is the correct thing to do. In future
> if we ever want process scoped invalidations support in this hcall,
> we may not be able to differentiate the availability of two functions
> cleanly from QEMU.
Yeah, it's not ideal.
> So does it make sense to implement the process scoped invalidation
> function also now itself even if it is not going to be used in
> KVM?
That might be a good idea, if it's not excessively difficult.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v12 00/31] Speculative page faults
From: Laurent Dufour @ 2020-12-14 9:36 UTC (permalink / raw)
To: Joel Fernandes, Chinwen Chang
Cc: jack, sergey.senozhatsky.work, peterz, Will Deacon, mhocko,
linux-mm, paulus, Punit Agrawal, hpa, Michel Lespinasse,
Alexei Starovoitov, Andrea Arcangeli, ak, Minchan Kim,
aneesh.kumar, x86, Matthew Wilcox, Daniel Jordan, Ingo Molnar,
zhong jiang, David Rientjes, paulmck, npiggin, sj38.park,
Jerome Glisse, dave, kemi.wang, kirill, Thomas Gleixner,
Haiyan Song, Ganesh Mahendran, Yang Shi, Mike Rapoport,
linuxppc-dev, linux-kernel, Sergey Senozhatsky, miles.chen,
vinayak menon, akpm, Tim Chen, haren
In-Reply-To: <X9bIDHZbe4MB+BAg@google.com>
Le 14/12/2020 à 03:03, Joel Fernandes a écrit :
> On Tue, Jul 07, 2020 at 01:31:37PM +0800, Chinwen Chang wrote:
> [..]
>>>> Hi Laurent,
>>>>
>>>> We merged SPF v11 and some patches from v12 into our platforms. After
>>>> several experiments, we observed SPF has obvious improvements on the
>>>> launch time of applications, especially for those high-TLP ones,
>>>>
>>>> # launch time of applications(s):
>>>>
>>>> package version w/ SPF w/o SPF improve(%)
>>>> ------------------------------------------------------------------
>>>> Baidu maps 10.13.3 0.887 0.98 9.49
>>>> Taobao 8.4.0.35 1.227 1.293 5.10
>>>> Meituan 9.12.401 1.107 1.543 28.26
>>>> WeChat 7.0.3 2.353 2.68 12.20
>>>> Honor of Kings 1.43.1.6 6.63 6.713 1.24
>>>
>>> That's great news, thanks for reporting this!
>>>
>>>>
>>>> By the way, we have verified our platforms with those patches and
>>>> achieved the goal of mass production.
>>>
>>> Another good news!
>>> For my information, what is your targeted hardware?
>>>
>>> Cheers,
>>> Laurent.
>>
>> Hi Laurent,
>>
>> Our targeted hardware belongs to ARM64 multi-core series.
>
> Hello!
>
> I was trying to develop an intuition about why does SPF give improvement for
> you on small CPU systems. This is just a high-level theory but:
>
> 1. Assume the improvement is because of elimination of "blocking" on
> mmap_sem.
> Could it be that the mmap_sem is acquired in write-mode unnecessarily in some
> places, thus causing blocking on mmap_sem in other paths? If so, is it
> feasible to convert such usages to acquiring them in read-mode?
That's correct, and the goal of this series is to try not holding the mmap_sem
in read mode during page fault processing.
Converting mmap_sem holder from write to read mode is not so easy and that work
as already been done in some places. If you think there are areas where this
could be done, you're welcome to send patches fixing that.
> 2. Assume the improvement is because of lesser read-side contention on
> mmap_sem.
> On small CPU systems, I would not expect reducing cache-line bouncing to give
> such a dramatic improvement in performance as you are seeing.
I don't think cache line bouncing reduction is the main sourcec of performance
improvement, I would rather think this is the lower part here.
I guess this is mainly because during loading time a lot of page fault is
occuring and thus SPF is reducing the contention on the mmap_sem.
> Thanks for any insight on this!
>
> - Joel
>
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/64s: Trim offlined CPUs from mm_cpumasks
From: Michael Ellerman @ 2020-12-14 10:43 UTC (permalink / raw)
To: Nicholas Piggin, Geert Uytterhoeven
Cc: Peter Zijlstra, Aneesh Kumar K.V, Linux Kernel Mailing List,
Anton Vorontsov, Thomas Gleixner, linuxppc-dev
In-Reply-To: <1607919238.kj439g85v5.astroid@bobo.none>
Nicholas Piggin <npiggin@gmail.com> writes:
> Excerpts from Geert Uytterhoeven's message of December 10, 2020 7:06 pm:
>> Hi Nicholas,
>>
>> On Fri, Nov 20, 2020 at 4:01 AM Nicholas Piggin <npiggin@gmail.com> wrote:
>>>
>>> When offlining a CPU, powerpc/64s does not flush TLBs, rather it just
>>> leaves the CPU set in mm_cpumasks, so it continues to receive TLBIEs
>>> to manage its TLBs.
>>>
>>> However the exit_flush_lazy_tlbs() function expects that after
>>> returning, all CPUs (except self) have flushed TLBs for that mm, in
>>> which case TLBIEL can be used for this flush. This breaks for offline
>>> CPUs because they don't get the IPI to flush their TLB. This can lead
>>> to stale translations.
>>>
>>> Fix this by clearing the CPU from mm_cpumasks, then flushing all TLBs
>>> before going offline.
>>>
>>> These offlined CPU bits stuck in the cpumask also prevents the cpumask
>>> from being trimmed back to local mode, which means continual broadcast
>>> IPIs or TLBIEs are needed for TLB flushing. This patch prevents that
>>> situation too.
>>>
>>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>>
>> Thanks for your patch!
>>
>>> --- a/arch/powerpc/platforms/powermac/smp.c
>>> +++ b/arch/powerpc/platforms/powermac/smp.c
>>> @@ -911,6 +911,8 @@ static int smp_core99_cpu_disable(void)
>>>
>>> mpic_cpu_set_priority(0xf);
>>>
>>> + cleanup_cpu_mmu_context();
>>> +
>>
>> I guess this change broke pmac32_defconfig+SMP in v5.10-rc7?
>>
>> arch/powerpc/platforms/powermac/smp.c: error: implicit
>> declaration of function 'cleanup_cpu_mmu_context'
>> [-Werror=implicit-function-declaration]: => 914:2
>>
>> http://kisskb.ellerman.id.au/kisskb/buildresult/14423174/
>
> Hey, yeah it does thanks for catching it. This patch fixes it for me
>
> ---
> From a9b5ec92ffac975e81c6d7db6ff2b1486b2723f7 Mon Sep 17 00:00:00 2001
> From: Nicholas Piggin <npiggin@gmail.com>
> Date: Mon, 14 Dec 2020 13:52:39 +1000
> Subject: [PATCH] powerpc/32s: Fix cleanup_cpu_mmu_context() compile bug
>
> 32s has no tlbiel_all() defined, so just disable the cleanup with a
> comment.
Or what about just:
diff --git a/arch/powerpc/include/asm/book3s/32/mmu-hash.h b/arch/powerpc/include/asm/book3s/32/mmu-hash.h
index 331187661236..685c589e723f 100644
--- a/arch/powerpc/include/asm/book3s/32/mmu-hash.h
+++ b/arch/powerpc/include/asm/book3s/32/mmu-hash.h
@@ -94,6 +94,7 @@ typedef struct {
} mm_context_t;
void update_bats(void);
+static inline void cleanup_cpu_mmu_context(void) { };
/* patch sites */
extern s32 patch__hash_page_A0, patch__hash_page_A1, patch__hash_page_A2;
cheers
^ permalink raw reply related
* Re: [RFC HACK PATCH] PCI: dwc: layerscape: Hack around enumeration problems with Honeycomb LX2K
From: Daniel Thompson @ 2020-12-14 10:43 UTC (permalink / raw)
To: Rob Herring
Cc: Roy Zang, Lorenzo Pieralisi, Linaro Patches, PCI, Jon Nettleton,
linux-kernel@vger.kernel.org, Minghuan Lian, linux-arm-kernel,
Bjorn Helgaas, linuxppc-dev, Mingkai Hu
In-Reply-To: <20201211170558.clfazgoetmery6u3@holly.lan>
On Fri, Dec 11, 2020 at 05:05:58PM +0000, Daniel Thompson wrote:
> On Fri, Dec 11, 2020 at 08:37:40AM -0600, Rob Herring wrote:
> > On Fri, Dec 11, 2020 at 6:15 AM Daniel Thompson
> > > BTW I noticed many other pcie-designware drivers take advantage
> > > of a function called dw_pcie_wait_for_link() in their init paths...
> > > but my naive attempts to add it to the layerscape driver results
> > > in non-booting systems so I haven't embarrassed myself by including
> > > that in the patch!
> >
> > You need to look at what's pending for v5.11, because I reworked this
> > to be more unified. The ordering of init is also possibly changed. The
> > sequence is now like this:
> >
> > dw_pcie_setup_rc(pp);
> > dw_pcie_msi_init(pp);
> >
> > if (!dw_pcie_link_up(pci) && pci->ops->start_link) {
> > ret = pci->ops->start_link(pci);
> > if (ret)
> > goto err_free_msi;
> > }
> >
> > /* Ignore errors, the link may come up later */
> > dw_pcie_wait_for_link(pci);
>
> Thanks. That looks likely to fix it since IIUC dw_pcie_wait_for_link()
> will end up waiting somewhat like the double check I added to
> ls_pcie_link_up().
>
> I'll take a look at let you know.
Yes. These changes have fixed the enumeration problems for me.
I tested pci/next and I cherry picked your patch series onto v5.10 and
both are working well.
Given this fixes a bug for me, do you think there is any scope for me
to whittle down your series into patches for the stable kernels or am
I likely to find too many extra bits being pulled in?
Daniel.
^ permalink raw reply
* Re: [PATCH v2] powerpc/book3s/kup: Mark the kuap/keup function non __init
From: Sachin Sant @ 2020-12-14 10:53 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev
In-Reply-To: <20201214080121.358567-1-aneesh.kumar@linux.ibm.com>
> On 14-Dec-2020, at 1:31 PM, Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> wrote:
>
> The kernel call these functions on cpu online and hence they should
> not be marked __init.
>
> Fixes: 3b47b7549ead ("powerpc/book3s64/kuap: Move KUAP related function outside radix")
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> —
This fixes the reported crash I ran into during a cpu online operation.
Reported-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
Tested-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
-Sachin
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/64s: Trim offlined CPUs from mm_cpumasks
From: Nicholas Piggin @ 2020-12-14 11:04 UTC (permalink / raw)
To: Geert Uytterhoeven, Michael Ellerman
Cc: Peter Zijlstra, Aneesh Kumar K.V, Linux Kernel Mailing List,
Anton Vorontsov, Thomas Gleixner, linuxppc-dev
In-Reply-To: <87h7oozn06.fsf@mpe.ellerman.id.au>
Excerpts from Michael Ellerman's message of December 14, 2020 8:43 pm:
> Nicholas Piggin <npiggin@gmail.com> writes:
>> Excerpts from Geert Uytterhoeven's message of December 10, 2020 7:06 pm:
>>> Hi Nicholas,
>>>
>>> On Fri, Nov 20, 2020 at 4:01 AM Nicholas Piggin <npiggin@gmail.com> wrote:
>>>>
>>>> When offlining a CPU, powerpc/64s does not flush TLBs, rather it just
>>>> leaves the CPU set in mm_cpumasks, so it continues to receive TLBIEs
>>>> to manage its TLBs.
>>>>
>>>> However the exit_flush_lazy_tlbs() function expects that after
>>>> returning, all CPUs (except self) have flushed TLBs for that mm, in
>>>> which case TLBIEL can be used for this flush. This breaks for offline
>>>> CPUs because they don't get the IPI to flush their TLB. This can lead
>>>> to stale translations.
>>>>
>>>> Fix this by clearing the CPU from mm_cpumasks, then flushing all TLBs
>>>> before going offline.
>>>>
>>>> These offlined CPU bits stuck in the cpumask also prevents the cpumask
>>>> from being trimmed back to local mode, which means continual broadcast
>>>> IPIs or TLBIEs are needed for TLB flushing. This patch prevents that
>>>> situation too.
>>>>
>>>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>>>
>>> Thanks for your patch!
>>>
>>>> --- a/arch/powerpc/platforms/powermac/smp.c
>>>> +++ b/arch/powerpc/platforms/powermac/smp.c
>>>> @@ -911,6 +911,8 @@ static int smp_core99_cpu_disable(void)
>>>>
>>>> mpic_cpu_set_priority(0xf);
>>>>
>>>> + cleanup_cpu_mmu_context();
>>>> +
>>>
>>> I guess this change broke pmac32_defconfig+SMP in v5.10-rc7?
>>>
>>> arch/powerpc/platforms/powermac/smp.c: error: implicit
>>> declaration of function 'cleanup_cpu_mmu_context'
>>> [-Werror=implicit-function-declaration]: => 914:2
>>>
>>> http://kisskb.ellerman.id.au/kisskb/buildresult/14423174/
>>
>> Hey, yeah it does thanks for catching it. This patch fixes it for me
>>
>> ---
>> From a9b5ec92ffac975e81c6d7db6ff2b1486b2723f7 Mon Sep 17 00:00:00 2001
>> From: Nicholas Piggin <npiggin@gmail.com>
>> Date: Mon, 14 Dec 2020 13:52:39 +1000
>> Subject: [PATCH] powerpc/32s: Fix cleanup_cpu_mmu_context() compile bug
>>
>> 32s has no tlbiel_all() defined, so just disable the cleanup with a
>> comment.
>
> Or what about just:
That works, I kind of wanted it in there explicit that we don't
clean up on 32s. I don't mind if you prefer this though.
Thanks,
Nick
>
> diff --git a/arch/powerpc/include/asm/book3s/32/mmu-hash.h b/arch/powerpc/include/asm/book3s/32/mmu-hash.h
> index 331187661236..685c589e723f 100644
> --- a/arch/powerpc/include/asm/book3s/32/mmu-hash.h
> +++ b/arch/powerpc/include/asm/book3s/32/mmu-hash.h
> @@ -94,6 +94,7 @@ typedef struct {
> } mm_context_t;
>
> void update_bats(void);
> +static inline void cleanup_cpu_mmu_context(void) { };
>
> /* patch sites */
> extern s32 patch__hash_page_A0, patch__hash_page_A1, patch__hash_page_A2;
>
>
> cheers
>
>
^ permalink raw reply
* [PATCH] powerpc: Inline setup_kup()
From: Michael Ellerman @ 2020-12-14 12:30 UTC (permalink / raw)
To: linuxppc-dev
setup_kup() is used by both 64-bit and 32-bit code. However on 64-bit
it must not be __init, because it's used for CPU hotplug, whereas on
32-bit it should be __init because it calls setup_kuap/kuep() which
are __init.
We worked around that problem in the past by marking it __ref, see
commit 67d53f30e23e ("powerpc/mm: fix section mismatch for
setup_kup()").
Marking it __ref basically just omits it from section mismatch
checking, which can lead to bugs, and in fact it did, see commit
44b4c4450f8d ("powerpc/64s: Mark the kuap/kuep functions non __init")
We can avoid all these problems by just making it static inline.
Because all it does is call other functions, making it inline actually
shrinks the 32-bit vmlinux by ~76 bytes.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/include/asm/kup.h | 8 ++++++--
arch/powerpc/mm/init-common.c | 6 ------
2 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/include/asm/kup.h b/arch/powerpc/include/asm/kup.h
index 5a9820c54da9..46b12c6dc728 100644
--- a/arch/powerpc/include/asm/kup.h
+++ b/arch/powerpc/include/asm/kup.h
@@ -49,8 +49,6 @@ extern bool disable_kuap;
#include <linux/pgtable.h>
-void setup_kup(void);
-
#ifdef CONFIG_PPC_KUEP
void setup_kuep(bool disabled);
#else
@@ -85,6 +83,12 @@ static inline void restore_user_access(unsigned long flags) { }
#endif /* CONFIG_PPC_BOOK3S_64 */
#endif /* CONFIG_PPC_KUAP */
+static inline void setup_kup(void)
+{
+ setup_kuep(disable_kuep);
+ setup_kuap(disable_kuap);
+}
+
static inline void allow_read_from_user(const void __user *from, unsigned long size)
{
allow_user_access(NULL, from, size, KUAP_READ);
diff --git a/arch/powerpc/mm/init-common.c b/arch/powerpc/mm/init-common.c
index afdebb95bcae..3a82f89827a5 100644
--- a/arch/powerpc/mm/init-common.c
+++ b/arch/powerpc/mm/init-common.c
@@ -47,12 +47,6 @@ static int __init parse_nosmap(char *p)
}
early_param("nosmap", parse_nosmap);
-void __ref setup_kup(void)
-{
- setup_kuep(disable_kuep);
- setup_kuap(disable_kuap);
-}
-
#define CTOR(shift) static void ctor_##shift(void *addr) \
{ \
memset(addr, 0, sizeof(void *) << (shift)); \
--
2.25.1
^ permalink raw reply related
* Re: [PATCH] powerpc: Inline setup_kup()
From: Christophe Leroy @ 2020-12-14 13:30 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev
In-Reply-To: <20201214123011.311024-1-mpe@ellerman.id.au>
Le 14/12/2020 à 13:30, Michael Ellerman a écrit :
> setup_kup() is used by both 64-bit and 32-bit code. However on 64-bit
> it must not be __init, because it's used for CPU hotplug, whereas on
> 32-bit it should be __init because it calls setup_kuap/kuep() which
> are __init.
>
> We worked around that problem in the past by marking it __ref, see
> commit 67d53f30e23e ("powerpc/mm: fix section mismatch for
> setup_kup()").
>
> Marking it __ref basically just omits it from section mismatch
> checking, which can lead to bugs, and in fact it did, see commit
> 44b4c4450f8d ("powerpc/64s: Mark the kuap/kuep functions non __init")
>
> We can avoid all these problems by just making it static inline.
> Because all it does is call other functions, making it inline actually
> shrinks the 32-bit vmlinux by ~76 bytes.
>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> ---
> arch/powerpc/include/asm/kup.h | 8 ++++++--
> arch/powerpc/mm/init-common.c | 6 ------
> 2 files changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/kup.h b/arch/powerpc/include/asm/kup.h
> index 5a9820c54da9..46b12c6dc728 100644
> --- a/arch/powerpc/include/asm/kup.h
> +++ b/arch/powerpc/include/asm/kup.h
> @@ -49,8 +49,6 @@ extern bool disable_kuap;
>
> #include <linux/pgtable.h>
>
> -void setup_kup(void);
> -
> #ifdef CONFIG_PPC_KUEP
> void setup_kuep(bool disabled);
> #else
> @@ -85,6 +83,12 @@ static inline void restore_user_access(unsigned long flags) { }
> #endif /* CONFIG_PPC_BOOK3S_64 */
> #endif /* CONFIG_PPC_KUAP */
>
> +static inline void setup_kup(void)
Should it be __always_inline ?
Christophe
> +{
> + setup_kuep(disable_kuep);
> + setup_kuap(disable_kuap);
> +}
> +
> static inline void allow_read_from_user(const void __user *from, unsigned long size)
> {
> allow_user_access(NULL, from, size, KUAP_READ);
> diff --git a/arch/powerpc/mm/init-common.c b/arch/powerpc/mm/init-common.c
> index afdebb95bcae..3a82f89827a5 100644
> --- a/arch/powerpc/mm/init-common.c
> +++ b/arch/powerpc/mm/init-common.c
> @@ -47,12 +47,6 @@ static int __init parse_nosmap(char *p)
> }
> early_param("nosmap", parse_nosmap);
>
> -void __ref setup_kup(void)
> -{
> - setup_kuep(disable_kuep);
> - setup_kuap(disable_kuap);
> -}
> -
> #define CTOR(shift) static void ctor_##shift(void *addr) \
> { \
> memset(addr, 0, sizeof(void *) << (shift)); \
>
^ permalink raw reply
* [PATCH -next] tty/hvc/hvsi_lib: convert comma to semicolon
From: Zheng Yongjun @ 2020-12-14 13:38 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel; +Cc: Zheng Yongjun
Replace a comma between expression statements by a semicolon.
Signed-off-by: Zheng Yongjun <zhengyongjun3@huawei.com>
---
drivers/tty/hvc/hvsi_lib.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/hvc/hvsi_lib.c b/drivers/tty/hvc/hvsi_lib.c
index 09289c8154ae..8c4ad495f819 100644
--- a/drivers/tty/hvc/hvsi_lib.c
+++ b/drivers/tty/hvc/hvsi_lib.c
@@ -301,7 +301,7 @@ int hvsilib_write_mctrl(struct hvsi_priv *pv, int dtr)
pr_devel("HVSI@%x: %s DTR...\n", pv->termno,
dtr ? "Setting" : "Clearing");
- ctrl.hdr.type = VS_CONTROL_PACKET_HEADER,
+ ctrl.hdr.type = VS_CONTROL_PACKET_HEADER;
ctrl.hdr.len = sizeof(struct hvsi_control);
ctrl.verb = cpu_to_be16(VSV_SET_MODEM_CTL);
ctrl.mask = cpu_to_be32(HVSI_TSDTR);
--
2.22.0
^ permalink raw reply related
* Re: [RFC HACK PATCH] PCI: dwc: layerscape: Hack around enumeration problems with Honeycomb LX2K
From: Rob Herring @ 2020-12-14 14:57 UTC (permalink / raw)
To: Daniel Thompson
Cc: Roy Zang, Lorenzo Pieralisi, Linaro Patches, PCI, Jon Nettleton,
linux-kernel@vger.kernel.org, Minghuan Lian, linux-arm-kernel,
Bjorn Helgaas, linuxppc-dev, Mingkai Hu
In-Reply-To: <20201214104337.wbvq2gvj3wi6bvzc@holly.lan>
On Mon, Dec 14, 2020 at 4:43 AM Daniel Thompson
<daniel.thompson@linaro.org> wrote:
>
> On Fri, Dec 11, 2020 at 05:05:58PM +0000, Daniel Thompson wrote:
> > On Fri, Dec 11, 2020 at 08:37:40AM -0600, Rob Herring wrote:
> > > On Fri, Dec 11, 2020 at 6:15 AM Daniel Thompson
> > > > BTW I noticed many other pcie-designware drivers take advantage
> > > > of a function called dw_pcie_wait_for_link() in their init paths...
> > > > but my naive attempts to add it to the layerscape driver results
> > > > in non-booting systems so I haven't embarrassed myself by including
> > > > that in the patch!
> > >
> > > You need to look at what's pending for v5.11, because I reworked this
> > > to be more unified. The ordering of init is also possibly changed. The
> > > sequence is now like this:
> > >
> > > dw_pcie_setup_rc(pp);
> > > dw_pcie_msi_init(pp);
> > >
> > > if (!dw_pcie_link_up(pci) && pci->ops->start_link) {
> > > ret = pci->ops->start_link(pci);
> > > if (ret)
> > > goto err_free_msi;
> > > }
> > >
> > > /* Ignore errors, the link may come up later */
> > > dw_pcie_wait_for_link(pci);
> >
> > Thanks. That looks likely to fix it since IIUC dw_pcie_wait_for_link()
> > will end up waiting somewhat like the double check I added to
> > ls_pcie_link_up().
> >
> > I'll take a look at let you know.
>
> Yes. These changes have fixed the enumeration problems for me.
>
> I tested pci/next and I cherry picked your patch series onto v5.10 and
> both are working well.
>
> Given this fixes a bug for me, do you think there is any scope for me
> to whittle down your series into patches for the stable kernels or am
> I likely to find too many extra bits being pulled in?
I think I'd just go the adding a delay route. It's a fairly big series
and depends on my other clean-up done in 5.10. And there's at least
some possibility it regresses some platform given the limited testing
linux-next gets.
Rob
^ permalink raw reply
* Re: [PATCH v12 00/31] Speculative page faults
From: Joel Fernandes @ 2020-12-14 18:10 UTC (permalink / raw)
To: Laurent Dufour
Cc: jack, sergey.senozhatsky.work, peterz, Will Deacon, mhocko,
linux-mm, paulus, Punit Agrawal, hpa, Michel Lespinasse,
Alexei Starovoitov, Andrea Arcangeli, ak, Minchan Kim,
aneesh.kumar, x86, Matthew Wilcox, Daniel Jordan, Ingo Molnar,
zhong jiang, Chinwen Chang, David Rientjes, paulmck, npiggin,
sj38.park, Jerome Glisse, dave, kemi.wang, kirill,
Thomas Gleixner, Haiyan Song, Ganesh Mahendran, Yang Shi,
Mike Rapoport, linuxppc-dev, linux-kernel, Sergey Senozhatsky,
miles.chen, vinayak menon, akpm, Tim Chen, haren
In-Reply-To: <b256e5ed-0d4c-4baf-16a6-f32f122e344f@linux.ibm.com>
On Mon, Dec 14, 2020 at 10:36:29AM +0100, Laurent Dufour wrote:
> Le 14/12/2020 à 03:03, Joel Fernandes a écrit :
> > On Tue, Jul 07, 2020 at 01:31:37PM +0800, Chinwen Chang wrote:
> > [..]
> > > > > Hi Laurent,
> > > > >
> > > > > We merged SPF v11 and some patches from v12 into our platforms. After
> > > > > several experiments, we observed SPF has obvious improvements on the
> > > > > launch time of applications, especially for those high-TLP ones,
> > > > >
> > > > > # launch time of applications(s):
> > > > >
> > > > > package version w/ SPF w/o SPF improve(%)
> > > > > ------------------------------------------------------------------
> > > > > Baidu maps 10.13.3 0.887 0.98 9.49
> > > > > Taobao 8.4.0.35 1.227 1.293 5.10
> > > > > Meituan 9.12.401 1.107 1.543 28.26
> > > > > WeChat 7.0.3 2.353 2.68 12.20
> > > > > Honor of Kings 1.43.1.6 6.63 6.713 1.24
> > > >
> > > > That's great news, thanks for reporting this!
> > > >
> > > > >
> > > > > By the way, we have verified our platforms with those patches and
> > > > > achieved the goal of mass production.
> > > >
> > > > Another good news!
> > > > For my information, what is your targeted hardware?
> > > >
> > > > Cheers,
> > > > Laurent.
> > >
> > > Hi Laurent,
> > >
> > > Our targeted hardware belongs to ARM64 multi-core series.
> >
> > Hello!
> >
> > I was trying to develop an intuition about why does SPF give improvement for
> > you on small CPU systems. This is just a high-level theory but:
> >
> > 1. Assume the improvement is because of elimination of "blocking" on
> > mmap_sem.
> > Could it be that the mmap_sem is acquired in write-mode unnecessarily in some
> > places, thus causing blocking on mmap_sem in other paths? If so, is it
> > feasible to convert such usages to acquiring them in read-mode?
>
> That's correct, and the goal of this series is to try not holding the
> mmap_sem in read mode during page fault processing.
>
> Converting mmap_sem holder from write to read mode is not so easy and that
> work as already been done in some places. If you think there are areas where
> this could be done, you're welcome to send patches fixing that.
>
> > 2. Assume the improvement is because of lesser read-side contention on
> > mmap_sem.
> > On small CPU systems, I would not expect reducing cache-line bouncing to give
> > such a dramatic improvement in performance as you are seeing.
>
> I don't think cache line bouncing reduction is the main sourcec of
> performance improvement, I would rather think this is the lower part here.
> I guess this is mainly because during loading time a lot of page fault is
> occuring and thus SPF is reducing the contention on the mmap_sem.
Thanks for the reply. I think I also wrongly assumed that acquiring mmap
rwsem in write mode in a syscall makes SPF moot. Peter explained to me on IRC
that tere's still perf improvement in write mode if an unrelated VMA is
modified while another VMA is faulting. CMIIW - not an mm expert by any
stretch.
Thanks!
- Joel
^ permalink raw reply
* Re: [PATCH 2/3] kbuild: LD_VERSION redenomination
From: Will Deacon @ 2020-12-14 23:05 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Thomas Bogendoerfer, linux-kbuild, Dominique Martinet,
linux-kernel, Jiaxun Yang, linux-mips, Paul Mackerras,
Catalin Marinas, Huacai Chen, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20201212165431.150750-2-masahiroy@kernel.org>
On Sun, Dec 13, 2020 at 01:54:30AM +0900, Masahiro Yamada wrote:
> Commit ccbef1674a15 ("Kbuild, lto: add ld-version and ld-ifversion
> macros") introduced scripts/ld-version.sh for GCC LTO.
>
> At that time, this script handled 5 version fields because GCC LTO
> needed the downstream binutils. (https://lkml.org/lkml/2014/4/8/272)
>
> The code snippet from the submitted patch was as follows:
>
> # We need HJ Lu's Linux binutils because mainline binutils does not
> # support mixing assembler and LTO code in the same ld -r object.
> # XXX check if the gcc plugin ld is the expected one too
> # XXX some Fedora binutils should also support it. How to check for that?
> ifeq ($(call ld-ifversion,-ge,22710001,y),y)
> ...
>
> However, GCC LTO was not merged into the mainline after all.
> (https://lkml.org/lkml/2014/4/8/272)
>
> So, the 4th and 5th fields were never used, and finally removed by
> commit 0d61ed17dd30 ("ld-version: Drop the 4th and 5th version
> components").
>
> Since then, the last 4-digits returned by this script is always zeros.
>
> Remove the meaningless last 4-digits. This makes the version format
> consistent with GCC_VERSION, CLANG_VERSION, LLD_VERSION.
>
> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
> ---
>
> arch/arm64/Kconfig | 2 +-
> arch/mips/loongson64/Platform | 2 +-
> arch/mips/vdso/Kconfig | 2 +-
> arch/powerpc/Makefile | 2 +-
> arch/powerpc/lib/Makefile | 2 +-
> scripts/ld-version.sh | 2 +-
> 6 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index a6b5b7ef40ae..69d56b21a6ec 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -1499,7 +1499,7 @@ config ARM64_PTR_AUTH
> depends on (CC_HAS_SIGN_RETURN_ADDRESS || CC_HAS_BRANCH_PROT_PAC_RET) && AS_HAS_PAC
> # Modern compilers insert a .note.gnu.property section note for PAC
> # which is only understood by binutils starting with version 2.33.1.
> - depends on LD_IS_LLD || LD_VERSION >= 233010000 || (CC_IS_GCC && GCC_VERSION < 90100)
> + depends on LD_IS_LLD || LD_VERSION >= 23301 || (CC_IS_GCC && GCC_VERSION < 90100)
> depends on !CC_IS_CLANG || AS_HAS_CFI_NEGATE_RA_STATE
> depends on (!FUNCTION_GRAPH_TRACER || DYNAMIC_FTRACE_WITH_REGS)
> help
Acked-by: Will Deacon <will@kernel.org>
Will
^ permalink raw reply
* [PATCH] selftests/powerpc: Add test to check if TM is disabled when it must be
From: Gustavo Romero @ 2020-12-15 0:49 UTC (permalink / raw)
To: linuxppc-dev; +Cc: mikey, gustavo.romero
Add a TM test to check that when TM is not advertised by the OS (is disabled) a
transaction can not really be started and generates a SIGILL, which is the right
behavior in that case.
Signed-off-by: Gustavo Romero <gromero@linux.ibm.com>
---
tools/testing/selftests/powerpc/tm/.gitignore | 1 +
tools/testing/selftests/powerpc/tm/Makefile | 2 +-
tools/testing/selftests/powerpc/tm/tm-no-tm.c | 48 +++++++++++++++++++++++++++
3 files changed, 50 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/powerpc/tm/tm-no-tm.c
diff --git a/tools/testing/selftests/powerpc/tm/.gitignore b/tools/testing/selftests/powerpc/tm/.gitignore
index d8900a0..1d23309 100644
--- a/tools/testing/selftests/powerpc/tm/.gitignore
+++ b/tools/testing/selftests/powerpc/tm/.gitignore
@@ -20,3 +20,4 @@ tm-unavailable
tm-trap
tm-sigreturn
tm-poison
+tm-no-tm
diff --git a/tools/testing/selftests/powerpc/tm/Makefile b/tools/testing/selftests/powerpc/tm/Makefile
index 5881e97..756a03f 100644
--- a/tools/testing/selftests/powerpc/tm/Makefile
+++ b/tools/testing/selftests/powerpc/tm/Makefile
@@ -5,7 +5,7 @@ SIGNAL_CONTEXT_CHK_TESTS := tm-signal-context-chk-gpr tm-signal-context-chk-fpu
TEST_GEN_PROGS := tm-resched-dscr tm-syscall tm-signal-msr-resv tm-signal-stack \
tm-vmxcopy tm-fork tm-tar tm-tmspr tm-vmx-unavail tm-unavailable tm-trap \
$(SIGNAL_CONTEXT_CHK_TESTS) tm-sigreturn tm-signal-sigreturn-nt \
- tm-signal-context-force-tm tm-poison tm-signal-pagefault
+ tm-signal-context-force-tm tm-poison tm-signal-pagefault tm-no-tm
TEST_FILES := settings
diff --git a/tools/testing/selftests/powerpc/tm/tm-no-tm.c b/tools/testing/selftests/powerpc/tm/tm-no-tm.c
new file mode 100644
index 0000000..3b83e20
--- /dev/null
+++ b/tools/testing/selftests/powerpc/tm/tm-no-tm.c
@@ -0,0 +1,48 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright 2020, Gustavo Romero, IBM Corp.
+ *
+ * This test checks if when TM is not supported by the OS indeed it's not
+ * possible to start a TM transaction. Moreover, when trying to start a new
+ * transaction the user gets an illegal instruction, which is the correct
+ * behavior in that case, instead of any other signal, like SIGSEGV etc.
+ *
+ * Since firmware can change the TM instruction behavior in many ways, it's good
+ * to have a test to check if TM is properly disabled when the OS advertises
+ * that TM is not available in userspace.
+ *
+ */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <signal.h>
+
+#include "utils.h"
+#include "tm.h"
+
+void illegal_signal_handler(int signo_notused, siginfo_t *si_notused, void *uc_notused)
+{
+ exit(EXIT_SUCCESS);
+}
+
+int tm_no_tm_test(void)
+{
+ struct sigaction illegal_sa;
+
+ SKIP_IF(have_htm());
+
+ illegal_sa.sa_flags = SA_SIGINFO;
+ illegal_sa.sa_sigaction = illegal_signal_handler;
+
+ sigaction(SIGILL, &illegal_sa, NULL);
+
+ /* It must cause a SIGILL since TM is not supported by the OS */
+ asm("tbegin.;");
+
+ return EXIT_FAILURE;
+}
+
+int main(int argc, char **argv)
+{
+ return test_harness(tm_no_tm_test, "tm_no_tm_test");
+}
--
2.7.4
^ permalink raw reply related
* [powerpc:next-test] BUILD SUCCESS bd9161ccbf25eef78b073c239621dfd298222a64
From: kernel test robot @ 2020-12-15 0:57 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
branch HEAD: bd9161ccbf25eef78b073c239621dfd298222a64 powerpc: Inline setup_kup()
elapsed time: 721m
configs tested: 183
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
m68k m5307c3_defconfig
ia64 tiger_defconfig
arm u300_defconfig
powerpc ppc44x_defconfig
xtensa allyesconfig
arm pxa255-idp_defconfig
mips maltaup_xpa_defconfig
mips rb532_defconfig
arm badge4_defconfig
h8300 h8s-sim_defconfig
arm axm55xx_defconfig
arm moxart_defconfig
powerpc pasemi_defconfig
powerpc adder875_defconfig
arc axs101_defconfig
sh se7206_defconfig
arm zx_defconfig
powerpc arches_defconfig
arc alldefconfig
arm eseries_pxa_defconfig
sparc allyesconfig
m68k amiga_defconfig
arm dove_defconfig
xtensa xip_kc705_defconfig
mips xway_defconfig
sh rts7751r2dplus_defconfig
powerpc ppa8548_defconfig
powerpc akebono_defconfig
arc defconfig
mips db1xxx_defconfig
mips vocore2_defconfig
powerpc maple_defconfig
h8300 edosk2674_defconfig
sh sdk7780_defconfig
m68k sun3_defconfig
mips cavium_octeon_defconfig
m68k m5407c3_defconfig
sh se7712_defconfig
xtensa audio_kc705_defconfig
mips rbtx49xx_defconfig
arm h5000_defconfig
i386 alldefconfig
arm cns3420vb_defconfig
arc hsdk_defconfig
m68k sun3x_defconfig
powerpc acadia_defconfig
arm pxa168_defconfig
sh rsk7269_defconfig
powerpc currituck_defconfig
powerpc mpc83xx_defconfig
mips ip32_defconfig
mips gpr_defconfig
powerpc tqm8540_defconfig
arm aspeed_g4_defconfig
arm shmobile_defconfig
mips ar7_defconfig
powerpc mpc8560_ads_defconfig
powerpc g5_defconfig
powerpc stx_gp3_defconfig
powerpc xes_mpc85xx_defconfig
mips rm200_defconfig
powerpc tqm8548_defconfig
arm lpd270_defconfig
mips sb1250_swarm_defconfig
powerpc ps3_defconfig
powerpc obs600_defconfig
sh ecovec24-romimage_defconfig
sh sh7770_generic_defconfig
powerpc kmeter1_defconfig
mips nlm_xlp_defconfig
mips loongson1b_defconfig
sh sh03_defconfig
x86_64 alldefconfig
xtensa virt_defconfig
nds32 allnoconfig
sh edosk7760_defconfig
mips capcella_defconfig
sh lboxre2_defconfig
sh sdk7786_defconfig
sh titan_defconfig
powerpc gamecube_defconfig
c6x evmc6472_defconfig
sh se7722_defconfig
arm spear6xx_defconfig
mips nlm_xlr_defconfig
mips lemote2f_defconfig
arc nsimosci_defconfig
arm at91_dt_defconfig
arm sama5_defconfig
arm mvebu_v5_defconfig
i386 defconfig
mips mpc30x_defconfig
sh ap325rxa_defconfig
sh microdev_defconfig
powerpc64 alldefconfig
mips decstation_r4k_defconfig
arm cm_x300_defconfig
m68k q40_defconfig
arm lart_defconfig
arm prima2_defconfig
h8300 alldefconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
c6x allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
h8300 allyesconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc defconfig
i386 tinyconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a001-20201214
i386 randconfig-a004-20201214
i386 randconfig-a003-20201214
i386 randconfig-a002-20201214
i386 randconfig-a006-20201214
i386 randconfig-a005-20201214
i386 randconfig-a001-20201213
i386 randconfig-a004-20201213
i386 randconfig-a003-20201213
i386 randconfig-a002-20201213
i386 randconfig-a005-20201213
i386 randconfig-a006-20201213
x86_64 randconfig-a016-20201214
x86_64 randconfig-a012-20201214
x86_64 randconfig-a013-20201214
x86_64 randconfig-a015-20201214
x86_64 randconfig-a014-20201214
x86_64 randconfig-a011-20201214
i386 randconfig-a014-20201214
i386 randconfig-a013-20201214
i386 randconfig-a012-20201214
i386 randconfig-a011-20201214
i386 randconfig-a015-20201214
i386 randconfig-a016-20201214
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
clang tested configs:
x86_64 randconfig-a003-20201214
x86_64 randconfig-a006-20201214
x86_64 randconfig-a002-20201214
x86_64 randconfig-a005-20201214
x86_64 randconfig-a004-20201214
x86_64 randconfig-a001-20201214
x86_64 randconfig-a016-20201213
x86_64 randconfig-a012-20201213
x86_64 randconfig-a013-20201213
x86_64 randconfig-a015-20201213
x86_64 randconfig-a014-20201213
x86_64 randconfig-a011-20201213
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:merge] BUILD SUCCESS 3a6a31edf52760dbc480853232f7bae9867f8e72
From: kernel test robot @ 2020-12-15 0:57 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge
branch HEAD: 3a6a31edf52760dbc480853232f7bae9867f8e72 Automatic merge of 'next' into merge (2020-12-14 23:35)
elapsed time: 723m
configs tested: 163
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
m68k m5307c3_defconfig
ia64 tiger_defconfig
arm u300_defconfig
powerpc ppc44x_defconfig
xtensa allyesconfig
arm pxa255-idp_defconfig
mips maltaup_xpa_defconfig
mips rb532_defconfig
arm badge4_defconfig
h8300 h8s-sim_defconfig
arm axm55xx_defconfig
arm moxart_defconfig
powerpc pasemi_defconfig
powerpc adder875_defconfig
arm eseries_pxa_defconfig
sparc allyesconfig
m68k amiga_defconfig
arm dove_defconfig
powerpc akebono_defconfig
arc defconfig
mips db1xxx_defconfig
mips vocore2_defconfig
sh rts7751r2d1_defconfig
arm hackkit_defconfig
mips bigsur_defconfig
m68k m5275evb_defconfig
i386 defconfig
powerpc maple_defconfig
h8300 edosk2674_defconfig
sh sdk7780_defconfig
m68k sun3_defconfig
mips cavium_octeon_defconfig
m68k m5407c3_defconfig
sh se7712_defconfig
xtensa audio_kc705_defconfig
mips rbtx49xx_defconfig
arm h5000_defconfig
i386 alldefconfig
arm cns3420vb_defconfig
arc hsdk_defconfig
m68k sun3x_defconfig
powerpc acadia_defconfig
arm pxa168_defconfig
arm lart_defconfig
arm milbeaut_m10v_defconfig
sparc sparc32_defconfig
mips ip22_defconfig
xtensa nommu_kc705_defconfig
arm aspeed_g4_defconfig
arm shmobile_defconfig
mips ar7_defconfig
powerpc mpc8560_ads_defconfig
powerpc g5_defconfig
powerpc stx_gp3_defconfig
powerpc xes_mpc85xx_defconfig
mips rm200_defconfig
powerpc tqm8548_defconfig
arm lpd270_defconfig
mips sb1250_swarm_defconfig
powerpc ps3_defconfig
powerpc obs600_defconfig
sh ecovec24-romimage_defconfig
sh sh7770_generic_defconfig
powerpc kmeter1_defconfig
mips nlm_xlp_defconfig
sh ap325rxa_defconfig
powerpc tqm5200_defconfig
csky alldefconfig
mips pistachio_defconfig
xtensa virt_defconfig
nds32 allnoconfig
sh edosk7760_defconfig
mips capcella_defconfig
sh lboxre2_defconfig
sh microdev_defconfig
powerpc64 alldefconfig
mips decstation_r4k_defconfig
arm cm_x300_defconfig
m68k q40_defconfig
arm prima2_defconfig
h8300 alldefconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
c6x allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
h8300 allyesconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc defconfig
i386 tinyconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a001-20201214
i386 randconfig-a004-20201214
i386 randconfig-a003-20201214
i386 randconfig-a002-20201214
i386 randconfig-a006-20201214
i386 randconfig-a005-20201214
i386 randconfig-a001-20201213
i386 randconfig-a004-20201213
i386 randconfig-a003-20201213
i386 randconfig-a002-20201213
i386 randconfig-a005-20201213
i386 randconfig-a006-20201213
x86_64 randconfig-a016-20201214
x86_64 randconfig-a012-20201214
x86_64 randconfig-a013-20201214
x86_64 randconfig-a015-20201214
x86_64 randconfig-a014-20201214
x86_64 randconfig-a011-20201214
i386 randconfig-a014-20201214
i386 randconfig-a013-20201214
i386 randconfig-a012-20201214
i386 randconfig-a011-20201214
i386 randconfig-a015-20201214
i386 randconfig-a016-20201214
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
clang tested configs:
x86_64 randconfig-a003-20201214
x86_64 randconfig-a006-20201214
x86_64 randconfig-a002-20201214
x86_64 randconfig-a005-20201214
x86_64 randconfig-a004-20201214
x86_64 randconfig-a001-20201214
x86_64 randconfig-a016-20201213
x86_64 randconfig-a012-20201213
x86_64 randconfig-a013-20201213
x86_64 randconfig-a015-20201213
x86_64 randconfig-a014-20201213
x86_64 randconfig-a011-20201213
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:next] BUILD SUCCESS 44b4c4450f8d31296ba633d74be753a85fd627bd
From: kernel test robot @ 2020-12-15 0:57 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
branch HEAD: 44b4c4450f8d31296ba633d74be753a85fd627bd powerpc/64s: Mark the kuap/kuep functions non __init
elapsed time: 722m
configs tested: 193
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
m68k m5307c3_defconfig
ia64 tiger_defconfig
arm u300_defconfig
powerpc ppc44x_defconfig
xtensa allyesconfig
arm pxa255-idp_defconfig
mips maltaup_xpa_defconfig
mips rb532_defconfig
arm badge4_defconfig
h8300 h8s-sim_defconfig
arm axm55xx_defconfig
arm moxart_defconfig
powerpc pasemi_defconfig
powerpc adder875_defconfig
arc axs101_defconfig
sh se7206_defconfig
arm zx_defconfig
powerpc arches_defconfig
arc alldefconfig
powerpc kmeter1_defconfig
arm eseries_pxa_defconfig
sparc allyesconfig
m68k amiga_defconfig
arm dove_defconfig
xtensa xip_kc705_defconfig
mips xway_defconfig
sh rts7751r2dplus_defconfig
powerpc ppa8548_defconfig
powerpc akebono_defconfig
arc defconfig
mips db1xxx_defconfig
mips vocore2_defconfig
powerpc maple_defconfig
h8300 edosk2674_defconfig
sh sdk7780_defconfig
m68k sun3_defconfig
mips cavium_octeon_defconfig
m68k m5407c3_defconfig
sh se7712_defconfig
xtensa audio_kc705_defconfig
mips rbtx49xx_defconfig
arm h5000_defconfig
i386 alldefconfig
arm cns3420vb_defconfig
arc hsdk_defconfig
m68k sun3x_defconfig
powerpc acadia_defconfig
arm pxa168_defconfig
sh rsk7269_defconfig
powerpc currituck_defconfig
powerpc mpc83xx_defconfig
mips ip32_defconfig
mips gpr_defconfig
powerpc tqm8540_defconfig
arm bcm2835_defconfig
powerpc socrates_defconfig
mips loongson1b_defconfig
powerpc fsp2_defconfig
mips qi_lb60_defconfig
arm multi_v7_defconfig
arm aspeed_g4_defconfig
arm shmobile_defconfig
mips ar7_defconfig
powerpc mpc8560_ads_defconfig
powerpc g5_defconfig
powerpc stx_gp3_defconfig
powerpc xes_mpc85xx_defconfig
mips rm200_defconfig
powerpc tqm8548_defconfig
arm lpd270_defconfig
mips sb1250_swarm_defconfig
powerpc pq2fads_defconfig
m68k m5475evb_defconfig
parisc alldefconfig
arm orion5x_defconfig
powerpc ps3_defconfig
powerpc obs600_defconfig
sh ecovec24-romimage_defconfig
sh sh7770_generic_defconfig
mips nlm_xlp_defconfig
sh sh03_defconfig
x86_64 alldefconfig
mips bmips_stb_defconfig
mips loongson1c_defconfig
powerpc pmac32_defconfig
xtensa virt_defconfig
nds32 allnoconfig
sh edosk7760_defconfig
mips capcella_defconfig
sh lboxre2_defconfig
sh sdk7786_defconfig
sh titan_defconfig
powerpc gamecube_defconfig
c6x evmc6472_defconfig
sh se7722_defconfig
arm spear6xx_defconfig
mips nlm_xlr_defconfig
mips lemote2f_defconfig
arc nsimosci_defconfig
sh rsk7264_defconfig
arm sunxi_defconfig
sh ap325rxa_defconfig
sh microdev_defconfig
powerpc64 alldefconfig
mips decstation_r4k_defconfig
arm cm_x300_defconfig
m68k q40_defconfig
arm lart_defconfig
arm prima2_defconfig
h8300 alldefconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
c6x allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
h8300 allyesconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc defconfig
i386 tinyconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a001-20201214
i386 randconfig-a004-20201214
i386 randconfig-a003-20201214
i386 randconfig-a002-20201214
i386 randconfig-a006-20201214
i386 randconfig-a005-20201214
i386 randconfig-a001-20201213
i386 randconfig-a004-20201213
i386 randconfig-a003-20201213
i386 randconfig-a002-20201213
i386 randconfig-a005-20201213
i386 randconfig-a006-20201213
x86_64 randconfig-a016-20201214
x86_64 randconfig-a012-20201214
x86_64 randconfig-a013-20201214
x86_64 randconfig-a015-20201214
x86_64 randconfig-a014-20201214
x86_64 randconfig-a011-20201214
i386 randconfig-a014-20201214
i386 randconfig-a013-20201214
i386 randconfig-a012-20201214
i386 randconfig-a011-20201214
i386 randconfig-a015-20201214
i386 randconfig-a016-20201214
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
clang tested configs:
x86_64 randconfig-a003-20201214
x86_64 randconfig-a006-20201214
x86_64 randconfig-a002-20201214
x86_64 randconfig-a005-20201214
x86_64 randconfig-a004-20201214
x86_64 randconfig-a001-20201214
x86_64 randconfig-a016-20201213
x86_64 randconfig-a012-20201213
x86_64 randconfig-a013-20201213
x86_64 randconfig-a015-20201213
x86_64 randconfig-a014-20201213
x86_64 randconfig-a011-20201213
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH] powerpc: Inline setup_kup()
From: Michael Ellerman @ 2020-12-15 1:42 UTC (permalink / raw)
To: Christophe Leroy, linuxppc-dev
In-Reply-To: <09e673ec-6d4e-2e8d-b843-018ce94142a4@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Le 14/12/2020 à 13:30, Michael Ellerman a écrit :
>> setup_kup() is used by both 64-bit and 32-bit code. However on 64-bit
>> it must not be __init, because it's used for CPU hotplug, whereas on
>> 32-bit it should be __init because it calls setup_kuap/kuep() which
>> are __init.
>>
>> We worked around that problem in the past by marking it __ref, see
>> commit 67d53f30e23e ("powerpc/mm: fix section mismatch for
>> setup_kup()").
>>
>> Marking it __ref basically just omits it from section mismatch
>> checking, which can lead to bugs, and in fact it did, see commit
>> 44b4c4450f8d ("powerpc/64s: Mark the kuap/kuep functions non __init")
>>
>> We can avoid all these problems by just making it static inline.
>> Because all it does is call other functions, making it inline actually
>> shrinks the 32-bit vmlinux by ~76 bytes.
>>
>> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>> ---
>> arch/powerpc/include/asm/kup.h | 8 ++++++--
>> arch/powerpc/mm/init-common.c | 6 ------
>> 2 files changed, 6 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/powerpc/include/asm/kup.h b/arch/powerpc/include/asm/kup.h
>> index 5a9820c54da9..46b12c6dc728 100644
>> --- a/arch/powerpc/include/asm/kup.h
>> +++ b/arch/powerpc/include/asm/kup.h
>> @@ -49,8 +49,6 @@ extern bool disable_kuap;
>>
>> #include <linux/pgtable.h>
>>
>> -void setup_kup(void);
>> -
>> #ifdef CONFIG_PPC_KUEP
>> void setup_kuep(bool disabled);
>> #else
>> @@ -85,6 +83,12 @@ static inline void restore_user_access(unsigned long flags) { }
>> #endif /* CONFIG_PPC_BOOK3S_64 */
>> #endif /* CONFIG_PPC_KUAP */
>>
>> +static inline void setup_kup(void)
>
> Should it be __always_inline ?
Yes I guess so, will fix. Thanks for reviewing.
cheers
^ permalink raw reply
* Re: [PATCH v2 1/1] powerpc/kvm: Fix mask size for emulated msgsndp
From: Paul Mackerras @ 2020-12-15 2:15 UTC (permalink / raw)
To: Leonardo Bras; +Cc: linuxppc-dev, linux-kernel, kvm-ppc
In-Reply-To: <20201208215707.31149-1-leobras.c@gmail.com>
On Tue, Dec 08, 2020 at 06:57:08PM -0300, Leonardo Bras wrote:
> According to ISAv3.1 and ISAv3.0b, the msgsndp is described to split RB in:
> msgtype <- (RB) 32:36
> payload <- (RB) 37:63
> t <- (RB) 57:63
>
> The current way of getting 'msgtype', and 't' is missing their MSB:
> msgtype: ((arg >> 27) & 0xf) : Gets (RB) 33:36, missing bit 32
> t: (arg &= 0x3f) : Gets (RB) 58:63, missing bit 57
>
> Fixes this by applying the correct mask.
>
> Signed-off-by: Leonardo Bras <leobras.c@gmail.com>
Acked-by: Paul Mackerras <paulus@ozlabs.org>
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Book3S: Assign boolean values to a bool variable
From: Paul Mackerras @ 2020-12-15 2:14 UTC (permalink / raw)
To: xiakaixu1987; +Cc: Kaixu Xia, linuxppc-dev, linux-kernel, kvm-ppc
In-Reply-To: <1604730382-5810-1-git-send-email-kaixuxia@tencent.com>
On Sat, Nov 07, 2020 at 02:26:22PM +0800, xiakaixu1987@gmail.com wrote:
> From: Kaixu Xia <kaixuxia@tencent.com>
>
> Fix the following coccinelle warnings:
>
> ./arch/powerpc/kvm/book3s_xics.c:476:3-15: WARNING: Assignment of 0/1 to bool variable
> ./arch/powerpc/kvm/book3s_xics.c:504:3-15: WARNING: Assignment of 0/1 to bool variable
>
> Reported-by: Tosk Robot <tencent_os_robot@tencent.com>
> Signed-off-by: Kaixu Xia <kaixuxia@tencent.com>
Acked-by: Paul Mackerras <paulus@ozlabs.org>
^ permalink raw reply
* Re: [PATCH] KVM: PPC: fix comparison to bool warning
From: Paul Mackerras @ 2020-12-15 2:14 UTC (permalink / raw)
To: xiakaixu1987; +Cc: Kaixu Xia, linuxppc-dev, kvm-ppc
In-Reply-To: <1604764178-8087-1-git-send-email-kaixuxia@tencent.com>
On Sat, Nov 07, 2020 at 11:49:38PM +0800, xiakaixu1987@gmail.com wrote:
> From: Kaixu Xia <kaixuxia@tencent.com>
>
> Fix the following coccicheck warning:
>
> ./arch/powerpc/kvm/booke.c:503:6-16: WARNING: Comparison to bool
> ./arch/powerpc/kvm/booke.c:505:6-17: WARNING: Comparison to bool
> ./arch/powerpc/kvm/booke.c:507:6-16: WARNING: Comparison to bool
>
> Reported-by: Tosk Robot <tencent_os_robot@tencent.com>
> Signed-off-by: Kaixu Xia <kaixuxia@tencent.com>
Acked-by: Paul Mackerras <paulus@ozlabs.org>
^ permalink raw reply
* [PATCH] powerpc/boot: Fix build of dts/fsl
From: Michael Ellerman @ 2020-12-15 3:29 UTC (permalink / raw)
To: masahiroy; +Cc: linuxppc-dev
The lkp robot reported that some configs fail to build, for example
mpc85xx_smp_defconfig, with:
cc1: fatal error: opening output file arch/powerpc/boot/dts/fsl/.mpc8540ads.dtb.dts.tmp: No such file or directory
This bisects to:
cc8a51ca6f05 ("kbuild: always create directories of targets")
Although that commit claims to be about in-tree builds, it somehow
breaks out-of-tree builds. But presumably it's just exposing a latent
bug in our Makefiles.
We can fix it by adding to targets for dts/fsl in the same way that we
do for dts.
Fixes: cc8a51ca6f05 ("kbuild: always create directories of targets")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/boot/Makefile | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 68a7534454cd..c3e084cceaed 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -372,6 +372,8 @@ initrd-y := $(filter-out $(image-y), $(initrd-y))
targets += $(image-y) $(initrd-y)
targets += $(foreach x, dtbImage uImage cuImage simpleImage treeImage, \
$(patsubst $(x).%, dts/%.dtb, $(filter $(x).%, $(image-y))))
+targets += $(foreach x, dtbImage uImage cuImage simpleImage treeImage, \
+ $(patsubst $(x).%, dts/fsl/%.dtb, $(filter $(x).%, $(image-y))))
$(addprefix $(obj)/, $(initrd-y)): $(obj)/ramdisk.image.gz
--
2.25.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox