* [v3 15/15] tools/perf: Add perf tools support for extended regs in power10
From: Athira Rajeev @ 2020-07-17 14:38 UTC (permalink / raw)
To: mpe; +Cc: ego, mikey, maddy, kvm, kvm-ppc, svaidyan, acme, jolsa,
linuxppc-dev
In-Reply-To: <1594996707-3727-1-git-send-email-atrajeev@linux.vnet.ibm.com>
Added support for supported regs which are new in power10
( MMCR3, SIER2, SIER3 ) to sample_reg_mask in the tool side
to use with `-I?` option. Also added PVR check to send extended
mask for power10 at kernel while capturing extended regs in
each sample.
Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
---
tools/arch/powerpc/include/uapi/asm/perf_regs.h | 6 ++++++
tools/perf/arch/powerpc/include/perf_regs.h | 3 +++
tools/perf/arch/powerpc/util/perf_regs.c | 6 ++++++
3 files changed, 15 insertions(+)
diff --git a/tools/arch/powerpc/include/uapi/asm/perf_regs.h b/tools/arch/powerpc/include/uapi/asm/perf_regs.h
index 225c64c..bdf5f10 100644
--- a/tools/arch/powerpc/include/uapi/asm/perf_regs.h
+++ b/tools/arch/powerpc/include/uapi/asm/perf_regs.h
@@ -52,6 +52,9 @@ enum perf_event_powerpc_regs {
PERF_REG_POWERPC_MMCR0,
PERF_REG_POWERPC_MMCR1,
PERF_REG_POWERPC_MMCR2,
+ PERF_REG_POWERPC_MMCR3,
+ PERF_REG_POWERPC_SIER2,
+ PERF_REG_POWERPC_SIER3,
/* Max regs without the extended regs */
PERF_REG_POWERPC_MAX = PERF_REG_POWERPC_MMCRA + 1,
};
@@ -60,6 +63,9 @@ enum perf_event_powerpc_regs {
/* PERF_REG_EXTENDED_MASK value for CPU_FTR_ARCH_300 */
#define PERF_REG_PMU_MASK_300 (((1ULL << (PERF_REG_POWERPC_MMCR2 + 1)) - 1) - PERF_REG_PMU_MASK)
+/* PERF_REG_EXTENDED_MASK value for CPU_FTR_ARCH_31 */
+#define PERF_REG_PMU_MASK_31 (((1ULL << (PERF_REG_POWERPC_SIER3 + 1)) - 1) - PERF_REG_PMU_MASK)
#define PERF_REG_MAX_ISA_300 (PERF_REG_POWERPC_MMCR2 + 1)
+#define PERF_REG_MAX_ISA_31 (PERF_REG_POWERPC_SIER3 + 1)
#endif /* _UAPI_ASM_POWERPC_PERF_REGS_H */
diff --git a/tools/perf/arch/powerpc/include/perf_regs.h b/tools/perf/arch/powerpc/include/perf_regs.h
index 46ed00d..63f3ac9 100644
--- a/tools/perf/arch/powerpc/include/perf_regs.h
+++ b/tools/perf/arch/powerpc/include/perf_regs.h
@@ -68,6 +68,9 @@
[PERF_REG_POWERPC_MMCR0] = "mmcr0",
[PERF_REG_POWERPC_MMCR1] = "mmcr1",
[PERF_REG_POWERPC_MMCR2] = "mmcr2",
+ [PERF_REG_POWERPC_MMCR3] = "mmcr3",
+ [PERF_REG_POWERPC_SIER2] = "sier2",
+ [PERF_REG_POWERPC_SIER3] = "sier3",
};
static inline const char *perf_reg_name(int id)
diff --git a/tools/perf/arch/powerpc/util/perf_regs.c b/tools/perf/arch/powerpc/util/perf_regs.c
index d64ba0c..2b6d470 100644
--- a/tools/perf/arch/powerpc/util/perf_regs.c
+++ b/tools/perf/arch/powerpc/util/perf_regs.c
@@ -14,6 +14,7 @@
#include <linux/kernel.h>
#define PVR_POWER9 0x004E
+#define PVR_POWER10 0x0080
const struct sample_reg sample_reg_masks[] = {
SMPL_REG(r0, PERF_REG_POWERPC_R0),
@@ -64,6 +65,9 @@
SMPL_REG(mmcr0, PERF_REG_POWERPC_MMCR0),
SMPL_REG(mmcr1, PERF_REG_POWERPC_MMCR1),
SMPL_REG(mmcr2, PERF_REG_POWERPC_MMCR2),
+ SMPL_REG(mmcr3, PERF_REG_POWERPC_MMCR3),
+ SMPL_REG(sier2, PERF_REG_POWERPC_SIER2),
+ SMPL_REG(sier3, PERF_REG_POWERPC_SIER3),
SMPL_REG_END
};
@@ -194,6 +198,8 @@ uint64_t arch__intr_reg_mask(void)
version = (((mfspr(SPRN_PVR)) >> 16) & 0xFFFF);
if (version == PVR_POWER9)
extended_mask = PERF_REG_PMU_MASK_300;
+ else if (version == PVR_POWER10)
+ extended_mask = PERF_REG_PMU_MASK_31;
else
return mask;
--
1.8.3.1
^ permalink raw reply related
* [v3 13/15] tools/perf: Add perf tools support for extended register capability in powerpc
From: Athira Rajeev @ 2020-07-17 14:38 UTC (permalink / raw)
To: mpe; +Cc: ego, mikey, maddy, kvm, kvm-ppc, svaidyan, acme, jolsa,
linuxppc-dev
In-Reply-To: <1594996707-3727-1-git-send-email-atrajeev@linux.vnet.ibm.com>
From: Anju T Sudhakar <anju@linux.vnet.ibm.com>
Add extended regs to sample_reg_mask in the tool side to use
with `-I?` option. Perf tools side uses extended mask to display
the platform supported register names (with -I? option) to the user
and also send this mask to the kernel to capture the extended registers
in each sample. Hence decide the mask value based on the processor
version.
Currently definitions for `mfspr`, `SPRN_PVR` are part of
`arch/powerpc/util/header.c`. Move this to a header file so that
these definitions can be re-used in other source files as well.
Signed-off-by: Anju T Sudhakar <anju@linux.vnet.ibm.com>
[Decide extended mask at run time based on platform]
Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Reviewed-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
---
tools/arch/powerpc/include/uapi/asm/perf_regs.h | 14 ++++++-
tools/perf/arch/powerpc/include/perf_regs.h | 5 ++-
| 9 +----
tools/perf/arch/powerpc/util/perf_regs.c | 49 +++++++++++++++++++++++++
| 15 ++++++++
5 files changed, 82 insertions(+), 10 deletions(-)
create mode 100644 tools/perf/arch/powerpc/util/utils_header.h
diff --git a/tools/arch/powerpc/include/uapi/asm/perf_regs.h b/tools/arch/powerpc/include/uapi/asm/perf_regs.h
index f599064..225c64c 100644
--- a/tools/arch/powerpc/include/uapi/asm/perf_regs.h
+++ b/tools/arch/powerpc/include/uapi/asm/perf_regs.h
@@ -48,6 +48,18 @@ enum perf_event_powerpc_regs {
PERF_REG_POWERPC_DSISR,
PERF_REG_POWERPC_SIER,
PERF_REG_POWERPC_MMCRA,
- PERF_REG_POWERPC_MAX,
+ /* Extended registers */
+ PERF_REG_POWERPC_MMCR0,
+ PERF_REG_POWERPC_MMCR1,
+ PERF_REG_POWERPC_MMCR2,
+ /* Max regs without the extended regs */
+ PERF_REG_POWERPC_MAX = PERF_REG_POWERPC_MMCRA + 1,
};
+
+#define PERF_REG_PMU_MASK ((1ULL << PERF_REG_POWERPC_MAX) - 1)
+
+/* PERF_REG_EXTENDED_MASK value for CPU_FTR_ARCH_300 */
+#define PERF_REG_PMU_MASK_300 (((1ULL << (PERF_REG_POWERPC_MMCR2 + 1)) - 1) - PERF_REG_PMU_MASK)
+
+#define PERF_REG_MAX_ISA_300 (PERF_REG_POWERPC_MMCR2 + 1)
#endif /* _UAPI_ASM_POWERPC_PERF_REGS_H */
diff --git a/tools/perf/arch/powerpc/include/perf_regs.h b/tools/perf/arch/powerpc/include/perf_regs.h
index e18a355..46ed00d 100644
--- a/tools/perf/arch/powerpc/include/perf_regs.h
+++ b/tools/perf/arch/powerpc/include/perf_regs.h
@@ -64,7 +64,10 @@
[PERF_REG_POWERPC_DAR] = "dar",
[PERF_REG_POWERPC_DSISR] = "dsisr",
[PERF_REG_POWERPC_SIER] = "sier",
- [PERF_REG_POWERPC_MMCRA] = "mmcra"
+ [PERF_REG_POWERPC_MMCRA] = "mmcra",
+ [PERF_REG_POWERPC_MMCR0] = "mmcr0",
+ [PERF_REG_POWERPC_MMCR1] = "mmcr1",
+ [PERF_REG_POWERPC_MMCR2] = "mmcr2",
};
static inline const char *perf_reg_name(int id)
--git a/tools/perf/arch/powerpc/util/header.c b/tools/perf/arch/powerpc/util/header.c
index d487007..1a95017 100644
--- a/tools/perf/arch/powerpc/util/header.c
+++ b/tools/perf/arch/powerpc/util/header.c
@@ -7,17 +7,10 @@
#include <string.h>
#include <linux/stringify.h>
#include "header.h"
+#include "utils_header.h"
#include "metricgroup.h"
#include <api/fs/fs.h>
-#define mfspr(rn) ({unsigned long rval; \
- asm volatile("mfspr %0," __stringify(rn) \
- : "=r" (rval)); rval; })
-
-#define SPRN_PVR 0x11F /* Processor Version Register */
-#define PVR_VER(pvr) (((pvr) >> 16) & 0xFFFF) /* Version field */
-#define PVR_REV(pvr) (((pvr) >> 0) & 0xFFFF) /* Revison field */
-
int
get_cpuid(char *buffer, size_t sz)
{
diff --git a/tools/perf/arch/powerpc/util/perf_regs.c b/tools/perf/arch/powerpc/util/perf_regs.c
index 0a52429..d64ba0c 100644
--- a/tools/perf/arch/powerpc/util/perf_regs.c
+++ b/tools/perf/arch/powerpc/util/perf_regs.c
@@ -6,9 +6,15 @@
#include "../../../util/perf_regs.h"
#include "../../../util/debug.h"
+#include "../../../util/event.h"
+#include "../../../util/header.h"
+#include "../../../perf-sys.h"
+#include "utils_header.h"
#include <linux/kernel.h>
+#define PVR_POWER9 0x004E
+
const struct sample_reg sample_reg_masks[] = {
SMPL_REG(r0, PERF_REG_POWERPC_R0),
SMPL_REG(r1, PERF_REG_POWERPC_R1),
@@ -55,6 +61,9 @@
SMPL_REG(dsisr, PERF_REG_POWERPC_DSISR),
SMPL_REG(sier, PERF_REG_POWERPC_SIER),
SMPL_REG(mmcra, PERF_REG_POWERPC_MMCRA),
+ SMPL_REG(mmcr0, PERF_REG_POWERPC_MMCR0),
+ SMPL_REG(mmcr1, PERF_REG_POWERPC_MMCR1),
+ SMPL_REG(mmcr2, PERF_REG_POWERPC_MMCR2),
SMPL_REG_END
};
@@ -163,3 +172,43 @@ int arch_sdt_arg_parse_op(char *old_op, char **new_op)
return SDT_ARG_VALID;
}
+
+uint64_t arch__intr_reg_mask(void)
+{
+ struct perf_event_attr attr = {
+ .type = PERF_TYPE_HARDWARE,
+ .config = PERF_COUNT_HW_CPU_CYCLES,
+ .sample_type = PERF_SAMPLE_REGS_INTR,
+ .precise_ip = 1,
+ .disabled = 1,
+ .exclude_kernel = 1,
+ };
+ int fd;
+ u32 version;
+ u64 extended_mask = 0, mask = PERF_REGS_MASK;
+
+ /*
+ * Get the PVR value to set the extended
+ * mask specific to platform.
+ */
+ version = (((mfspr(SPRN_PVR)) >> 16) & 0xFFFF);
+ if (version == PVR_POWER9)
+ extended_mask = PERF_REG_PMU_MASK_300;
+ else
+ return mask;
+
+ attr.sample_regs_intr = extended_mask;
+ attr.sample_period = 1;
+ event_attr_init(&attr);
+
+ /*
+ * check if the pmu supports perf extended regs, before
+ * returning the register mask to sample.
+ */
+ fd = sys_perf_event_open(&attr, 0, -1, -1, 0);
+ if (fd != -1) {
+ close(fd);
+ mask |= extended_mask;
+ }
+ return mask;
+}
--git a/tools/perf/arch/powerpc/util/utils_header.h b/tools/perf/arch/powerpc/util/utils_header.h
new file mode 100644
index 0000000..5788eb1
--- /dev/null
+++ b/tools/perf/arch/powerpc/util/utils_header.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __PERF_UTIL_HEADER_H
+#define __PERF_UTIL_HEADER_H
+
+#include <linux/stringify.h>
+
+#define mfspr(rn) ({unsigned long rval; \
+ asm volatile("mfspr %0," __stringify(rn) \
+ : "=r" (rval)); rval; })
+
+#define SPRN_PVR 0x11F /* Processor Version Register */
+#define PVR_VER(pvr) (((pvr) >> 16) & 0xFFFF) /* Version field */
+#define PVR_REV(pvr) (((pvr) >> 0) & 0xFFFF) /* Revison field */
+
+#endif /* __PERF_UTIL_HEADER_H */
--
1.8.3.1
^ permalink raw reply related
* Re: [RFC PATCH 4/7] x86: use exit_lazy_tlb rather than membarrier_mm_sync_core_before_usermode
From: Alan Stern @ 2020-07-17 14:51 UTC (permalink / raw)
To: Mathieu Desnoyers
Cc: linux-arch, paulmck, Arnd Bergmann, Peter Zijlstra, x86,
linux-kernel, Nicholas Piggin, linux-mm, Andy Lutomirski,
linuxppc-dev
In-Reply-To: <1770378591.18523.1594993165391.JavaMail.zimbra@efficios.com>
On Fri, Jul 17, 2020 at 09:39:25AM -0400, Mathieu Desnoyers wrote:
> ----- On Jul 16, 2020, at 5:24 PM, Alan Stern stern@rowland.harvard.edu wrote:
>
> > On Thu, Jul 16, 2020 at 02:58:41PM -0400, Mathieu Desnoyers wrote:
> >> ----- On Jul 16, 2020, at 12:03 PM, Mathieu Desnoyers
> >> mathieu.desnoyers@efficios.com wrote:
> >>
> >> > ----- On Jul 16, 2020, at 11:46 AM, Mathieu Desnoyers
> >> > mathieu.desnoyers@efficios.com wrote:
> >> >
> >> >> ----- On Jul 16, 2020, at 12:42 AM, Nicholas Piggin npiggin@gmail.com wrote:
> >> >>> I should be more complete here, especially since I was complaining
> >> >>> about unclear barrier comment :)
> >> >>>
> >> >>>
> >> >>> CPU0 CPU1
> >> >>> a. user stuff 1. user stuff
> >> >>> b. membarrier() 2. enter kernel
> >> >>> c. smp_mb() 3. smp_mb__after_spinlock(); // in __schedule
> >> >>> d. read rq->curr 4. rq->curr switched to kthread
> >> >>> e. is kthread, skip IPI 5. switch_to kthread
> >> >>> f. return to user 6. rq->curr switched to user thread
> >> >>> g. user stuff 7. switch_to user thread
> >> >>> 8. exit kernel
> >> >>> 9. more user stuff
...
> >> Requiring a memory barrier between update of rq->curr (back to current process's
> >> thread) and following user-space memory accesses does not seem to guarantee
> >> anything more than what the initial barrier at the beginning of __schedule
> >> already
> >> provides, because the guarantees are only about accesses to user-space memory.
...
> > Is it correct to say that the switch_to operations in 5 and 7 include
> > memory barriers? If they do, then skipping the IPI should be okay.
> >
> > The reason is as follows: The guarantee you need to enforce is that
> > anything written by CPU0 before the membarrier() will be visible to CPU1
> > after it returns to user mode. Let's say that a writes to X and 9
> > reads from X.
> >
> > Then we have an instance of the Store Buffer pattern:
> >
> > CPU0 CPU1
> > a. Write X 6. Write rq->curr for user thread
> > c. smp_mb() 7. switch_to memory barrier
> > d. Read rq->curr 9. Read X
> >
> > In this pattern, the memory barriers make it impossible for both reads
> > to miss their corresponding writes. Since d does fail to read 6 (it
> > sees the earlier value stored by 4), 9 must read a.
> >
> > The other guarantee you need is that g on CPU0 will observe anything
> > written by CPU1 in 1. This is easier to see, using the fact that 3 is a
> > memory barrier and d reads from 4.
>
> Right, and Nick's reply involving pairs of loads/stores on each side
> clarifies the situation even further.
The key part of my reply was the question: "Is it correct to say that
the switch_to operations in 5 and 7 include memory barriers?" From the
text quoted above and from Nick's reply, it seems clear that they do
not.
I agree with Nick: A memory barrier is needed somewhere between the
assignment at 6 and the return to user mode at 8. Otherwise you end up
with the Store Buffer pattern having a memory barrier on only one side,
and it is well known that this arrangement does not guarantee any
ordering.
One thing I don't understand about all this: Any context switch has to
include a memory barrier somewhere, but both you and Nick seem to be
saying that steps 6 and 7 don't include (or don't need) any memory
barriers. What am I missing?
Alan Stern
^ permalink raw reply
* Re: [RFC PATCH 4/7] x86: use exit_lazy_tlb rather than membarrier_mm_sync_core_before_usermode
From: Mathieu Desnoyers @ 2020-07-17 15:39 UTC (permalink / raw)
To: Alan Stern
Cc: linux-arch, paulmck, Arnd Bergmann, Peter Zijlstra, x86,
linux-kernel, Nicholas Piggin, linux-mm, Andy Lutomirski,
linuxppc-dev
In-Reply-To: <20200717145102.GC1147780@rowland.harvard.edu>
----- On Jul 17, 2020, at 10:51 AM, Alan Stern stern@rowland.harvard.edu wrote:
> On Fri, Jul 17, 2020 at 09:39:25AM -0400, Mathieu Desnoyers wrote:
>> ----- On Jul 16, 2020, at 5:24 PM, Alan Stern stern@rowland.harvard.edu wrote:
>>
>> > On Thu, Jul 16, 2020 at 02:58:41PM -0400, Mathieu Desnoyers wrote:
>> >> ----- On Jul 16, 2020, at 12:03 PM, Mathieu Desnoyers
>> >> mathieu.desnoyers@efficios.com wrote:
>> >>
>> >> > ----- On Jul 16, 2020, at 11:46 AM, Mathieu Desnoyers
>> >> > mathieu.desnoyers@efficios.com wrote:
>> >> >
>> >> >> ----- On Jul 16, 2020, at 12:42 AM, Nicholas Piggin npiggin@gmail.com wrote:
>> >> >>> I should be more complete here, especially since I was complaining
>> >> >>> about unclear barrier comment :)
>> >> >>>
>> >> >>>
>> >> >>> CPU0 CPU1
>> >> >>> a. user stuff 1. user stuff
>> >> >>> b. membarrier() 2. enter kernel
>> >> >>> c. smp_mb() 3. smp_mb__after_spinlock(); // in __schedule
>> >> >>> d. read rq->curr 4. rq->curr switched to kthread
>> >> >>> e. is kthread, skip IPI 5. switch_to kthread
>> >> >>> f. return to user 6. rq->curr switched to user thread
>> >> >>> g. user stuff 7. switch_to user thread
>> >> >>> 8. exit kernel
>> >> >>> 9. more user stuff
>
> ...
>
>> >> Requiring a memory barrier between update of rq->curr (back to current process's
>> >> thread) and following user-space memory accesses does not seem to guarantee
>> >> anything more than what the initial barrier at the beginning of __schedule
>> >> already
>> >> provides, because the guarantees are only about accesses to user-space memory.
>
> ...
>
>> > Is it correct to say that the switch_to operations in 5 and 7 include
>> > memory barriers? If they do, then skipping the IPI should be okay.
>> >
>> > The reason is as follows: The guarantee you need to enforce is that
>> > anything written by CPU0 before the membarrier() will be visible to CPU1
>> > after it returns to user mode. Let's say that a writes to X and 9
>> > reads from X.
>> >
>> > Then we have an instance of the Store Buffer pattern:
>> >
>> > CPU0 CPU1
>> > a. Write X 6. Write rq->curr for user thread
>> > c. smp_mb() 7. switch_to memory barrier
>> > d. Read rq->curr 9. Read X
>> >
>> > In this pattern, the memory barriers make it impossible for both reads
>> > to miss their corresponding writes. Since d does fail to read 6 (it
>> > sees the earlier value stored by 4), 9 must read a.
>> >
>> > The other guarantee you need is that g on CPU0 will observe anything
>> > written by CPU1 in 1. This is easier to see, using the fact that 3 is a
>> > memory barrier and d reads from 4.
>>
>> Right, and Nick's reply involving pairs of loads/stores on each side
>> clarifies the situation even further.
>
> The key part of my reply was the question: "Is it correct to say that
> the switch_to operations in 5 and 7 include memory barriers?" From the
> text quoted above and from Nick's reply, it seems clear that they do
> not.
I remember that switch_mm implies it, but not switch_to.
The scenario that triggered this discussion is when the scheduler does a
lazy tlb entry/exit, which is basically switch from a user task to
a kernel thread without changing the mm, and usually switching back afterwards.
This optimization means the rq->curr mm temporarily differs, which prevent
IPIs from being sent by membarrier, but without involving a switch_mm.
This requires explicit memory barriers either on entry/exit of lazy tlb
mode, or explicit barriers in the scheduler for those special-cases.
> I agree with Nick: A memory barrier is needed somewhere between the
> assignment at 6 and the return to user mode at 8. Otherwise you end up
> with the Store Buffer pattern having a memory barrier on only one side,
> and it is well known that this arrangement does not guarantee any
> ordering.
Yes, I see this now. I'm still trying to wrap my head around why the memory
barrier at the end of membarrier() needs to be paired with a scheduler
barrier though.
> One thing I don't understand about all this: Any context switch has to
> include a memory barrier somewhere, but both you and Nick seem to be
> saying that steps 6 and 7 don't include (or don't need) any memory
> barriers. What am I missing?
All context switch have the smp_mb__before_spinlock at the beginning of
__schedule(), which I suspect is what you refer to. However this barrier
is before the store to rq->curr, not after.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
^ permalink raw reply
* Re: [RFC PATCH 4/7] x86: use exit_lazy_tlb rather than membarrier_mm_sync_core_before_usermode
From: Alan Stern @ 2020-07-17 16:11 UTC (permalink / raw)
To: Mathieu Desnoyers
Cc: linux-arch, paulmck, Arnd Bergmann, Peter Zijlstra, x86,
linux-kernel, Nicholas Piggin, linux-mm, Andy Lutomirski,
linuxppc-dev
In-Reply-To: <1697220787.18880.1595000348405.JavaMail.zimbra@efficios.com>
> > I agree with Nick: A memory barrier is needed somewhere between the
> > assignment at 6 and the return to user mode at 8. Otherwise you end up
> > with the Store Buffer pattern having a memory barrier on only one side,
> > and it is well known that this arrangement does not guarantee any
> > ordering.
>
> Yes, I see this now. I'm still trying to wrap my head around why the memory
> barrier at the end of membarrier() needs to be paired with a scheduler
> barrier though.
The memory barrier at the end of membarrier() on CPU0 is necessary in
order to enforce the guarantee that any writes occurring on CPU1 before
the membarrier() is executed will be visible to any code executing on
CPU0 after the membarrier(). Ignoring the kthread issue, we can have:
CPU0 CPU1
x = 1
barrier()
y = 1
r2 = y
membarrier():
a: smp_mb()
b: send IPI IPI-induced mb
c: smp_mb()
r1 = x
The writes to x and y are unordered by the hardware, so it's possible to
have r2 = 1 even though the write to x doesn't execute until b. If the
memory barrier at c is omitted then "r1 = x" can be reordered before b
(although not before a), so we get r1 = 0. This violates the guarantee
that membarrier() is supposed to provide.
The timing of the memory barrier at c has to ensure that it executes
after the IPI-induced memory barrier on CPU1. If it happened before
then we could still end up with r1 = 0. That's why the pairing matters.
I hope this helps your head get properly wrapped. :-)
Alan Stern
^ permalink raw reply
* Re: [RFC PATCH 4/7] x86: use exit_lazy_tlb rather than membarrier_mm_sync_core_before_usermode
From: Mathieu Desnoyers @ 2020-07-17 16:22 UTC (permalink / raw)
To: Alan Stern
Cc: linux-arch, paulmck, Arnd Bergmann, Peter Zijlstra, x86,
linux-kernel, Nicholas Piggin, linux-mm, Andy Lutomirski,
linuxppc-dev
In-Reply-To: <20200717161145.GA1150454@rowland.harvard.edu>
----- On Jul 17, 2020, at 12:11 PM, Alan Stern stern@rowland.harvard.edu wrote:
>> > I agree with Nick: A memory barrier is needed somewhere between the
>> > assignment at 6 and the return to user mode at 8. Otherwise you end up
>> > with the Store Buffer pattern having a memory barrier on only one side,
>> > and it is well known that this arrangement does not guarantee any
>> > ordering.
>>
>> Yes, I see this now. I'm still trying to wrap my head around why the memory
>> barrier at the end of membarrier() needs to be paired with a scheduler
>> barrier though.
>
> The memory barrier at the end of membarrier() on CPU0 is necessary in
> order to enforce the guarantee that any writes occurring on CPU1 before
> the membarrier() is executed will be visible to any code executing on
> CPU0 after the membarrier(). Ignoring the kthread issue, we can have:
>
> CPU0 CPU1
> x = 1
> barrier()
> y = 1
> r2 = y
> membarrier():
> a: smp_mb()
> b: send IPI IPI-induced mb
> c: smp_mb()
> r1 = x
>
> The writes to x and y are unordered by the hardware, so it's possible to
> have r2 = 1 even though the write to x doesn't execute until b. If the
> memory barrier at c is omitted then "r1 = x" can be reordered before b
> (although not before a), so we get r1 = 0. This violates the guarantee
> that membarrier() is supposed to provide.
>
> The timing of the memory barrier at c has to ensure that it executes
> after the IPI-induced memory barrier on CPU1. If it happened before
> then we could still end up with r1 = 0. That's why the pairing matters.
>
> I hope this helps your head get properly wrapped. :-)
It does help a bit! ;-)
This explains this part of the comment near the smp_mb at the end of membarrier:
* Memory barrier on the caller thread _after_ we finished
* waiting for the last IPI. [...]
However, it does not explain why it needs to be paired with a barrier in the
scheduler, clearly for the case where the IPI is skipped. I wonder whether this part
of the comment is factually correct:
* [...] Matches memory barriers around rq->curr modification in scheduler.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
^ permalink raw reply
* [powerpc:next] BUILD SUCCESS 61f879d97ce4510dd29d676a20d67692e3b34806
From: kernel test robot @ 2020-07-17 17:25 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: 61f879d97ce4510dd29d676a20d67692e3b34806 powerpc/pseries: Detect secure and trusted boot state of the system.
elapsed time: 1716m
configs tested: 103
configs skipped: 1
The following configs have been built successfully.
More configs may be tested in the coming days.
arm defconfig
arm allyesconfig
arm allmodconfig
arm allnoconfig
arm64 allyesconfig
arm64 defconfig
arm64 allmodconfig
arm64 allnoconfig
arm aspeed_g4_defconfig
mips ip27_defconfig
m68k m5307c3_defconfig
sh j2_defconfig
powerpc ppc64_defconfig
parisc allyesconfig
i386 allnoconfig
i386 allyesconfig
i386 defconfig
i386 debian-10.3
ia64 allmodconfig
ia64 allnoconfig
ia64 allyesconfig
ia64 defconfig
m68k allmodconfig
m68k allnoconfig
m68k sun3_defconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
nios2 allyesconfig
openrisc defconfig
c6x allyesconfig
c6x allnoconfig
openrisc allyesconfig
nds32 defconfig
nds32 allnoconfig
csky allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
h8300 allmodconfig
xtensa defconfig
arc defconfig
arc allyesconfig
sh allmodconfig
sh allnoconfig
microblaze allnoconfig
mips allyesconfig
mips allnoconfig
mips allmodconfig
parisc allnoconfig
parisc defconfig
parisc allmodconfig
powerpc allyesconfig
powerpc rhel-kconfig
powerpc allmodconfig
powerpc allnoconfig
powerpc defconfig
x86_64 randconfig-a005-20200717
x86_64 randconfig-a006-20200717
x86_64 randconfig-a002-20200717
x86_64 randconfig-a001-20200717
x86_64 randconfig-a003-20200717
x86_64 randconfig-a004-20200717
i386 randconfig-a001-20200717
i386 randconfig-a005-20200717
i386 randconfig-a002-20200717
i386 randconfig-a006-20200717
i386 randconfig-a003-20200717
i386 randconfig-a004-20200717
x86_64 randconfig-a012-20200716
x86_64 randconfig-a011-20200716
x86_64 randconfig-a016-20200716
x86_64 randconfig-a014-20200716
x86_64 randconfig-a013-20200716
x86_64 randconfig-a015-20200716
i386 randconfig-a016-20200717
i386 randconfig-a011-20200717
i386 randconfig-a015-20200717
i386 randconfig-a012-20200717
i386 randconfig-a013-20200717
i386 randconfig-a014-20200717
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
s390 allyesconfig
s390 allnoconfig
s390 allmodconfig
s390 defconfig
sparc allyesconfig
sparc defconfig
sparc64 defconfig
sparc64 allnoconfig
sparc64 allyesconfig
sparc64 allmodconfig
x86_64 rhel-7.6-kselftests
x86_64 rhel-8.3
x86_64 kexec
x86_64 rhel
x86_64 lkp
x86_64 fedora-25
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [RFC PATCH 4/7] x86: use exit_lazy_tlb rather than membarrier_mm_sync_core_before_usermode
From: Alan Stern @ 2020-07-17 17:44 UTC (permalink / raw)
To: Mathieu Desnoyers
Cc: linux-arch, paulmck, Arnd Bergmann, Peter Zijlstra, x86,
linux-kernel, Nicholas Piggin, linux-mm, Andy Lutomirski,
linuxppc-dev
In-Reply-To: <12700909.18968.1595002969773.JavaMail.zimbra@efficios.com>
On Fri, Jul 17, 2020 at 12:22:49PM -0400, Mathieu Desnoyers wrote:
> ----- On Jul 17, 2020, at 12:11 PM, Alan Stern stern@rowland.harvard.edu wrote:
>
> >> > I agree with Nick: A memory barrier is needed somewhere between the
> >> > assignment at 6 and the return to user mode at 8. Otherwise you end up
> >> > with the Store Buffer pattern having a memory barrier on only one side,
> >> > and it is well known that this arrangement does not guarantee any
> >> > ordering.
> >>
> >> Yes, I see this now. I'm still trying to wrap my head around why the memory
> >> barrier at the end of membarrier() needs to be paired with a scheduler
> >> barrier though.
> >
> > The memory barrier at the end of membarrier() on CPU0 is necessary in
> > order to enforce the guarantee that any writes occurring on CPU1 before
> > the membarrier() is executed will be visible to any code executing on
> > CPU0 after the membarrier(). Ignoring the kthread issue, we can have:
> >
> > CPU0 CPU1
> > x = 1
> > barrier()
> > y = 1
> > r2 = y
> > membarrier():
> > a: smp_mb()
> > b: send IPI IPI-induced mb
> > c: smp_mb()
> > r1 = x
> >
> > The writes to x and y are unordered by the hardware, so it's possible to
> > have r2 = 1 even though the write to x doesn't execute until b. If the
> > memory barrier at c is omitted then "r1 = x" can be reordered before b
> > (although not before a), so we get r1 = 0. This violates the guarantee
> > that membarrier() is supposed to provide.
> >
> > The timing of the memory barrier at c has to ensure that it executes
> > after the IPI-induced memory barrier on CPU1. If it happened before
> > then we could still end up with r1 = 0. That's why the pairing matters.
> >
> > I hope this helps your head get properly wrapped. :-)
>
> It does help a bit! ;-)
>
> This explains this part of the comment near the smp_mb at the end of membarrier:
>
> * Memory barrier on the caller thread _after_ we finished
> * waiting for the last IPI. [...]
>
> However, it does not explain why it needs to be paired with a barrier in the
> scheduler, clearly for the case where the IPI is skipped. I wonder whether this part
> of the comment is factually correct:
>
> * [...] Matches memory barriers around rq->curr modification in scheduler.
The reasoning is pretty much the same as above:
CPU0 CPU1
x = 1
barrier()
y = 1
r2 = y
membarrier():
a: smp_mb()
switch to kthread (includes mb)
b: read rq->curr == kthread
switch to user (includes mb)
c: smp_mb()
r1 = x
Once again, it is possible that x = 1 doesn't become visible to CPU0
until shortly before b. But if c is omitted then "r1 = x" can be
reordered before b (to any time after a), so we can have r1 = 0.
Here the timing requirement is that c executes after the first memory
barrier on CPU1 -- which is one of the ones around the rq->curr
modification. (In fact, in this scenario CPU1's switch back to the user
process is irrelevant.)
Alan Stern
^ permalink raw reply
* Re: [RFC PATCH 4/7] x86: use exit_lazy_tlb rather than membarrier_mm_sync_core_before_usermode
From: Mathieu Desnoyers @ 2020-07-17 17:52 UTC (permalink / raw)
To: Alan Stern
Cc: linux-arch, paulmck, Arnd Bergmann, Peter Zijlstra, x86,
linux-kernel, Nicholas Piggin, linux-mm, Andy Lutomirski,
linuxppc-dev
In-Reply-To: <20200717174400.GA1156312@rowland.harvard.edu>
----- On Jul 17, 2020, at 1:44 PM, Alan Stern stern@rowland.harvard.edu wrote:
> On Fri, Jul 17, 2020 at 12:22:49PM -0400, Mathieu Desnoyers wrote:
>> ----- On Jul 17, 2020, at 12:11 PM, Alan Stern stern@rowland.harvard.edu wrote:
>>
>> >> > I agree with Nick: A memory barrier is needed somewhere between the
>> >> > assignment at 6 and the return to user mode at 8. Otherwise you end up
>> >> > with the Store Buffer pattern having a memory barrier on only one side,
>> >> > and it is well known that this arrangement does not guarantee any
>> >> > ordering.
>> >>
>> >> Yes, I see this now. I'm still trying to wrap my head around why the memory
>> >> barrier at the end of membarrier() needs to be paired with a scheduler
>> >> barrier though.
>> >
>> > The memory barrier at the end of membarrier() on CPU0 is necessary in
>> > order to enforce the guarantee that any writes occurring on CPU1 before
>> > the membarrier() is executed will be visible to any code executing on
>> > CPU0 after the membarrier(). Ignoring the kthread issue, we can have:
>> >
>> > CPU0 CPU1
>> > x = 1
>> > barrier()
>> > y = 1
>> > r2 = y
>> > membarrier():
>> > a: smp_mb()
>> > b: send IPI IPI-induced mb
>> > c: smp_mb()
>> > r1 = x
>> >
>> > The writes to x and y are unordered by the hardware, so it's possible to
>> > have r2 = 1 even though the write to x doesn't execute until b. If the
>> > memory barrier at c is omitted then "r1 = x" can be reordered before b
>> > (although not before a), so we get r1 = 0. This violates the guarantee
>> > that membarrier() is supposed to provide.
>> >
>> > The timing of the memory barrier at c has to ensure that it executes
>> > after the IPI-induced memory barrier on CPU1. If it happened before
>> > then we could still end up with r1 = 0. That's why the pairing matters.
>> >
>> > I hope this helps your head get properly wrapped. :-)
>>
>> It does help a bit! ;-)
>>
>> This explains this part of the comment near the smp_mb at the end of membarrier:
>>
>> * Memory barrier on the caller thread _after_ we finished
>> * waiting for the last IPI. [...]
>>
>> However, it does not explain why it needs to be paired with a barrier in the
>> scheduler, clearly for the case where the IPI is skipped. I wonder whether this
>> part
>> of the comment is factually correct:
>>
>> * [...] Matches memory barriers around rq->curr modification in scheduler.
>
> The reasoning is pretty much the same as above:
>
> CPU0 CPU1
> x = 1
> barrier()
> y = 1
> r2 = y
> membarrier():
> a: smp_mb()
> switch to kthread (includes mb)
> b: read rq->curr == kthread
> switch to user (includes mb)
> c: smp_mb()
> r1 = x
>
> Once again, it is possible that x = 1 doesn't become visible to CPU0
> until shortly before b. But if c is omitted then "r1 = x" can be
> reordered before b (to any time after a), so we can have r1 = 0.
>
> Here the timing requirement is that c executes after the first memory
> barrier on CPU1 -- which is one of the ones around the rq->curr
> modification. (In fact, in this scenario CPU1's switch back to the user
> process is irrelevant.)
That indeed covers the last scenario I was wondering about. Thanks Alan!
Mathieu
>
> Alan Stern
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
^ permalink raw reply
* [PATCH] macintosh/therm_adt746x: Replace HTTP links with HTTPS ones
From: Alexander A. Klimov @ 2020-07-17 18:29 UTC (permalink / raw)
To: colin, benh, linuxppc-dev, linux-kernel; +Cc: Alexander A. Klimov
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.
Deterministic algorithm:
For each file:
If not .svg:
For each line:
If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
Replace HTTP with HTTPS.
Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de>
---
Continuing my work started at 93431e0607e5.
See also: git log --oneline '--author=Alexander A. Klimov <grandmaster@al2klimov.de>' v5.7..master
If there are any URLs to be removed completely
or at least not (just) HTTPSified:
Just clearly say so and I'll *undo my change*.
See also: https://lkml.org/lkml/2020/6/27/64
If there are any valid, but yet not changed URLs:
See: https://lkml.org/lkml/2020/6/26/837
If you apply the patch, please let me know.
drivers/macintosh/therm_adt746x.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/macintosh/therm_adt746x.c b/drivers/macintosh/therm_adt746x.c
index 8f7725dc2166..7e218437730c 100644
--- a/drivers/macintosh/therm_adt746x.c
+++ b/drivers/macintosh/therm_adt746x.c
@@ -5,8 +5,8 @@
* Copyright (C) 2003, 2004 Colin Leroy, Rasmus Rohde, Benjamin Herrenschmidt
*
* Documentation from 115254175ADT7467_pra.pdf and 3686221171167ADT7460_b.pdf
- * http://www.onsemi.com/PowerSolutions/product.do?id=ADT7467
- * http://www.onsemi.com/PowerSolutions/product.do?id=ADT7460
+ * https://www.onsemi.com/PowerSolutions/product.do?id=ADT7467
+ * https://www.onsemi.com/PowerSolutions/product.do?id=ADT7460
*
*/
--
2.27.0
^ permalink raw reply related
* Re: [PATCH v3 02/12] powerpc/kexec_file: mark PPC64 specific code
From: Thiago Jung Bauermann @ 2020-07-17 18:34 UTC (permalink / raw)
To: Hari Bathini
Cc: Pingfan Liu, Petr Tesarik, Nayna Jain, Kexec-ml,
Mahesh J Salgaonkar, Mimi Zohar, lkml, linuxppc-dev, Sourabh Jain,
Andrew Morton, Dave Young, Vivek Goyal, Eric Biederman
In-Reply-To: <63d551a9-684b-768b-8b0f-2a0da68d7f11@linux.ibm.com>
Hari Bathini <hbathini@linux.ibm.com> writes:
> On 16/07/20 7:19 am, Thiago Jung Bauermann wrote:
>>
>> I didn't forget about this patch. I just wanted to see more of the
>> changes before comenting on it.
>>
>> Hari Bathini <hbathini@linux.ibm.com> writes:
>>
>>> Some of the kexec_file_load code isn't PPC64 specific. Move PPC64
>>> specific code from kexec/file_load.c to kexec/file_load_64.c. Also,
>>> rename purgatory/trampoline.S to purgatory/trampoline_64.S in the
>>> same spirit.
>>
>> There's only a 64 bit implementation of kexec_file_load() so this is a
>> somewhat theoretical exercise, but there's no harm in getting the code
>> organized, so:
>>
>> Reviewed-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
>>
>> I have just one question below.
>
> <snip>
>
>>> +/**
>>> + * setup_new_fdt_ppc64 - Update the flattend device-tree of the kernel
>>> + * being loaded.
>>> + * @image: kexec image being loaded.
>>> + * @fdt: Flattened device tree for the next kernel.
>>> + * @initrd_load_addr: Address where the next initrd will be loaded.
>>> + * @initrd_len: Size of the next initrd, or 0 if there will be none.
>>> + * @cmdline: Command line for the next kernel, or NULL if there will
>>> + * be none.
>>> + *
>>> + * Returns 0 on success, negative errno on error.
>>> + */
>>> +int setup_new_fdt_ppc64(const struct kimage *image, void *fdt,
>>> + unsigned long initrd_load_addr,
>>> + unsigned long initrd_len, const char *cmdline)
>>> +{
>>> + int chosen_node, ret;
>>> +
>>> + /* Remove memory reservation for the current device tree. */
>>> + ret = delete_fdt_mem_rsv(fdt, __pa(initial_boot_params),
>>> + fdt_totalsize(initial_boot_params));
>>> + if (ret == 0)
>>> + pr_debug("Removed old device tree reservation.\n");
>>> + else if (ret != -ENOENT) {
>>> + pr_err("Failed to remove old device-tree reservation.\n");
>>> + return ret;
>>> + }
>>> +
>>> + ret = setup_new_fdt(image, fdt, initrd_load_addr, initrd_len,
>>> + cmdline, &chosen_node);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + ret = fdt_setprop(fdt, chosen_node, "linux,booted-from-kexec", NULL, 0);
>>> + if (ret)
>>> + pr_err("Failed to update device-tree with linux,booted-from-kexec\n");
>>> +
>>> + return ret;
>>> +}
>>
>> For setup_purgatory_ppc64() you start with an empty function and build
>> from there, but for setup_new_fdt_ppc64() you moved some code here. Is
>> the code above 64 bit specific?
>
> Actually, I was not quiet sure if fdt updates like in patch 6 & patch 9 can be
> done after setup_ima_buffer() call. If you can confirm, I will move them back
> to setup_purgatory()
Hari and I discussed this off-line and we came to the conclusion that
theis code can be moved back to setup_new_fdt().
--
Thiago Jung Bauermann
IBM Linux Technology Center
^ permalink raw reply
* [PATCH] macintosh/adb: Replace HTTP links with HTTPS ones
From: Alexander A. Klimov @ 2020-07-17 18:35 UTC (permalink / raw)
To: benh, grandmaster, linuxppc-dev, linux-kernel
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.
Deterministic algorithm:
For each file:
If not .svg:
For each line:
If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
Replace HTTP with HTTPS.
Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de>
---
Continuing my work started at 93431e0607e5.
See also: git log --oneline '--author=Alexander A. Klimov <grandmaster@al2klimov.de>' v5.7..master
If there are any URLs to be removed completely
or at least not (just) HTTPSified:
Just clearly say so and I'll *undo my change*.
See also: https://lkml.org/lkml/2020/6/27/64
If there are any valid, but yet not changed URLs:
See: https://lkml.org/lkml/2020/6/26/837
If you apply the patch, please let me know.
drivers/macintosh/adb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/macintosh/adb.c b/drivers/macintosh/adb.c
index e49d1f287a17..73b396189039 100644
--- a/drivers/macintosh/adb.c
+++ b/drivers/macintosh/adb.c
@@ -163,7 +163,7 @@ static int adb_scan_bus(void)
* See if anybody actually moved. This is suggested
* by HW TechNote 01:
*
- * http://developer.apple.com/technotes/hw/hw_01.html
+ * https://developer.apple.com/technotes/hw/hw_01.html
*/
adb_request(&req, NULL, ADBREQ_SYNC | ADBREQ_REPLY, 1,
(highFree << 4) | 0xf);
--
2.27.0
^ permalink raw reply related
* Re: [PATCH v6] ima: move APPRAISE_BOOTPARAM dependency on ARCH_POLICY to runtime
From: Bruno Meneguele @ 2020-07-17 18:40 UTC (permalink / raw)
To: linux-kernel, x86, linuxppc-dev, linux-s390, linux-integrity
Cc: erichte, nayna, stable, zohar
In-Reply-To: <20200713164830.101165-1-bmeneg@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 3783 bytes --]
On Mon, Jul 13, 2020 at 01:48:30PM -0300, Bruno Meneguele wrote:
> The IMA_APPRAISE_BOOTPARAM config allows enabling different "ima_appraise="
> modes - log, fix, enforce - at run time, but not when IMA architecture
> specific policies are enabled. This prevents properly labeling the
> filesystem on systems where secure boot is supported, but not enabled on the
> platform. Only when secure boot is actually enabled should these IMA
> appraise modes be disabled.
>
> This patch removes the compile time dependency and makes it a runtime
> decision, based on the secure boot state of that platform.
>
> Test results as follows:
>
> -> x86-64 with secure boot enabled
>
> [ 0.015637] Kernel command line: <...> ima_policy=appraise_tcb ima_appraise=fix
> [ 0.015668] ima: Secure boot enabled: ignoring ima_appraise=fix boot parameter option
>
> -> powerpc with secure boot disabled
>
> [ 0.000000] Kernel command line: <...> ima_policy=appraise_tcb ima_appraise=fix
> [ 0.000000] Secure boot mode disabled
>
> -> Running the system without secure boot and with both options set:
>
> CONFIG_IMA_APPRAISE_BOOTPARAM=y
> CONFIG_IMA_ARCH_POLICY=y
>
> Audit prompts "missing-hash" but still allow execution and, consequently,
> filesystem labeling:
>
> type=INTEGRITY_DATA msg=audit(07/09/2020 12:30:27.778:1691) : pid=4976
> uid=root auid=root ses=2
> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 op=appraise_data
> cause=missing-hash comm=bash name=/usr/bin/evmctl dev="dm-0" ino=493150
> res=no
>
> Cc: stable@vger.kernel.org
> Fixes: d958083a8f64 ("x86/ima: define arch_get_ima_policy() for x86")
> Signed-off-by: Bruno Meneguele <bmeneg@redhat.com>
> ---
> v6:
> - explictly print the bootparam being ignored to the user (Mimi)
> v5:
> - add pr_info() to inform user the ima_appraise= boot param is being
> ignored due to secure boot enabled (Nayna)
> - add some testing results to commit log
> v4:
> - instead of change arch_policy loading code, check secure boot state at
> "ima_appraise=" parameter handler (Mimi)
> v3:
> - extend secure boot arch checker to also consider trusted boot
> - enforce IMA appraisal when secure boot is effectively enabled (Nayna)
> - fix ima_appraise flag assignment by or'ing it (Mimi)
> v2:
> - pr_info() message prefix correction
> security/integrity/ima/Kconfig | 2 +-
> security/integrity/ima/ima_appraise.c | 6 ++++++
> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/security/integrity/ima/Kconfig b/security/integrity/ima/Kconfig
> index edde88dbe576..62dc11a5af01 100644
> --- a/security/integrity/ima/Kconfig
> +++ b/security/integrity/ima/Kconfig
> @@ -232,7 +232,7 @@ config IMA_APPRAISE_REQUIRE_POLICY_SIGS
>
> config IMA_APPRAISE_BOOTPARAM
> bool "ima_appraise boot parameter"
> - depends on IMA_APPRAISE && !IMA_ARCH_POLICY
> + depends on IMA_APPRAISE
> default y
> help
> This option enables the different "ima_appraise=" modes
> diff --git a/security/integrity/ima/ima_appraise.c b/security/integrity/ima/ima_appraise.c
> index a9649b04b9f1..28a59508c6bd 100644
> --- a/security/integrity/ima/ima_appraise.c
> +++ b/security/integrity/ima/ima_appraise.c
> @@ -19,6 +19,12 @@
> static int __init default_appraise_setup(char *str)
> {
> #ifdef CONFIG_IMA_APPRAISE_BOOTPARAM
> + if (arch_ima_get_secureboot()) {
> + pr_info("Secure boot enabled: ignoring ima_appraise=%s boot parameter option",
> + str);
> + return 1;
> + }
> +
> if (strncmp(str, "off", 3) == 0)
> ima_appraise = 0;
> else if (strncmp(str, "log", 3) == 0)
> --
> 2.26.2
>
Ping for review.
Many thanks.
--
bmeneg
PGP Key: http://bmeneg.com/pubkey.txt
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH v3 1/3] powerpc/powernv/idle: Replace CPU features checks with PVR checks
From: Pratik Rajesh Sampat @ 2020-07-17 18:53 UTC (permalink / raw)
To: mpe, npiggin, benh, paulus, mikey, ego, svaidy, psampat,
pratik.r.sampat, linuxppc-dev, linux-kernel
In-Reply-To: <20200717185306.60607-1-psampat@linux.ibm.com>
As the idle framework's architecture is incomplete, hence instead of
checking for just the processor type advertised in the device tree CPU
features; check for the Processor Version Register (PVR) so that finer
granularity can be leveraged while making processor checks.
Signed-off-by: Pratik Rajesh Sampat <psampat@linux.ibm.com>
---
arch/powerpc/platforms/powernv/idle.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/idle.c b/arch/powerpc/platforms/powernv/idle.c
index 2dd467383a88..f62904f70fc6 100644
--- a/arch/powerpc/platforms/powernv/idle.c
+++ b/arch/powerpc/platforms/powernv/idle.c
@@ -92,7 +92,7 @@ static int pnv_save_sprs_for_deep_states(void)
if (rc != 0)
return rc;
- if (cpu_has_feature(CPU_FTR_ARCH_300)) {
+ if (pvr_version_is(PVR_POWER9)) {
rc = opal_slw_set_reg(pir, P9_STOP_SPR_MSR, msr_val);
if (rc)
return rc;
@@ -116,7 +116,7 @@ static int pnv_save_sprs_for_deep_states(void)
return rc;
/* Only p8 needs to set extra HID regiters */
- if (!cpu_has_feature(CPU_FTR_ARCH_300)) {
+ if (!pvr_version_is(PVR_POWER9)) {
rc = opal_slw_set_reg(pir, SPRN_HID1, hid1_val);
if (rc != 0)
@@ -971,7 +971,7 @@ unsigned long pnv_cpu_offline(unsigned int cpu)
__ppc64_runlatch_off();
- if (cpu_has_feature(CPU_FTR_ARCH_300) && deepest_stop_found) {
+ if (pvr_version_is(PVR_POWER9) && deepest_stop_found) {
unsigned long psscr;
psscr = mfspr(SPRN_PSSCR);
@@ -1175,7 +1175,7 @@ static void __init pnv_disable_deep_states(void)
pr_warn("cpuidle-powernv: Disabling idle states that lose full context\n");
pr_warn("cpuidle-powernv: Idle power-savings, CPU-Hotplug affected\n");
- if (cpu_has_feature(CPU_FTR_ARCH_300) &&
+ if (pvr_version_is(PVR_POWER9) &&
(pnv_deepest_stop_flag & OPAL_PM_LOSE_FULL_CONTEXT)) {
/*
* Use the default stop state for CPU-Hotplug
@@ -1205,7 +1205,7 @@ static void __init pnv_probe_idle_states(void)
return;
}
- if (cpu_has_feature(CPU_FTR_ARCH_300))
+ if (pvr_version_is(PVR_POWER9))
pnv_power9_idle_init();
for (i = 0; i < nr_pnv_idle_states; i++)
@@ -1278,7 +1278,7 @@ static int pnv_parse_cpuidle_dt(void)
pnv_idle_states[i].residency_ns = temp_u32[i];
/* For power9 */
- if (cpu_has_feature(CPU_FTR_ARCH_300)) {
+ if (pvr_version_is(PVR_POWER9)) {
/* Read pm_crtl_val */
if (of_property_read_u64_array(np, "ibm,cpu-idle-state-psscr",
temp_u64, nr_idle_states)) {
@@ -1337,7 +1337,7 @@ static int __init pnv_init_idle_states(void)
if (cpu == cpu_first_thread_sibling(cpu))
p->idle_state = (1 << threads_per_core) - 1;
- if (!cpu_has_feature(CPU_FTR_ARCH_300)) {
+ if (!pvr_version_is(PVR_POWER9)) {
/* P7/P8 nap */
p->thread_idle_state = PNV_THREAD_RUNNING;
} else {
--
2.25.4
^ permalink raw reply related
* [PATCH v3 0/3] powernv/idle: Power9 idle cleanup
From: Pratik Rajesh Sampat @ 2020-07-17 18:53 UTC (permalink / raw)
To: mpe, npiggin, benh, paulus, mikey, ego, svaidy, psampat,
pratik.r.sampat, linuxppc-dev, linux-kernel
v2: https://lkml.org/lkml/2020/7/10/28
Changelog v2-->v3:
1. Based on comments from Nicholas Piggin, introducing a cleanup patch
in which, instead of checking for CPU_FTR_ARCH_300 check for
PVR_POWER9 to allow for a finer granularity of checks where one
processor generation can have multiple ways to handling idle
2. Removed saving-restoring DAWR, DAWRX patch for P10 systems. Based on
discussions it has become evident that checks based on PVR is the way
to go; however, P10 PVR is yet to up-stream hence shelving this patch
for later.
Pratik Rajesh Sampat (3):
powerpc/powernv/idle: Replace CPU features checks with PVR checks
powerpc/powernv/idle: Rename pnv_first_spr_loss_level variable
powerpc/powernv/idle: Exclude mfspr on HID1,4,5 on P9 and above
arch/powerpc/platforms/powernv/idle.c | 38 +++++++++++++--------------
1 file changed, 19 insertions(+), 19 deletions(-)
--
2.25.4
^ permalink raw reply
* [PATCH v3 2/3] powerpc/powernv/idle: Rename pnv_first_spr_loss_level variable
From: Pratik Rajesh Sampat @ 2020-07-17 18:53 UTC (permalink / raw)
To: mpe, npiggin, benh, paulus, mikey, ego, svaidy, psampat,
pratik.r.sampat, linuxppc-dev, linux-kernel
In-Reply-To: <20200717185306.60607-1-psampat@linux.ibm.com>
Replace the variable name from using "pnv_first_spr_loss_level" to
"pnv_first_fullstate_loss_level".
As pnv_first_spr_loss_level is supposed to be the earliest state that
has OPAL_PM_LOSE_FULL_CONTEXT set, however as shallow states too loose
SPR values, render an incorrect terminology.
Signed-off-by: Pratik Rajesh Sampat <psampat@linux.ibm.com>
---
arch/powerpc/platforms/powernv/idle.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/idle.c b/arch/powerpc/platforms/powernv/idle.c
index f62904f70fc6..d439e11af101 100644
--- a/arch/powerpc/platforms/powernv/idle.c
+++ b/arch/powerpc/platforms/powernv/idle.c
@@ -48,7 +48,7 @@ static bool default_stop_found;
* First stop state levels when SPR and TB loss can occur.
*/
static u64 pnv_first_tb_loss_level = MAX_STOP_STATE + 1;
-static u64 pnv_first_spr_loss_level = MAX_STOP_STATE + 1;
+static u64 pnv_first_fullstate_loss_level = MAX_STOP_STATE + 1;
/*
* psscr value and mask of the deepest stop idle state.
@@ -657,7 +657,7 @@ static unsigned long power9_idle_stop(unsigned long psscr, bool mmu_on)
*/
mmcr0 = mfspr(SPRN_MMCR0);
}
- if ((psscr & PSSCR_RL_MASK) >= pnv_first_spr_loss_level) {
+ if ((psscr & PSSCR_RL_MASK) >= pnv_first_fullstate_loss_level) {
sprs.lpcr = mfspr(SPRN_LPCR);
sprs.hfscr = mfspr(SPRN_HFSCR);
sprs.fscr = mfspr(SPRN_FSCR);
@@ -741,7 +741,7 @@ static unsigned long power9_idle_stop(unsigned long psscr, bool mmu_on)
* just always test PSSCR for SPR/TB state loss.
*/
pls = (psscr & PSSCR_PLS) >> PSSCR_PLS_SHIFT;
- if (likely(pls < pnv_first_spr_loss_level)) {
+ if (likely(pls < pnv_first_fullstate_loss_level)) {
if (sprs_saved)
atomic_stop_thread_idle();
goto out;
@@ -1088,7 +1088,7 @@ static void __init pnv_power9_idle_init(void)
* the deepest loss-less (OPAL_PM_STOP_INST_FAST) stop state.
*/
pnv_first_tb_loss_level = MAX_STOP_STATE + 1;
- pnv_first_spr_loss_level = MAX_STOP_STATE + 1;
+ pnv_first_fullstate_loss_level = MAX_STOP_STATE + 1;
for (i = 0; i < nr_pnv_idle_states; i++) {
int err;
struct pnv_idle_states_t *state = &pnv_idle_states[i];
@@ -1099,8 +1099,8 @@ static void __init pnv_power9_idle_init(void)
pnv_first_tb_loss_level = psscr_rl;
if ((state->flags & OPAL_PM_LOSE_FULL_CONTEXT) &&
- (pnv_first_spr_loss_level > psscr_rl))
- pnv_first_spr_loss_level = psscr_rl;
+ (pnv_first_fullstate_loss_level > psscr_rl))
+ pnv_first_fullstate_loss_level = psscr_rl;
/*
* The idle code does not deal with TB loss occurring
@@ -1111,8 +1111,8 @@ static void __init pnv_power9_idle_init(void)
* compatibility.
*/
if ((state->flags & OPAL_PM_TIMEBASE_STOP) &&
- (pnv_first_spr_loss_level > psscr_rl))
- pnv_first_spr_loss_level = psscr_rl;
+ (pnv_first_fullstate_loss_level > psscr_rl))
+ pnv_first_fullstate_loss_level = psscr_rl;
err = validate_psscr_val_mask(&state->psscr_val,
&state->psscr_mask,
@@ -1158,7 +1158,7 @@ static void __init pnv_power9_idle_init(void)
}
pr_info("cpuidle-powernv: First stop level that may lose SPRs = 0x%llx\n",
- pnv_first_spr_loss_level);
+ pnv_first_fullstate_loss_level);
pr_info("cpuidle-powernv: First stop level that may lose timebase = 0x%llx\n",
pnv_first_tb_loss_level);
--
2.25.4
^ permalink raw reply related
* [PATCH v3 3/3] powerpc/powernv/idle: Exclude mfspr on HID1, 4, 5 on P9 and above
From: Pratik Rajesh Sampat @ 2020-07-17 18:53 UTC (permalink / raw)
To: mpe, npiggin, benh, paulus, mikey, ego, svaidy, psampat,
pratik.r.sampat, linuxppc-dev, linux-kernel
In-Reply-To: <20200717185306.60607-1-psampat@linux.ibm.com>
POWER9 onwards the support for the registers HID1, HID4, HID5 has been
receded.
Although mfspr on the above registers worked in Power9, In Power10
simulator is unrecognized. Moving their assignment under the
check for machines lower than Power9
Signed-off-by: Pratik Rajesh Sampat <psampat@linux.ibm.com>
Reviewed-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
---
arch/powerpc/platforms/powernv/idle.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/idle.c b/arch/powerpc/platforms/powernv/idle.c
index d439e11af101..d24d6671f3e8 100644
--- a/arch/powerpc/platforms/powernv/idle.c
+++ b/arch/powerpc/platforms/powernv/idle.c
@@ -73,9 +73,6 @@ static int pnv_save_sprs_for_deep_states(void)
*/
uint64_t lpcr_val = mfspr(SPRN_LPCR);
uint64_t hid0_val = mfspr(SPRN_HID0);
- uint64_t hid1_val = mfspr(SPRN_HID1);
- uint64_t hid4_val = mfspr(SPRN_HID4);
- uint64_t hid5_val = mfspr(SPRN_HID5);
uint64_t hmeer_val = mfspr(SPRN_HMEER);
uint64_t msr_val = MSR_IDLE;
uint64_t psscr_val = pnv_deepest_stop_psscr_val;
@@ -117,6 +114,9 @@ static int pnv_save_sprs_for_deep_states(void)
/* Only p8 needs to set extra HID regiters */
if (!pvr_version_is(PVR_POWER9)) {
+ uint64_t hid1_val = mfspr(SPRN_HID1);
+ uint64_t hid4_val = mfspr(SPRN_HID4);
+ uint64_t hid5_val = mfspr(SPRN_HID5);
rc = opal_slw_set_reg(pir, SPRN_HID1, hid1_val);
if (rc != 0)
--
2.25.4
^ permalink raw reply related
* Re: [PATCH v3 03/12] powerpc/kexec_file: add helper functions for getting memory ranges
From: Hari Bathini @ 2020-07-17 20:00 UTC (permalink / raw)
To: Thiago Jung Bauermann
Cc: Pingfan Liu, Petr Tesarik, Nayna Jain, Kexec-ml,
Mahesh J Salgaonkar, Mimi Zohar, lkml, linuxppc-dev, Sourabh Jain,
Andrew Morton, Dave Young, Vivek Goyal, Eric Biederman
In-Reply-To: <0684ed3d-0dde-8dce-f12c-72ef86bc91f9@linux.ibm.com>
On 17/07/20 10:02 am, Hari Bathini wrote:
>
>
> On 15/07/20 5:19 am, Thiago Jung Bauermann wrote:
>>
>> Hello Hari,
>>
>> Hari Bathini <hbathini@linux.ibm.com> writes:
>>
>>> In kexec case, the kernel to be loaded uses the same memory layout as
>>> the running kernel. So, passing on the DT of the running kernel would
>>> be good enough.
>>>
>>> But in case of kdump, different memory ranges are needed to manage
>>> loading the kdump kernel, booting into it and exporting the elfcore
>>> of the crashing kernel. The ranges are exlude memory ranges, usable
>>
>> s/exlude/exclude/
>>
>>> memory ranges, reserved memory ranges and crash memory ranges.
>>>
>>> Exclude memory ranges specify the list of memory ranges to avoid while
>>> loading kdump segments. Usable memory ranges list the memory ranges
>>> that could be used for booting kdump kernel. Reserved memory ranges
>>> list the memory regions for the loading kernel's reserve map. Crash
>>> memory ranges list the memory ranges to be exported as the crashing
>>> kernel's elfcore.
>>>
>>> Add helper functions for setting up the above mentioned memory ranges.
>>> This helpers facilitate in understanding the subsequent changes better
>>> and make it easy to setup the different memory ranges listed above, as
>>> and when appropriate.
>>>
>>> Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
>>> Tested-by: Pingfan Liu <piliu@redhat.com>
>>
>
> <snip>
>
>>> +/**
>>> + * add_reserved_ranges - Adds "/reserved-ranges" regions exported by f/w
>>> + * to the given memory ranges list.
>>> + * @mem_ranges: Range list to add the memory ranges to.
>>> + *
>>> + * Returns 0 on success, negative errno on error.
>>> + */
>>> +int add_reserved_ranges(struct crash_mem **mem_ranges)
>>> +{
>>> + int i, len, ret = 0;
>>> + const __be32 *prop;
>>> +
>>> + prop = of_get_property(of_root, "reserved-ranges", &len);
>>> + if (!prop)
>>> + return 0;
>>> +
>>> + /*
>>> + * Each reserved range is an (address,size) pair, 2 cells each,
>>> + * totalling 4 cells per range.
>>
>> Can you assume that, or do you need to check the #address-cells and
>> #size-cells properties of the root node?
>
> Taken from early_reserve_mem_dt() which did not seem to care.
> Should we be doing any different here?
On second thoughts, wouldn't hurt to be extra cautious. Will use
#address-cells & #size-cells to parse reserved-ranges.
Thanks
Hari
^ permalink raw reply
* Re: [PATCH] powerpc/boot: Use address-of operator on section symbols
From: Geert Uytterhoeven @ 2020-07-18 7:50 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Arnd Bergmann, Geoff Levand, Linux Kernel Mailing List,
clang-built-linux, Paul Mackerras, Joel Stanley, linuxppc-dev
In-Reply-To: <20200624035920.835571-1-natechancellor@gmail.com>
Hi Nathan,
On Wed, Jun 24, 2020 at 6:02 AM Nathan Chancellor
<natechancellor@gmail.com> wrote:
> arch/powerpc/boot/main.c:107:18: warning: array comparison always
> evaluates to a constant [-Wtautological-compare]
> if (_initrd_end > _initrd_start) {
> ^
> arch/powerpc/boot/main.c:155:20: warning: array comparison always
> evaluates to a constant [-Wtautological-compare]
> if (_esm_blob_end <= _esm_blob_start)
> ^
> 2 warnings generated.
>
> These are not true arrays, they are linker defined symbols, which are
> just addresses. Using the address of operator silences the warning
> and does not change the resulting assembly with either clang/ld.lld
> or gcc/ld (tested with diff + objdump -Dr).
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/212
> Reported-by: Joel Stanley <joel@jms.id.au>
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> arch/powerpc/boot/main.c | 4 ++--
> arch/powerpc/boot/ps3.c | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/boot/main.c b/arch/powerpc/boot/main.c
> index a9d209135975..cae31a6e8f02 100644
> --- a/arch/powerpc/boot/main.c
> +++ b/arch/powerpc/boot/main.c
> @@ -104,7 +104,7 @@ static struct addr_range prep_initrd(struct addr_range vmlinux, void *chosen,
> {
> /* If we have an image attached to us, it overrides anything
> * supplied by the loader. */
> - if (_initrd_end > _initrd_start) {
> + if (&_initrd_end > &_initrd_start) {
>
Are you sure that fix is correct?
extern char _initrd_start[];
extern char _initrd_end[];
extern char _esm_blob_start[];
extern char _esm_blob_end[];
Of course the result of their comparison is a constant, as the addresses
are constant. If clangs warns about it, perhaps that warning should be moved
to W=1?
But adding "&" is not correct, according to C.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] powerpc/boot: Use address-of operator on section symbols
From: Arnd Bergmann @ 2020-07-18 9:13 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Geoff Levand, LKML, clang-built-linux, Paul Mackerras,
Joel Stanley, Nathan Chancellor, linuxppc-dev
In-Reply-To: <CAKwvOd=5nE6fkwp8iw0JqwQFp5KcUaC7RyEf2L6+tkbp9smsvg@mail.gmail.com>
On Thu, Jun 25, 2020 at 6:32 PM 'Nick Desaulniers' via Clang Built
Linux <clang-built-linux@googlegroups.com> wrote:
>
> On Wed, Jun 24, 2020 at 6:19 PM Geoff Levand <geoff@infradead.org> wrote:
> >
> > Hi Nathan,
> >
> > On 6/23/20 8:59 PM, Nathan Chancellor wrote:
> > > These are not true arrays, they are linker defined symbols, which are
> > > just addresses. Using the address of operator silences the warning
> > > and does not change the resulting assembly with either clang/ld.lld
> > > or gcc/ld (tested with diff + objdump -Dr).
> >
> > Thanks for your patch. I tested this patch applied to v5.8-rc2 on a
> > PS3 and it seems OK.
>
> PS3? Folks still have ones that can boot Linux? Those ****ers took
> my Yellow Dog Linux away from me; I enjoyed depositing that settlement
> check! Hopefully by now, folks have figured out how to roll back the
> system firmware?
I still have the PS3 from Hong Kong with original 1.5 (IIRC) firmware
that I demoed at LCA2006. Haven't booted it in at least 12 years, and
never used it for games or movies other than the free "Casino Royale"
they sent everyone.
Arnd
^ permalink raw reply
* [PATCH] HID: udraw-ps3: Replace HTTP links with HTTPS ones
From: Alexander A. Klimov @ 2020-07-18 10:33 UTC (permalink / raw)
To: hadess, jikos, benjamin.tissoires, mpe, benh, paulus, linux-input,
linuxppc-dev, linux-kernel
Cc: Alexander A. Klimov
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.
Deterministic algorithm:
For each file:
If not .svg:
For each line:
If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
Replace HTTP with HTTPS.
Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de>
---
Continuing my work started at 93431e0607e5.
See also: git log --oneline '--author=Alexander A. Klimov <grandmaster@al2klimov.de>' v5.7..master
If there are any URLs to be removed completely
or at least not (just) HTTPSified:
Just clearly say so and I'll *undo my change*.
See also: https://lkml.org/lkml/2020/6/27/64
If there are any valid, but yet not changed URLs:
See: https://lkml.org/lkml/2020/6/26/837
If you apply the patch, please let me know.
drivers/hid/hid-udraw-ps3.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/hid-udraw-ps3.c b/drivers/hid/hid-udraw-ps3.c
index b0fbd11aa0fc..b2e17ef2ea27 100644
--- a/drivers/hid/hid-udraw-ps3.c
+++ b/drivers/hid/hid-udraw-ps3.c
@@ -16,7 +16,7 @@ MODULE_LICENSE("GPL");
/*
* Protocol information from:
- * http://brandonw.net/udraw/
+ * https://brandonw.net/udraw/
* and the source code of:
* https://vvvv.org/contribution/udraw-hid
*/
--
2.27.0
^ permalink raw reply related
* [PATCH] powerpc: Replace HTTP links with HTTPS ones
From: Alexander A. Klimov @ 2020-07-18 10:39 UTC (permalink / raw)
To: mpe, benh, paulus, corbet, herbert, davem, leitao, nayna,
pfsmorigo, grandmaster, linuxppc-dev, linux-doc, linux-kernel,
linux-crypto
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.
Deterministic algorithm:
For each file:
If not .svg:
For each line:
If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
Replace HTTP with HTTPS.
Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de>
---
Continuing my work started at 93431e0607e5.
See also: git log --oneline '--author=Alexander A. Klimov <grandmaster@al2klimov.de>' v5.7..master
If there are any URLs to be removed completely
or at least not (just) HTTPSified:
Just clearly say so and I'll *undo my change*.
See also: https://lkml.org/lkml/2020/6/27/64
If there are any valid, but yet not changed URLs:
See: https://lkml.org/lkml/2020/6/26/837
If you apply the patch, please let me know.
Documentation/powerpc/mpc52xx.rst | 2 +-
arch/powerpc/crypto/crc32-vpmsum_core.S | 2 +-
arch/powerpc/include/asm/hydra.h | 2 +-
drivers/crypto/vmx/aesp8-ppc.pl | 2 +-
drivers/crypto/vmx/ghashp8-ppc.pl | 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/powerpc/mpc52xx.rst b/Documentation/powerpc/mpc52xx.rst
index 8676ac63e077..30260707c3fe 100644
--- a/Documentation/powerpc/mpc52xx.rst
+++ b/Documentation/powerpc/mpc52xx.rst
@@ -2,7 +2,7 @@
Linux 2.6.x on MPC52xx family
=============================
-For the latest info, go to http://www.246tNt.com/mpc52xx/
+For the latest info, go to https://www.246tNt.com/mpc52xx/
To compile/use :
diff --git a/arch/powerpc/crypto/crc32-vpmsum_core.S b/arch/powerpc/crypto/crc32-vpmsum_core.S
index c3524eba4d0d..a16a717c809c 100644
--- a/arch/powerpc/crypto/crc32-vpmsum_core.S
+++ b/arch/powerpc/crypto/crc32-vpmsum_core.S
@@ -19,7 +19,7 @@
* We then use fixed point Barrett reduction to compute a mod n over GF(2)
* for n = CRC using POWER8 instructions. We use x = 32.
*
- * http://en.wikipedia.org/wiki/Barrett_reduction
+ * https://en.wikipedia.org/wiki/Barrett_reduction
*
* Copyright (C) 2015 Anton Blanchard <anton@au.ibm.com>, IBM
*/
diff --git a/arch/powerpc/include/asm/hydra.h b/arch/powerpc/include/asm/hydra.h
index b3b0f2d020f0..ae02eb53d6ef 100644
--- a/arch/powerpc/include/asm/hydra.h
+++ b/arch/powerpc/include/asm/hydra.h
@@ -10,7 +10,7 @@
*
* © Copyright 1995 Apple Computer, Inc. All rights reserved.
*
- * It's available online from http://www.cpu.lu/~mlan/ftp/MacTech.pdf
+ * It's available online from https://www.cpu.lu/~mlan/ftp/MacTech.pdf
* You can obtain paper copies of this book from computer bookstores or by
* writing Morgan Kaufmann Publishers, Inc., 340 Pine Street, Sixth Floor, San
* Francisco, CA 94104. Reference ISBN 1-55860-393-X.
diff --git a/drivers/crypto/vmx/aesp8-ppc.pl b/drivers/crypto/vmx/aesp8-ppc.pl
index db874367b602..50a0a18f35da 100644
--- a/drivers/crypto/vmx/aesp8-ppc.pl
+++ b/drivers/crypto/vmx/aesp8-ppc.pl
@@ -50,7 +50,7 @@
# Written by Andy Polyakov <appro@openssl.org> for the OpenSSL
# project. The module is, however, dual licensed under OpenSSL and
# CRYPTOGAMS licenses depending on where you obtain it. For further
-# details see http://www.openssl.org/~appro/cryptogams/.
+# details see https://www.openssl.org/~appro/cryptogams/.
# ====================================================================
#
# This module implements support for AES instructions as per PowerISA
diff --git a/drivers/crypto/vmx/ghashp8-ppc.pl b/drivers/crypto/vmx/ghashp8-ppc.pl
index 38b06503ede0..09bba1852eec 100644
--- a/drivers/crypto/vmx/ghashp8-ppc.pl
+++ b/drivers/crypto/vmx/ghashp8-ppc.pl
@@ -13,7 +13,7 @@
# Written by Andy Polyakov <appro@openssl.org> for the OpenSSL
# project. The module is, however, dual licensed under OpenSSL and
# CRYPTOGAMS licenses depending on where you obtain it. For further
-# details see http://www.openssl.org/~appro/cryptogams/.
+# details see https://www.openssl.org/~appro/cryptogams/.
# ====================================================================
#
# GHASH for for PowerISA v2.07.
--
2.27.0
^ permalink raw reply related
* Re: [PATCH] HID: udraw-ps3: Replace HTTP links with HTTPS ones
From: Bastien Nocera @ 2020-07-18 10:38 UTC (permalink / raw)
To: Alexander A. Klimov, jikos, benjamin.tissoires, mpe, benh, paulus,
linux-input, linuxppc-dev, linux-kernel
In-Reply-To: <20200718103344.3407-1-grandmaster@al2klimov.de>
On Sat, 2020-07-18 at 12:33 +0200, Alexander A. Klimov wrote:
> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM
> as HTTPS traffic is much harder to manipulate.
>
> Deterministic algorithm:
> For each file:
> If not .svg:
> For each line:
> If doesn't contain `\bxmlns\b`:
> For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
> If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
> If both the HTTP and HTTPS versions
> return 200 OK and serve the same content:
> Replace HTTP with HTTPS.
>
> Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de>
Looks good!
Acked-by: Bastien Nocera <hadess@hadess.net>
^ permalink raw reply
* [PATCH] ASoC: fsl: Replace HTTP links with HTTPS ones
From: Alexander A. Klimov @ 2020-07-18 11:12 UTC (permalink / raw)
To: timur, nicoleotsuka, Xiubo.Lee, festevam, lgirdwood, broonie,
perex, tiwai, shawnguo, s.hauer, kernel, linux-imx, alsa-devel,
linuxppc-dev, linux-arm-kernel, linux-kernel
Cc: Alexander A. Klimov
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.
Deterministic algorithm:
For each file:
If not .svg:
For each line:
If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
Replace HTTP with HTTPS.
Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de>
---
Continuing my work started at 93431e0607e5.
See also: git log --oneline '--author=Alexander A. Klimov <grandmaster@al2klimov.de>' v5.7..master
If there are any URLs to be removed completely
or at least not (just) HTTPSified:
Just clearly say so and I'll *undo my change*.
See also: https://lkml.org/lkml/2020/6/27/64
If there are any valid, but yet not changed URLs:
See: https://lkml.org/lkml/2020/6/26/837
If you apply the patch, please let me know.
sound/soc/fsl/imx-audmix.c | 4 ++--
sound/soc/fsl/imx-audmux.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/sound/soc/fsl/imx-audmix.c b/sound/soc/fsl/imx-audmix.c
index e09b45de0efd..96980cb0497f 100644
--- a/sound/soc/fsl/imx-audmix.c
+++ b/sound/soc/fsl/imx-audmix.c
@@ -6,8 +6,8 @@
* License. You may obtain a copy of the GNU General Public License
* Version 2 or later at the following locations:
*
- * http://www.opensource.org/licenses/gpl-license.html
- * http://www.gnu.org/copyleft/gpl.html
+ * https://www.opensource.org/licenses/gpl-license.html
+ * https://www.gnu.org/copyleft/gpl.html
*/
#include <linux/module.h>
diff --git a/sound/soc/fsl/imx-audmux.c b/sound/soc/fsl/imx-audmux.c
index 3ce85a43e08f..25c18b9e348f 100644
--- a/sound/soc/fsl/imx-audmux.c
+++ b/sound/soc/fsl/imx-audmux.c
@@ -5,7 +5,7 @@
// Copyright 2009 Pengutronix, Sascha Hauer <s.hauer@pengutronix.de>
//
// Initial development of this code was funded by
-// Phytec Messtechnik GmbH, http://www.phytec.de
+// Phytec Messtechnik GmbH, https://www.phytec.de
#include <linux/clk.h>
#include <linux/debugfs.h>
--
2.27.0
^ permalink raw reply related
* Re: [PATCH v3 0/3] Off-load TLB invalidations to host for !GTSE
From: Michael Ellerman @ 2020-07-18 12:40 UTC (permalink / raw)
To: bharata, Nicholas Piggin
Cc: sfr, aneesh.kumar, linux-kernel, linux-next, Qian Cai,
linuxppc-dev
In-Reply-To: <20200717042854.GL7902@in.ibm.com>
Bharata B Rao <bharata@linux.ibm.com> writes:
> On Fri, Jul 17, 2020 at 12:44:00PM +1000, Nicholas Piggin wrote:
>> Excerpts from Nicholas Piggin's message of July 17, 2020 12:08 pm:
>> > Excerpts from Qian Cai's message of July 17, 2020 3:27 am:
>> >> On Fri, Jul 03, 2020 at 11:06:05AM +0530, Bharata B Rao wrote:
>> >>> Hypervisor may choose not to enable Guest Translation Shootdown Enable
>> >>> (GTSE) option for the guest. When GTSE isn't ON, the guest OS isn't
>> >>> permitted to use instructions like tblie and tlbsync directly, but is
>> >>> expected to make hypervisor calls to get the TLB flushed.
>> >>>
>> >>> This series enables the TLB flush routines in the radix code to
>> >>> off-load TLB flushing to hypervisor via the newly proposed hcall
>> >>> H_RPT_INVALIDATE.
>> >>>
>> >>> To easily check the availability of GTSE, it is made an MMU feature.
>> >>> The OV5 handling and H_REGISTER_PROC_TBL hcall are changed to
>> >>> handle GTSE as an optionally available feature and to not assume GTSE
>> >>> when radix support is available.
>> >>>
>> >>> The actual hcall implementation for KVM isn't included in this
>> >>> patchset and will be posted separately.
>> >>>
>> >>> Changes in v3
>> >>> =============
>> >>> - Fixed a bug in the hcall wrapper code where we were missing setting
>> >>> H_RPTI_TYPE_NESTED while retrying the failed flush request with
>> >>> a full flush for the nested case.
>> >>> - s/psize_to_h_rpti/psize_to_rpti_pgsize
>> >>>
>> >>> v2: https://lore.kernel.org/linuxppc-dev/20200626131000.5207-1-bharata@linux.ibm.com/T/#t
>> >>>
>> >>> Bharata B Rao (2):
>> >>> powerpc/mm: Enable radix GTSE only if supported.
>> >>> powerpc/pseries: H_REGISTER_PROC_TBL should ask for GTSE only if
>> >>> enabled
>> >>>
>> >>> Nicholas Piggin (1):
>> >>> powerpc/mm/book3s64/radix: Off-load TLB invalidations to host when
>> >>> !GTSE
>> >>
>> >> Reverting the whole series fixed random memory corruptions during boot on
>> >> POWER9 PowerNV systems below.
>> >
>> > If I s/mmu_has_feature(MMU_FTR_GTSE)/(1)/g in radix_tlb.c, then the .o
>> > disasm is the same as reverting my patch.
>> >
>> > Feature bits not being set right? PowerNV should be pretty simple, seems
>> > to do the same as FTR_TYPE_RADIX.
>>
>> Might need this fix
>>
>> ---
>>
>> diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
>> index 9cc49f265c86..54c9bcea9d4e 100644
>> --- a/arch/powerpc/kernel/prom.c
>> +++ b/arch/powerpc/kernel/prom.c
>> @@ -163,7 +163,7 @@ static struct ibm_pa_feature {
>> { .pabyte = 0, .pabit = 6, .cpu_features = CPU_FTR_NOEXECUTE },
>> { .pabyte = 1, .pabit = 2, .mmu_features = MMU_FTR_CI_LARGE_PAGE },
>> #ifdef CONFIG_PPC_RADIX_MMU
>> - { .pabyte = 40, .pabit = 0, .mmu_features = MMU_FTR_TYPE_RADIX },
>> + { .pabyte = 40, .pabit = 0, .mmu_features = (MMU_FTR_TYPE_RADIX | MMU_FTR_GTSE) },
>> #endif
>> { .pabyte = 1, .pabit = 1, .invert = 1, .cpu_features = CPU_FTR_NODSISRALIGN },
>> { .pabyte = 5, .pabit = 0, .cpu_features = CPU_FTR_REAL_LE,
>
> Michael - Let me know if this should be folded into 1/3 and the complete
> series resent.
No it's already merged.
Please send a proper patch with a Fixes: tag and a change log that
explains the details.
cheers
^ 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