* Re: [RFC 00/11] perf: Enhancing perf to export processor hazard information
From: Peter Zijlstra @ 2020-03-02 10:13 UTC (permalink / raw)
To: Ravi Bangoria
Cc: mark.rutland, ak, maddy, alexander.shishkin, jolsa, linux-kernel,
eranian, adrian.hunter, robert.richter, yao.jin, mingo, paulus,
acme, namhyung, kim.phillips, linuxppc-dev, alexey.budankov,
kan.liang
In-Reply-To: <20200302052355.36365-1-ravi.bangoria@linux.ibm.com>
On Mon, Mar 02, 2020 at 10:53:44AM +0530, Ravi Bangoria wrote:
> Modern processors export such hazard data in Performance
> Monitoring Unit (PMU) registers. Ex, 'Sampled Instruction Event
> Register' on IBM PowerPC[1][2] and 'Instruction-Based Sampling' on
> AMD[3] provides similar information.
>
> Implementation detail:
>
> A new sample_type called PERF_SAMPLE_PIPELINE_HAZ is introduced.
> If it's set, kernel converts arch specific hazard information
> into generic format:
>
> struct perf_pipeline_haz_data {
> /* Instruction/Opcode type: Load, Store, Branch .... */
> __u8 itype;
> /* Instruction Cache source */
> __u8 icache;
> /* Instruction suffered hazard in pipeline stage */
> __u8 hazard_stage;
> /* Hazard reason */
> __u8 hazard_reason;
> /* Instruction suffered stall in pipeline stage */
> __u8 stall_stage;
> /* Stall reason */
> __u8 stall_reason;
> __u16 pad;
> };
Kim, does this format indeed work for AMD IBS?
^ permalink raw reply
* Re: [PATCH v18 00/24] selftests, powerpc, x86: Memory Protection Keys
From: Sandipan Das @ 2020-03-02 10:25 UTC (permalink / raw)
To: shuah, skhan
Cc: linux-arch, fweimer, linux-mm, aneesh.kumar, x86, linuxram,
mhocko, Dave Hansen, mingo, linux-kselftest, akpm, msuchanek,
linuxppc-dev, bauerman
In-Reply-To: <5887a858-b669-752e-b65e-ed7d7ded34aa@intel.com>
Hi Shuah,
On 31/01/20 3:21 am, Dave Hansen wrote:
> On 1/29/20 10:36 PM, Sandipan Das wrote:
>> v18:
>> (1) Fixed issues with x86 multilib builds based on
>> feedback from Dave.
>> (2) Moved patch 2 to the end of the series.
>
> These (finally) build and run successfully for me on an x86 system with
> protection keys. Feel free to add my Tested-by, and Acked-by.
>
> FWIW, I don't think look perfect, but my standards are lower for
> selftests/ than normal kernel code. :)
>
Any updates on considering this for merging?
- Sandipan
^ permalink raw reply
* RE: [PATCH net-next 00/23] Clean driver, module and FW versions
From: Madalin Bucur (OSS) @ 2020-03-02 10:44 UTC (permalink / raw)
To: Leon Romanovsky, David S . Miller, Jakub Kicinski
Cc: Ajit Khaparde, Denis Kirjanov, Prashant Sreedharan,
Govindarajulu Varadarajan, Somnath Kotur, Vishal Kulkarni,
GR-everest-linux-l2@marvell.com, Casey Leedom, Doug Berger,
bcm-kernel-feedback-list@broadcom.com, Linus Walleij,
Sunil Goutham, Parvi Kaustubhi, Ariel Elior, Hans Ulli Kroll,
Satanand Burla, Felix Manlunas, Leon Romanovsky, Claudiu Manoil,
Florian Fainelli, Sathya Perla, Michael Chan,
linux-arm-kernel@lists.infradead.org, Raghu Vatsavayi,
GR-Linux-NIC-Dev@marvell.com, Andy Duan, Sriharsha Basavapatna,
linux-parisc@vger.kernel.org, Siva Reddy Kallam, Rasesh Mody,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Leo Li,
Hartley Sweeten, Robert Richter, Derek Chickles,
linuxppc-dev@lists.ozlabs.org, Sudarsana Kalluru,
Christian Benvenuti
In-Reply-To: <20200301144457.119795-1-leon@kernel.org>
> -----Original Message-----
> From: David Miller <davem@davemloft.net>
> Sent: Monday, March 2, 2020 5:02 AM
> To: leon@kernel.org
> Subject: Re: [PATCH net-next 00/23] Clean driver, module and FW versions
>
> From: Leon Romanovsky <leon@kernel.org>
> Date: Sun, 1 Mar 2020 16:44:33 +0200
>
> > This is second batch of the series which removes various static
> > versions in favour of globaly defined Linux kernel version.
>
> This generally looks fine to me but I'll let it sit for a few days so
> that others can review.
Reviewed drivers/net/ethernet/freescale changes, thank you!
Reviewed-by: Madalin Bucur <madalin.bucur@oss.nxp.com>
^ permalink raw reply
* Re: [GIT PULL] Second batch of KVM changes for Linux 5.6-rc4 (or rc5)
From: Michael Ellerman @ 2020-03-02 10:51 UTC (permalink / raw)
To: Linus Torvalds, Paolo Bonzini
Cc: Masahiro Yamada, linuxppc-dev, Linux Kernel Mailing List,
KVM list
In-Reply-To: <CAHk-=wiin_LkqP2Cm5iPc5snUXYqZVoMFawZ-rjhZnawven8SA@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Sun, Mar 1, 2020 at 1:03 PM Paolo Bonzini <pbonzini@redhat.com> wrote:
>>
>> Paolo Bonzini (4):
>> KVM: allow disabling -Werror
>
> Honestly, this is just badly done.
>
> You've basically made it enable -Werror only for very random
> configurations - and apparently the one you test.
>
> Doing things like COMPILE_TEST disables it, but so does not having
> EXPERT enabled.
>
> So it looks entirely ad-hoc and makes very little sense. At least the
> "with KASAN, disable this" part makes sense, since that's a known
> source or warnings. But everything else looks very random.
>
> I've merged this, but I wonder why you couldn't just do what I
> suggested originally?
>
> Seriously, if you script your build tests, and don't even look at the
> results, then you might as well use
>
> make KCFLAGS=-Werror
>
> instead of having this kind of completely random option that has
> almost no logic to it at all.
>
> And if you depend entirely on random build infrastructure like the
> 0day bot etc, this likely _is_ going to break when it starts using a
> new gcc version, or when it starts testing using clang, or whatever.
> So then we end up with another odd random situation where now kvm (and
> only kvm) will fail those builds just because they are automated.
>
> Yes, as I said in that original thread, I'd love to do -Werror in
> general, at which point it wouldn't be some random ad-hoc kvm special
> case for some random option. But the "now it causes problems for
> random compiler versions" is a real issue again - but at least it
> wouldn't be a random kernel subsystem that happens to trigger it, it
> would be a _generic_ issue, and we'd have everybody involved when a
> compiler change introduces a new warning.
>
> I've pulled this for now, but I really think it's a horrible hack, and
> it's just done entirely wrong.
>
> Adding the powerpc people, since they have more history with their
> somewhat less hacky one. Except that one automatically gets disabled
> by "make allmodconfig" and friends, which is also kind of pointless.
>
> Michael, what tends to be the triggers for people using
> PPC_DISABLE_WERROR? Do you have reports for it?
My memory is that we have had very few reports of it actually causing
problems. But I don't have hard data to back that up.
It has tripped up the Clang folks, but that's partly because they're
building clang HEAD, and also because ~zero powerpc kernel developers
are building regularly with clang. I'm trying to fix the latter ...
The thing that makes me disable -Werror (enable PPC_DISABLE_WERROR) most
often is bisecting back to before fixes for my current compiler were
merged.
For example with GCC 8 if you go back before ~4.18 you hit the warning
fixed by bee20031772a ("disable -Wattribute-alias warning for
SYSCALL_DEFINEx()").
And then building with GCC head sometimes requires disabling -Werror
because of some new warning, sometimes valid sometimes not.
I think we could mostly avoid those problems by having the option only
on by default for known compiler versions.
eg:
config WERROR
bool "Build with -Werror"
default CC_IS_GCC && (GCC_VERSION >= 70000 && GCC_VERSION <= 90000)
And we could bump the upper version up once each new GCC version has had
any problems ironed out.
> Could we have a _generic_ option that just gets enabled by default,
> except it gets disabled by _known_ issues (like KASAN).
Right now I don't think we could have a generic option that's enabled by
default, there's too many warnings floating around on minor arches and
in odd configurations.
But we could have a generic option that signifies the desire to build
with -Werror where possible, and then each arch/subsystem/etc could use
that config option to enable -Werror in stages.
Then after a release or three we could change the option to globally
enable -Werror and opt-out any areas that are still problematic.
It's also possible to use -Wno-error to turn certain warnings back into
warnings even when -Werror is set, so that's another way we could
incrementally attack the problem.
It'd also be nice if we could do:
$ make WERROR=0
Or something similarly obvious to turn off the WERROR option. That way
users don't even have to edit their .config manually, they just rerun
make with WERROR=0 and it works.
> Being disabled for "make allmodconfig" is kind of against one of the
> _points_ of "the build should be warning-free".
True, it was just the conservative choice to disable it for allmod/yes.
We should probably revisit that these days.
cheers
^ permalink raw reply
* eh_frame confusion
From: Rasmus Villemoes @ 2020-03-02 10:56 UTC (permalink / raw)
To: LKML, Linux Kbuild mailing list, linuxppc-dev@lists.ozlabs.org
I'm building a ppc32 kernel, and noticed that after upgrading from gcc-7
to gcc-8 all object files now end up having .eh_frame section. For
vmlinux, that's not a problem, because they all get discarded in
arch/powerpc/kernel/vmlinux.lds.S . However, they stick around in
modules, which doesn't seem to be useful - given that everything worked
just fine with gcc-7, and I don't see anything in the module loader that
handles .eh_frame.
The reason I care is that my target has a rather tight rootfs budget,
and the .eh_frame section seem to occupy 10-30% of the file size
(obviously very depending on the particular module).
Comparing the .foo.o.cmd files, I don't see change in options that might
explain this (there's a bunch of new -Wno-*, and the -mspe=no spelling
is apparently no longer supported in gcc-8). Both before and after, there's
-fno-dwarf2-cfi-asm
about which gcc's documentation says
'-fno-dwarf2-cfi-asm'
Emit DWARF unwind info as compiler generated '.eh_frame' section
instead of using GAS '.cfi_*' directives.
Looking into where that comes from got me even more confused, because
both arm and unicore32 say
# Never generate .eh_frame
KBUILD_CFLAGS += $(call cc-option,-fno-dwarf2-cfi-asm)
while the ppc32 case at hand says
# FIXME: the module load should be taught about the additional relocs
# generated by this.
# revert to pre-gcc-4.4 behaviour of .eh_frame
but prior to gcc-8, .eh_frame didn't seem to get generated anyway.
Can .eh_frame sections be discarded for modules (on ppc32 at least), or
is there some magic that makes them necessary when building with gcc-8?
Rasmus
^ permalink raw reply
* Re: [PATCH v3 1/5] mm/memremap_pages: Introduce memremap_compat_align()
From: Aneesh Kumar K.V @ 2020-03-02 12:01 UTC (permalink / raw)
To: Dan Williams, linux-nvdimm; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <158291747142.1609624.18276461572536139551.stgit@dwillia2-desk3.amr.corp.intel.com>
Dan Williams <dan.j.williams@intel.com> writes:
> The "sub-section memory hotplug" facility allows memremap_pages() users
> like libnvdimm to compensate for hardware platforms like x86 that have a
> section size larger than their hardware memory mapping granularity. The
> compensation that sub-section support affords is being tolerant of
> physical memory resources shifting by units smaller (64MiB on x86) than
> the memory-hotplug section size (128 MiB). Where the platform
> physical-memory mapping granularity is limited by the number and
> capability of address-decode-registers in the memory controller.
>
> While the sub-section support allows memremap_pages() to operate on
> sub-section (2MiB) granularity, the Power architecture may still
> require 16MiB alignment on "!radix_enabled()" platforms.
>
> In order for libnvdimm to be able to detect and manage this per-arch
> limitation, introduce memremap_compat_align() as a common minimum
> alignment across all driver-facing memory-mapping interfaces, and let
> Power override it to 16MiB in the "!radix_enabled()" case.
>
> The assumption / requirement for 16MiB to be a viable
> memremap_compat_align() value is that Power does not have platforms
> where its equivalent of address-decode-registers never hardware remaps a
> persistent memory resource on smaller than 16MiB boundaries. Note that I
> tried my best to not add a new Kconfig symbol, but header include
> entanglements defeated the #ifndef memremap_compat_align design pattern
> and the need to export it defeats the __weak design pattern for arch
> overrides.
>
> Based on an initial patch by Aneesh.
>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> Link: http://lore.kernel.org/r/CAPcyv4gBGNP95APYaBcsocEa50tQj9b5h__83vgngjq3ouGX_Q@mail.gmail.com
> Reported-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> Reported-by: Jeff Moyer <jmoyer@redhat.com>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> ---
> arch/powerpc/Kconfig | 1 +
> arch/powerpc/mm/ioremap.c | 21 +++++++++++++++++++++
> drivers/nvdimm/pfn_devs.c | 2 +-
> include/linux/memremap.h | 8 ++++++++
> include/linux/mmzone.h | 1 +
> lib/Kconfig | 3 +++
> mm/memremap.c | 23 +++++++++++++++++++++++
> 7 files changed, 58 insertions(+), 1 deletion(-)
>
^ permalink raw reply
* Re: [PATCH v3 2/5] libnvdimm/pfn: Prevent raw mode fallback if pfn-infoblock valid
From: Aneesh Kumar K.V @ 2020-03-02 12:02 UTC (permalink / raw)
To: Dan Williams, linux-nvdimm; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <158291747661.1609624.13504407869218712107.stgit@dwillia2-desk3.amr.corp.intel.com>
Dan Williams <dan.j.williams@intel.com> writes:
> The EOPNOTSUPP return code from the pmem driver indicates that the
> namespace has a configuration that may be valid, but the current kernel
> does not support it. Expand this to all of the nd_pfn_validate() error
> conditions after the infoblock has been verified as self consistent.
>
> This prevents exposing the namespace to I/O when the infoblock needs to
> be corrected, or the system needs to be put into a different
> configuration (like changing the page size on PowerPC).
>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> Cc: Jeff Moyer <jmoyer@redhat.com>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> ---
> drivers/nvdimm/pfn_devs.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/nvdimm/pfn_devs.c b/drivers/nvdimm/pfn_devs.c
> index a5c25cb87116..79fe02d6f657 100644
> --- a/drivers/nvdimm/pfn_devs.c
> +++ b/drivers/nvdimm/pfn_devs.c
> @@ -561,14 +561,14 @@ int nd_pfn_validate(struct nd_pfn *nd_pfn, const char *sig)
> dev_dbg(&nd_pfn->dev, "align: %lx:%lx mode: %d:%d\n",
> nd_pfn->align, align, nd_pfn->mode,
> mode);
> - return -EINVAL;
> + return -EOPNOTSUPP;
> }
> }
>
> if (align > nvdimm_namespace_capacity(ndns)) {
> dev_err(&nd_pfn->dev, "alignment: %lx exceeds capacity %llx\n",
> align, nvdimm_namespace_capacity(ndns));
> - return -EINVAL;
> + return -EOPNOTSUPP;
> }
>
> /*
> @@ -581,7 +581,7 @@ int nd_pfn_validate(struct nd_pfn *nd_pfn, const char *sig)
> if (offset >= resource_size(&nsio->res)) {
> dev_err(&nd_pfn->dev, "pfn array size exceeds capacity of %s\n",
> dev_name(&ndns->dev));
> - return -EBUSY;
> + return -EOPNOTSUPP;
> }
>
> if ((align && !IS_ALIGNED(nsio->res.start + offset + start_pad, align))
> @@ -589,7 +589,7 @@ int nd_pfn_validate(struct nd_pfn *nd_pfn, const char *sig)
> dev_err(&nd_pfn->dev,
> "bad offset: %#llx dax disabled align: %#lx\n",
> offset, align);
> - return -ENXIO;
> + return -EOPNOTSUPP;
> }
>
> return 0;
> _______________________________________________
> Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
> To unsubscribe send an email to linux-nvdimm-leave@lists.01.org
^ permalink raw reply
* Re: [PATCH v3 3/5] libnvdimm/namespace: Enforce memremap_compat_align()
From: Aneesh Kumar K.V @ 2020-03-02 12:08 UTC (permalink / raw)
To: Dan Williams, linux-nvdimm; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <158291748226.1609624.8971922874557923784.stgit@dwillia2-desk3.amr.corp.intel.com>
Dan Williams <dan.j.williams@intel.com> writes:
> The pmem driver on PowerPC crashes with the following signature when
> instantiating misaligned namespaces that map their capacity via
> memremap_pages().
>
> BUG: Unable to handle kernel data access at 0xc001000406000000
> Faulting instruction address: 0xc000000000090790
> NIP [c000000000090790] arch_add_memory+0xc0/0x130
> LR [c000000000090744] arch_add_memory+0x74/0x130
> Call Trace:
> arch_add_memory+0x74/0x130 (unreliable)
> memremap_pages+0x74c/0xa30
> devm_memremap_pages+0x3c/0xa0
> pmem_attach_disk+0x188/0x770
> nvdimm_bus_probe+0xd8/0x470
>
> With the assumption that only memremap_pages() has alignment
> constraints, enforce memremap_compat_align() for
> pmem_should_map_pages(), nd_pfn, and nd_dax cases. This includes
> preventing the creation of namespaces where the base address is
> misaligned and cases there infoblock padding parameters are invalid.
>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> Reported-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> Cc: Jeff Moyer <jmoyer@redhat.com>
> Fixes: a3619190d62e ("libnvdimm/pfn: stop padding pmem namespaces to section alignment")
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> ---
> drivers/nvdimm/namespace_devs.c | 12 ++++++++++++
> drivers/nvdimm/pfn_devs.c | 26 +++++++++++++++++++++++---
> 2 files changed, 35 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/nvdimm/namespace_devs.c b/drivers/nvdimm/namespace_devs.c
> index 032dc61725ff..68e89855f779 100644
> --- a/drivers/nvdimm/namespace_devs.c
> +++ b/drivers/nvdimm/namespace_devs.c
> @@ -10,6 +10,7 @@
> #include <linux/nd.h>
> #include "nd-core.h"
> #include "pmem.h"
> +#include "pfn.h"
> #include "nd.h"
>
> static void namespace_io_release(struct device *dev)
> @@ -1739,6 +1740,17 @@ struct nd_namespace_common *nvdimm_namespace_common_probe(struct device *dev)
> return ERR_PTR(-ENODEV);
> }
May be add a comment here that both dax/fsdax namespace details are
checked in nd_pfn_validate() so that we look at start_pad and end_trunc
while validating the namespace?
>
> + if (pmem_should_map_pages(dev)) {
> + struct nd_namespace_io *nsio = to_nd_namespace_io(&ndns->dev);
> + struct resource *res = &nsio->res;
> +
> + if (!IS_ALIGNED(res->start | (res->end + 1),
> + memremap_compat_align())) {
> + dev_err(&ndns->dev, "%pr misaligned, unable to map\n", res);
> + return ERR_PTR(-EOPNOTSUPP);
> + }
> + }
> +
> if (is_namespace_pmem(&ndns->dev)) {
> struct nd_namespace_pmem *nspm;
>
> diff --git a/drivers/nvdimm/pfn_devs.c b/drivers/nvdimm/pfn_devs.c
> index 79fe02d6f657..3bdd4b883d05 100644
> --- a/drivers/nvdimm/pfn_devs.c
> +++ b/drivers/nvdimm/pfn_devs.c
> @@ -446,6 +446,7 @@ static bool nd_supported_alignment(unsigned long align)
> int nd_pfn_validate(struct nd_pfn *nd_pfn, const char *sig)
> {
> u64 checksum, offset;
> + struct resource *res;
> enum nd_pfn_mode mode;
> struct nd_namespace_io *nsio;
> unsigned long align, start_pad;
> @@ -578,13 +579,14 @@ int nd_pfn_validate(struct nd_pfn *nd_pfn, const char *sig)
> * established.
> */
> nsio = to_nd_namespace_io(&ndns->dev);
> - if (offset >= resource_size(&nsio->res)) {
> + res = &nsio->res;
> + if (offset >= resource_size(res)) {
> dev_err(&nd_pfn->dev, "pfn array size exceeds capacity of %s\n",
> dev_name(&ndns->dev));
> return -EOPNOTSUPP;
> }
>
> - if ((align && !IS_ALIGNED(nsio->res.start + offset + start_pad, align))
> + if ((align && !IS_ALIGNED(res->start + offset + start_pad, align))
> || !IS_ALIGNED(offset, PAGE_SIZE)) {
> dev_err(&nd_pfn->dev,
> "bad offset: %#llx dax disabled align: %#lx\n",
> @@ -592,6 +594,18 @@ int nd_pfn_validate(struct nd_pfn *nd_pfn, const char *sig)
> return -EOPNOTSUPP;
> }
>
> + if (!IS_ALIGNED(res->start + le32_to_cpu(pfn_sb->start_pad),
> + memremap_compat_align())) {
> + dev_err(&nd_pfn->dev, "resource start misaligned\n");
> + return -EOPNOTSUPP;
> + }
> +
> + if (!IS_ALIGNED(res->end + 1 - le32_to_cpu(pfn_sb->end_trunc),
> + memremap_compat_align())) {
> + dev_err(&nd_pfn->dev, "resource end misaligned\n");
> + return -EOPNOTSUPP;
> + }
> +
> return 0;
> }
> EXPORT_SYMBOL(nd_pfn_validate);
> @@ -750,7 +764,13 @@ static int nd_pfn_init(struct nd_pfn *nd_pfn)
> start = nsio->res.start;
> size = resource_size(&nsio->res);
> npfns = PHYS_PFN(size - SZ_8K);
> - align = max(nd_pfn->align, SUBSECTION_SIZE);
> + align = max(nd_pfn->align, memremap_compat_align());
> + if (!IS_ALIGNED(start, memremap_compat_align())) {
> + dev_err(&nd_pfn->dev, "%s: start %pa misaligned to %#lx\n",
> + dev_name(&ndns->dev), &start,
> + memremap_compat_align());
> + return -EINVAL;
> + }
This validates start in case of a new namespace creation where the user
updated nd_region->align value? A comment there would help when looking
at the code later?
> end_trunc = start + size - ALIGN_DOWN(start + size, align);
> if (nd_pfn->mode == PFN_MODE_PMEM) {
> /*
> _______________________________________________
> Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
> To unsubscribe send an email to linux-nvdimm-leave@lists.01.org
^ permalink raw reply
* Re: [GIT PULL] Second batch of KVM changes for Linux 5.6-rc4 (or rc5)
From: Segher Boessenkool @ 2020-03-02 12:14 UTC (permalink / raw)
To: Michael Ellerman
Cc: KVM list, linuxppc-dev, Linux Kernel Mailing List,
Masahiro Yamada, Paolo Bonzini, Linus Torvalds
In-Reply-To: <87pndvrpvj.fsf@mpe.ellerman.id.au>
On Mon, Mar 02, 2020 at 09:51:44PM +1100, Michael Ellerman wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
> > Michael, what tends to be the triggers for people using
> > PPC_DISABLE_WERROR? Do you have reports for it?
>
> My memory is that we have had very few reports of it actually causing
> problems. But I don't have hard data to back that up.
I build all archs with GCC trunk.
It always breaks for me, with thousands of errors, which is why since
many years I carry 21 lines of patch to thoroughly disable -Werror for
the powerpc arch. It takes over a year from when a warning is added to
the kernel taking care of it -- and of course, I build with the current
development version of the compiler, so I get to see many misfiring
warnings and other fallout as well. (Currently there are more than 100
warnings, this is way too many to consider attacking that as well).
> It has tripped up the Clang folks, but that's partly because they're
> building clang HEAD, and also because ~zero powerpc kernel developers
> are building regularly with clang. I'm trying to fix the latter ...
Is anyone building regularly with GCC HEAD? Power or any other arch?
> And then building with GCC head sometimes requires disabling -Werror
> because of some new warning, sometimes valid sometimes not.
Yes. And never worth breaking the build for.
-Werror is something you use if you do not trust your developers.
Warnings are not errors. The compiler warns for things that
heuristically look suspicious. And it errors for things that are wrong.
Some warnings have many false positives, but are so useful (find many
nasty problems, for example) that it is worth enabling them often.
-Werror sabotages that, giving people an extra incentive to disable
useful warnings.
> I think we could mostly avoid those problems by having the option only
> on by default for known compiler versions.
Well, the kernel disables most useful warnings anyway, so that might
even work, sure.
> It'd also be nice if we could do:
>
> $ make WERROR=0
>
> Or something similarly obvious to turn off the WERROR option. That way
> users don't even have to edit their .config manually, they just rerun
> make with WERROR=0 and it works.
That would be nice, yes, that would help my situation as well.
Segher
^ permalink raw reply
* Re: eh_frame confusion
From: Segher Boessenkool @ 2020-03-02 12:44 UTC (permalink / raw)
To: Rasmus Villemoes
Cc: linuxppc-dev@lists.ozlabs.org, LKML, Linux Kbuild mailing list
In-Reply-To: <3b00b45f-74b5-13e3-9a98-c3d6b3bb7286@rasmusvillemoes.dk>
On Mon, Mar 02, 2020 at 11:56:05AM +0100, Rasmus Villemoes wrote:
> I'm building a ppc32 kernel, and noticed that after upgrading from gcc-7
> to gcc-8 all object files now end up having .eh_frame section.
Since GCC 8, we enable -fasynchronous-unwind-tables by default for
PowerPC. See https://gcc.gnu.org/r259298 .
> For
> vmlinux, that's not a problem, because they all get discarded in
> arch/powerpc/kernel/vmlinux.lds.S . However, they stick around in
> modules, which doesn't seem to be useful - given that everything worked
> just fine with gcc-7, and I don't see anything in the module loader that
> handles .eh_frame.
It is useful for debugging. Not many people debug the kernel like this,
of course.
Segher
^ permalink raw reply
* [Bug 199471] [Bisected][Regression] windfarm_pm* no longer gets automatically loaded when CONFIG_I2C_POWERMAC=y is set
From: bugzilla-daemon @ 2020-03-02 13:13 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-199471-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=199471
Wolfram Sang (wsa@the-dreams.de) changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |ASSIGNED
Regression|No |Yes
--- Comment #15 from Wolfram Sang (wsa@the-dreams.de) ---
"I guess so 'cause if I build i2c_powermac as a module and manually modprobe
it, all the relevant windfarm modules get pulled in. But not before."
Maybe there is a module dependency I overlooked so far, but at least there is
no code loading the pm72 module from i2c-powermac.
However, the bisect is very valuable and very likely the commit is the culprit.
I was suspecting something changed the MODINFO, so loading fails, but I missed
this commit, so far. Also, it took me two approaches until I understood all the
behaviour involved. Macintosh drivers are still confusing.
I will cook up a patch to test later today to see if I was right.
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [Bug 201723] [Bisected][Regression] THERM_WINDTUNNEL not working any longer in kernel 4.19.x (PowerMac G4 MDD)
From: bugzilla-daemon @ 2020-03-02 13:16 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-201723-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=201723
Wolfram Sang (wsa@the-dreams.de) changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |CODE_FIX
--- Comment #7 from Wolfram Sang (wsa@the-dreams.de) ---
Commited as 38b17afb0ebb ("macintosh: therm_windtunnel: fix regression when
instantiating devices") and available upstream since v5.6-rc4.
Thanks for everyone helping, especially Erhard, of course!
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* Re: [RFC 02/11] perf/core: Data structure to present hazard data
From: maddy @ 2020-03-02 14:23 UTC (permalink / raw)
To: Peter Zijlstra, Ravi Bangoria
Cc: mark.rutland, ak, alexander.shishkin, jolsa, Madhavan Srinivasan,
linux-kernel, eranian, adrian.hunter, robert.richter, yao.jin,
mingo, paulus, acme, namhyung, kim.phillips, linuxppc-dev,
alexey.budankov, kan.liang
In-Reply-To: <20200302095515.GR18400@hirez.programming.kicks-ass.net>
On 3/2/20 3:25 PM, Peter Zijlstra wrote:
> On Mon, Mar 02, 2020 at 10:53:46AM +0530, Ravi Bangoria wrote:
>> From: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
>>
>> Introduce new perf sample_type PERF_SAMPLE_PIPELINE_HAZ to request kernel
>> to provide cpu pipeline hazard data. Also, introduce arch independent
>> structure 'perf_pipeline_haz_data' to pass hazard data to userspace. This
>> is generic structure and arch specific data needs to be converted to this
>> format.
>>
>> Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
>> Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
>> ---
>> include/linux/perf_event.h | 7 ++++++
>> include/uapi/linux/perf_event.h | 32 ++++++++++++++++++++++++++-
>> kernel/events/core.c | 6 +++++
>> tools/include/uapi/linux/perf_event.h | 32 ++++++++++++++++++++++++++-
>> 4 files changed, 75 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
>> index 547773f5894e..d5b606e3c57d 100644
>> --- a/include/linux/perf_event.h
>> +++ b/include/linux/perf_event.h
>> @@ -1001,6 +1001,7 @@ struct perf_sample_data {
>> u64 stack_user_size;
>>
>> u64 phys_addr;
>> + struct perf_pipeline_haz_data pipeline_haz;
>> } ____cacheline_aligned;
>>
>> /* default value for data source */
>> @@ -1021,6 +1022,12 @@ static inline void perf_sample_data_init(struct perf_sample_data *data,
>> data->weight = 0;
>> data->data_src.val = PERF_MEM_NA;
>> data->txn = 0;
>> + data->pipeline_haz.itype = PERF_HAZ__ITYPE_NA;
>> + data->pipeline_haz.icache = PERF_HAZ__ICACHE_NA;
>> + data->pipeline_haz.hazard_stage = PERF_HAZ__PIPE_STAGE_NA;
>> + data->pipeline_haz.hazard_reason = PERF_HAZ__HREASON_NA;
>> + data->pipeline_haz.stall_stage = PERF_HAZ__PIPE_STAGE_NA;
>> + data->pipeline_haz.stall_reason = PERF_HAZ__SREASON_NA;
>> }
> NAK, Don't touch anything outside of the first cacheline here.
My bad, should have looked at the comment in "struct perf_sample_data {".
Will move it to perf_prepare_sample().
Thanks for comments.
Maddy
^ permalink raw reply
* [Bug 199471] [Bisected][Regression] windfarm_pm* no longer gets automatically loaded when CONFIG_I2C_POWERMAC=y is set
From: bugzilla-daemon @ 2020-03-02 14:48 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-199471-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=199471
--- Comment #16 from Wolfram Sang (wsa@the-dreams.de) ---
Created attachment 287755
--> https://bugzilla.kernel.org/attachment.cgi?id=287755&action=edit
proof-of-concept patch for testing
Here is the promised patch. I converted all I2C MODULE tables. pm72 didn't have
one, so we will see what pulls it in.
A test with a machine needing the lm75 driver would be great. Because some code
change was needed there.
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* Re: [RFC 02/11] perf/core: Data structure to present hazard data
From: Mark Rutland @ 2020-03-02 14:48 UTC (permalink / raw)
To: Ravi Bangoria
Cc: ak, maddy, peterz, jolsa, Madhavan Srinivasan, linux-kernel,
eranian, adrian.hunter, alexander.shishkin, yao.jin, mingo,
paulus, acme, robert.richter, namhyung, kim.phillips,
linuxppc-dev, alexey.budankov, kan.liang
In-Reply-To: <20200302052355.36365-3-ravi.bangoria@linux.ibm.com>
On Mon, Mar 02, 2020 at 10:53:46AM +0530, Ravi Bangoria wrote:
> From: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
>
> Introduce new perf sample_type PERF_SAMPLE_PIPELINE_HAZ to request kernel
> to provide cpu pipeline hazard data. Also, introduce arch independent
> structure 'perf_pipeline_haz_data' to pass hazard data to userspace. This
> is generic structure and arch specific data needs to be converted to this
> format.
>
> Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
> Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
> ---
> include/linux/perf_event.h | 7 ++++++
> include/uapi/linux/perf_event.h | 32 ++++++++++++++++++++++++++-
> kernel/events/core.c | 6 +++++
> tools/include/uapi/linux/perf_event.h | 32 ++++++++++++++++++++++++++-
> 4 files changed, 75 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> index 547773f5894e..d5b606e3c57d 100644
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -1001,6 +1001,7 @@ struct perf_sample_data {
> u64 stack_user_size;
>
> u64 phys_addr;
> + struct perf_pipeline_haz_data pipeline_haz;
> } ____cacheline_aligned;
>
> /* default value for data source */
> @@ -1021,6 +1022,12 @@ static inline void perf_sample_data_init(struct perf_sample_data *data,
> data->weight = 0;
> data->data_src.val = PERF_MEM_NA;
> data->txn = 0;
> + data->pipeline_haz.itype = PERF_HAZ__ITYPE_NA;
> + data->pipeline_haz.icache = PERF_HAZ__ICACHE_NA;
> + data->pipeline_haz.hazard_stage = PERF_HAZ__PIPE_STAGE_NA;
> + data->pipeline_haz.hazard_reason = PERF_HAZ__HREASON_NA;
> + data->pipeline_haz.stall_stage = PERF_HAZ__PIPE_STAGE_NA;
> + data->pipeline_haz.stall_reason = PERF_HAZ__SREASON_NA;
> }
>
> extern void perf_output_sample(struct perf_output_handle *handle,
> diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
> index 377d794d3105..ff252618ca93 100644
> --- a/include/uapi/linux/perf_event.h
> +++ b/include/uapi/linux/perf_event.h
> @@ -142,8 +142,9 @@ enum perf_event_sample_format {
> PERF_SAMPLE_REGS_INTR = 1U << 18,
> PERF_SAMPLE_PHYS_ADDR = 1U << 19,
> PERF_SAMPLE_AUX = 1U << 20,
> + PERF_SAMPLE_PIPELINE_HAZ = 1U << 21,
Can we please have perf_event_open() reject this sample flag for PMUs
without the new callback (introduced in the next patch)?
That way it'll be possible to detect whether the PMU exposes this.
Thanks,
Mark.
^ permalink raw reply
* Re: [PATCH] ima: add a new CONFIG for loading arch-specific policies
From: Mimi Zohar @ 2020-03-02 14:48 UTC (permalink / raw)
To: Nayna Jain, linux-integrity, linuxppc-dev, linux-efi, linux-s390
Cc: Martin Schwidefsky, Philipp Rudo, Ard Biesheuvel, linux-kernel
In-Reply-To: <1582744207-25969-1-git-send-email-nayna@linux.ibm.com>
On Wed, 2020-02-26 at 14:10 -0500, Nayna Jain wrote:
> Every time a new architecture defines the IMA architecture specific
> functions - arch_ima_get_secureboot() and arch_ima_get_policy(), the IMA
> include file needs to be updated. To avoid this "noise", this patch
> defines a new IMA Kconfig IMA_SECURE_AND_OR_TRUSTED_BOOT option, allowing
> the different architectures to select it.
>
> Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: Nayna Jain <nayna@linux.ibm.com>
> Cc: Ard Biesheuvel <ardb@kernel.org>
> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
> Cc: Philipp Rudo <prudo@linux.ibm.com>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> ---
> arch/powerpc/Kconfig | 2 +-
> arch/s390/Kconfig | 1 +
> arch/x86/Kconfig | 1 +
> include/linux/ima.h | 3 +--
> security/integrity/ima/Kconfig | 9 +++++++++
> 5 files changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 497b7d0b2d7e..b8ce1b995633 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -246,6 +246,7 @@ config PPC
> select SYSCTL_EXCEPTION_TRACE
> select THREAD_INFO_IN_TASK
> select VIRT_TO_BUS if !PPC64
> + select IMA_SECURE_AND_OR_TRUSTED_BOOT if PPC_SECURE_BOOT
> #
> # Please keep this list sorted alphabetically.
> #
> @@ -978,7 +979,6 @@ config PPC_SECURE_BOOT
> prompt "Enable secure boot support"
> bool
> depends on PPC_POWERNV
> - depends on IMA_ARCH_POLICY
> help
> Systems with firmware secure boot enabled need to define security
> policies to extend secure boot to the OS. This config allows a user
> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
> index 8abe77536d9d..90ff3633ade6 100644
> --- a/arch/s390/Kconfig
> +++ b/arch/s390/Kconfig
> @@ -195,6 +195,7 @@ config S390
> select ARCH_HAS_FORCE_DMA_UNENCRYPTED
> select SWIOTLB
> select GENERIC_ALLOCATOR
> + select IMA_SECURE_AND_OR_TRUSTED_BOOT
>
>
> config SCHED_OMIT_FRAME_POINTER
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index beea77046f9b..cafa66313fe2 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -230,6 +230,7 @@ config X86
> select VIRT_TO_BUS
> select X86_FEATURE_NAMES if PROC_FS
> select PROC_PID_ARCH_STATUS if PROC_FS
> + select IMA_SECURE_AND_OR_TRUSTED_BOOT if EFI
Not everyone is interested in enabling IMA or requiring IMA runtime
policies. With this patch, enabling IMA_ARCH_POLICY is therefore
still left up to the person building the kernel. As a result, I'm
seeing the following warning, which is kind of cool.
WARNING: unmet direct dependencies detected for
IMA_SECURE_AND_OR_TRUSTED_BOOT
Depends on [n]: INTEGRITY [=y] && IMA [=y] && IMA_ARCH_POLICY [=n]
Selected by [y]:
- X86 [=y] && EFI [=y]
Ard, Michael, Martin, just making sure this type of warning is
acceptable before upstreaming this patch. I would appreciate your
tags.
thanks!
Mimi
>
> config INSTRUCTION_DECODER
> def_bool y
> diff --git a/include/linux/ima.h b/include/linux/ima.h
> index 1659217e9b60..aefe758f4466 100644
> --- a/include/linux/ima.h
> +++ b/include/linux/ima.h
> @@ -30,8 +30,7 @@ extern void ima_kexec_cmdline(const void *buf, int size);
> extern void ima_add_kexec_buffer(struct kimage *image);
> #endif
>
> -#if (defined(CONFIG_X86) && defined(CONFIG_EFI)) || defined(CONFIG_S390) \
> - || defined(CONFIG_PPC_SECURE_BOOT)
> +#ifdef CONFIG_IMA_SECURE_AND_OR_TRUSTED_BOOT
> extern bool arch_ima_get_secureboot(void);
> extern const char * const *arch_get_ima_policy(void);
> #else
> diff --git a/security/integrity/ima/Kconfig b/security/integrity/ima/Kconfig
> index 3f3ee4e2eb0d..d17972aa413a 100644
> --- a/security/integrity/ima/Kconfig
> +++ b/security/integrity/ima/Kconfig
> @@ -327,3 +327,12 @@ config IMA_QUEUE_EARLY_BOOT_KEYS
> depends on IMA_MEASURE_ASYMMETRIC_KEYS
> depends on SYSTEM_TRUSTED_KEYRING
> default y
> +
> +config IMA_SECURE_AND_OR_TRUSTED_BOOT
> + bool
> + depends on IMA
> + depends on IMA_ARCH_POLICY
> + default n
> + help
> + This option is selected by architectures to enable secure and/or
> + trusted boot based on IMA runtime policies.
^ permalink raw reply
* Re: [PATCH] ima: add a new CONFIG for loading arch-specific policies
From: Ard Biesheuvel @ 2020-03-02 14:52 UTC (permalink / raw)
To: Mimi Zohar
Cc: linux-s390, linux-efi, Nayna Jain, Linux Kernel Mailing List,
Philipp Rudo, Martin Schwidefsky, linux-integrity, linuxppc-dev
In-Reply-To: <1583160524.8544.91.camel@linux.ibm.com>
On Mon, 2 Mar 2020 at 15:48, Mimi Zohar <zohar@linux.ibm.com> wrote:
>
> On Wed, 2020-02-26 at 14:10 -0500, Nayna Jain wrote:
> > Every time a new architecture defines the IMA architecture specific
> > functions - arch_ima_get_secureboot() and arch_ima_get_policy(), the IMA
> > include file needs to be updated. To avoid this "noise", this patch
> > defines a new IMA Kconfig IMA_SECURE_AND_OR_TRUSTED_BOOT option, allowing
> > the different architectures to select it.
> >
> > Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
> > Signed-off-by: Nayna Jain <nayna@linux.ibm.com>
> > Cc: Ard Biesheuvel <ardb@kernel.org>
> > Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
> > Cc: Philipp Rudo <prudo@linux.ibm.com>
> > Cc: Michael Ellerman <mpe@ellerman.id.au>
> > ---
> > arch/powerpc/Kconfig | 2 +-
> > arch/s390/Kconfig | 1 +
> > arch/x86/Kconfig | 1 +
> > include/linux/ima.h | 3 +--
> > security/integrity/ima/Kconfig | 9 +++++++++
> > 5 files changed, 13 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> > index 497b7d0b2d7e..b8ce1b995633 100644
> > --- a/arch/powerpc/Kconfig
> > +++ b/arch/powerpc/Kconfig
> > @@ -246,6 +246,7 @@ config PPC
> > select SYSCTL_EXCEPTION_TRACE
> > select THREAD_INFO_IN_TASK
> > select VIRT_TO_BUS if !PPC64
> > + select IMA_SECURE_AND_OR_TRUSTED_BOOT if PPC_SECURE_BOOT
> > #
> > # Please keep this list sorted alphabetically.
> > #
> > @@ -978,7 +979,6 @@ config PPC_SECURE_BOOT
> > prompt "Enable secure boot support"
> > bool
> > depends on PPC_POWERNV
> > - depends on IMA_ARCH_POLICY
> > help
> > Systems with firmware secure boot enabled need to define security
> > policies to extend secure boot to the OS. This config allows a user
> > diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
> > index 8abe77536d9d..90ff3633ade6 100644
> > --- a/arch/s390/Kconfig
> > +++ b/arch/s390/Kconfig
> > @@ -195,6 +195,7 @@ config S390
> > select ARCH_HAS_FORCE_DMA_UNENCRYPTED
> > select SWIOTLB
> > select GENERIC_ALLOCATOR
> > + select IMA_SECURE_AND_OR_TRUSTED_BOOT
> >
> >
> > config SCHED_OMIT_FRAME_POINTER
> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > index beea77046f9b..cafa66313fe2 100644
> > --- a/arch/x86/Kconfig
> > +++ b/arch/x86/Kconfig
> > @@ -230,6 +230,7 @@ config X86
> > select VIRT_TO_BUS
> > select X86_FEATURE_NAMES if PROC_FS
> > select PROC_PID_ARCH_STATUS if PROC_FS
> > + select IMA_SECURE_AND_OR_TRUSTED_BOOT if EFI
>
> Not everyone is interested in enabling IMA or requiring IMA runtime
> policies. With this patch, enabling IMA_ARCH_POLICY is therefore
> still left up to the person building the kernel. As a result, I'm
> seeing the following warning, which is kind of cool.
>
> WARNING: unmet direct dependencies detected for
> IMA_SECURE_AND_OR_TRUSTED_BOOT
> Depends on [n]: INTEGRITY [=y] && IMA [=y] && IMA_ARCH_POLICY [=n]
> Selected by [y]:
> - X86 [=y] && EFI [=y]
>
> Ard, Michael, Martin, just making sure this type of warning is
> acceptable before upstreaming this patch. I would appreciate your
> tags.
>
Ehm, no, warnings like these are not really acceptable. It means there
is an inconsistency in the way the Kconfig dependencies are defined.
Does this help:
select IMA_SECURE_AND_OR_TRUSTED_BOOT if EFI && IMA_ARCH_POLICY
?
>
> >
> > config INSTRUCTION_DECODER
> > def_bool y
> > diff --git a/include/linux/ima.h b/include/linux/ima.h
> > index 1659217e9b60..aefe758f4466 100644
> > --- a/include/linux/ima.h
> > +++ b/include/linux/ima.h
> > @@ -30,8 +30,7 @@ extern void ima_kexec_cmdline(const void *buf, int size);
> > extern void ima_add_kexec_buffer(struct kimage *image);
> > #endif
> >
> > -#if (defined(CONFIG_X86) && defined(CONFIG_EFI)) || defined(CONFIG_S390) \
> > - || defined(CONFIG_PPC_SECURE_BOOT)
> > +#ifdef CONFIG_IMA_SECURE_AND_OR_TRUSTED_BOOT
> > extern bool arch_ima_get_secureboot(void);
> > extern const char * const *arch_get_ima_policy(void);
> > #else
> > diff --git a/security/integrity/ima/Kconfig b/security/integrity/ima/Kconfig
> > index 3f3ee4e2eb0d..d17972aa413a 100644
> > --- a/security/integrity/ima/Kconfig
> > +++ b/security/integrity/ima/Kconfig
> > @@ -327,3 +327,12 @@ config IMA_QUEUE_EARLY_BOOT_KEYS
> > depends on IMA_MEASURE_ASYMMETRIC_KEYS
> > depends on SYSTEM_TRUSTED_KEYRING
> > default y
> > +
> > +config IMA_SECURE_AND_OR_TRUSTED_BOOT
> > + bool
> > + depends on IMA
> > + depends on IMA_ARCH_POLICY
> > + default n
> > + help
> > + This option is selected by architectures to enable secure and/or
> > + trusted boot based on IMA runtime policies.
>
>
>
>
^ permalink raw reply
* Re: [RFC 02/11] perf/core: Data structure to present hazard data
From: Mark Rutland @ 2020-03-02 14:54 UTC (permalink / raw)
To: Ravi Bangoria
Cc: ak, maddy, peterz, jolsa, Madhavan Srinivasan, linux-kernel,
eranian, adrian.hunter, alexander.shishkin, yao.jin, mingo,
paulus, acme, robert.richter, namhyung, kim.phillips,
linuxppc-dev, alexey.budankov, kan.liang
In-Reply-To: <20200302052355.36365-3-ravi.bangoria@linux.ibm.com>
On Mon, Mar 02, 2020 at 10:53:46AM +0530, Ravi Bangoria wrote:
> From: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
>
> Introduce new perf sample_type PERF_SAMPLE_PIPELINE_HAZ to request kernel
> to provide cpu pipeline hazard data. Also, introduce arch independent
> structure 'perf_pipeline_haz_data' to pass hazard data to userspace. This
> is generic structure and arch specific data needs to be converted to this
> format.
>
> Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
> Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
> ---
> include/linux/perf_event.h | 7 ++++++
> include/uapi/linux/perf_event.h | 32 ++++++++++++++++++++++++++-
> kernel/events/core.c | 6 +++++
> tools/include/uapi/linux/perf_event.h | 32 ++++++++++++++++++++++++++-
> 4 files changed, 75 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> index 547773f5894e..d5b606e3c57d 100644
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -1001,6 +1001,7 @@ struct perf_sample_data {
> u64 stack_user_size;
>
> u64 phys_addr;
> + struct perf_pipeline_haz_data pipeline_haz;
> } ____cacheline_aligned;
I don't think you can add this here, see below.
> /* default value for data source */
> @@ -1021,6 +1022,12 @@ static inline void perf_sample_data_init(struct perf_sample_data *data,
> data->weight = 0;
> data->data_src.val = PERF_MEM_NA;
> data->txn = 0;
> + data->pipeline_haz.itype = PERF_HAZ__ITYPE_NA;
> + data->pipeline_haz.icache = PERF_HAZ__ICACHE_NA;
> + data->pipeline_haz.hazard_stage = PERF_HAZ__PIPE_STAGE_NA;
> + data->pipeline_haz.hazard_reason = PERF_HAZ__HREASON_NA;
> + data->pipeline_haz.stall_stage = PERF_HAZ__PIPE_STAGE_NA;
> + data->pipeline_haz.stall_reason = PERF_HAZ__SREASON_NA;
> }
>
> extern void perf_output_sample(struct perf_output_handle *handle,
> diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
> index 377d794d3105..ff252618ca93 100644
> --- a/include/uapi/linux/perf_event.h
> +++ b/include/uapi/linux/perf_event.h
> @@ -142,8 +142,9 @@ enum perf_event_sample_format {
> PERF_SAMPLE_REGS_INTR = 1U << 18,
> PERF_SAMPLE_PHYS_ADDR = 1U << 19,
> PERF_SAMPLE_AUX = 1U << 20,
> + PERF_SAMPLE_PIPELINE_HAZ = 1U << 21,
>
> - PERF_SAMPLE_MAX = 1U << 21, /* non-ABI */
> + PERF_SAMPLE_MAX = 1U << 22, /* non-ABI */
>
> __PERF_SAMPLE_CALLCHAIN_EARLY = 1ULL << 63, /* non-ABI; internal use */
> };
> @@ -870,6 +871,13 @@ enum perf_event_type {
> * { u64 phys_addr;} && PERF_SAMPLE_PHYS_ADDR
> * { u64 size;
> * char data[size]; } && PERF_SAMPLE_AUX
> + * { u8 itype;
> + * u8 icache;
> + * u8 hazard_stage;
> + * u8 hazard_reason;
> + * u8 stall_stage;
> + * u8 stall_reason;
> + * u16 pad;} && PERF_SAMPLE_PIPELINE_HAZ
> * };
The existing comment shows the aux data *immediately* after ther
phys_addr field, where you've placed struct perf_pipeline_haz_data.
If adding to struct perf_sample_data is fine, this needs to come before
the aux data in this comment. If adding to struct perf_sample_data is
not fine. struct perf_pipeline_haz_data cannot live there.
I suspect the latter is true, but you're getting away with it because
you're not using both PERF_SAMPLE_AUX and PERF_SAMPLE_PIPELINE_HAZ
simultaneously.
Thanks,
Mark.
> */
> PERF_RECORD_SAMPLE = 9,
> @@ -1185,4 +1193,26 @@ struct perf_branch_entry {
> reserved:40;
> };
>
> +struct perf_pipeline_haz_data {
> + /* Instruction/Opcode type: Load, Store, Branch .... */
> + __u8 itype;
> + /* Instruction Cache source */
> + __u8 icache;
> + /* Instruction suffered hazard in pipeline stage */
> + __u8 hazard_stage;
> + /* Hazard reason */
> + __u8 hazard_reason;
> + /* Instruction suffered stall in pipeline stage */
> + __u8 stall_stage;
> + /* Stall reason */
> + __u8 stall_reason;
> + __u16 pad;
> +};
> +
> +#define PERF_HAZ__ITYPE_NA 0x0
> +#define PERF_HAZ__ICACHE_NA 0x0
> +#define PERF_HAZ__PIPE_STAGE_NA 0x0
> +#define PERF_HAZ__HREASON_NA 0x0
> +#define PERF_HAZ__SREASON_NA 0x0
> +
> #endif /* _UAPI_LINUX_PERF_EVENT_H */
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index e453589da97c..d00037c77ccf 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -1754,6 +1754,9 @@ static void __perf_event_header_size(struct perf_event *event, u64 sample_type)
> if (sample_type & PERF_SAMPLE_PHYS_ADDR)
> size += sizeof(data->phys_addr);
>
> + if (sample_type & PERF_SAMPLE_PIPELINE_HAZ)
> + size += sizeof(data->pipeline_haz);
> +
> event->header_size = size;
> }
>
> @@ -6712,6 +6715,9 @@ void perf_output_sample(struct perf_output_handle *handle,
> perf_aux_sample_output(event, handle, data);
> }
>
> + if (sample_type & PERF_SAMPLE_PIPELINE_HAZ)
> + perf_output_put(handle, data->pipeline_haz);
> +
> if (!event->attr.watermark) {
> int wakeup_events = event->attr.wakeup_events;
>
> diff --git a/tools/include/uapi/linux/perf_event.h b/tools/include/uapi/linux/perf_event.h
> index 377d794d3105..ff252618ca93 100644
> --- a/tools/include/uapi/linux/perf_event.h
> +++ b/tools/include/uapi/linux/perf_event.h
> @@ -142,8 +142,9 @@ enum perf_event_sample_format {
> PERF_SAMPLE_REGS_INTR = 1U << 18,
> PERF_SAMPLE_PHYS_ADDR = 1U << 19,
> PERF_SAMPLE_AUX = 1U << 20,
> + PERF_SAMPLE_PIPELINE_HAZ = 1U << 21,
>
> - PERF_SAMPLE_MAX = 1U << 21, /* non-ABI */
> + PERF_SAMPLE_MAX = 1U << 22, /* non-ABI */
>
> __PERF_SAMPLE_CALLCHAIN_EARLY = 1ULL << 63, /* non-ABI; internal use */
> };
> @@ -870,6 +871,13 @@ enum perf_event_type {
> * { u64 phys_addr;} && PERF_SAMPLE_PHYS_ADDR
> * { u64 size;
> * char data[size]; } && PERF_SAMPLE_AUX
> + * { u8 itype;
> + * u8 icache;
> + * u8 hazard_stage;
> + * u8 hazard_reason;
> + * u8 stall_stage;
> + * u8 stall_reason;
> + * u16 pad;} && PERF_SAMPLE_PIPELINE_HAZ
> * };
> */
> PERF_RECORD_SAMPLE = 9,
> @@ -1185,4 +1193,26 @@ struct perf_branch_entry {
> reserved:40;
> };
>
> +struct perf_pipeline_haz_data {
> + /* Instruction/Opcode type: Load, Store, Branch .... */
> + __u8 itype;
> + /* Instruction Cache source */
> + __u8 icache;
> + /* Instruction suffered hazard in pipeline stage */
> + __u8 hazard_stage;
> + /* Hazard reason */
> + __u8 hazard_reason;
> + /* Instruction suffered stall in pipeline stage */
> + __u8 stall_stage;
> + /* Stall reason */
> + __u8 stall_reason;
> + __u16 pad;
> +};
> +
> +#define PERF_HAZ__ITYPE_NA 0x0
> +#define PERF_HAZ__ICACHE_NA 0x0
> +#define PERF_HAZ__PIPE_STAGE_NA 0x0
> +#define PERF_HAZ__HREASON_NA 0x0
> +#define PERF_HAZ__SREASON_NA 0x0
> +
> #endif /* _UAPI_LINUX_PERF_EVENT_H */
> --
> 2.21.1
>
^ permalink raw reply
* Re: [PATCH] ima: add a new CONFIG for loading arch-specific policies
From: Mimi Zohar @ 2020-03-02 14:56 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-s390, linux-efi, Nayna Jain, Linux Kernel Mailing List,
Philipp Rudo, Martin Schwidefsky, linux-integrity, linuxppc-dev
In-Reply-To: <CAKv+Gu_E9O05xB7i2Y8KiMJUjtZoq54GxSbHnyTFePcF6fqQNA@mail.gmail.com>
On Mon, 2020-03-02 at 15:52 +0100, Ard Biesheuvel wrote:
> On Mon, 2 Mar 2020 at 15:48, Mimi Zohar <zohar@linux.ibm.com> wrote:
> >
> > On Wed, 2020-02-26 at 14:10 -0500, Nayna Jain wrote:
> > > Every time a new architecture defines the IMA architecture specific
> > > functions - arch_ima_get_secureboot() and arch_ima_get_policy(), the IMA
> > > include file needs to be updated. To avoid this "noise", this patch
> > > defines a new IMA Kconfig IMA_SECURE_AND_OR_TRUSTED_BOOT option, allowing
> > > the different architectures to select it.
> > >
> > > Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
> > > Signed-off-by: Nayna Jain <nayna@linux.ibm.com>
> > > Cc: Ard Biesheuvel <ardb@kernel.org>
> > > Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
> > > Cc: Philipp Rudo <prudo@linux.ibm.com>
> > > Cc: Michael Ellerman <mpe@ellerman.id.au>
> > > ---
> > > arch/powerpc/Kconfig | 2 +-
> > > arch/s390/Kconfig | 1 +
> > > arch/x86/Kconfig | 1 +
> > > include/linux/ima.h | 3 +--
> > > security/integrity/ima/Kconfig | 9 +++++++++
> > > 5 files changed, 13 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> > > index 497b7d0b2d7e..b8ce1b995633 100644
> > > --- a/arch/powerpc/Kconfig
> > > +++ b/arch/powerpc/Kconfig
> > > @@ -246,6 +246,7 @@ config PPC
> > > select SYSCTL_EXCEPTION_TRACE
> > > select THREAD_INFO_IN_TASK
> > > select VIRT_TO_BUS if !PPC64
> > > + select IMA_SECURE_AND_OR_TRUSTED_BOOT if PPC_SECURE_BOOT
> > > #
> > > # Please keep this list sorted alphabetically.
> > > #
> > > @@ -978,7 +979,6 @@ config PPC_SECURE_BOOT
> > > prompt "Enable secure boot support"
> > > bool
> > > depends on PPC_POWERNV
> > > - depends on IMA_ARCH_POLICY
> > > help
> > > Systems with firmware secure boot enabled need to define security
> > > policies to extend secure boot to the OS. This config allows a user
> > > diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
> > > index 8abe77536d9d..90ff3633ade6 100644
> > > --- a/arch/s390/Kconfig
> > > +++ b/arch/s390/Kconfig
> > > @@ -195,6 +195,7 @@ config S390
> > > select ARCH_HAS_FORCE_DMA_UNENCRYPTED
> > > select SWIOTLB
> > > select GENERIC_ALLOCATOR
> > > + select IMA_SECURE_AND_OR_TRUSTED_BOOT
> > >
> > >
> > > config SCHED_OMIT_FRAME_POINTER
> > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > > index beea77046f9b..cafa66313fe2 100644
> > > --- a/arch/x86/Kconfig
> > > +++ b/arch/x86/Kconfig
> > > @@ -230,6 +230,7 @@ config X86
> > > select VIRT_TO_BUS
> > > select X86_FEATURE_NAMES if PROC_FS
> > > select PROC_PID_ARCH_STATUS if PROC_FS
> > > + select IMA_SECURE_AND_OR_TRUSTED_BOOT if EFI
> >
> > Not everyone is interested in enabling IMA or requiring IMA runtime
> > policies. With this patch, enabling IMA_ARCH_POLICY is therefore
> > still left up to the person building the kernel. As a result, I'm
> > seeing the following warning, which is kind of cool.
> >
> > WARNING: unmet direct dependencies detected for
> > IMA_SECURE_AND_OR_TRUSTED_BOOT
> > Depends on [n]: INTEGRITY [=y] && IMA [=y] && IMA_ARCH_POLICY [=n]
> > Selected by [y]:
> > - X86 [=y] && EFI [=y]
> >
> > Ard, Michael, Martin, just making sure this type of warning is
> > acceptable before upstreaming this patch. I would appreciate your
> > tags.
> >
>
> Ehm, no, warnings like these are not really acceptable. It means there
> is an inconsistency in the way the Kconfig dependencies are defined.
>
> Does this help:
>
> select IMA_SECURE_AND_OR_TRUSTED_BOOT if EFI && IMA_ARCH_POLICY
>
> ?
Yes, that's fine for x86. Michael, Martin, do you want something
similar or would you prefer actually selecting IMA_ARCH_POLICY?
Mimi
^ permalink raw reply
* [powerpc:fixes-test] BUILD SUCCESS cb0cc635c7a9fa8a3a0f75d4d896721819c63add
From: kbuild test robot @ 2020-03-02 15:23 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git fixes-test
branch HEAD: cb0cc635c7a9fa8a3a0f75d4d896721819c63add powerpc: Include .BTF section
elapsed time: 4704m
configs tested: 350
configs skipped: 154
The following configs have been built successfully.
More configs may be tested in the coming days.
arm allmodconfig
arm allnoconfig
arm allyesconfig
arm64 allmodconfig
arm64 allnoconfig
arm64 allyesconfig
arm at91_dt_defconfig
arm efm32_defconfig
arm exynos_defconfig
arm multi_v5_defconfig
arm multi_v7_defconfig
arm shmobile_defconfig
arm sunxi_defconfig
arm64 defconfig
sparc allyesconfig
mips fuloong2e_defconfig
i386 allyesconfig
ia64 defconfig
powerpc defconfig
i386 allnoconfig
powerpc ppc64_defconfig
openrisc or1ksim_defconfig
xtensa common_defconfig
ia64 alldefconfig
h8300 edosk2674_defconfig
s390 allnoconfig
sparc defconfig
nds32 allnoconfig
s390 alldefconfig
s390 zfcpdump_defconfig
mips allnoconfig
mips allmodconfig
s390 allmodconfig
arc allyesconfig
mips malta_kvm_defconfig
m68k sun3_defconfig
xtensa iss_defconfig
i386 alldefconfig
ia64 allnoconfig
h8300 h8s-sim_defconfig
m68k m5475evb_defconfig
nios2 3c120_defconfig
m68k multi_defconfig
powerpc allnoconfig
sparc64 allnoconfig
openrisc simple_smp_defconfig
sh allnoconfig
s390 defconfig
alpha defconfig
parisc allnoconfig
i386 defconfig
ia64 allmodconfig
ia64 allyesconfig
c6x allyesconfig
c6x evmc6678_defconfig
nios2 10m50_defconfig
h8300 h8300h-sim_defconfig
m68k allmodconfig
arc defconfig
microblaze mmu_defconfig
microblaze nommu_defconfig
powerpc rhel-kconfig
mips 32r2_defconfig
mips 64r6el_defconfig
mips allyesconfig
parisc allyesconfig
parisc generic-32bit_defconfig
parisc generic-64bit_defconfig
x86_64 randconfig-a001-20200228
x86_64 randconfig-a002-20200228
x86_64 randconfig-a003-20200228
i386 randconfig-a001-20200228
i386 randconfig-a002-20200228
i386 randconfig-a003-20200228
x86_64 randconfig-a001-20200229
x86_64 randconfig-a002-20200229
x86_64 randconfig-a003-20200229
i386 randconfig-a001-20200229
i386 randconfig-a002-20200229
i386 randconfig-a003-20200229
x86_64 randconfig-a001-20200301
x86_64 randconfig-a002-20200301
x86_64 randconfig-a003-20200301
i386 randconfig-a001-20200301
i386 randconfig-a002-20200301
i386 randconfig-a003-20200301
x86_64 randconfig-a001-20200302
x86_64 randconfig-a002-20200302
x86_64 randconfig-a003-20200302
i386 randconfig-a001-20200302
i386 randconfig-a002-20200302
i386 randconfig-a003-20200302
alpha randconfig-a001-20200228
m68k randconfig-a001-20200228
mips randconfig-a001-20200228
nds32 randconfig-a001-20200228
parisc randconfig-a001-20200228
riscv randconfig-a001-20200228
alpha randconfig-a001-20200302
parisc randconfig-a001-20200302
alpha randconfig-a001-20200229
m68k randconfig-a001-20200229
nds32 randconfig-a001-20200229
parisc randconfig-a001-20200229
riscv randconfig-a001-20200229
m68k randconfig-a001-20200302
mips randconfig-a001-20200302
nds32 randconfig-a001-20200302
riscv randconfig-a001-20200302
c6x randconfig-a001-20200229
h8300 randconfig-a001-20200229
microblaze randconfig-a001-20200229
nios2 randconfig-a001-20200229
sparc64 randconfig-a001-20200229
c6x randconfig-a001-20200228
h8300 randconfig-a001-20200228
microblaze randconfig-a001-20200228
nios2 randconfig-a001-20200228
sparc64 randconfig-a001-20200228
c6x randconfig-a001-20200302
microblaze randconfig-a001-20200302
csky randconfig-a001-20200228
openrisc randconfig-a001-20200228
s390 randconfig-a001-20200228
sh randconfig-a001-20200228
xtensa randconfig-a001-20200228
csky randconfig-a001-20200302
s390 randconfig-a001-20200302
sh randconfig-a001-20200302
csky randconfig-a001-20200229
openrisc randconfig-a001-20200229
s390 randconfig-a001-20200229
xtensa randconfig-a001-20200229
xtensa randconfig-a001-20200302
x86_64 randconfig-b001-20200228
x86_64 randconfig-b002-20200228
x86_64 randconfig-b003-20200228
i386 randconfig-b001-20200228
i386 randconfig-b002-20200228
i386 randconfig-b003-20200228
x86_64 randconfig-b001-20200301
x86_64 randconfig-b002-20200301
x86_64 randconfig-b003-20200301
i386 randconfig-b001-20200301
i386 randconfig-b002-20200301
i386 randconfig-b003-20200301
x86_64 randconfig-b001-20200229
x86_64 randconfig-b002-20200229
x86_64 randconfig-b003-20200229
i386 randconfig-b001-20200229
i386 randconfig-b002-20200229
i386 randconfig-b003-20200229
x86_64 randconfig-b001-20200302
x86_64 randconfig-b002-20200302
x86_64 randconfig-b003-20200302
i386 randconfig-b001-20200302
i386 randconfig-b002-20200302
i386 randconfig-b003-20200302
x86_64 randconfig-c001-20200228
x86_64 randconfig-c002-20200228
x86_64 randconfig-c003-20200228
i386 randconfig-c001-20200228
i386 randconfig-c002-20200228
i386 randconfig-c003-20200228
x86_64 randconfig-c001-20200301
x86_64 randconfig-c002-20200301
x86_64 randconfig-c003-20200301
i386 randconfig-c001-20200301
i386 randconfig-c002-20200301
i386 randconfig-c003-20200301
x86_64 randconfig-c001-20200229
x86_64 randconfig-c002-20200229
x86_64 randconfig-c003-20200229
i386 randconfig-c001-20200229
i386 randconfig-c002-20200229
i386 randconfig-c003-20200229
x86_64 randconfig-c001-20200302
x86_64 randconfig-c002-20200302
x86_64 randconfig-c003-20200302
i386 randconfig-c001-20200302
i386 randconfig-c002-20200302
i386 randconfig-c003-20200302
x86_64 randconfig-d001-20200228
x86_64 randconfig-d002-20200228
x86_64 randconfig-d003-20200228
i386 randconfig-d001-20200228
i386 randconfig-d002-20200228
i386 randconfig-d003-20200228
x86_64 randconfig-d001-20200301
x86_64 randconfig-d002-20200301
x86_64 randconfig-d003-20200301
i386 randconfig-d001-20200301
i386 randconfig-d002-20200301
i386 randconfig-d003-20200301
x86_64 randconfig-d001-20200229
x86_64 randconfig-d002-20200229
x86_64 randconfig-d003-20200229
i386 randconfig-d001-20200229
i386 randconfig-d002-20200229
i386 randconfig-d003-20200229
x86_64 randconfig-d001-20200302
x86_64 randconfig-d002-20200302
x86_64 randconfig-d003-20200302
i386 randconfig-d001-20200302
i386 randconfig-d002-20200302
i386 randconfig-d003-20200302
x86_64 randconfig-e001-20200301
x86_64 randconfig-e002-20200301
x86_64 randconfig-e003-20200301
i386 randconfig-e001-20200301
i386 randconfig-e002-20200301
i386 randconfig-e003-20200301
x86_64 randconfig-e001-20200228
x86_64 randconfig-e002-20200228
x86_64 randconfig-e003-20200228
i386 randconfig-e001-20200228
i386 randconfig-e002-20200228
i386 randconfig-e003-20200228
x86_64 randconfig-e001-20200229
x86_64 randconfig-e002-20200229
x86_64 randconfig-e003-20200229
i386 randconfig-e001-20200229
i386 randconfig-e002-20200229
i386 randconfig-e003-20200229
x86_64 randconfig-e001-20200302
x86_64 randconfig-e002-20200302
x86_64 randconfig-e003-20200302
i386 randconfig-e003-20200302
i386 randconfig-e001-20200302
i386 randconfig-e002-20200302
x86_64 randconfig-f001-20200228
x86_64 randconfig-f002-20200228
x86_64 randconfig-f003-20200228
i386 randconfig-f001-20200228
i386 randconfig-f002-20200228
i386 randconfig-f003-20200228
x86_64 randconfig-f001-20200229
x86_64 randconfig-f002-20200229
x86_64 randconfig-f003-20200229
i386 randconfig-f001-20200229
i386 randconfig-f002-20200229
i386 randconfig-f003-20200229
x86_64 randconfig-f001-20200301
x86_64 randconfig-f002-20200301
x86_64 randconfig-f003-20200301
i386 randconfig-f001-20200301
i386 randconfig-f002-20200301
i386 randconfig-f003-20200301
x86_64 randconfig-f001-20200302
x86_64 randconfig-f002-20200302
x86_64 randconfig-f003-20200302
i386 randconfig-f001-20200302
i386 randconfig-f002-20200302
i386 randconfig-f003-20200302
x86_64 randconfig-g001-20200228
x86_64 randconfig-g002-20200228
x86_64 randconfig-g003-20200228
i386 randconfig-g001-20200228
i386 randconfig-g002-20200228
i386 randconfig-g003-20200228
x86_64 randconfig-g001-20200229
x86_64 randconfig-g002-20200229
x86_64 randconfig-g003-20200229
i386 randconfig-g001-20200229
i386 randconfig-g002-20200229
i386 randconfig-g003-20200229
i386 randconfig-g002-20200302
i386 randconfig-g003-20200302
x86_64 randconfig-g001-20200302
x86_64 randconfig-g002-20200302
x86_64 randconfig-g003-20200302
i386 randconfig-g001-20200302
x86_64 randconfig-g001-20200301
x86_64 randconfig-g002-20200301
x86_64 randconfig-g003-20200301
i386 randconfig-g001-20200301
i386 randconfig-g002-20200301
i386 randconfig-g003-20200301
x86_64 randconfig-h001-20200228
x86_64 randconfig-h002-20200228
x86_64 randconfig-h003-20200228
i386 randconfig-h001-20200228
i386 randconfig-h002-20200228
i386 randconfig-h003-20200228
x86_64 randconfig-h001-20200301
x86_64 randconfig-h002-20200301
x86_64 randconfig-h003-20200301
i386 randconfig-h001-20200301
i386 randconfig-h002-20200301
i386 randconfig-h003-20200301
x86_64 randconfig-h001-20200302
x86_64 randconfig-h002-20200302
x86_64 randconfig-h003-20200302
i386 randconfig-h001-20200302
i386 randconfig-h002-20200302
i386 randconfig-h003-20200302
x86_64 randconfig-h001-20200229
x86_64 randconfig-h002-20200229
x86_64 randconfig-h003-20200229
i386 randconfig-h001-20200229
i386 randconfig-h002-20200229
i386 randconfig-h003-20200229
arc randconfig-a001-20200228
arm randconfig-a001-20200228
arm64 randconfig-a001-20200228
ia64 randconfig-a001-20200228
powerpc randconfig-a001-20200228
sparc randconfig-a001-20200228
arc randconfig-a001-20200229
arm randconfig-a001-20200229
arm64 randconfig-a001-20200229
ia64 randconfig-a001-20200229
powerpc randconfig-a001-20200229
sparc randconfig-a001-20200229
arc randconfig-a001-20200301
arm randconfig-a001-20200301
arm64 randconfig-a001-20200301
ia64 randconfig-a001-20200301
powerpc randconfig-a001-20200301
sparc randconfig-a001-20200301
arm64 randconfig-a001-20200302
ia64 randconfig-a001-20200302
powerpc randconfig-a001-20200302
arc randconfig-a001-20200302
arm randconfig-a001-20200302
sparc randconfig-a001-20200302
riscv allmodconfig
riscv allnoconfig
riscv allyesconfig
riscv defconfig
riscv nommu_virt_defconfig
riscv rv32_defconfig
s390 allyesconfig
s390 debug_defconfig
sh allmodconfig
sh rsk7269_defconfig
sh sh7785lcr_32bit_defconfig
sh titan_defconfig
sparc64 allmodconfig
sparc64 allyesconfig
sparc64 defconfig
um defconfig
um i386_defconfig
um x86_64_defconfig
x86_64 fedora-25
x86_64 kexec
x86_64 lkp
x86_64 rhel
x86_64 rhel-7.2-clear
x86_64 rhel-7.6
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [Bug 199471] [Bisected][Regression] windfarm_pm* no longer gets automatically loaded when CONFIG_I2C_POWERMAC=y is set
From: bugzilla-daemon @ 2020-03-02 15:39 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-199471-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=199471
--- Comment #17 from Erhard F. (erhard_f@mailbox.org) ---
(In reply to Wolfram Sang from comment #16)
> Created attachment 287755 [details]
> proof-of-concept patch for testing
>
> Here is the promised patch. I converted all I2C MODULE tables. pm72 didn't
> have one, so we will see what pulls it in.
>
> A test with a machine needing the lm75 driver would be great. Because some
> code change was needed there.
Excellent! Applied your patch on 5.6-rc4 and it just works fine on my G5 11,2!
I can leave CONFIG_WINDFARM=m and the correct modules get pulled in just as it
was before kernel 4.17.
I can't test on the G5 7,3 from my original bug report 'cause I sold this one.
But from my understanding this "lm75" sensor is used in pretty any windfarm_pm*
module?
# grep -i lm75 drivers/macintosh/windfarm_pm*.c
drivers/macintosh/windfarm_pm112.c: request_module("windfarm_lm75_sensor");
drivers/macintosh/windfarm_pm121.c:
request_module("windfarm_lm75_sensor");
drivers/macintosh/windfarm_pm72.c: request_module("windfarm_lm75_sensor");
drivers/macintosh/windfarm_pm81.c:
request_module("windfarm_lm75_sensor");
drivers/macintosh/windfarm_pm91.c:
request_module("windfarm_lm75_sensor");
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [Bug 199471] [Bisected][Regression] windfarm_pm* no longer gets automatically loaded when CONFIG_I2C_POWERMAC=y is set
From: bugzilla-daemon @ 2020-03-02 15:40 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-199471-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=199471
--- Comment #18 from Erhard F. (erhard_f@mailbox.org) ---
Created attachment 287757
--> https://bugzilla.kernel.org/attachment.cgi?id=287757&action=edit
dmesg (kernel 5.6-rc4 + patch, PowerMac G5 11,2)
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* Re: [PATCH] selftests: powerpc: Add tlbie_test in .gitignore
From: Sasha Levin @ 2020-03-02 15:44 UTC (permalink / raw)
To: Sasha Levin, Christophe Leroy, Aneesh Kumar K.V, Shuah Khan,
Michael Ellerman
Cc: linux-mm, stable, linuxppc-dev, linux-kernel, linux-kselftest
In-Reply-To: <259f9c06ed4563c4fa4fa8ffa652347278d769e7.1582847784.git.christophe.leroy@c-s.fr>
Hi
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag
fixing commit: 93cad5f78995 ("selftests/powerpc: Add test case for tlbie vs mtpidr ordering issue").
The bot has tested the following trees: v5.5.6, v5.4.22, v4.19.106, v4.14.171.
v5.5.6: Failed to apply! Possible dependencies:
5eb7cfb3a2b1 ("selftests/powerpc: Add a test of bad (out-of-range) accesses")
v5.4.22: Failed to apply! Possible dependencies:
5eb7cfb3a2b1 ("selftests/powerpc: Add a test of bad (out-of-range) accesses")
v4.19.106: Failed to apply! Possible dependencies:
16391bfc8623 ("selftests/powerpc: Add test of fork with mapping above 512TB")
5eb7cfb3a2b1 ("selftests/powerpc: Add a test of bad (out-of-range) accesses")
7b570361f6f6 ("selftests/powerpc: Add missing newline at end of file")
b7683fc66eba ("selftests/powerpc: Add a test of wild bctr")
v4.14.171: Failed to apply! Possible dependencies:
16391bfc8623 ("selftests/powerpc: Add test of fork with mapping above 512TB")
5eb7cfb3a2b1 ("selftests/powerpc: Add a test of bad (out-of-range) accesses")
6ed361586b32 ("selftests/powerpc: Add a test of SEGV error behaviour")
7b570361f6f6 ("selftests/powerpc: Add missing newline at end of file")
b7683fc66eba ("selftests/powerpc: Add a test of wild bctr")
NOTE: The patch will not be queued to stable trees until it is upstream.
How should we proceed with this patch?
--
Thanks
Sasha
^ permalink raw reply
* Re: [RFC PATCH v1] powerpc/prom_init: disable XIVE in Secure VM.
From: Cédric Le Goater @ 2020-03-02 7:34 UTC (permalink / raw)
To: Ram Pai
Cc: aik, andmike, groug, kvm-ppc, clg, sukadev, linuxppc-dev,
bauerman, david
In-Reply-To: <20200229225140.GA5618@oc0525413822.ibm.com>
On 2/29/20 11:51 PM, Ram Pai wrote:
> On Sat, Feb 29, 2020 at 09:27:54AM +0100, Cédric Le Goater wrote:
>> On 2/29/20 8:54 AM, Ram Pai wrote:
>>> XIVE is not correctly enabled for Secure VM in the KVM Hypervisor yet.
>>>
>>> Hence Secure VM, must always default to XICS interrupt controller.
>>
>> have you tried XIVE emulation 'kernel-irqchip=off' ?
>
> yes and it hangs. I think that option, continues to enable some variant
> of XIVE in the VM.
HW is not involved, KVM is not involved anymore and all is emulated at
the QEMU level in user space. What is the issue ?
> There are some known deficiencies between KVM
> and the ultravisor negotiation, resulting in a hang in the SVM.
That is something else to investigate. feature/capability negotiation
is the core of the hypervisor stack :
OPAL <-> PowerNV <-> KVM <-> QEMU <-> guest OS
>>> If XIVE is requested through kernel command line option "xive=on",
>>> override and turn it off.
>>
>> This is incorrect. It is negotiated through CAS depending on the FW
>> capabilities and the KVM capabilities.
>
> Yes I understand, qemu/KVM have predetermined a set of capabilties that
> it can offer to the VM. The kernel within the VM has a list of
> capabilties it needs to operate correctly. So both negotiate and
> determine something mutually ammicable.
>
> Here I am talking about the list of capabilities that the kernel is
> trying to determine, it needs to operate correctly. "xive=on" is one of
> those capabilities the kernel is told by the VM-adminstrator, to enable.
XIVE is not a kernel capability. It's platform support and the default
for P9 is the native exploitation mode which makes full use of the P9
interrupt controller. For non XIVE aware kernels, the hypervisor emulates
the legacy interface on top of XIVE.
"xive=off" was introduced for distro testing. It skips the negotiation
process of the XIVE native exploitation mode on the guest. But it's not
a negotiation setting. It's a chicken switch.
> Unfortunately if the VM-administrtor blindly requests to enable it, the
> kernel must override it, if it knows that will be switching the VM into
> a SVM soon. No point negotiating a capability with Qemu; through CAS,
> if it knows it cannot handle that capability.
I don't understand. Are you talking about SVM or XIVE ?
>>> If XIVE is the only supported platform interrupt controller; specified
>>> through qemu option "ic-mode=xive", simply abort. Otherwise default to
>>> XICS.
>>
>>
>> I don't think it is a good approach to downgrade the guest kernel
>> capabilities this way.
>>
>> PAPR has specified the CAS negotiation process for this purpose. It
>> comes in two parts under KVM. First the KVM hypervisor advertises or
>> not a capability to QEMU. The second is the CAS negotiation process
>> between QEMU and the guest OS.
>
> Unfortunately, this is not viable. At the time the hypervisor
> advertises its capabilities to qemu, the hypervisor has no idea whether
> that VM will switch into a SVM or not.
OK, but the hypervisor knows if it can handle 'SVM' guests or not and,
if not, there is no point in advertising a 'SVM' capability to the guest.
> The decision to switch into a> SVM is taken by the kernel running in the VM. This happens much later,
> after the hypervisor has already conveyed its capabilties to the qemu, and
> qemu has than instantiated the VM.
So you don't have negotiation with the hypervisor ? How does the guest
knows the hypervisor platform can handle SVMs ? try and see if it fails ?
If so, it seems quite broken to me.
> As a result, CAS in prom_init is the only place where this negotiation
> can take place.
Euh. I don't follow. This is indeed where CAS is performed and so it's
*the* place to check that the hypervisor has 'SVM' support ?
>> The SVM specifications might not be complete yet and if some features
>> are incompatible, I think we should modify the capabilities advertised
>> by the hypervisor : no XIVE in case of SVM. QEMU will automatically
>> use the fallback path and emulate the XIVE device, same as setting
>> 'kernel-irqchip=off'.
>
> As mentioned above, this would be an excellent approach, if the
> Hypervisor was aware of the VM's intent to switch into a SVM. Neither
> the hypervisor knows, nor the qemu. Only the kernel running within the
> VM knows about it.
The hypervisor (KVM/QEMU) never knows what are the guest OS capabilities
or its intents. That is why there is a negotiation process.
I would do :
* OPAL FW advertises 'SVM' support to the Linux PowerNV (through DT)
* KVM advertises 'SVM' support to QEMU (extend KVM ioctls)
* QEMU advertises 'SVM' support to guest OS (through CAS or DT)
* Guest OS should not try to use SVM it is not supported.
If the passthrough of HW pages is not supported by Ultravisor, KVM
should not advertised XIVE to QEMU which would then use fallback mode.
If emulated XIVE or XICS is not supported by SVM guests, then we have
a problem and we need to understand why ! :)
And if XIVE is still a problem, then the guest could change the CAS
request and remove XIVE when SVM is being set. I suppose that we have
all this information before CAS. Do we ?
It should be a runtime choice taking into account the full software
stack rather than a compile choice at the bottom which would impact
all other options. This is not acceptable IMHO.
Cheers,
C.
^ permalink raw reply
* [Bug 206733] New: i2c i2c-3: i2c-powermac: modalias failure on /uni-n@f8000000/i2c@f8001000/cereal@1c0
From: bugzilla-daemon @ 2020-03-02 16:50 UTC (permalink / raw)
To: linuxppc-dev
https://bugzilla.kernel.org/show_bug.cgi?id=206733
Bug ID: 206733
Summary: i2c i2c-3: i2c-powermac: modalias failure on
/uni-n@f8000000/i2c@f8001000/cereal@1c0
Product: Platform Specific/Hardware
Version: 2.5
Kernel Version: 5.6-rc4
Hardware: PPC-32
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: PPC-32
Assignee: platform_ppc-32@kernel-bugs.osdl.org
Reporter: erhard_f@mailbox.org
Regression: No
Created attachment 287759
--> https://bugzilla.kernel.org/attachment.cgi?id=287759&action=edit
dmesg (5.6-rc4, PowerMac G4 DP)
The G4 MDD/DP can't quite pick up this device, despite it shows up in the
bootlog earlier.
[...]
Mär 02 17:23:45 T600 kernel: i2c-dev: adapter [uni-n 1] registered as minor 3
Mär 02 17:23:45 T600 kernel: i2c i2c-3: adapter [uni-n 1] registered
Mär 02 17:23:45 T600 kernel: PowerMac i2c bus uni-n 1 registered
Mär 02 17:23:45 T600 kernel: i2c i2c-3: i2c-powermac: register
/uni-n@f8000000/i2c@f8001000/cereal@1c0
Mär 02 17:23:45 T600 kernel: i2c i2c-3: i2c-powermac: modalias failure on
/uni-n@f8000000/i2c@f8001000/cereal@1c0
Mär 02 17:23:45 T600 kernel: i2c-dev: adapter [uni-n 0] registered as minor 4
[...]
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ 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